I told Joshua Aaron, developer of ICEBlock, that he was running a vulnerable version of Apache on his server. He ignored my vulnerability report and blocked me, and his service is still vulnerable today https://micahflee.com/iceblock-handled-my-vulnerability-report-in-the-worst-possible-way/

@micahflee Please note that installing the latest Ubuntu security updates for Apache httpd does not necessarily upgrade Apache to the latest available version. Instead, security fixes are typically backported to the version included with the distribution. As a result, the displayed version remains unchanged.

For example, even after fully updating Ubuntu 22.04 LTS, the Apache version shown in the Server header still appears as 2.4.52, despite being patched with the latest security fixes.

@h0ng10 @micahflee This is a fairly common mistake too and causes a lot of bullshit work for security teams. A banner string (*especially* in case of Apache HTTPd) doesn't mean anything, so unless you can demonstrate the presence of a vulnerability this is nothing (aka PoC||GTFO).

(edited) In addition the cited CVE-2024-38476 requires a *malicious backend* to be exploitable:

https://devco.re/blog/2024/08/09/confusion-attacks-exploiting-hidden-semantic-ambiguity-in-apache-http-server-en/

@micahflee
For someone just trying to help their neighbors. I want to make sure I understand that I should advise them to not use the app and let others in their community know?

I've read your other blogs about the ecosystem problems with the app and I this should be an, "Oh, duh." Sort of thing but I want to be very sure what I'm communicating before I send a message to folks who are already scared and not technology saavy.

Its more that I don't have experience with how to help folks in this situation and I want to make sure I'm not knee jerk doing something that compounds other issues they are facing that I'm ignorant to. Thank you for your and anyone else's patients in educating me.

@micahflee you did the right thing.

@micahflee Can you clarify whether you have any reason to believe it's actually vulnerable to anything? Most of those vulns only affect wacky configurations, commercial hosting environments where the customers are untrusted and may be running malicious serverside code, and particular types of web application stuff (vs static content).

Personally I tend to look unkindly on vuln reporters who assert that something of mine is vulnerable based on some checklist for the version they find running rather than actual analysis.

@buherator @h0ng10 @micahflee

my general policy when I'm configuring ASF httpd is to turn off all of the telemetry that is exposed by default in distribution-provided configurations; there is no benefit to it being visible.

@VulpineAmethyst @h0ng10 @micahflee This is a totally different question (even assuming the server is not intentionally lying...), please don't go down this rabbit hole (I've been there a bunch of times and it doesn't lead anywhere).

Yeah, an unauthenticated nmap scan getting back a banner header is essentially worthless as an actual vulnerability detection. I get beg bounties for that shit constantly. And a lot of times it's just shit on the load balancer anyways.
@dalias @micahflee

@micahflee there’s a lot to say, actually: https://www.shodan.io/host/69.164.211.16

@patpro @micahflee
Dude has more brands than a stolen cow.

Furthermore, that particular CVE only creates a vulnerable configuration if they're running Apache httpd with mod_rewrite or mod_proxy. Which means if you aren't running those modules, that vuln isn't a vuln. LOTS of vulns with big scary numbers aren't actually a vulnerability unless you're using the software with specific configurations enabled.

For fucks sake, at least read the goddamn CVE links.

https://nvd.nist.gov/vuln/detail/CVE-2024-38476

https://httpd.apache.org/security/vulnerabilities_24.html

I'd block you too if you showed up smearing my app with no more evidence than a low effort nmap.

@dalias @micahflee

It's a valid discussion of whether the app is useful or not, but goddamn...
@dalias @micahflee

@JessTheUnstill @micahflee Exactly. I ignore "vuln reporters" who copy & paste drivel from scanners, and block if they keep being annoying about it.

@micahflee seems to be up to date now!

@compi it worked!

@JessTheUnstill can't tell if "beg bounties" is a typo or a funni play on words

@dalias @micahflee

@micahflee I haven't followed this closely so I'm probably missing a lot of context, but I see people being quick to call him a scammer or some kind of malicious actor but I just see him as well-meaning but incompetent.

Update: He has updated Apache to 2.4.65! Public disclosure after getting privately ignore works, it turns out

