Comment by paaloeye
5 hours ago
> Anyone can intercept any HTTPS connection these tools make.
yeah, it's not ideal but the scale of the threat is way overblown tbh. You have to compromise a lot to be able to make a MITM here.
Let's not treat it like PHP2Shell.
Don't underplay it either though: with a compromised but unrevoked signing cert all it takes is a successful phish, or some problem to allow DNS poisoning (or hack a wireless AP, or …) to direct you to a fake site or (potentially worse as it might be less immediately noticeable and could quietly collect credentials/data for a while) send your automated tools to a malicious API.
It may not be directly exploitable on its own, which is the impression some reports give, but it is a serious hole to leave open especially with the current rate of old security issues being found, as it could be _incredibly_ useful to a malicious actor as part of an exploit chain.
Doesn't affect app bundles though, only *nix commands. This'd be detected pretty quickly, at least by the significant portion of patched devices.
Unless you're clever enough to only poison user agents known to be macOS and CLI. You'd probably get by.
xz-tools was only caught because it had a bug causing slow startups and someone was micro-benchmarking Postgres and decided to dive in further.
2 replies →
Yeah, it increases the attack surface of mitm attacks to your network from the local os level.
It's pretty easy to compromise things like McDonalds or Starbucks WiFi hotspots though, just setup a Pineapple with the right SSIDs and a 5G modem, funnel your target domains through your mitmproxy via the DHCP DNS server you're providing, and that's basically it.
I agree it's not PHP2Shell, but its certainly not being "way overblown" here.
Why would these public network would allow guest hosts to communicate with each other?
I think they're saying you create your own malicious wifi network and people will unintentionally connect to it. This network specifies your malicious DNS server via DHCP, and everything looks secure to the client. I think the main issue with this in practice is that all the major browsers have been updated to not trust these certs.
3 replies →
They wouldn't. A device like the Pineapple broadcasts its own copycat wireless signal and tricks unsuspecting clients to connect to it thinking it's the real one.
Edit: Holy moly we all jumped on this comment at the same time didn't we.
2 replies →
It’s extremely common to see other Macs pop up in the ‘network’ panel in Finder in the independent coffee shops around me. I imagine they’re just signing up for a business plan and using the routers the ISP gives them with a custom SSID and password.
They don't need to, a Pineapple (or anything else that can run a wireless access point, you could do this with a laptop) just needs to advertise the expected SSID and do so with a stronger signal than the official ones for people's devices to connect to it instead of the actual network.
You dont interact with anyone. You just set your own hotspot and people will connect to it.
The near-universal use of TLS and the absurd ceremony we go through to ship root CAs everywhere is all premised on the idea that MITMs are not terribly difficult.
The entire reason one can rest easy as they connect to their coffee shop's WPA2-PSK network, is the security provided by TLS.
And if you don't think an ISP or agency would abuse this if it could be done undetectably then you haven't been paying attention these last 20 years (hence why DoH is now a thing).
Even a simple rouge AP is enough to become a MITM for this.
Why is the color of the access point relevant?
You can take your laptop to a busy place, make a "free wifi" hotspot that runs everything through mitmproxy and you can steal everything.
I think "everything" is an overstatement. Browsers included the compromised intermediates in their CRLs within hours of disclosure.
So this isn't like Firesheep [0]. Yes, there would be vulnerable traffic, like the git client this thread is discusing, but it's not "everything"
[0] https://en.wikipedia.org/wiki/Firesheep
If you see a developer using git on a Mac laptop in a coffeeshop, you can intercept that and gain their repo and probably password hashes pretty easily.
> You have to compromise a lot to be able to make a MITM here.
This is just an argument against TLS in general. Use plain http if you believe this.
Appealing to complexity is always fun. Just throwing "a lot" in there for good measure and you won't have to think about practical security implications.
php2shell was overblown perhaps but this is being blown quite correctly
The TLS trust chain is the last defense against MITM attacks. The prevalence of MITM attacks is in fact the very reason TLS exists. I'd say it's a lot worse than PHP2Shell because it doesn't only affect poorly maintained servers, but potentially ALL credentials and secrets a user sends over a compromised network with compromised CAs on their device.
The window of opportunity to MITM has passed. If you attempted an MITM from an easy vantage such as telco, ISP, or public wifi you'd be trivially detected as a significant portion of devices are patched, including on these unpatched macs as only the *nix commands are affected and not app bundles.
This is way worse than PHP2Shell in scope of impact and its effects will stick around for much longer. Well, as long as the validity period of the compromised certs anyway
If you hijack the DNS, the laptop can be pwned quite easily. Think of all the coffee shops with unprotected routers out there.
> You have to compromise a lot to be able to make a MITM here.
It's trivially easy to mount an ARP spoofing attack. I did that at school two decades ago and on-the-fly rewrote <img src=...> to hardcore porn images for funsies.
mitmproxy [1], a popular toolkit for making that easy, has the option to generate "eMudhra" certificates on the fly now.
It is trivially easy to compromise things, all you need is physical access to the network.
[1] https://news.ycombinator.com/item?id=50189232
I don't know why you're downvoted, any public wifi access point in a shop could be compromised and users would never notice.
Client isolation is very common on wireless and wired LANs these days in enterprise and guest network environments. You also have tools like dynamic arp inspection to block poisoning attempts via the network switch.
If you get past all of that, you still need a victim who is actively using a cli tool on macOS using https.
It’s not impossible, but the conditions are much more specific than those needed to inject porn into a webpage on a poorly configured school network in 2006.
…and yet it doesn't help at all if a laptop sees an AP with strong signal in its vicinity and connects to that instead of the meticulously configured AP that sits behind the counter with a slightly weaker signal.
2 replies →
> all you need is physical access to the network
Yeah that's not so much "trivially easy"
Do you have a cell phone? Do you use Wifi? Do you use an ISP who, in the last few decades, has performed any form of interception or traffic-tampering?
I hazard that the answer to all three of those is "yes".
> all you need is physical access to the network.
yeah, it's trivial to punch somebody in the face in the morning, all you need to do is to be by their bad in the morning when they are waking up.
You don't have physical access to the network, doesn't mean other actor aren't here. Working for providers, governments, or being able to impersonate them. This is a serious issue, it shouldn't be downplayed.
If you think it's not that important, it becomes a critic about TLS and basically saying that ciphers for web traffic are useless.
Public wifi hotspots tend to give you that opportunity. Large commercial hotspots have inter-client communication blocked, but your average coffee shop style network? You're lucky if it even is an isolated VLAN from the shop's cash register lol.
Have you never used wifi at a coffee shop?
Physical access to networks isn't that hard to come by.
11 replies →
[flagged]