Wednesday, 30 October 2013

What is known about the Adobe breach now and what is in store

If you have ever used Adobe.com in your lifetime, reset your password if you know or cannot remember if you ever signed up for an account there. It doesn't matter if Adobe themselves have reached out to you or not, reports of there being 38 million accounts at risk were incorrect: it's really 153 million. This was mentioned in Kreb's article, but news reports outside of him are throwing erroneous figures.

The source of the aptly named "users.tar.gz" came from a Russian website that I had been monitoring for a few days. A user eventually shared it when the link went dead and a kind fellow determined a safe way to download it in a reasonable period of time as the person who reposted used an ad-supported file sharing website. In the end, it cost 2 EUR to download the file.

It's now in the hands of many researchers including myself.

Here are some facts that a number of us taking a look at the leaked user data have in store:

  • The exact count of the leaked credentials is at most 153,004,874. This has yet to be confirmed but in conversations with a friend who is also looking at the data, it worked out to about 50 duplicate accounts for every 10,000.

  • Passwords are stored in DES format. There is a global key as opposed to a unique one for each user.

  • It should also be kept in mind that not every user account has a password listed in this file. It is not to say that there is no password leaked any of these types, but don't take this as assurance to say the least.

  • Users range from businesses, to governments, to NGOs, and to people like you and I.

  • The most commonly used passwords were "123456", "password", "123456789", "12345678", and "qwerty". This was determined not via password breaking but due to the fact that users have stored some hints in the password recovery details.



The leaked data is also stored in this format (with user details removed):
103251449-|--|-[...]@yahoo.co.jp-|-hbpRGiyyvW0Ix+w38j30rA==-|-password|--
103251644-|--|-[...]@yahoo.com-|-7ZANzFDeVNU=-|-only password|--
103251834-|--|-[...]@seznam.cz-|-L8qbAD3jl3jioxG6CatHBw==-|-? password|--
103252332-|--|-[...]@yahoo.com-|-N/Bo4qtibWs=-|-where is my password?|--
103252463-|--|-[...]@aol.com-|-//mMaopP+fE=-|-habbo password|--
103252538-|--|-[...]@yahoo.com-|-8rGaJa+8UUSY41q03G/5+A==-|-real password|--
103252720-|--|-[...]@gmail.com-|-YQR6szpR2NTioxG6CatHBw==-|-gmail password|--
103253089-|--|-[...]@yahoo.co.uk-|-rFB6XOjEj1S/hiuNpU1UXA==-|-password|--
103253394-|--|-[...]@gmail.com-|-aK1lx9gGXIyTrmSEaSpL2A==-|-password|--


One excerpt from an e-mail I had received earlier should be taken into account as well:

Actually, I think its double DES for the longer ones. Just two des
concatenated, one for first 8 char and one for second. You can see
that a lot of the longer passwords have the same ending. This happens
because many second halves of passwords longer than 8 char will be the
same. For instance, a 9 char password will only have 1 char and 7
blank spaces in its hash. Also, this is terrible. You should be able
to easily figure out the salt as well.


If you think that Rock You was bad, Adobe will make it look like it was just a passing fart.

Again, I do suggest that if you think you might have given your details to Adobe that you just reset your passwords if you have not already.

Edit: Adobe clarified that the passwords are all DES as I suspected (or 3DES to be exact). I did make an erroneous assumption about it being another hashing function but that has been proven to be otherwise.

Tuesday, 29 October 2013

Using a Bitcoin ATM



Today I was one of the first people in the whole world to use an in-service ATM built specifically to purchase and sell Bitcoins as one was put into service today here in Vancouver. I've never really been too big into Bitcoin (or "BTC") in the past although I did at one point have 4 BTC (which at its peak would have been worth something like $1,000 CAD), but I had lost the wallet file associated with it. I did also briefly mine Litecoins, an alternative to Bitcoin, but I lost interest in the idea very quickly.



