Tales from the BCrypt | TechSNAP 85
Posted on: November 22, 2012

How Allan saved PayPal from an embarrassing leak and a bunch of cash, details on the FreeBSD project’s compromise, and the latest advances in password hashing.
Plus the bug in iOS 6 that could cost you money, and a batch of your questions and our answers!
All that and a lot more in this week’s TechSNAP!
Thanks to:
Use our code tech495 to get a .COM for $4.95, or go20off5 to save 20% on your entire order!
$4.99 SSL certificates, just use our code 499ssl2. Expires 12-31-12!
Pick your code and save:
techsnap7: $7.49 .com
techsnap10: 10% off
techsnap11: $1.99 hosting for the first 3 months
techsnap20: 20% off 1, 2, 3 year hosting plans
techsnap40: $10 off $40
techsnap25: 25% off new Virtual DataCenter plans
techsnapx: 20% off .xxx domains
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 Feeds | Torrent Feed |
Support the Show:
|
Show Notes:
Get TechSNAP on your Android:
Browser Affiliate Extension:
- Jupiter Broadcasting Affiliate Extensions for Chrome and Firefox
- PayPal’s new bug bounty program opened on June 21st 2012
- On June 29th, the security researcher in this story decided to take a look at PayPal and see if he could make some money
- He started his quest with a search on SHODAN (search engine for service information, like version numbers etc) for ‘admin paypal’
- He found a number of publically accessible ‘staging’ servers for PayPal (such as stage2mb106.paypal.com)
- He started by trying to do an authentication bypass by using SQL injection using the randomly selected username ‘lsmith’
- This returned an error message, but also the string ‘You are logged in as Lori Smith’
- After some more testing, he found jsmith was Janine Smith
- He wasn’t sure what this staging admin area did yet, but after some googing he found examples of court documents dumping the details of a paypal account that are generated by the tool at admin.paypal.com
- This is where the researcher found the first problem with PayPal’s bug bounty program. PayPal asks that all submissions be encrypted with PGP to ensure privacy, however the PGP key posted on the bug bounty program website had expired
- On July 5th he finally got a proper PGP key and sent his report
- July 19th – automated report that submission was received
- August 7th – submission closed as ‘invalid’
- August 8th – submission recategorized and reopened
- August 21st – A hand written reply to another bug report, says the current report is still open and payment will be sent when it is fixed
- August 29th – received payment for a ‘XSS Vulnerability’, which seems like a miscategorization, asks if this is a mistake, never gets a reply
- Researcher’s Writeup
- Allan has also participated in the PayPal Bug Bounty program, after finding a cache of stolen paypal accounts totaling millions of dollars (a story to be covered in depth when I get time)
- My own disclosure to the program started on September 15th and was finally concluded today, November 21st
- The first automated reply saying they had received the report was September 17th
- September 20th they replied asking for some additional information
- October 26th, Paypal apologized for the delay and notified me that while my submission did not qualify under the Bug Bounty program, due to the nature of the information they were still going to award me $1000, I should expect payment in 3 weeks
- November 21st, I received my payment and clearance to talk about the incident
- On November 17th the FreeBSD security officer announced that intrusions into two servers operated by the FreeBSD project had been detected on November 11th
- The affected machines were taken offline for analysis
- A large portion of the remaining infrastructure machines were also taken offline as a precaution
- The two machines that were compromised were part of the legacy third-party package building infrastructure
- It is believed that the compromise may have occurred as early as the 19th September 2012
- The compromise is believed to have occurred due to the leak of an SSH key from a developer who legitimately had access to the machines in question, and was not due to any vulnerability or code exploit within FreeBSD
- At no time did this attack place the core FreeBSD operating system (kernel, userland, contributed apps (ssh/sshd, bind, etc)) at risk
- However, the attacker had access sufficient to potentially allow the compromise of third-party packages. No evidence of this has been found during in-depth analysis, however the FreeBSD Project is not taking any risks, and has thrown out all of the packages it was building for the release of FreeBSD 9.1 and building them from scratch
- If you are running a system that has had no third-party packages installed or updated on it between the 19th September and 11th November 2012, you have no reason to worry
- The Source, Ports and Documentation Subversion repositories have been audited, and the project is confident that no changes have been made to them. Any users relying on them for updates have no reason to worry
- The project cannot guarantee the integrity of any packages available for installation between 19th September 2012 and 11th November 2012, or of any ports compiled from trees obtained via any means other than through svn.freebsd.org or one of its mirrors. Although there is no evidence to suggest any tampering took place and such interference is unlikely, the FreeBSD Project recommends you consider reinstalling any such machines from scratch, using trusted sources
- Additional Source
- Official PHP RFC Wiki
- Why do we need password hashing: to store passwords in a way such that we can verify the a user is entering the correct password, but if our database is compromised, the attacker cannot easily determine the users password
- Why do we need strong cryptographic password hashing: Using regular hashing functions such as MD5 or even SHA512 is not sufficient. Regular hashing algorithms are designed to be fast and that is undesirable. Additionally, a straight hash is subject to attack by rainbow tables (precalculated hashes). Cryptographic hashes add a salt, to make each hash unique (even if multiple users use the same password, because the salt will be different, the hash will be different). Cryptographic hashes also usually include a stretching or slowing algorithm, that makes the hash take longer to calculate, sha512crypt uses a loop count, doing the hash 10000 times. Some algorithms like bcrypt are resistant to acceleration by a GPU, and other algorithms such as scrypt are designed to be memory intensive to resist acceleration for ASIC or FPGAs.
- The new PHP password hashing API makes the process of generating and validating hashes much easier, and includes a system for upgrading hashes
- The new API allows you to optionally specify the hash to use, and if not defaults to bcrypt (the old crypt() defaulted to DES). This also means that in the future, if PHP changes the default password hash, all new hashes will be made using the new algorithm
- The API introduces a function that checks if a password hash needs to be upgraded. So when a user attempts to login, you check that they have entered the correct password (your database contains a hash from the old algorithm, but the hashes contain a marker at the front that identifies the hashing algorithm), if it is correct, you then use the attempted password (which you have in plain text, since you require that to generate a hash to check against the hash in your database) and hash it with the new algorithm, and overwrite the copy in your database. With this system, the first time a user with an old hash logs in, their hash is upgraded to the new algorithm
- PHP 5.5 is just coming out in beta, and will likely not see production use for a while, but you do not have to wait, there is a pure-PHP implementation for PHP 5.3
- The issue has been detailed in a blog post at PRX.org
- They looked into it after being approached by folks at This American Life about extremely high bills from their CDN for the month of October.
- Chris has heard from other podcasters about this issue, and for some less prepared networks/shows it’s caused a semi-DDoS effect for many hours after an episode release.
- PRX.org was able to reproduce the issue with several podcasts in the Podcast app, including podcasts using Limelight and Akamai CDNs.
- PRX.org was unable to reproduce the issue using iOS 5 or using iOS 6.0.1, but there are still many people using iOS 6.0.0. We believe that this issue, combined with the bug causing the phone to behave as though it is connected to WiFi even when it is not, could account for the significant data overages reported with the release of iOS 6.
- Others have reported the issue remains in iOS 6.0.1, but is perhaps alleviated by the resolution of the wifi bug.
- When the file has completed downloading, it begins downloading again from the beginning of the file and continues for as long as one is streaming the file.
- As long as one is listening to audio being streamed with iOS 6, it is using significant amounts of data.
- There appears to be a system-wide problem with the AV Foundation framework in iOS 6.0.0, impacting any App in the app store that uses that backend.
- Apple does not appear to have acknowledged the specific issue.
- Original PRX Labs post
- More Coverage at Ars Technica and The Next Web
- Openwall are the developers behind John the Ripper
- Talk covers the challenges of securing against online and offline attacks
- Covers the Pros and Cons of the YubiHSM, a USB hardware security module for servers from the makers of the YubiKey
- Covers the future vulnerabilities of PBKDF2 and bcrypt
- Talks about the advantages of scrypt
- scrypt was invented by Colin Percival (former FreeBSD Security Officer), for his tarsnap secure online backup product
- scrypt is designed to be much more secure against hardware brute-force attacks (using ASICs and FPGAs etc), it uses a time-memory trade off, requiring a large amount of ram to lower the required amount of CPU cycles, making dedicated hardware attacks much more expensive to carry out
- “if 5 seconds are spent computing a derived key, the cost of a hardware brute-force attack against scrypt is roughly 4000 times greater than the cost of a similar attack against bcrypt (to find the same password), and 20000 times greater than a similar attack against PBKDF2”
- When used for file encryption, the cost of cracking the password is 100 billion times more than the cost of cracking the same password on a file encrypted by openssl enc
- scrypt is now an IETF internet draft
- Bustin some Debian kFreeBSD chops!
- PSA to Android ROM Lovers
- Password Policies on Hosted Panels?
- Getting around ISP Compression
- New malware variant uses googledocs to call home
- Facebook enabling HTTPS by default
- New Linux Rootkit Emerges
- Thieves use Airport’s own forklifts to steal $1.5 million worth of iPad Minis. Apple crime wave
- Leahy scuttles his warrantless e-mail surveillance bill
- Experts debate the legality of counter-hacking
- Microsoft gives away free Media Center Pack activation keys, turns out they can be used to activate Windows 8 Preview as Windows 8 Pro
- Online activist to found AT&T was leaking information about customers’ iPads found guilty under the Computer Fraud and Abuse Act for unauthorized access to the leaked material
- Paypal Bans Usenet Providers Over Piracy Concerns
- Dutch webhosting provider develops application that automatically patches customers’ wordpress if they do not patch it them selves within 2 weeks
- A $600 battery powered transmitter that could crash an entire city’s 4G network