Using phone tones and a little Python to get access to someone’s bank account, and Oracle steps up with an early patch for Java but it doesn’t fix everything.
Then we answer a big batch of your questions, and much more on this week’s TechSNAP.
The February CPU was originally scheduled for February 19th, but was released February 1st
The patch fixes 50 different issues, more than half of which have a CVSS risk score of 10 out of 10
This CPU covers issues #29, 50, 52 and 53 reported by Security Explorations, however a fix for issue #51 is still outstanding. Each of these issues is a sandbox security bypass
In addition to the new ‘disable java in all browsers’ setting in the java control panel that was introduced in the last CPU, this update also changes the default security setting to high, requiring users to approve all unsigned applets, rather than letting them run silently
“The size of this Critical Patch Update, as well as its early publication, demonstrate Oracle’s intention to accelerate the release of Java fixes, particularly to help address the security worthiness of the Java Runtime Environment (JRE) in desktop browsers.”
The next Java CPU is not scheduled until June 18th 2013
Banks is Africa uses Audio-One-Time-Passwords (AOTP), since most users do not have smart phones, and SMS is not widely deployed
The way the system works, is that after a user logs in to their bank and makes a transaction, the bank calls their mobile phone to verify the transaction. The user holds their mobile phone up to the speakers on their computer, and the browser plays some audio, which is then received by the bank via the open phone line, and compared
The researchers wrote a python script to simulate logging in to the bank 10,000 times, and recorded the audio for each of these attempts
There are a number of issues with the implementation of this system
Users login to their bank with their mobile phone number and a 4 digit pin, this is obviously not very secure, and is also open to brute force attacks, since both credentials are numeric, and the phone numbers are fairly predictable
The researchers found that the AOTPs are not cryptographically random
The AOTPs are only 1000ms long
Based on analysis, the AOTPs only contain 55 bits of information
The system assumes it is connecting to the users’ mobile phone, when it may actually be redirected
Based on predictable AOTPs, the researchers were able to save a AOTP as the voicemail greeting on a target users’ number, so when the bank made the verification call, it got the expected tones
Brute force attacks against voicemail passwords are fairly trivial, as most are only 3 or 4 digit pins, and users often leave them at defaults such as the last 3–4 digits of the phone number, a birth date or 1234
Some carriers also offer a web interface for retrieving your voicemail making web based attacks possible as well
The twitter security team detected an unusual pattern of attempts to access their infrastructure
In the process of investigating, they found a live ongoing attack
They believe the attackers may have had access to: usernames, email addresses, session tokens and encrypted/salted versions of passwords – for approximately 250,000 users
If twitter believes you were affected, you will have already received a password reset email
Twitter reminds you to choose a password that is at least 10 characters long, a mix of case and symbols, and to never use the same password on multiple sites
The blog post needlessly mentions the recent Java exploits, and how browsers are disabling the plugin, creating a false equivalency or relationship between what happened to the Twitter servers and the ongoing saga of Java
At the end of the blog post, they again remind users to disable Java, even though java played no part in this attack
While debugging a problem that would cause their on-premise VoIP devices to suddenly fail, a sysadmin discovered a bug in the Intel EEPROM
A very interesting story of the steps required to reliably reproduce the problem, in order to attempt to isolate it
If a specific bit has a value of 32 (ASCII 2) the nic will die, and can only be revived by a full power cycle
However, to complicate things, if a value of 34 (ASCII 4) happens to fall at this specific offset, the NIC is ‘inoculated’, and won’t crash if it subsequently receives a 32 or 33
It took a great deal of testing to reproduce the problem, because if a nic got inoculated, it wouldn’t fail again until it was power cycled