It just frustrates me that I have brought this up multiple times, wondering why we are paying to do this training and then we can't actually do the training.
Like it would be one thing if the URL then just had the full URL in it and we could still see where it was going. But no, it is a completely obfuscated URL.
The worst part is, it isn't like it takes you to a page to verify you actually want to go to this link. It just takes you right there assuming you are on a browser that has approved that it can open links from your email.
I really really want to do know what good this does AT ALL besides likely checking some checkbox for something.
In their defence, curl isn't completely benign in this case. You just confirmed to the person who sent you the link that your email address is valid and reaches a person.
Also, there's no reason to believe that you're curling the same redirect as you get from clicking the link.
There's this thing compromised webservers do where, if you type in www.example.com into your browser, and go straight there, you get the normal web page. If you click a link from Google, and have a google.com referrer in your request, you get a little bit of JavaScript included that that redirects you to another site to buy herbal remedies or fake watches or whatever.
If you are the business owner and go directly to your home page to see what's what, you think everything is fine; if you are a tech trying to debug it and you curl the webpage, everything looks fine [unless you curl with a referrer set]. You probably think Google has the wrong URL or something.
Likewise -- I don't know what a click-through from an email client looks like, but it wouldn't surprise me if there's an identifiable header or referrer or something. If that's the case, you could write your malicious URL shortener to redirect you to www.example.com/ if you curl it bare, or www.exam.ple.co/m/ if you have the redirect header. Curling the URL in question doesn't necessarily prove it's safe to click on.
Not that depressing. Audit your current web server configurations. You can dump the in-memory representation generally. Diff it with the on disk representation, and bam. Instant canary. If you're worried about a tainted on disk version, do the integrity check against a version invisible to the outside net.
Also, redeploy configs and reload on the regular, and you essentially force an actor to get an active foothold on your system to re-exploit and persist the compromise.
It's not impossible to defend yourself against these types of things if you're vigilant. You can also script your deployment to the point where you can nuke your site from orbit with minimal impact, and reestablish it. It's all about your threat model.
But yes. Things like nginx, apache & co are remarkably comprehensive in the things you can configure them to do. I find that my most dreaded part of standing up a new service is inevitably writing the load balancer/host web server configs.
You're completely right of course, and I hadn't considered that.
However, there's apparently people scraping and reselling (or bribing employees, dunno) corporate directories. In my case everyone has firstname.lastname@corpo.com, so judging by the high volumes of creepy ass, targeted corporate spam I get on my work mail... this is hardly a public secret.
Not necessarily? What's stopping an email server from probing links in all incoming emails regardless of valid recipient for malware analysis purposes?
In fact, I would be surprised if, e.g., Gmail, does not do this.
