Virtual Private Surveillance | TechSNAP 248

Posted on: January 7, 2016

Posted in: Featured, TechSNAP, Video

Comment on This Video

Share This Video

Embed This Video

Virtual Private Surveillance | TechSNAP 248

We break down the Bicycle attack against SSL, the story of Brian Krebs’s PayPal account getting hacked & the scoop on the Juniper Saga.

Plus some great questions, our answers, a news breaking round up & much more!

Thanks to:


DigitalOcean

Ting

iXsystems

Direct Download:

HD Video | Mobile Video | MP3 Audio | OGG Audio | YouTube | HD Torrent | Mobile Torrent

RSS Feeds:

HD Video Feed | Mobile Video Feed | MP3 Audio Feed | Ogg Audio Feed | iTunes Feed | Torrent Feed

Become a supporter on Patreon:

Patreon

— Show Notes: —

The Bicycle Attack against SSL/TLS

  • Security Researcher Guido Vranken has published a new attack against all versions to SSL/TLS
  • “While the sound configuration of both endpoints of a connection is understood to prevent the decoding from ciphertext to plaintext without having access to the private key(s), transactions conducted over a channel embedded in TLS leak various types of information.”
  • “A lot of research has been performed on how to stack up these different ‘knowns’ in order to meticulously reconstruct the user’s actions, given that the encrypted streams are known to an observer who is or has been listening in on the ‘secure’ transmission between two endpoints.”
  • “In this paper I will show that for a presumably large subset of web applications, it is easy to infer the length of parts of the plaintext, or certain attributes thereof, from a recorded stream of encrypted messages. Having access to the private key is not necessary. In fact, the actual ciphertexts embedded in the stream are irrelevant to the deduction, and entry-level arithmetic suffices.”
  • The attack can allow a passive listener to determine the length of your password, significantly reducing the effort required to brute force crack the password
  • The attack takes advantage of the known characteristics of HTTP transactions (although it could be used against other protocols), to determine the length of a specific field
  • In a regular HTTP form post, when a user is logging into a website, the post data consists of the form fields encoded as a string
  • Something like: username=allan&password=correcthorsebatterystaple&sub=Login
  • When the form is submitted over an encrypted connection (HTTPS), the text is not visible, however the length of the payload is known
  • If the length of the form field names, and the username are known, then the length of the password can be determined
  • So, this attack requires knowing the targets username, although that is not a problem during a targeted attack
  • Most of the other information can be determined by the attacker by logging into an account on the site themselves
  • The attack requires knowing things like the target user’s browser user-agent string, but this can be determined by them visiting any unencrypted website.
  • The lengths of other headers, like user-agent and cookie, can be calculated by looking at requests to other known assets on the site, like an image or css file that is loaded by the login page
  • With all of this information, the length of the packet, less the lengths of the known fields, leaves you with the length of the targets password
  • This significantly reduces the complexity of a brute force attack
  • If you know the password is exactly 12 characters long, you do not have to try every possible combination of 10, 11, 13, 14 etc character long passwords.
  • Because of the nature of this attack, it also works against previously recorded sessions, even from years ago
  • “It may also be executed on a larger scale on TOR exit nodes, VPN’s, proxies and other Internet traffic conduits in order to detect weak or short passwords susceptible to a brute-force or an attack based on a dictionary of often-used passwords”
  • The name “Bicycle Attack” was chosen because: if you wrap a bicycle in giftwrap, you can still tell it is a bicycle
  • The research then goes on to look at how this same concept can be applied to GPS coordinates, and IPv4 addresses. Just by knowing the length of the IP address, you can reduce the possible search space to only ~30% of the total. Some lengths cut the search space even more.

  • #missioncomplete

  • https://forums.freenas.org/index.php?threads/freenas-logo-design-contest.39968/

Merry Christmas: We stole your paypal account

  • Alternative link, Krebs appears to be under a DDoS attack
  • Krebs’ PayPal account was compromised on Christmas Eve
  • “The perpetrator tried to further stir up trouble by sending my PayPal funds to a hacker gang tied to the jihadist militant group ISIS. Although the intruder failed to siphon any funds, the successful takeover of the account speaks volumes about why most organizations — including many financial institutions — remain woefully behind the times in authenticating their customers and staying ahead of identity thieves.”
  • “On Christmas Eve morning, I received an email from PayPal stating that an email address had been added to my account. I immediately logged into my account from a pristine computer, changed the password, switched my email address back to to the primary contact address, and deleted the rogue email account.”
  • “I then called PayPal and asked how the perpetrator had gotten in, and was there anything else they could do to prevent this from happening again? The customer service person at PayPal said the attacker had simply logged in with my username and password, and that I had done everything I could in response to the attack. The representative assured me they would monitor the account for suspicious activity, and that I should rest easy.”
  • “Twenty minutes later I was outside exercising in the unseasonably warm weather when I stopped briefly to check email again: Sure enough, the very same rogue email address had been added back to my account. But by the time I got back home to a computer, my email address had been removed and my password had been changed. So much for PayPal’s supposed “monitoring;” the company couldn’t even spot the same fraudulent email address when it was added a second time.”
  • “In my second call to PayPal, I insisted on speaking with a supervisor. That person was able to tell me that, as I suspected, my (very long and complex) password was never really compromised. The attacker had merely called in to PayPal’s customer support, pretended to be me and was able to reset my password by providing nothing more than the last four digits of my Social Security number and the last four numbers of an old credit card account.”
  • “Let’s leave aside for a moment the reality that all of this static information about Brian Krebs has been posted online by various miscreants over the years (and probably remains online): Any company that authenticates customers with nothing more than static identifiers — address, SSN, DOB, phone number, credit card number, etc. — is vulnerable to these takeover attempts.”
  • “I asked the PayPal supervisor why the company couldn’t simply verify my identity by sending a text message to my phone, or a special signal to a PayPal mobile app? After all, PayPal has had the same mobile number of mine on file for years (the attacker also deleted that number from my profile as well). The supervisor explained that the company didn’t have any mobile authentication technologies, and that in order to regain access to the funds in my account I had to send the company a photocopied or scanned copy of my driver’s license.”
  • Not exactly something hard to fake, because I doubt they check it very carefully
  • “When I pressed the PayPal representative about whether he had any other ways to validate my identity short of sending a copy of my license, he offered to do so “using public records.” Now, I understand that what he actually meant was that PayPal would work with a major credit bureau to ask me a series of so-called “out of wallet” or “knowledge-based authentication” (KBA) questions — essentially yet more requests for static information that can be gleaned from a variety of sources online. But that didn’t stop me from playfully asking the representative why a security challenge should rely on answers from public records? He responded that someone probably would have to go down to a courthouse somewhere to do that, which made me laugh out loud and wish him a Merry Christmas.”
  • Krebs had a PayPal two-factor authentication token, but it apparently was not required to access the account
  • A user in the comments points out: “A dynamic identifier, such as a temporary code sent via SMS to a user’s mobile phone, isn’t any better if the provider of the mobile service is also vulnerable. I had my bank accounts emptied after Vodafone UK allowed someone to walk in off the street and transfer my phone number to a new Vodafone account in store. Hugely frustrating that they could ever allow this.”

The Juniper Saga

  • “On December 17, Juniper announced that some of their products were affected by “unauthorized code in ScreenOS that could allow a knowledgeable attacker to gain administrative access to NetScreen® devices and to decrypt VPN connections”. That sounds like an attacker managed to subvert Juniper’s source code repository and insert a backdoor.”
  • “Juniper followed up with a slightly more detailed post that noted that there were two backdoors: one via SSH and one that “may allow a knowledgeable attacker who can monitor VPN traffic to decrypt that traffic”. Either of these would be very interesting to a nation-state attacker but that latter—passive decryption of VPN connections—is really in their neighborhood.”
  • “Dual-EC was an NSA effort to introduce a backdoored pseudo-random number generator (PRNG) that, given knowledge of a secret key, allowed an attacker to observe output from the RNG and then predict its future output. If an attacker can predict the output of the PRNG then they can know the keys that one or both sides of a VPN connection will choose and decrypt it. (For more details, see the research paper.)”
  • “During the CRYPTO 2007 rump session, Niels Ferguson and Dan Shumow demonstrated that if the points are not randomly generated, but carefully chosen in advance, the security of Dual_EC DRBG can be subverted by the party doing the choosing; effectively backdooring the PRNG. Namely if one chooses P, Q such that Q=P*e holds for a value e that is kept secret, it will allow the party that generated said P, Q to recover the internal state of the PRNG from observed output in a computationally “cheap fashion” – hence instances of Dual_EC PRNG for which the provenance of the points P and Q is unknown are susceptible to having been backdoored.”
  • “It stands to reason that whoever managed to slip in their own Q will also know the corresponding e such that P*e=Q (the value P was unchanged from the standard) and hence is able recover the internal state of the backdoored Dual_EC generator from the output generator. What is unknown however is what an attack would look like for the PRNG cascade employed by Juniper’s ScreenOS.”
  • In the past, Juniper put out a KB article explaining their use of Dual_EC:
  • “ScreenOS does make use of the Dual_EC_DRBG standard, but is designed to not use Dual_EC_DRBG as its primary random number generator. ScreenOS uses it in a way that should not be vulnerable to the possible issue that has been brought to light. Instead of using the NIST recommended curve points it uses self-generated basis points and then takes the output as an input to FIPS/ANSI X.9.31 PRNG, which is the random number generator used in ScreenOS cryptographic operations.”
  • “However, apparently starting in August 2012 (release date according to release notes for 6.3.0r12), Juniper started shipping ScreenOS firmware images with a different point Q. Adam Caucill first noted this difference after HD Moore posted a diff of strings found in the SSG 500 6.2.0r14 and the 6.2.0r15 firmware. As we can deduce from their recent security advisory and the fact that they reverted back to the old value Q in the patched images, this was a change not authored by them. Apparently Juniper only realised this recently and not when they were issuing KB28205.”
  • “Static analysis indicates that the output of the Dual_EC generator indeed is not used directly, but rather only to reseed an ANSI X9.31 PRNG. Besides the unused EC PRNG known-answer test function, a function we call reseed_system_prng is the only one that references the ec_prng_generate_output function”
  • “Update: Shortly after reading my post, Willem Pinckaers pointed out that the reseed_system_prng function sets the global variable system_prng_bufpos to 32. This means that after the first invocation of this function, the for loop right after the reseed call in system_prng_gen_block never executes. Hence, the ANSI X9.31 PRNG code is completely non-functional.”
  • “if it wasn’t the NSA who did this, we have a case where a US government backdoor effort (Dual-EC) laid the groundwork for someone else to attack US interests. Certainly this attack would be a lot easier given the presence of a backdoor-friendly RNG already in place. And I’ve not even discussed the SSH backdoor which, as Wired notes, could have been the work of a different group entirely. That backdoor certainly isn’t NOBUS—Fox-IT claim to have found the backdoor password in six hours”
  • “NOBUS” is an intelligence community term for “nobody but us”

Feedback:

https://twitter.com/JohnLaTwC/status/682350922710659073


https://twitter.com/JohnLaTwC/status/682352201927294976

Round Up:

Question? Comments? Contact us here!