The number of people who were at the coffee shop was minimal, maybe a dozen or so even though it was lunchtime. Admittedly the coffee shop is a bit away from the central business district of downtown Vancouver, but there were plenty of offices and businesses around, so I found it surprising that there was not many people about. Nonetheless, there were people who did not appear to be tech-centric who did in fact take a sip of the BTC Kool-Aid and throw some money at it. Surprisingly, the one individual who qualified in this category threw $100 CAD into the machine. She appeared to be visiting from rural British Columbia too as she was wearing a badge for a conference, representing a real estate agency from outside of the Lower Mainland.



The machine itself is more kiosk-like than ATM and I do have some criticisms about how you are to use it. For example, if you wish to purchase Bitcoins, you have to enter bills at the bottom of the machine, requiring you to bend down to do so. This isn't the end of the world of course, but people would complain if those horrid self-checkouts required you to do so or if an actual bank-issued ATM required you to put the card on the side.



To comply with Canadian money laundering laws, you are required to use a palm scanner to verify your identity. This makes sense except for one problem: the people behind the ATM's operations must approve your palm.

For this visit, the approval of my palm was instantaneous as they had staff on hand to monitor the machine and verify that it wasn't mixed up with anyone else. However, in conversations with one of the ATM's owners, I was informed that approval would otherwise take upwards of an hour (possibly more I guess) as they must do the approvals manually. This seems awfully silly as why would I use a machine that requires me to spend an hour to wait for approval? It is things like this that will limit acceptance of BTC if acceptance is at all possible.



I did decide to take the plunge and purchase some BTC. I only had a $20 note on me so I decided to just use that for the purposes of the experiment. As evident in the above image, you can only purchase Bitcoins in $20 or $100 incrementals, up to $1,000 CAD. The $20 note ended up equating to 0.092 BTC at the time, but I didn't get the opportunity to ask if it was a fixed rate for the day or if it was a live conversion. The going rate for 1 BTC was $218.26 CAD.



I did not have a wallet at the time either so the machine provided me with one and also gave me a private key in the form of a QR code printed on a receipt. I later went and enabled the wallet on my laptop at the office and do now see my BTC inside. I also got a receipt for the purchase of the coins I had made too.



Processing of the transaction took about an hour before it showed up on Blockchain. I have to admit, even with all of its quirks and delays, it actually is rather painless to use once you've gotten to used to the awkward palm scanner.

Now one thing I will be honest about: I am still not convinced about Bitcoin. It's neat, I can see people making a lot of money from it, but overall I am just not a "Bitcoiniac" so to speak. If people want to send me BTC, I am cool with that, but I just don't have as much excitement over it.

And yes, please send me some Bitcoin if you desire!
19K3c1zZZMyGBSm2vxV58DU9yy9TWdwd75


Also if you're reading this, do give Canary a look see as that is my main project.

Wednesday, 16 October 2013

Compass card: a review

I was one of the lucky recipients of a Compass card that is due to be launched in the next half-year.

Due to my being away in Europe for a good chunk of the testing programme and having Canary to work on, I haven't had the time to play around with the card as much as I want to so what you're getting here is pretty much the raw data. I can gladly answer any questions if you e-mail me.

I do have friends in the local Vancouver information security scene that are poking at the system themselves.

Tapping in and out and flaws



The system in place works no different than other systems such as San Francisco's Clipper card. Boarding a bus or entering a station takes one simple firm tap on the reader (needs to be held down for a half-second) and that will be enough to transmit a signal to and from the card and the reader. It could be a bit slow for a bus, but with enough gates, it won't be an issue at any station.



However, due to the zone system that is currently in place, it is quite easy to board a bus and then once at the back, you can tap out. As you can see in the image above, tapping out too fast will present that above message. Yet if you wait just a few seconds after the bus has started to move, you can immediately tap out.

You can repeat this on the bus at least twice in a row but then the system does lock you out if you attempt to tap more than four times in one trip. I haven't tried this more than once but my fifth and consecutive taps ended up resulting in the same error as above being shown. The card did work however when I entered a SkyTrain station at the bus' terminus.

