Category Archives: Uncategorized

eBay user list confirmed non-legit

What we suspected, turned out to be true… Ebay confirmed that the data is not legitimate. This is now also confirmed if you look at the data. We looked at

  • is this email address associated with an ebay account? (worringly, one can easily check this at the ebay site)
  • is this email address known in https://shouldichangemypassword.com/ ?

Out of 12,663 records,

  • only 2,025 emails are registered with eBay and
  • 3,720 emails are known hacked emails according to Should I change my password.

ebay_emailregistered ebay_hackedemail

A first look at the eBay user list for sale (unconfirmed whether its legitimate)

UPDATE: Most likely this list is not legitimate. Too many things don’t add up. I would have loved to see eBay following good security practices and certainly do hope that this is the case for the “real” eBay dump.

According to http://pastebin.com/vmvjGw3N, there exists a full ebay user database dump of 145,312,663 records.

In order to get the database, you need to send 1.4453 BTC (~ 755.27 USD as per coinbase). So far nobody has done this (https://blockchain.info/address/1e4aLP3jKD9wRAcSRNVb7VHbd7KbcdPfA)

The user provided a sample of 12,663 entries from the APAC region. We’ll look at these in this blog.

WARNING: We have no idea whether these users are really from ebay or whether this all is legitimate. Let’s just assume for a moment that it is.

The entries are like: <<NAME>> |pbkdf2_sha256$12000$<<SALT>>$<<VALUE>>|<<EMAIL>>|<<ADDRESS>>|<<PHONE>>|<<DOB>>

The good news is that the password uses PBKDF2 (Password-Based Key Derivation Function 2) with SHA256 as hashing function with a 64 bit salt. That is the standard recommented salt length.

It seems that eBay uses 12,000 iterations for this algorithm. When the standard was written in 2000, the recommended minimum number of iterations was 1000, so this is 12x of that which seems good.

Because of the salt, rainbow tables can’t really used against this, so each password need to be computed individually (the salt per password prevents rainbow tables to be used against all at once).

So overall if this turns out to be legitimate, I think one can honestly say that ebay followed good security practices.

The email, address , phone and date of birth are in there in plain text however.

browser extensions, a better attack vector than drive-by-downloads?

I came across this blog post (locally cached pdf) a couple of days ago of a developer of a Chrome extension who filled the gap after Google dropped support for the RSS reader. His Chrome extension was popular and gained more than 30,000 users.

To cut the long story short, he sold it for a 4 figure amount to someone who then turn his extension into a adware riddled version and updated all 30,000 users.

That seems to be an awful efficient way of infecting a lot of users for very little money. His chrome extension was “Add to Feedly”.

Unfortunately these things occur more and more often. Another example is “Tweet this Page” was taken down by Google due to it starting to hijack google searches. Apparently the developer sold it for $500! (from here)

In both cases, the bad guys talked the authors into selling by making nice claims such as “…they wanted the extension ‘for further development’”.

The funny thing is that Google (who is distributing Chrome) is making around 97% of its revenue from online ads, so it is not surprising that advertising within chrome extensions is neither prohibited nor discouraged.

“…Injected ads are allowed in Chrome extensions, but Google’s policy states that which app the ads are coming from must be clearly disclosed to the user, and they cannot interfere with any native ads or the functionality of the website.” (from here)

For malware authors, hijacking legitimate and good extensions is an outstanding business model. First of all, they know exactly how many potential victims they can buy. Secondly, due to auto-updates they can infect these people nicely and thirdly it takes quite a while for google to remove “non-behaving” extensions from the store.

What is the risk here? or What can a malicious chrome extension do?

Google has automated screening capabilities that will minimize the distribution of malware through chrome extensions. However we all know that malicious actors have tools available to make sure their software is never be found to be malicious. But then again, launching an executable (malicious or not) in a completely transparent way is not so easy.

The much bigger risk is that the chrome extension has full control of the website content, including all form fields. This could mean that a malicious chrome extension can

  • inject any kind of javascript into the website, effectively providing the same functionality as every sophisticated banking trojan out there. Should we call this Zeus-in-the-Extensions ;-)
  • sniff any provided input values into form fields. These could be usernames, password, one-time-password, tokens, email addresses, date of birth, SSN and much more.

Google has already announced that their extension policy is due to change in June 2014 and the new policy will require extensions to serve a single purpose. It would never cross my mind that they do this to vastly increase the number of chrome extensions, but surely only to provide a good service to us.