@micahflee public disclosure usually works, period. It's kind of you to have tried to notify him privately, though.

This guy's bad-faith behavior make me seriously question his motives. If I wanted to gather a bunch of information on people who oppose the incoming fascist regime and their footsoldiers, making a half-assed app that purports to help resist them, getting it running on a bunch of peoples' devices, and then collecting information from those devices would be one hell of a way to do that.

If you don't care about your users' privacy, you don't need to worry about security.

@micahflee how hard is it to have a cronjob that auto update/upgrade everything.

Pretty hard if you actually want your environment to not break randomly when an update goes bump.
@lfzz @micahflee

They definitely do not have any reason and this is a bad-faith post for clicks. If you read the post they did zero followup work to confirm any vulnerability and just spent all their time instead complaining about being ignored. Instead of doing anything constructive, this person just bullied a stranger based entirely on a scan banner.

We have this automated where I work; it's called Nessus, and everyone hates it, because like this person, it lacks context, doesn't understand the things it alerts on, and we'd be better off without it.


CC: @micahflee@infosec.exchange

@compi @micahflee bug reporting ftw! I have some sympathy for the developer - getting 'unflattering' feedback is hard to hear when your intentions are well meaning. But otoh - a mistake could literally mean people disappear, so patching is the security floor - in reality they need a much higher standard, and even then it is a high risk endeavor.

@micahflee “And, as I showed you before, just one of the vulns is CVE-2024-38476, which you can read about here” — LMAO, I’m 100% sure that even you haven’t read it. It’s unrelated vuln with very complex and unrealistic exploitation scenario

@micahflee In what kind of universe you even seen an infrastructure that consists of “trusted and valuable” nginx proxy that being tried to pwn by “malicious backend application” 🤦🏻‍♀️🤦🏻‍♀️🤦🏻‍♀️

@micahflee Or it was easier to configure the server to lie about the version than put up with your harassment.

@pndc what harassment?

@micahflee honestly nice reminder for me to check all of my installs, admittedly something I’m bad at keeping up with 🫣

@troy you can automate it with something like https://linuxblog.io/how-to-enable-unattended-upgrades-on-ubuntu-debian/, or even just cron jobs

@micahflee One thing that is devaluing disclosures is the barrage of "I discovered an XSS in your website" noise so sometimes it's hard to sift through all the dross.. I'm not trying to justify any behavior, just explaining how I sometimes feel with situations like this :)

@johnmclear I very much doubt you've had a situation like this.

He gave a talk where he promised perfect privacy and security, and also made it clear that he doesn't know what he's doing. He had several people privately reach out to him offering help in all sorts of ways, including things like security audits, and he rejected them. Before my first blog post, I told him that one of the things I noticed was his server had a vulnerable version of Apache, and I published a blog post. I gave him warning again that if he didn't update his Apache I'd write another blog post after a week. Then, after he didn't update Apache, I told published, and he finally did.

@khm @dalias I didn't try confirming it was exploitable because his ego is so fragile he'd probably want to sue me for it. And he updated to a new version of Apache (without known critical CVEs) after I published my post, btw, so in the end I helped him

@micahflee @khm I didn't see any legitimately critical CVEs there.

not to mention the fact, as mentioned, it's not possible to ascertain which CVEs apply based on an arbitrary version string or nmap fingerprint. now this jerk is victim-blaming the person who was bullied into reinstalling software because some clout-chasing beancounter needed something to tiktok into a camera about.

like of course this dude had to do something, he had some twerp with a basement full of followers shit-talking him with zero evidence and then shit-talking him again for correctly blocking an ignorant gadfly.

this whole thing is an embarassment and it's the worst kind of pedantic bullshit "cybersecurity" that helps nobody but a self-aggrandizing parasite.

CC: @micahflee@infosec.exchange

@micahflee @khm @dalias

... his ego is so fragile he'd probably want to sue me for it

Leaving aside whether or not this is actually true, I'd like to know why you already thought this before even contacting him. After all, most security researchers check if the suspected vulnerabilities are exploitable before reporting them, not after.

@khm @dalias @micahflee

Just to be clear:

1) You think he should've conducted an unauthorized pen test against the server to confirm the vulnerability?

