Researcher finds flaw in PayPal that may expose sensitive data

• 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

Two FreeBSD project servers compromised by leaked SSH key

• 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

PHP 5.5 to introduce new password hashing API

• 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

iOS 6 streaming bug causes excessive data user

• 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 gives talk at YaC2012 about password hashing

• 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

Feedback:

• Bustin some Debian kFreeBSD chops!
• PSA to Android ROM Lovers
• Password Policies on Hosted Panels?
• Getting around ISP Compression

Round Up:

• 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

The post Tales from the BCrypt | TechSNAP 85 first appeared on Jupiter Broadcasting.

Chip and Pin security flaw exposed by Cambridge Researchers

• Chip and Pin technology replaces the traditional magnetic strip and signature method of authorizing a Credit Card or Debit Card transaction
• The technology uses the chip embedded in the card to authenticate itself to the PoS (Point of Sale) terminal, once the PIN is entered, proving that it is not a forged or cloned card
• This provides stronger authentication of the card holder, using the secret PIN rather than comparing signatures
• The original idea behind this concept was to shift liability for fraudulent transactions to the card holder, since the transaction could only go through if the PIN was provided, the transaction must have been authorized by the card holder, or the card holder was careless with their PIN number
• This liability shift was never enacted, due to various flaws found in the system, including one where a blank card, connected to a stolen card, could be used to access the funds on the stolen card with an arbitrary pin number
• The most recent flaw takes the form of a pre-play attack, which allows the attacker to determine the information required to authorize a transaction without the PIN number
• The authentication protocol used between the PoS and the Chip requires the PoS terminate to generate a nonce , referred to in the documentation as an ‘unpredictable number’. The purpose of the nonce is to ensure that the authentication is fresh, preventing an attacker from using an old authentication response
• The problem is in the implementation, many PoS terminates do not generate a random (or even pseudo-random) number for the nonce, but rather use a timestamp or counter
• This allows an attack, that from the logs at your bank, appears as if your card was cloned, which is supposed to be nearly impossible due to the chip embedded in your card
• The researchers discovered this vulnerability while investigating the case of an HSBC customer who was refused a refund from his bank, who stated that he must have entered his PIN at the ATM where his cash was withdrawn, in a different country
• At the behest of the researchers, he demanded the banks logs of the transaction
  Date Time UN
  2011–06–29 10:37:24 F1246E04
  2011–06–29 10:37:59 F1241354
  2011–06–29 10:38:34 F1244328
  2011–06–29 10:39:08 F1247348
• As you can see, the ‘unpredictable number’s do not seem very random at all, infact they appear to be a 17 bit fixed value, followed by a 15 bit counter that is incremented every few milliseconds, and rolls over every 3 or so minutes
• The research discusses how this weakness could use used to execute a ‘pre-play’ attack
• An employee working at a restaurant or retail store, could run your card through a device that would provide the authentication code required to access the card during some specific window of time in the future, allowing them to withdraw funds from your account at an ATM without knowing your PIN number. This attack could also be executed by malware built in to a PoS terminal or vending machine
• The researchers built their own special card that could extract the unpredictable number from each transaction they performed, and by doing a number of ‘balance check’ transactions, where we able to assess the randomness of the UNs
• Research Paper
• Blog post by Reseacher

NIST chooses keccak as new SHA–3 hashing algorithm

• Pronounced catch-ack
• The algorithm was designed by Guido Bertoni, Joan Daemen and Gilles Van Assche of STMicroelectronics and Michaël Peeters of NXP Semiconductors, and was one of 63 entrants to the NIST competition
• The competition started in 2007 when it looked like there may be issues with SHA–2
• Those issues never surfaced and SHA–2 is still considered secure
• Because keccak is not derivative of SHA–2, but entire different, it means that an attack against SHA–2 will be very unlikely to also be effective against SHA–3

Feedback:

• I need help finding the correct chat server

• Openfire Server

• Some information on the Nexus S and NFC

• rsync Hard Links and full backups?

• An easy way to encrypt on the go?

• Why do banks use passwords at all?

• Can we get TechSNAP on Stitcher?

Jupiter Broadcasting on Stitcher

Have some fun:

• What will be in the news the week in October when Allan is at Euro BSD Con? Let make a prediction on the head lines or just make up funny stuff to read

What I wish the new hires “knew”

Round-Up:

• Regulators shut down global PC ‘tech support’ scam
  • “Hello, I’m definitely not calling from India. Can I take control of your PC?”
• Britain in talks on cybersecurity hotline with China and Russia
• New Oracle hacks revealed
• The Most Important Meeting You’ve Never Heard of
• Facebook denied private messages were leaked, messages were old wall-to-wall posts that users misunderstood
• Squirrels account for 17% of all cable damage at Level3 communications
• 10 most bizarre cable cuts
• Server Room Nightmares
• Obligatory XKCD

The post Wire-Shark | TechSNAP 78 first appeared on Jupiter Broadcasting.