Real Hacks are not easy
Published by marco on
Most of us know “hackers” from the media—either the news media, television shows like Mr. Robot, or movies like Swordfish. But the fast and easy way of hacking presented in the media actually does a disservice to how incredibly clever these hacks really are.
Less-complex techniques—like guessing or brute-forcing passwords—still work super-well. And you’ve always got social engineering hacks, like just asking someone for their credentials in an official-sounding way. But real, technical hacking involves getting to know a system’s dependencies and memory layout and runtime environment even better than the original programmers ever did.
Note: Both of these issues have been fixed, but it’s fascinating to read about how they did it. It really offers insight into what to avoid doing in your own code (e.g. do not open a
NSO’s zero-click iMessage exploit
The first article A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution by Ian Beer & Samuel Groß (Google Project Zero) is a longer read, but I found it fascinating how many pieces they needed to chain together in order to hack iMessage—which they managed to do with a 0-click exploit. Just sending a message to the phone with a specially coded picture in it was enough to trigger code to run automatically that, unfortunately, ran before the sandbox. It overwrote memory in a controlled manner—making sure not to crash the app—and set up its own virtual machine to execute arbitrary code, which it then did.
“The bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream. It’s pretty incredible, and at the same time, pretty terrifying.”
VSC with WSL opens an unprotected WebSocket
The second hack is less wide-reaching, in that it would apply only to certain software developers using certain tools, which automatically limits the audience. The RCE in Visual Studio Code’s Remote WSL for Fun and Negative Profit by Parsia (Hackerman's Hacking Tutorials) describes, in relatively easy-to-follow detail, how the author found a pretty big hole in the remote-debugging support for Visual Studio Code using WSL (Windows Subsystem for Linux).
In order for it to work, the user had to approve opening the port in the Windows Firewall, but it was kind of unconscionable that it opened such a big hole. The developer could be forgiven for thinking that it was OK to approve the request, given that they had just initiated an action to debug between machines. Approving a firewall in that situation is not only expected, but incredibly common. The dialog box doesn’t provide an information about which ports it wanted to amend.
The Local WebSocket Server
Every time you see a local WebSocket server, you should check WHO can connect to it.
— TL;DR WebSockets
WebSockets start with a handshake. It is always a “simple” (in the context of Cross-Origin Resource Sharing or CORS) GET request so the browser sends it without a preflight request.
These bugs can be chained:
- The local WebSocket server is listening on all interfaces. If allowed through the Windows firewall, outside applications may connect to this server.
- We can spawn a Node inspector instance on a specific port. It’s also listening on all interfaces. External applications can connect to it.
- If an outside app or a local website can connect to either of these servers, they can run arbitrary code on the target machine.