Oh, they also make it easier to use payment options to extensions. I can already see the topic for a future blog post.

Why metadata matters…

I know this is all over the web right now in the discussion about NSA and their natural hunger to collect whatever they can get their hands on. I don’t want to start a discussion on the legality or the ethnics of this, but the following slide from the EFF makes a very good point and to preserve it for my own good, here it is :)

metadata-1

see https://www.eff.org/deeplinks/2013/06/why-metadata-matters for more details…

Also very relevant is the post by Kieran Healy on “Using Metadata to find Paul Revere” here. A local copy is available here as pdf.

Example of a “well-done” phishing attack

So I got the following email this morning in my inbox which made it happily past our gateway based spam filter and my outlook spam filter.

1

The link is a phishing site (even though it is https:// ;-) – however no phishing filters have it in their list (e.g. google, firefox, microsoft, netcraft…) Clicking on it gets me here

2

Going through the process, they surely collect the hell of a lot of personal information. They also “check” each input values to be correct (e.g. you can’t continue by entering a non-valid credit card number). Looks really nice and clean.

3

4

5,jpg

And very nicely, they will try to log me into Amex straight away, so if I would have given them my “real” credentials, I would have been logged into my account…

7

Wow what a certificate (verified.cm) – CA’s completely broken

Looking at recent hacks, I had a quick look at the SSL certificate from verified.cm and who on earth is signing the certificate below? Oh yes… It is GlobalSign for sure… If we would need another argument why Certificate Authorities are broken, here it is… but then again we knew this for so long and they still exist…

So the SSL certificate for verified.cm has been issued to ssl2968.cloudflare.com. Cloudflare is of course a well-known cloud-based web firewall that is used by many good and shady sites.

This certificate has the following 40 (in words: FOURTY!) Alternative Names. Oh and don’t worry, it is also valid for 4 more years (until Jan 15, 2018). What could possible go wrong with this?

Did I mention that the domain that it was issued to doesn’t even resolve (ssl2968.cloudflare.com)?

Here are the fourty Alternative Names:

  • ssl2968.cloudflare.com
  • *.verified.cm
  • verified.cm
  • *.lynnfieldcommons.com
  • *.seehawaiilive.com
  • *.seaislandshops.com
  • bluesafesolutions.com.au
  • larende.com
  • *.youractivistportal.com
  • *.calligraphyofchina.com
  • seaislandshops.com
  • *.uvioo.com
  • snipjournal.com
  • escortgps.xxx
  • *.larende.com
  • seehawaiilive.com
  • *.snipjournal.com
  • *.prestomarket.com
  • *.themeat.dk
  • *.d2haa.org
  • cargames.org.uk
  • d2haa.org
  • *.templatation.com
  • *.descansogardens.org
  • youractivistportal.com
  • *.bluesafesolutions.com.au
  • tipple.me
  • calligraphyofchina.com
  • *.cargames.org.uk
  • *.tipple.me
  • landisgyr.com
  • prestomarket.org
  • *.prestomarket.org
  • uvioo.com
  • *.escortgps.xxx
  • templatation.com
  • prestomarket.com
  • *.landisgyr.com
  • lynnfieldcommons.com
  • descansogardens.org
  • themeat.dk

Quality Assurance in Trojans (Spyeye)

In my day-to-day work, I focus quite heavily on the configuration files and the way trojans work in a particular circumstance.

Spyeye is obviously one of the trojans that is high on the radar as it is believed that the authors behind Zeus and Spyeye have “merged”. This has been supported by findings that Zeus and Spyeye trojans can now talk to the same backend system. (All trojans need a C&C server where they report their stolen data to. In this case, the C&C backend can handle data from Zeus and Spyeye).

The Spyeye trojan has a plugin structure that is extensible and makes sure that the trojan can adapt to new situations.

Well known Plugins are:

  • webfakes (alter web content in HTTP and HTTPS requests… this is to compromise any website)
  • ddos (denial of service)
  • ccgrabber (credit card grabber… scans POST request for credit card numbers (using Luhns algorithm) and steals the info)
  • backconnect (either via RDP or SOCKS5. provides a means for the fraudster to connect to your computer)

But one plugin was new to me

  • bugreport

This plugin takes care of any crashes of the Spyeye trojan and more details to the problem will be sent to the fraudster. The fraudster can also define what should happen in this case.

WOW… A built-in mechanism that allows the perpetrators to collect critical QA information from client systems to help them to make the trojan better? How many commercial software applications do have a similar system?