2) You think "You seem to be running Apache httpd 2.4.57 [...] this version of Apache has multiple critical CVEs which could take over your server" is "bullying"?

3) You think an enterprise would be better off not using a tool like Nessus to alert on potential vulnerabilities that should be reviewed?

lol. "supercomputing engineer" lmao

@jazzhandmedowns @khm @micahflee I can't speak for them, but as for me:

1. No, nobody should conduct an unauthorized pentest, but you should not publicly claim someone is vulnerable to random CVEs that almost surely don't apply to them.

2. Leveraging CVEs that almost surely don't apply (which can be determined easily by actually reading them rather than just reading the self-promotional "CRITICAL!! OMG!!" tagging) against someone to claim they're irresponsible and putting their users in danger certainly sounds like it comes close to "bullying".

3. How an enterprise deems it most efficient to manage their security is their business. If they like not having to worry about subtleties and just being able to check off boxes based on version numbers, yay I guess. But that doesn't entitle anyone to set this policy for others. Working with backported patches (esp using trustworthy distros that did that for you) is generally a lot safer than constantly chasing latest versions.

@micahflee

Yet another reason to avoid besides the traffic analysis.

@JessTheUnstill @dalias @micahflee vendors we pay for that do "vulnerability scans" at scale are extremely guilty of this shit, so much so that I have a Confluence page of responses for our different public sites.

WAF / firewall / CDN / load-balancer / proxy / server just returns lies because we know better / etc

It’ll be the latter. @dalias @JessTheUnstill @xyhhx @micahflee

https://www.computerweekly.com/feature/Dealing-with-the-challenge-of-beg-bounties

@BenAveling @dalias @xyhhx @micahflee

1. Nobody said that. My assertion is this dipshit didn't have sufficient evidence for anything more than an email worrying about the Apache version. Once. Not a series of histrionic blog posts about it.

2. Nobody said that. It was the rest of the behavior that constituted bullying. You're going to have to come up with a better approach than "inaccurately summarizing my arguments" to get anywhere here.

3. Yes, I do, because Nessus as deployed at many agencies is a box-checking exercise used in place of proper security engineering. I can provide dozens of real-world examples of poorly-configured Nessus scans doing more harm than good, but I don't think you're making a good-faith argument here, so it's probably not worth my time.

lol. "easily verifiable claims" lmao

CC: @dalias@hachyderm.io @micahflee@infosec.exchange

@JessTheUnstill @dalias @micahflee

I tend to agree. More testing or detail needed, especially if there's exploits for it kicking around out there, though that gets into grey area.

For whatever it's worth though, mod_proxy and mod_rewrite are probably the two most commonly enabled modules after SSL. Many distributions shipped with them on by default for years and I'd wager the vast majority of modern deployments of Apache have them on.

@fennix @JessTheUnstill @micahflee Most of the "vulns" are of the form "if you run a malware webapp on Apache, it can do things you don't want to the Apache server". Which is like, "duh".

Others are things that only affect very specific setups with specific kinds of dynamic content.

I didn't see any that would affect a setup that's just serving static content or where you trust all the server-side code you're running on it.

just for shits and giggles, I'll give a sterling example regarding this kind of bullshit being problematic in an actual working environment.

normally, when one purchases a RHEL license, you purchase a license for the major version. You're expected to roll along from e.g. 9.2 -> 9.3 etc. However, for precisely-engineered things like supercomputers, this is not a good idea, because it subjects you to performance regressions that aren't tested for in the mainline distro. Red Hat's solution to this is to offer "EUS" licenses -- extended update support. This means you can stick on e.g. 9.2 far longer than the normal contract, because Red Hat does the work backporting security patches. What doesn't change is the upstream version numbers tagged on the packages.

For an inexcusably long time, Nessus didn't support this unless you had a full-time person on the backend identifying the package versions (including release and/or build versions), which almost nobody does.

The result? You follow all the STIGs, you've got vendor security support, your node bringup health-check runs POC code to confirm known vulns are covered, and you still get angry emails with six hundred false positives from whatever peabrain is lazily running the Nessus scan. Now, instead of doing actual administration, you have to write memos, rehashing the arguments you made last time, because the kind of "security engineer" who hits the panic button behind some bullshit lasts about six months on the job, but the badly-configured Nessus deployment outlives them to be run by the next box-checker to warm that seat.

This is exactly the same scenario. Some low-information box-checker gets angry because nobody listens to their baseless whining. The only difference is it's happening on some asshole's blog instead of in an Outlook thread with everyone's managers CCed.

CC: @jazzhandmedowns@mastodon.sdf.org @dalias@hachyderm.io @micahflee@infosec.exchange

@khm @dalias @micahflee

You criticized Micah for having done "zero followup work to confirm any vulnerability" but by what means are you suggesting he do so?

This isn't the agency you work for; it's some rando's app. Sure, it's POSSIBLE that his Apache had a backported patch, but it's JUST AS POSSIBLE that he doesn't know how to secure his shit.

You're assuming it's the former because you're projecting frustrations from your JOB onto a wholly unrelated scenario—that's some sadfuck shit!

I'm not suggesting any means by which he follow up, because it's not his fucking place to follow up. That's why I said what I said -- the shit he found warranted one friendly email and no more. The complete lack of information about the operating environment possessed by Captain Blogsalot is a Very Large Signpost that this rando is not the person to publicly pillory some other rando. That's my entire point! It doesn't even matter who is right, because there is nothing here to be right about.

I'm assuming it's the former because I have no reason to believe it's the latter. What you're deriding as "frustrations from my JOB" is what is known in the industry as "professional experience," which is the arcane lore that you asked about and which allows me to recognize when some blogger fuck is sticking his nose where it is not helpful. I hope this context brings you peace.

CC: @dalias@hachyderm.io @micahflee@infosec.exchange

@khm @dalias @micahflee

So your initial criticism was that he "did zero followup work to confirm any vulnerability"

but now you're saying "it's not his fucking place to follow up"?

Which one is it?

Given your anger management issues and winning personality, it's becoming clearer that the security engineers at your agency are using nessus scans just to bust your balls, lol

My initial criticism was "zero followup work," thus rendering the blog posts baseless fearmongering, and now I'm saying it's not his place to follow up, which is consistent because the blog posts are a bad idea which should not have been posted to begin with.

Not sure why this is confusing for you, but given that you think you can read emotions through social media posts, I'm sure a lot of things are confusing for you

CC: @dalias@hachyderm.io @micahflee@infosec.exchange

@khm @dalias @micahflee

Oh dear, you're unable to read emotions through social media posts?

And you think that's the normal experience of most people?

There's something you really need to know about yourself, but honestly, I shouldn't be the one to tell you.

I presume the deflection indicates I've got through to you and you finally understand my argmuent. Glad we got there in the end!

CC: @dalias@hachyderm.io @micahflee@infosec.exchange

@khm @dalias @micahflee

counterpoint : don't assume malice for what can be explained by ignorance..

in a world with unfettered access to massive stores of knowledge, most ignorance is malicious

CC: @dalias@hachyderm.io @micahflee@infosec.exchange

@d_olex @micahflee cloudflare i guess?

@Li @micahflee I meant self-hosted infrastructure like the one that author of the post tried to scan: it looks like potential attacker can't even reach this vulnerable code on their setup

@d_olex @micahflee oh yeah, i dont disagree this CVE is probably irrelevant .. but it is an issue generally* and probably doesn't hurt much to update

@Li @micahflee IDK, looks like “security theater” to me

@Li @micahflee TBH this whole situation looks like “actors of security theater condemning other people for participation in activism theater” which makes it even more ironical

@JessTheUnstill @dalias @micahflee
On a slight tangent he should probably root around in his config to enable TS 1.3 (and get rid of the weaker ciphers) and possibly hide the Apache server version etc: "Apache/2.4.65 (Unix) OpenSSL/3.5.1"

Not a huge deal https://www.ssllabs.com/ssltest/analyze.html?d=iceblock.app

Well, from other stuff in the thread looks like he got cyber bullied into making everyone go away with server hardening at least from unauthenticated scanning POV. But tbh, without more evidence than banner headers, this is seriously poor form from @ micahflee . If you're going to whip up a lunch mob, get better evidence.

@davep @dalias

@JessTheUnstill @dalias Yeah, not cool.