Leaky RSA Keys | TechSNAP 231

chris

7 years ago

Red Hat highlights how leaky many open source RSA implementations are, Netflix releases Sleepy Puppy & the Mac is definitely under attack.

Plus some quick feedback, a rockin’ roundup & much, much more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

— Show Notes: —

NetFlix releases new open source security tool, Sleepy Puppy

Sleepy Puppy is a delayed XSS (Cross-Site Scripting) vulnerability scanner
In a typical XSS scan, and attacker (or the scanner program) attempts to send a script as part of some user input (the comment on a blog or something like that, or via a URL variable). This content is then shown to that user, and often times, other users. If I can make a bit of my javascript run on your computer, when you visit someone else’s site, I have achieved XSS
There are a number of scanners out there, and they “fuzz test” all of the inputs and variables they can find, and attempt to get some code they submit to be returned to them
This new tool from NetFlix addresses second level vulnerabilities, and beyond
What if an attacker injects the code on the website, and the website mitigates this, but some other application, internal or public facing, also uses the data from the database, and it then ends up being vulnerable to the XSS
Sleepy Puppy is a “XSS payload management framework”, it generates unique code snippets for each injection, so that when a successful XSS happens, it can be tracked back to its source, even if that is outside of the application where the exploit took place
“Delayed XSS testing is a variant of stored XSS testing that can be used to extend the scope of coverage beyond the immediate application being tested. With delayed XSS testing, security engineers inject an XSS payload on one application that may get reflected back in a separate application with a different origin.”
- Show Diagram
“Here we see a security engineer inject an XSS payload into the assessment target (App #1 Server) that does not result in an XSS vulnerability. However, that payload was stored in a database (DB) and reflected back in a second application not accessible to the tester. Even though the tester can’t access the vulnerable application, the vulnerability could still be used to take advantage of the user. In fact, these types of vulnerabilities can be even more dangerous than standard XSS since the potential victims are likely to be privileged types of users (employees, administrators, etc.)”
SleepyPuppy ships with a default set of assessments includes, so is ready to use out of the box

Researchers announce new iOS vulnerability: brokenchain

The vulnerability allows a piece of malware to access the keychain in iOS, and copy your saved passwords and other secret keys
These keys can then be exfiltrated via SMS or HTTP etc
When the malware attempts to access the keychain, iOS presents a dialog asking them user to allow or deny the action, but the malware can simulate a tap on the screen and accept the dialog
Further, some malware seems to be able to cause the popup to appear off screen, so the user never even sees it
“Special-crafted commands can be triggered by malware — or even an image or video — which causes OS X to display a prompt to click an Allow button. But rather than relying on users clicking on a button that appears unexpectedly, the button is displayed very briefly off the edge of the screen or behind the dock, and is automatically pressed using a further command. It is then possible to intercept a user’s password and send it to the attacker via SMS or any other means.”
“Apple has been told about the vulnerability. The company has not only failed to issue a fix yet, but has not even responded to Jebara and Rahbani.”
Ars Technica found that parts of the vulnerability have existed since 2011, and have been used actively
“DevilRobber, the then new threat caught the attention of security researchers because it commandeered a Mac’s graphics card and CPU to perform the mathematical calculations necessary to mine Bitcoins, something that was novel at the time. Less obvious was the DevilRobber’s use of the AppleScript programming language to locate a window requesting permission to access the Keychain and then simulate a mouse click over the OK button.”
“The same technique was being used by the Genieo adware installer to gain access to a Safari extensions list that’s protected inside the Mac Keychain.”
The same day, another group of researchers independently found the same vulnerability
Windows UAC has a bunch of defenses against apps users accidentally accepting or malware auto-clicking the authorization popups. Maybe we need the same in mobile OSes
“Mac users should remember that the technique works only when invoked by an application already installed on their systems. There is no evidence the technique can be carried out through drive-by exploits or attacks that don’t require social engineering and end-user interaction. Still, the weakness is unsettling, because it allows the same app requesting access to the keychain to unilaterally approve it and to do so quickly enough for many users to have no idea what has happened. And by default, OS X will grant the access without requiring the user to enter a password. The Mac keychain is the protected place storing account passwords and cryptographic keys.”
Maybe the solution is to require the unlock code or password in order to authorize access to sensitive areas like the keychain
“I think that Apple needs to isolate that particular window,” Reed told Ars on Wednesday. “They need to pull that particular window out of the window list … in a way that an app can’t tell it’s on the screen and get its location.”

Factoring RSA keys with TLS Forward Secrecy

“Back in 1996, Arjen Lenstra described an attack against an optimization (called the Chinese Remainder Theorem optimization, or RSA-CRT for short). If a fault happened during the computation of a signature (using the RSA-CRT optimization), an attacker might be able to recover the private key from the signature (an “RSA-CRT key leak”). At the time, use of cryptography on the Internet was uncommon, and even ten years later, most TLS (or HTTPS) connections were immune to this problem by design because they did not use RSA signatures.”
“This changed gradually, when forward secrecy for TLS was recommended and introduced by many web sites.”
“We evaluated the source code of several free software TLS implementations to see if they implement hardening against this particular side-channel attack, and discovered that it is missing in some of these implementations. In addition, we used a TLS crawler to perform TLS handshakes with servers on the Internet, and collected evidence that this kind of hardening is still needed, and missing in some of the server implementations: We saw several RSA-CRT key leaks, where we should not have observed any at all.”
“An observer of the private key leak can use this information to cryptographically impersonate the server, after redirecting network traffic, conducting a man-in-the-middle attack. Either the client making the TLS handshake can see this leak, or a passive observer capturing network traffic. The key leak also enables decryption of connections which do not use forward secrecy, without the need for a man-in-the-middle attack. However, forward secrecy must be enabled in the server for this kind of key leak to happen in the first place, and with such a server configuration, most clients will use forward secrecy, so an active attack will be required for configurations which can theoretically lead to RSA-CRT key leaks.”
“Does this break RSA? No. Lenstra’s attack is a so-called side-channel attack, which means that it does not attack RSA directly. Rather, it exploits unexpected implementation behavior. RSA, and the RSA-CRT optimization with appropriate hardening, is still considered secure.“
While it appears that OpenSSL and NSS properly implement the hardening, some other products do not
It seems RedHat discovered this issue some time ago, and reported it to a number of vendors
Oracle patched OpenJDK back in April
“None of the key leaks we observed in the wild could be attributed to these open-source projects, and no key leaks showed up in our lab testing, which is why this additional hardening, while certainly desirable to have, does not seem critical at this time.”
“Once the necessary data is collected, the actual computation is marginally more complicated than a regular RSA signature verification. In short, it is quite cheap in terms of computing cost, particularly in comparison to other cryptographic attacks.”
Then the most important question came up
“Does this vulnerability have an name? We think that “RSA-CRT hardening” (for the countermeasure) and “RSA-CRT key leaks” (for a successful side-channel attack) is sufficiently short and descriptive, and no branding is appropriate. We expect that several CVE IDs will be assigned for the underlying vulnerabilities leading to RSA-CRT key leaks. Some vendors may also assign CVE IDs for RSA-CRT hardening, although no key leaks have been seen in practice so far.”
Crypto Rundown, Hardened:
- GnuPG
- NSS
- OpenSSL 1.0.1l
- OpenJDK8 (after the April patch)
- cryptlib (hardening disabled by default)
Unhardened:
- GNUTLS (via libgcrypt and Nettle)
- Go 1.4.1
- libgcrypt (1.6.2)
- Nettle (3.0.0)
- ocaml-nocrypto (0.5.1)
- OpenSwan (2.6.44)
- PolarSSL (1.3.9)
Technical Record [PDF]