I was kind of hoping this paper would do a bit more but it was interesting regardless. The idea here was to apply standard Natural Language Processing techniques to detect vulnerabilities in code. My initial reading was that it wouldn’t work, but they did appear to have some success with this approach. Achieving 90+% accuracy in detecting the trained CWEs. Unfortunately the dataset used (https://samate.nist.gov/SARD/) does not reflect real-world source code, which is something I’d have liked to see this tested against. It is interesting though that despite the differences between natural language and programming that the training was still effective.

This is another one of those, IDE/tooling doing more than you expect issues. In Rust you have #[proc_macro]s which are functions that are executed at compile time. The issue here is that the Rust-Analyzer, a common Language Server protocol implementation (used by the Rust plugin on VSCode) will expand these macros when analyzing the code also, creating an opportunity to, as in this PoC’s case, exfiltrate data.

The vulnerability itself is in ExifTool, in parsing DjVu archive metadata it will parse the token, do some validation on it to make sure its safe and call eval on it to parse the C-Style string escapes within the string. The problem is the validation trips up on handling an escaped newline, ignoring the newline character and thinking the next character is the escaped one. Leading to the case where a backslash followed by a newline then a quote will be treated as though the quote is escaped, allowing for an unescaped quote to be injected and and arbitrary perl to be added to the eval string.

The vulnerability here is in libterm.js as used by AWS CloudShell. When handing the escape to get the Termcap/Terminfo string (+q) it’ll reflect the parameter right back into the respond. The problem there is the response is sent back via .send() which ultimately leads into the terminal’s input so by adding a newline into your param an attacker can escape the escape code and inject their own commands. An attacker in this case just needs to control output to the terminal, this can be from a curl or a cat or any other command.

Kind of a neat attack to track users across browsers. Potentially fairly loud for most users though. The issue stems from all the custom scheme:// handlers applications can register, it make it possible to determine if an application (that registers such a handler) has been installed based on how the browser reacts when trying to open a url with the custom scheme. You can use this to enumerate several applications and create a unique identifier.

For Firefox, Safari and Tor Browser opening the custom schema would result in either an internal error page (when not registered), or an about:blank page (with a prompt to accept opening the application). Same Origin Policy would allow the opener to access the about:blank page but not the error page this could be used to detect whether or not the application was installed. Tor Browser in particular though would hide the prompt, and popups automatically. This allowed for a more silent attack using an iframe.

On Chrome there was some extra protection as you cannot launch an application without user interaction. This could be bypassed by opening a PDF in the page first, opening a PDF disabled the restriction.

Crypto-attacks are not my strong point, so I might be missing some nuance to this one. The first important concept is flash loans. These are smart contract backed loans, basically you can borrow money like a loan from a provider, the condition being that you must return the loan+fee/interest in the same transaction as you take the loan out. It enables arbitrage where you simultaneously purchase the same asset in multiple markets, taking advantage of a pricing difference. You get to pocket the profit, however it can also fund capital-intensive attacks like this.

FEI is a stablecoin, it tries to algorithmically stabilize its own price Minting new coins at $1.01 each whenever the price goes above that.

Uniswap, a decentralized exchange used to change between various crypto coins. You can swap on it, or you can be a liquidity provider, basically just deposit a coins into a pool at a particular rate. Liquidity should only be deposited at the current rate. The reserve rate should also be looked up before submitting the transaction and not as part of the transaction.

Which is where part of the problem comes in, FEI will sell newly minted coins on its “Bonding Curve” contract, the funds are held there until allocate() is called which then adds the funds to the Uniswap pool. Allocate looks up the current market rate to dump the funds into the pool with 100% slippage (price movement) allowed. Allocate does try to determine that its not being called within a contract, but the check fails to account for being called within a constructor which allows an attacker to cause the allocate call to happen during the transaction.

The full attack being that an attacker can flash borrow ETH, use some to purchase FEI on the Uniswap pool, driving up the market rate. Then purchase Fei from the bonding curve at $1.01. Trigger allocate which dumps the ETH into the ETH-FEI Uniswap pool at the current (artificially elevated market rate), and then sell back the purchased FEI at the elevated price and payback the flash loan, keeping the profit.

This is a surprisingly simple reflected XSS on instagram.com. Just a next= URL parameter that is reflected into an href, you can include a javascript: target for the url. However, on-page javascript will rewrite the onclick handler which rewrites it. Middle clicking however will trigger it.

D-Link attempted to provide some protection against brute-force by delaying the response for three seconds on a bad login. The problem was that the delay only happened on a bad login meaning, so there was a clear timing difference between a good and bad login attempt. It was also only delaying the one connection, so reconnecting once you knew it was bad and trying again worked to bypass the defense.

Plenty of background here, both in terms of software, architecture, and testing environment. Probably worth checking out if you want to get into car hacking. The vulnerabilities covered are in the HiQNet protocol. Three of them are a count field not being validated, allocating a fixed buffer, and reading an “unlimited” count of things into them. One was an unchecked length field in the proto header, it would use this to skip in memory to the next message, so an attacker gets an OOB read out of it. The most interesting vulnerability was a type confusion in MultiSvSetAttributes where you can set multiple attributes of an Sv object. For each attribute id you also provide a new type and new value. It’ll dereference the memory and treat it as the new type setting its default value before writing the new value to it. Because it doesn’t actually convert or otherwise deal with changing types, if the new type is larger than the old type you’ll get a potential overflow from the confusion.

They also go into exploiting this, using the vulnerability to corrupt a string’s length field to get a read primitive and leak addresses for ASLR defeat, and corrupting a vtable entry for code execution.

12 CVEs, a few fundamental design issues, and some implementation issues. The implementation issues generally just removed some restrictions on abusing the design flaws making them more practical. The interesting part are the design flaws though.

First is in frame aggregation. As it is inefficient to send many small frames over the air a device might aggregate multiple frames into a single WiFi packet. When this happens a flag is set in the header indicating aggregation happened. The problem is that a MitM can manipulate this flag as it is not protected from tampering. So, with attacker controlled TCP data (like connecting to an attacker controlled server) a MitM can flip the flag on the WiFi packet and have its data treated as though it was multiple frames aggregated together. Enabling the injection of packets, such as an ICMP Router Advertisement providing a new malicious DNS to be used.

Second is an issue with the fragment cache. The note here being that fragmentation is rarely used except on WiFi 6. The issue being that the cache is not cleared across connections of the same MAC. So an attacker can connect, spoof their MAC to match the victim, and send a fragment to the router to be cached then disconnect. WHen the victim connects, and potentially sends their own fragments it’ll join the new packets with the attacker’s packets, allowing for exfiltration or injection of packets.

Third is the “Mixed Key” attack. This is where the fragments will be decrypted and reassembled even if different keys were used when sending them. The attack scenario being say a victim sends two packets, A and B, a MitM drops B, the victim refreshes their session key, and sends two more packets A2 and B2, the MitM dropping A2 this time. The packet will be reassembled as A and B2. Creating a scenario where an attacker and mix-and-match packets to create something more interesting. The author admits this is a fairly academic and unrealistic attack but still worth considering as someone might make it practical in the future.