After a phone conversation with him, I realized that his computer was hacked a few days before. He told me that he saw the mouse moving by itself, but what happened then was not clear to him. Anyway, he did not feel the urge to call me immediately. Needless to say that his knowledge on computers is low.
I immediately started to investigate.

How the computer was hacked

The computer is running Ubuntu . I suspected a vulnerability, but I soon realized that it was much simpler than that: by mistake, a VNC session was left opened!

x11vnc with no authentication and no logging… Damned!

What the attacker did

What he tried first was to create a user to maintain access. But the scammer was probably low tech and soon abandonned.

Here is his sequence in the shell history:

261 adduser -u 0 -o -g 0 -G 0,1,2,3,4,6,10 -M xxxcx
262 useradd -d /home/xxxcx -m nokia00
263 passwd xxxcx

Command #261 failed, because of unproper syntax. I guess he meant useradd, as adduser on Debian/Ubuntu has totally different options. Note that what he was trying to do is create a new root user named xxxcx (with no home directory).

He probably did not realize his mistake, but yet tried this time useradd with fewer options in command #262. This time, he would create the home directory and name the user nokia00… Why not. Alas, the command can’t work as a standard user!

Then, command #263: he tried to change the current password, but again he failed as it is required to know it before updating it…

And that’s it. Pretty lame, isn’t it? He got quickly discouraged and started to use exclusively Firefox.

On-line shopping

With support of forensicswiki.org, I dumped the full Firefox profile on my computer and started to analyze it with the Sqlite Manager extension.

Sorry but I will be hiding private info and sensitive data that could be used for a legal action.

I got most info from the files cookies.sqlite and places.sqlite.

cookies.sqlite: a lot of info: email and billing info used by the attacker

places.sqlite: attacker’s browsing history, with interesting purchase references in GET parameters

The guy didn’t loose time, he knew precisely what he wanted and what to do.

1. He first visited two websites to localize the computer: ip2location.com and ip-tracker.org. You may think that it is a strange first move, but I will come back on that later as I have a theory.
2. Now that he knew in what country he was (country XXX), he started to do online shopping.

It is interesting that his online shopping was all linked to web hosting:

• templates from dreamtemplates.com
• a .net domain name (with however part of the prefix being localized accordingly to the country suffix).
• hosting at netfirms.com and mg1host.com

Note that the criminal used a online payment platform that I never heard about before: 2checkout.com aka 2co.com.

Unfortunately, when I investigated, all cookies were expired so I could not connect to the criminal’s account.

Yet, it still had some valuable info. The most interesting info I found was from a cookie from dreamtemplates.com. I got all the billing info used by the attacker:

• attacker’s gmail address (probably compromised or anonymous)
• Name and address for the billing, that sounded real…

Also, GET parameters in URLs were very interesting.

In some of them, you can guess the amount of the purchase he did. He for sure bought stuff for at least a total of 500$. But it is without counting the stuff that I cannot guess from URLs, so it is probably sensibly much more in reality.

But, even better, some had order ids. Hey, wait! Let’s have a look on the 2co website:

2co order review = order number + email

Hmmm… we have the email address and the order number… bingo!

Now, we have at least all info of the credit card owner, certainly the biggest victim in this mess.

Conclusion

That’s it for now. We are still in the process of transmitting the info to the police and alerting the victim.

Here are a few thoughts by the way:

• Logging, always logging! It is a pity that we know literally nothing about the scammer source ip address. All his actions were made from within a VNC session and it leaves no trace. He may have came from another proxy, but who knows… I still have a little hope that under legal request, the Internet provider of my relative will be able to provide some logs.

• Nowadays, it is still difficult to report such a case to the police and to help the victim. The local police is at loss and does not really know what to do. The cyber section is slow to answer, probably crawling under requests (mostly spam stuff?).

• Not every one has a computer specialist among friends or relatives. It must be a terrible experience to see the police coming to you for a fraud one hasn’t committed directly. Few people, even sometimes among IT professionals, understand that.

• The criminal seemed low tech, but very organized at the same time.
  Here is my theory: he probably has a precise goal and is not loosing time.
  He follows a process: geo-localize the victim or target a country and choose accordingly financial data in his database.
  Then, he purchases stuff from a list of items he needs or he is requested.
  Finally, if he could not find a way to maintain access in seconds, he leaves. Mission done: this scammer is probably doing it full time, as a professional activity. Lame but efficient for the crime industry.

• The credit card info was accompanied with private info: real name and address. We all know that but it is always shocking to think how it can easily obtained: compromised computer, hacked online shop or database, dishonest employee (e.g. at the hotel), etc.

• The websites  will probably be used for more scamming and illegal activities. I am going to monitor the domain I got for a while.

Keep wired for updates.

[error] SSL Library Error: 336068931 error:14080143:SSL routines:SSL3_ACCEPT:unsafe legacy renegotiation disabled

It occurs appears when I try to use a SSL client certificate with Safari. Of course, authentication is broken as it just fails on an 403 error page.

So it seems that Safari is the last browser which was not patched against CVE-2009-3555 !

2009 !! At least, I quickly checked the other browsers I had around and they were fine: IE, Firefox, Chrome… I am having an issue with Opera also, but although I have not identified the problem yet, it seems unrelated (and does not throw the same error).

Note that I reported the issue to Apple, but I did not receive any answer. Silence on the wire.

Even though it requires a little of social engineering, it is quite dangerous. Yet another string to add to the bow.

Now the latest version of Apache mod_ssl (2.2) embeds an option to reactivate old way client renegociation :

SSLInsecureRenegotiation on

Check the official doc for more details. With this option activated, you can now safely upgrade openSSL and mod_ssl without breaking your clients. They should have done it from the begining, shouldn’t they ?

The next step will be to move on to the new protocol definitely, to solve for good the CVE-2009-3555 vulnerability. For that we have to wait for the browsers to support it.

Firefox has started to work seriously on it and we can expect some support in the next releases (some settings will be possible through about:config).

They even created a test site. This screenshot was taken from Google Chrome (5.0.366.2, openSUSE repo) which already has support for the SSL protocol :

So I just set up the Shockingly Big IE6 Warning plugin in this blog.

Then I became curious and checked the stats of this site :

So there is still about 9% of our visitors that are running IE 6 and 3% using some rather outdated versions of Firefox.

And, my god, I would have never imagined that Netscape would appear in the list !

Yes, there is still a lot of work to do about security awareness among users.

By default, Firefox 3 has a very annoying setting : it will prompt you with a box to select your certificate, every time the browser access to a file.

I quickly realized that there is not setting in the preference tab to change this behavior. That sucks, really !

Fortunately, it is possible to tweak it within the about:config page. Set the security.default_personal_cert entry with Select Automatically instead of Ask Every Time.

But what a dumb behavior !

It is like the alert page that Firefox displays every time a self-signed certificate is used. I am now wondering if the developers really understood well what a certificate is !

Setting Firefox properly for Client certificate