This flaw was publicised earlier this week and the response from TransLink was nothing more than how much life will be better with the new Compass card system. Needless to say, I am almost certain that they were aware of this issue from the get go and to be honest, it's not much of a flaw to begin with seeing that there aren't that many bus routes that require multi-zone fare and if they do, they generally require you to tap into a gate at some point since they connect to a SkyTrain station.

The loophole so far doesn't exist within the SkyTrain system as you do need to tap out to physically leave the station. This issue will be be more apparent when TransLink eventually adopts a distance-based system, but I imagine that the buses will be taken into account.

Contents of the card itself



So for those who are curious about it from a technical stance, the Compass system uses a Cubic implementation of MIFARE DESFire EV1. At this time, the proprietary standard does not have any known vulnerabilities, but I have included the raw details about it below.

# IC manufacturer:
NXP Semiconductors

# IC type:
MIFARE DESFire EV1 (MF3ICD41)

# DESFire Applications:
1 unknown application

-- NDEF ------------------------------

# NFC data set storage not present:
Maximum NDEF storage size after format: 4094 bytes

-- EXTRA ------------------------------

# Memory information:
Size: 4 kB
Available: 4.0 kB

# IC detailed information:
Capacitance: 17 pF

# Version information:
Vendor ID: NXP
Hardware info:
* Type/subtype: 0x01/0x01
* Version: 1.0
* Storage size: 4096 bytes
* Protocol: ISO/IEC 14443-2 and -3
Software info:
* Type/subtype: 0x01/0x01
* Version: 1.4
* Storage size: 4096 bytes
* Protocol: ISO/IEC 14443-3 and -4
Batch no: 0xBA3417AE30
Production date: week 08, 2012

-- TECH ------------------------------

# Technologies supported:
ISO/IEC 7816-4 compatible
Native DESFire APDU framing
ISO/IEC 14443-4 (Type A) compatible
ISO/IEC 14443-3 (Type A) compatible
ISO/IEC 14443-2 (Type A) compatible

# Android technology information:
Tag description:
* TAG: Tech [android.nfc.tech.IsoDep, android.nfc.tech.NfcA, android.nfc.tech.NdefFormatable]
android.nfc.tech.NdefFormatable
android.nfc.tech.IsoDep
* Maximum transceive length: 261 bytes
* Default maximum transceive time-out: 309 ms
* Extended length APDUs not supported
android.nfc.tech.NfcA
* Maximum transceive length: 253 bytes
* Default maximum transceive time-out: 618 ms
MIFARE Classic support present in Android

# Detailed protocol information:
ID: 04:48:0B:F2:59:22:80
ATQA: 0x4403
SAK: 0x20
ATS: 0x067577810280
* Max. accepted frame size: 64 bytes (FSCI: 5)
* Supported receive rates:
- 106, 212, 424, 848 kbit/s (DR: 1, 2, 4, 8)
* Supported send rates:
- 106, 212, 424, 848 kbit/s (DS: 1, 2, 4, 8)
* Different send and receive rates supported
* SFGT: 604.1 us (SFGI: 1)
* FWT: 77.33 ms (FWI: 8)
* NAD not supported
* CID supported
* Historical bytes: 0x80 |.|

# Memory content:
PICC level (Application ID 0x000000)
* PICC key configuration:
- AES key
- PICC key changeable
- PICC key required for:
~ directory list access: no
~ create/delete applications: yes
- Configuration changeable
- PICC key version: 129

Application ID 0x000001
* Key configuration:
- 14 (3)DES keys
- Master key changeable
- Master key required for:
~ directory list access: no
~ create/delete files: yes
- Configuration changeable
- Key itself required for changing a key
* 1 file present

- File ID 0x00: Standard data, 384 bytes
~ Communication: with MAC
~ Read key: key #1
~ Write key: key #2
~ Read/Write key: key #2
~ Change key: master key
~ (No access)


I do suggest that you look into Adam Laurie's RFIDIOt site if you're interested in looking at the card for yourself.