Most of us know "hackers" from the media---either the news media, television shows like <i>Mr. Robot</i>, or movies like <i>Swordfish</i>. 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, <i>technical</i> 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 <i>not</i> open a <c>WebSocket</c> on <c>0.0.0.0</c>). <h>NSO's zero-click iMessage exploit</h> The first article <a href="https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-into-nso-zero-click.html" author="Ian Beer & Samuel Groß" source="Google Project Zero">A deep dive into an NSO zero-click iMessage exploit: Remote Code Execution</a> 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 <i>before</i> 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. <bq>JBIG2 doesn't have scripting capabilities, but when combined with a vulnerability, it does have the ability to emulate circuits of arbitrary logic gates operating on arbitrary memory. So why not just use that to build your own computer architecture and script that!? That's exactly what this exploit does. <b>Using over 70,000 segment commands defining logical bit operations, they define a small computer architecture with features such as registers and a full 64-bit adder and comparator</b> which they use to search memory and perform arithmetic operations. It's not as fast as Javascript, but it's fundamentally computationally equivalent. The bootstrapping operations for the sandbox escape exploit are written to run on this logic circuit and <b>the whole thing runs in this weird, emulated environment created out of a single decompression pass through a JBIG2 stream.</b> It's pretty incredible, and at the same time, pretty terrifying.</bq> <h>VSC with WSL opens an unprotected WebSocket</h> 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 <a href="https://parsiya.net/blog/2021-12-20-rce-in-visual-studio-codes-remote-wsl-for-fun-and-negative-profit/#fnref:1" author="Parsia" source="Hackerman's Hacking Tutorials">RCE in Visual Studio Code's Remote WSL for Fun and Negative Profit</a> 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 <i>such a big hole</i>. 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. <bq quote-style="none"><b>The Local WebSocket Server</b> Every time you see a local WebSocket server, you should check <b>WHO</b> can connect to it. <iq>WebSocket connections are not bound by the Same-Origin Policy and JavaScript in the browser can connect to local servers.</iq> <i>--- TL;DR WebSockets</i> WebSockets start with a handshake. It is always a "<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests">simple</a>" (in the context of Cross-Origin Resource Sharing or CORS) GET request so the browser sends it without a preflight request.</bq> <bq quote-style="none">These bugs can be chained:<ol>The local WebSocket server is listening on all interfaces. If allowed through the Windows firewall, outside applications may connect to this server. <b>The local WebSocket server does not check the Origin header in the WebSocket handshakes or have any mode of authentication. The JavaScript in the browser can connect to this server. This is true even if the server is listening on localhost.</b> 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.</ol></bq>