Aug 282014
 

Our reader Travis sent us the following message:

We have had 2 users this morning hit a Forbes page: hxxp://www.forbes.com/sites/jimblasingame/2013/05/07/success-or-achievement/

And then after being referred from there to: hxxp://ml314.com/tag.aspx?2772014

They are setting off our FireEye web appliance. It is advising that this is an "Infection Match" which I am not entirely familiar with their systems determinations as it is fairly new to us. I called down the source of the link they went to and can submit that as well if you would like it, but I haven't had a chance to look at it yet just beautified it and saved it.

I went ahead and downloaded the "ml314.com" URL using wget, and what comes back is heavily obfuscated Javascript. I am just quoting some excerpts of it below:

(function(a){var g=window.document;var h=[];var e=[];var f=(g.readyState=="complete"||g.readyState=="loaded"||g.readyState=="interactive");var d=null;var j=function(k){try{k.apply(this,e)}catch(l){if(d!==null){d.call(this,l)}}};var c=functi...36);F=p(F,D,B,G,E[1],12,-389564586);G=p(G,F,D,B,E[2],17,606105819);B=p(B,G,F,D,E[3],22,-1044525330);D=p(D,B,G,F,E[4],7,-176418897);F=p(F,D,B,G,E[5],12,1200080426);G=p(G,F,D,B,E[6],17,-1473231341);B=p(B,G,F,D,E[7],22,-45705983);D=p(D,B,G,F,E[8],7,1770035416);F=p(F,D,B,G,E[9],12,-1958414417);G=p(G,F,D,B,E[10],17,-42063);B=p(B,G,F,D,E[11],22,-1990404162);D=p(D,B,G,F,E[12],7,1804603682);F=p(F,D,B,G,E[13],12,-40341101);G=p(G,F,D, ... function f(o){o.preventDefault();o.stopPropagation()}function i(o){if(g){return g}if(o.matches){g=o.matches}if(o.webkitMatchesSelector){g=o.webkitMatchesSelector}if(o.mozMatchesSelector){g=o.mozMatchesSelector}if(o.msMatchesSelector){g=o.msMatchesSelector}if(o.oMat ... try{s=new ActiveXObject("ShockwaveFlash.ShockwaveFlash");p=s.GetVariable("$version").substring(4);p=p.split(",");p=p[0]+"."+p[1]}catch(r){}if(s){q="Flash"}return{name:q,version:

In short: Very obfuscated (not just "minimized"), and a lot of keywords that point to detecting plugin versions. Something that you would certainly find in your average exploit kit. But overall, it didn't quite "add up". Not having a ton of time, I ran it through a couple Javascript de-obfuscators without much luck. The domain "ml314.com" also looked a bit "odd", but lets see when it was registered:

$ whois ml314.com?

   Domain Name: ML314.COM
   Name Server: NS.RACKSPACE.COM
   Name Server: NS2.RACKSPACE.COM
   Updated Date: 22-apr-2013
   Creation Date: 22-apr-2013
   Expiration Date: 22-apr-2018

?Admin Organization: Madison Logic
Admin Street: 257 Park Ave South
Admin Street: 5th Floor

The domain name isn't new, and hosted in what I would call a "decent" neighborhood on the Internet. The owner information doesn't look outright fake, and indeed gives us a bit more information to solve the puzzle. Turns out that "Madison Logic" is in the web advertisement / click through business, so what you are seeing is likely their proprietary Javascript to track users better. 

In the end, I call this a "false positive", but then again, feel free to correct me. This is just one example how sometimes things are not simple "black/white" when it comes to odd Javascript.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Aug 272014
 

Further to the recent story on Memory Trolling for PCI data, I was able to spend one more day fishing in memory, I dug a bit deeper and come up with more fun Credit Card / Memory goodness with our friend the Point of Sale application.

First of all, just searching for credit card numbers returns a lot of duplicates, as indicated in yesterday's story.  In the station and POS application I was working with, it turns out that if you search for the card number string plus the word "Approved", a single line was returned per transaction, with the credit card and PIN.  For instance, to find all Visa card transactions (one record per transaction):

strings memdump.img | grep VISA | grep -i APPROVED  | wc -l         
     323       

In addition, I was able to find several hundred debit card numbers, simply by using those same search concept, but using the term "INTERAC" instead.  Note that this search gets you both the approved and not approved transactions.

strings memdump.img | grep INTERAC | grep -i APPROVED | wc -l
     200

With that done, I started looking at the duplicate data, and realized that some of the duplicate "records" I was tossing out looked interesting - sort of XML-like.   Upon closer inspection, it turns out that they were fully formed MS SQL posts (and no, just as the credit card numbers themselves, I won't be sharing the text of any of those)

Interestingly, the SQL post formatted the credit card numbers as 123456******1234, such that the first 6 and last 4 digits are in clear text,but the middle digits are masked out.  

This lines right up with the PCI 2.0 spec, section 3.3, which indicates that if you mask a PAN (Primary Account Number) that way, it is no longer considered sensitive. (https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf).  I'm not sure how keen I am on 3.3 -  - I can see that storing this info allows the merchant to use that as a "pseudo customer number", so that they can track repeat purchases and so on, but I'm not sure that the benefits outweigh the risks in this case.   I'd much prefer encrypting on the reader itself, so that the merchant and POS software never sees the card number at all - it's encrypted right from the reader to the payment processor (or gateway).

As I said when I started this, I'm not the expert memory carver that some of our readers are - please, use our comment section and tell us what interesting things you've found in a memory image!

===============
Rob VandenBrink
Metafore

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
%d bloggers like this: