ISC StormCast for Friday, September 5th 2014, (Fri, Sep 5th)

Latest Alerts - Thu, 09/04/2014 - 17:18
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Identifying Firewalls from the Outside-In. Or, "There's Gold in them thar UDP ports!", (Thu, Sep 4th)

Latest Alerts - Wed, 09/03/2014 - 19:18

In a penetration test, often the key to bypassing a security control is as simple as knowing identifying the platform it's implemented on.  In other words, it's a lot easier to get past something if you know what it is.  For instance, quite often you'll be probing a set of perimeter addresses, and if there are no vulnerable hosts NAT-ed out for you, you might start feeling like you're at a dead end.   Knowing what those hosts are would be really helpful right about now.  So, what to do next?

Look at UDP, that's what.  Quite often scanning the entire UDP range will simply burn hours or days with not a lot to show for it, but if you target your scans carefully, you can quite often get some good information in a hurry.

Scanning NTP is a great start.  Way too many folks don't realize that when you make a network device (a router or switch for instance) an NTP client, quite often you also make it an NTP server as well, and NTP servers love to tell you all about themselves.  All too often that port is left open because nobody knows to block it.  

Another service that quite often bypasses all firewall ACLs is the corporate remote access IPSEC VPN specifically IKE/ISAKMP (udp/500).  Even if this is a branch firewall with a site-to-site VPN to head office, often IKE is misconfigured to bypass the interface ACL, or the VPN to head office is enabled with a blanket "any any" permit for IKE.

Let's take a look at these two sevices - we'll let's use NMAP to dig a little deeper.  First, let's scan for those ports:

nmap -Pn -sU -p123,500 --open x.x.x.x
Starting Nmap 6.46 ( ) at 2014-08-29 12:13 Eastern Daylight Time

Nmap scan report for (x.x.x.x)
Host is up (0.070s latency).
123/udp open  ntp
500/udp open  isakmp

Nmap done: 1 IP address (1 host up) scanned in 46.69 seconds

OK, so we found open UDP ports - how does this help us?  Let's run the SECOND set of scans against these two ports, starting with expanding the NMAP scan to use the ntp-info script:

C:\ > nmap -Pn -sU -p123 --open x.x.x.x --script=ntp-info.nse

Starting Nmap 6.46 ( ) at 2014-08-29 12:37 Eastern Daylight Time

Nmap scan report for (x.x.x.x)
Host is up (0.042s latency).
123/udp open  ntp
| ntp-info:
|   receive time stamp: 2014-08-29T16:38:51
|   version: 4
|   processor: unknown
|   system: UNIX
|   leap: 0
|   stratum: 4
|   precision: -27
|   rootdelay: 43.767
|   rootdispersion: 135.150
|   peer: 37146
|   refid:
|   reftime: 0xD7AB23A5.12F4E3CA
|   poll: 10
|   clock: 0xD7AB2B15.EA066B43
|   state: 4
|   offset: 11.828
|   frequency: 53.070
|   jitter: 1.207
|   noise: 6.862
|_  stability: 0.244

Nmap done: 1 IP address (1 host up) scanned in 48.91 seconds

Oops - ntp-info not only tells more about our host, it also discloses the NTP server that it's syncing to - in this case check that host IP in red - that's an internal host.  In my books, that can be rephrased as "the next target host", or maybe if not next, at least on the list "for later".  Interestingly, support for ntp-info requests positions this host nicely to act as an NTP reflector/amplifier, which can then be used in DDOS spoofing attacks.  The send/receive ration is just under 1:7 (54 bytes sent, 370 received), so not great, but that's still a 7x amplification which you can spoof.

Back to the pentest - ntp-info gives us some good info, it doesn't specifically tell us what OS our target host is running, so let's take a look at IKE next, with service detection enabled:

C: \> nmap -Pn -sU -p500 -sV --open x.x.x.x

Starting Nmap 6.46 ( ) at 2014-08-29 13:10 Eastern Daylight Time

Nmap scan report for (x.x.x.x)
Host is up (0.010s latency).
500/udp open  isakmp
Service Info: OS: IOS 12.3/12.4; CPE: cpe:/o:cisco:ios:12.3-12.4

Service detection performed. Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 159.05 seconds

Ah - very nice!  Nmap correctly tells us that this device is a Cisco Router (not an ASA or any other device)

The ike-scan utility should give us some additional IKE info, let's try that with a few different options:

A basic verbose assess (main mode) gives us nothing:

C: > ike-scan -v x.x.x.x
DEBUG: pkt len=336 bytes, bandwidth=56000 bps, int=52000 us
Starting ike-scan 1.9 with 1 hosts (
x.x.x.x    Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=ea1b111d68fbcc7d)

Ending ike-scan 1.9: 1 hosts scanned in 0.041 seconds (24.39 hosts/sec).  0 returned handshake; 1 returned notify

Ditto, main mode IKEv2:

C: > ike-scan -v -2 x.x.x.x
DEBUG: pkt len=296 bytes, bandwidth=56000 bps, int=46285 us
Starting ike-scan 1.9 with 1 hosts (
---     Pass 1 of 3 completed
---     Pass 2 of 3 completed
---     Pass 3 of 3 completed

Ending ike-scan 1.9: 1 hosts scanned in 2.432 seconds (0.41 hosts/sec).  0 returned handshake; 0 returned notify

with just nat-t, still nothing:

C: > ike-scan -v -nat-t x.x.x.x
DEBUG: pkt len=336 bytes, bandwidth=56000 bps, int=52000 us
Starting ike-scan 1.9 with 1 hosts (
x.x.x.x    Notify message 14 (NO-PROPOSAL-CHOSEN) HDR=(CKY-R=ea1b111d8198ef48)

Ending ike-scan 1.9: 1 hosts scanned in 0.038 seconds (26.32 hosts/sec).  0 returned handshake; 1 returned notify

Aggressive mode however is a winner-winnner-chicken-dinner!

C: > ike-scan -v -A x.x.x.x
DEBUG: pkt len=356 bytes, bandwidth=56000 bps, int=54857 us
Starting ike-scan 1.9 with 1 hosts (
x.x.x.x    Aggressive Mode Handshake returned HDR=(CKY-R=ea1b111d4f1622a2)
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=2
8800) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=afcad71368a1f1c96b8
696fc77570100 (Dead Peer Detection v1.0) VID=1fdcb6004f1722a231f9e4f59b27b857 VI
D=09002689dfd6b712 (XAUTH) KeyExchange(128 bytes) ID(Type=ID_IPV4_ADDR, Value=x.x.x.x) Nonce(20 bytes) Hash(20 bytes)

Ending ike-scan 1.9: 1 hosts scanned in 0.068 seconds (14.71 hosts/sec).  1 returned handshake; 0 returned notify

We see from this that the remote office router (this is what this device is)  is configured for aggressive mode and XAUTH - so in other words, there's likely a userid and password along with the preshared key to authenticate the tunnel.  Note that ike-scan identifies this host as "Cisco unity", so while it gives us some new information, for basic device identification, in this case NMAP gave us better info.

What should you do to prevent scans like this and the exploits based on them?  The ACL on your perimeter interface might currently end with a "deny tcp any any log" - consider adding on "deny udp any any log", or better yet, replace it with "deny ip any any log".  Permit *exactly* what you need, deny everything else, and just as important - LOG everything that gets denied.  Logging most of what is permitted also is also a good idea - if you've ever had to troubleshoot a problem or backtrack a security incident without logs, you are likely already doing this.

Adding a few honeypots into the mix is also a nice touch.  Denying ICMP will often defeat scripts or cursory scans.  Many network devices can be configured to detect scans and "shun" the scanning host - test this first though, you don't want to block production traffic by accident with an active control like this.

Have you found something neat in what most might otherwise consider a common and relatively "secure" protocol?  Please, use our diary to share your story !

Rob VandenBrink

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, September 4th 2014, (Thu, Sep 4th)

Latest Alerts - Wed, 09/03/2014 - 17:00
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

F5 BigIP Unauthenticated rsync Vulnerability, (Wed, Sep 3rd)

Latest Alerts - Wed, 09/03/2014 - 05:39

The reason I decided to write up this vulnerability is not the fact that this is a very popular system, or that there is a huge risk here. The main reason is that it struck me with a certain amount of sadness that we still have to deal with this problem in 2014. For example, I found an rsync configuration guide from 1999 that recommends the use of rsync over ssh [1].

F5 uses rsync to synchronize configurations if the BigIP load balancer is used in high availability mode. Sadly, the rsync server that is used for this does not require any authentication. As a result, an attacker can upload and download arbitrary files. The proof of concept exploit uploads an "authorized_keys" file permitting the attacker to ssh to the device and obtaining full shell access. In order to be vulnerable, the interface used to synchronize the devices has to be exposed [2].

F5 made a patch available [3].

But I think the lesson is larger then "Patch F5". This is about not forgetting history. In many of our classes, a complaint is why we include some older vulnerabilities. For example our "Securing Unix" class is going over some of the issues with "r" services like "rsh" and how to automate almost anything using ssh. 

What should you do? As a first step, a quick scan of your network for open rsync servers (port 873 tcp). Next, if you use ssh as you should, take a look at how you manage ssh keys as this is the next big problem. Are you keeping your secret keys in one (and only one) secure spot? Do you use different keys for different purposes? This can be a larger project to work out and implement correctly.



Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, September 3rd 2014, (Wed, Sep 3rd)

Latest Alerts - Tue, 09/02/2014 - 17:28
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Firefox 32 released, time to update - now with support for Public Certificate Pinning. Release notes here:, (Tue, Sep 2nd)

Latest Alerts - Tue, 09/02/2014 - 16:01

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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

"Death" of Internet Services, (Tue, Sep 2nd)

Latest Alerts - Tue, 09/02/2014 - 08:13

No, we're not talking about 1940's literature today - I've been reading, as have many, that Microsoft is planning to finally stop the venerable MSN Messenger Chat service. I find it interesting that the press is touting that MSN has few users left.  This might be true in our community, and I wouldn’t doubt that almost every demographic has moved away from MSN to other chat services like SMS on phones, Facebook, Skype, Twitter or whatever.

But maybe Toronto is an internet backwater or something – for every IPS stand up or egress filter I configure, in any company I’ll still find a handful of MSN Messenger users.  While we're seeing generally low activity on the main port used by MSN (1863) , we still see spikes in traffic -

Do internet services ever die naturally?  It seems to me that folks hang on to what they know like grim death, and only give up services when they’re terminated forcibly.  

As a penetration tester, these older services can be a gold mine.  To me, older services (not to pick on any one service in particular) quite often are clear-text, so if you can get a clean packet capture then you've got a very good shot at harvesting credentials.  And we know for a fact that folks will tend to re-use credentials - userid's are easy to derive, but if you can harvest passwords on one service, you've got an excellent chance at re-using them to compromise another application or service.

Again, I'm not sure if it's just me, but I also tend to see that users of these older "consumer" type applications like this for some reason seem to be clustered in the upper echelons of many companies.  In other words, some of the best targets (politically at least) are using some of the most easily compromised applications.

Password re-use, prefering old/known applications to new ones, and "user clustering" around older apps - are you seeing this same trends?  

Did xkcd get it right?

Please, use our comment form and let us know what you're seeing, both on MSN messenger or on other "old" internet applications!

Rob VandenBrink

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Apple iCloud Security Incident, (Tue, Sep 2nd)

Latest Alerts - Tue, 09/02/2014 - 03:57

There's lots of interest in the recent iCloud incident, where apparently several "celebrity" accounts were compromised.

Sorry to say, it's not a rumour.  It's also something that could and should have been prevented.  It turns out that the API for the "Find My iPhone" app did not have protections against brute force attacks.

This, combined with the first couple hundred lines of a common password dictionary (often downloaded as the filename  "500 worst passwords") resulted in some targeted accounts being compromised.  And of course once an account password is successfully guessed, all iCloud data for that account is available to the attackers.  So no rocket science, no uber hacking skills.  Just one exposed attack surface, basic coding skills and some persistence.

Having gone through that password file, you really wonder how much folks using any of those passwords valued their data in the first place.

Apple quickly fixed the vulnerability, so it is no longer in play (unless your account was compromised prior to the mitigation and you haven't changed your password).  The code is on github if you are interested.

This just reinforces the common theme that - to put it mildly - trusting personal data to simple passwords is not recommended.  If you can't use complex passwords (for me, that's greater than 15 characters) or don't have a second factor, then don't use the service.

Rob VandenBrink

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, September 2nd 2014, (Tue, Sep 2nd)

Latest Alerts - Mon, 09/01/2014 - 17:46
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Dodging Browser Zero Days - Changing your Org's Default Browser Centrally, (Mon, Sep 1st)

Latest Alerts - Mon, 09/01/2014 - 09:09

In a recent story about "what's a sysadmin to do?", we suggested that since our browsers seem to take turns with zero days lately, that system administrator should have processes in place to prepare for when their corporate standard browser has a major vulnerability that doesn't yet have a patch.  Administrators should be able to "push" out a change for their user community's default browser within a few minutes of a zero day being confirmed.

So - How exactly would you do this in an Active Directory Domain?

First of all, have a desktop or start menu shortcut that uses http:// or https:// - usually pointed to one or more corporate applications.  It's not uncommon to also see corporate web apps in the start menu.   Be sure that none of these links point to the programs themselves, just the URI's.  This gets folks in the habit of punching that shortcut every morning (or or having it auto-start for them), starting them off on the right foot - with the browser you've selected for them.  Having people start their browser by the actual link to the executable defeats the purpose of setting the defaults.

It turns out that the default browser can be changed by updating just 5 registry keys - the prefered application for htm and html files, as well as the prefered application for the ftp, http and https protocols.


============ Registry keys for Firefox  - reg-ff.reg ==============


============  Registry keys for Internet Explorer - reg-ie.reg ==============


============  Registry keys for Chrome - reg-goo.reg ==============



You can dig and find lots of other registry keys that will influence the browser, but these 5 will nail most things in a hurry - which is the goal.  You can also find more reg keys that will change the default browser, but these are the keys set by control panel (in Windows 7 anyway), so for me they're likely the safest keys - the ones that, for today at least, will be most likely to work most reliably for most environments.

So, what's the easiest way to push these settings out?   There are a few ways to go.  First, save the above into 3 different text based REG files

The easiest way in my book is to update everyone's startup - in a Group Policy, add the following to User Configuration / Windows Settings / Scripts (Logon/Logoff)

registry /s browser-chrome.reg  (or whichever REG is your target).

The trick then is to get folks to logout and login - hopefully you are forcing folks to logout each day by setting a hard logout time (a good thing to consider if you're not doing that today), so if you get your change in before folks typically start, they'll get your update.

If you need to push this out with GPO in mid-stream, you can set registry keys directly in Group Policy, under GPO > User Configuration > Preferences > Windows Settings > Registry

Microsoft publishes a "right way" to set the default browser on a few different pages, but it typically involves importing settings from a known correct station ( ).  This can be a problem if you've got multiple operating systems or want a more script-controlled approach.

There are certainly many other ways to push settings out using Group Policy (using ADM/ADMX files for instance), or by scripting using sysinternals or powershell commands.  The sysinternals approach has a lot of appeal because many admins already have a sysinternals "go fix it" approach already in their toolbelt.  Powershell appeals because it's the whiz-bang-shiny new tool, but lots of admins are still learning this language, so it might not fall into the "get it done quick" bucket so neatly.  ADMs will absolutely do the job nicely - I didn't have the time to cobble together and ADM or ADMX file for this, but will give it a shot over the next few days (unless one of our readers beats me to it that is!)

Once set, each browser can be configured using group policy using a vendor-supplied or open-source ADM or ADMX file.  Import the vendor file ADM(X) into GPO, and you'll be able to configure or restrict 3rd party browsers just as easily as you do IE.

This article was meant more as set of a "quick and dirty" ways to make this change for a large number of your user community in a hurry.  If you've got a neat script or an ADM file that does this job in a more elegant way than I've described, please, share using our comment form!


Rob VandenBrink 

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

1900/UDP (SSDP) Scanning and DDOS, (Sun, Aug 31st)

Latest Alerts - Sun, 08/31/2014 - 07:50

Over the last few weeks we have detected a significant increase in both scanning for 1900/UDP and a huge increase of 1900/UDP being used for amplified reflective DDOS attacks.  1900/UDP is the Simple Service Discovery Protocol (SSDP) which is a part of Universal Plug and Play (UPnP). The limited information available to me indicates that the majority of the devices that are being used in these DDOS attacks are DLink routers, and some other devices, most likely unpatched or unpatchable and vulnerable to the UPnP flaws announced by HD Moore in January of 2013.

In the corresponding interval we have also seen a significant decrease in Network Time Protocol (NTP) based DDOS.  The big question in my mind is why have the attackers decided to switch from NTP, which has a maximum amplification factor of 600 plus, to SSDP which has an amplification factor of approximately 30.

If anybody has any more information on this, or even better yet, packet captures from one of the devices being used as a reflector, please let me know!

-- Rick Wanner - rwanner at isc dot sans dot edu - - Twitter:namedeplume (Protected)

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Friday, August 29th 2014, (Fri, Aug 29th)

Latest Alerts - Thu, 08/28/2014 - 17:12
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

False Positive or Not? Difficult to Analyze Javascript, (Fri, Aug 29th)

Latest Alerts - Thu, 08/28/2014 - 16:36

Our reader Travis sent us the following message:

We have had 2 users this morning hit a Forbes page: hxxp://

And then after being referred from there to: hxxp://

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 "" 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){,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 "" also looked a bit "odd", but lets see when it was registered:

$ whois​

   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.

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Thursday, August 28th 2014, (Thu, Aug 28th)

Latest Alerts - Wed, 08/27/2014 - 17:44
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

One More Day of Trolling in POS Memory, (Wed, Aug 27th)

Latest Alerts - Wed, 08/27/2014 - 15:36

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         

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

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. (  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

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Microsoft has modified and re-released MS14-045 - /, (Wed, Aug 27th)

Latest Alerts - Wed, 08/27/2014 - 14:59
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Wednesday, August 27th 2014, (Wed, Aug 27th)

Latest Alerts - Tue, 08/26/2014 - 18:40
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

ISC StormCast for Tuesday, August 26th 2014, (Tue, Aug 26th)

Latest Alerts - Mon, 08/25/2014 - 17:33
(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Point of Sale Terminal Protection - "Fortress PCI at the Mall", (Tue, Aug 26th)

Latest Alerts - Mon, 08/25/2014 - 17:13

This is a very broad topic, but over the last few months I've seen some really nicly protected PCI termainls.  Especially since many POS environments are still running Windows XP, this is an important topic to discuss.

Things that I've seen done very well:

First of all, only allow access to the POS app - retail staff generally don't require access to email or the internet, at least not from the sales terminal.  Most POS systems I've seen are running kiosk setups, which removes explorer, the start button and kills all hotkeys.  I'm often able to break out of windows kiosk applications from the keyboard by using a hotkey combination that's been missed.  For instance, Windows+U calls utilman.exe in XP, if you replace utilman with cmd.exe you are in.  Be sure to account for hot-keys!

If you lock down the POS terminals such that a CMD prompt / start menu and so on are not accessible, then the classic "usb rubber ducky" or "teensy" keyboard as a usb key type attack - where you drop a usb key into and exposed port while making a purchase - is that much tougher.  If you can't get a cmd prompt or some field to enter commands, a malicious keyboard attack of this type isn't likely to succeed.

On that same note, use GPO or your endpoint protection product to lock down USB access.  Even if (or maybe especially if) a repair tech needs USB access, inserting a USB device should need a call to head office.

Use network protections:
The local router generally establishes a VPN to head office
The POS terminal should not have internet access
The POS terminal should have only limited access to head office resources (typically a small DMZ for data collection)
Similarly, only required head office resources should have access to the POS terminal
The POS terminal should not  be on the same network as or have access to the rest of the store.  For instance, guest wireless, security cameras, alarm systems and so on should all be in VLANs other than the POS VLAN, and none of those should have access to the POS (and vice versa)

For goodness sake, harden your store's firewall/router, and use a template (that you audit) so that you know that they are all configured correctly!  Hardening guides are available for most platforms, the Center for Internet Security's hardening guide for Cisco is a solid one to use as a guide if your perimeter device doesn't have a vendor supplied document.  Though if your firewall/router vendor doesn't have security guidance, maybe you should look at a different solution ...

If your POS terminal tries to connect to an IP that isn't yours, that's an IOC (Indicator of Compromise) - even a simple DNS query to a "different" server can be a giveaway.  If you see unexplained traffic, it's worth investigating - whitelisting stuff like this to make the alert go away is a BAD IDEA!

Use endpoint protections to your advantage.  That means AV, whitelisting and every other EP feature.  Don't install an AV product and leave it at the defaults, tune it for your POS systems.  While you can certainly circumvent AV using SET, Metasploit, VEIL and so on, that's a moving target.  What might work today to evade one AV vendor might very well not work tomorrow.  PLus you'll find that getting a generic application to evade AV is tough - most of the Metasploit evasion techniques top out at a fairly small memory footprint (4K in a lot of cases)

A distributed IPS is the way to go. With hundreds or in some cases thousands of terminals, you need an IPS local to each terminal to detect IOCs as early in the process as possible.  

Secure your passwords, have a good password policy in the OS, and / or use 2 factor
Don't re-use admin passwords.  If an attacker can get mimikatz on your system, or use procdump to get an lsass memory image, then (on XP), you've likely given up most of the passwords on that system.  Even without that, once you get password hashes, anyone who's serious can use GPUs and crack all the local passwords within a few minutes (or a few days if they have to go with brute force).  
Don't store passwords under the keyboard.  In almost every POS engagement, I can lift up the keyboard and have immediate access.  It's to the point that I include that photo in my reports.  Granted, in most stores getting to the keyboard can be a challenge, but if you show up with a laptop bag and say "I'm with IT, Joe (or whoever the IT Director is) sent me", you'd be surprised how much help you'll get from the sales folks.

Keep on top of current POS malware, especially the IOCs for each (the recent backoff malware is a good example).   This week's alert from the US CERT no the new backoff variants is a good read for instance (  The copious amount of discussion on the Target breach (and the associated BlackPOS malware) is another place to look.

Each of these protections in themselves can be circumvented.  But the more you layer on, the better  The harder you make your attacker work to penetrate your environment, the more likely they will target someone else.  Your goal is to make things as difficult for the attacker as possible, to force them to make as much "noise" - ie generate as many alarms- as possible as they work their way in, to give you a chance at blocking them at one point or another

This is just a start at protecting a POS system or netowrk.  This is meant as the start of a disucssion - I'd be very interested to know what else folks are doing to secure their terminals.  Please use our comment form to share your approaches!

Rob VandenBrink, Metafore

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Trolling Memory for Credit Cards in POS / PCI Environments, (Tue, Aug 26th)

Latest Alerts - Mon, 08/25/2014 - 17:06

In a recent penetration test, I was able to parlay a network oversight into access to a point of sale terminal.  Given the discussions these days, the next step for me was an obvious one - memory analysis.

My first step was to drive to the store I had compromised and purchase an item.

I'm not a memory analysis guru, but the memory capture and analysis was surprisingly easy.  First, dump memory:
Yup, it's that simple, I had the dumpit executable locally by that point (more info here
or, if you don't have keyboard access (dumpit requires a physical "enter" key, I/O redirection won't work for this):
win32dd /f memdump.img
(from the SANS Forensics Cheat Sheet at )

Next, I'll dig for my credit card number specifically:

strings memdump.img | grep [mycardnumbergoeshere] | wc -l

Yup, that's 171 occurences in memory, unencrypted.  So far, we're still PCI complaint - PCI 2.0 doesn't mention cardholder data in memory, and 3.0 only mentions it in passing.  The PCI standard mainly cares about data at rest - which to most auditors means "on disk or in database", or data in transit - which means on the wire, capturable by tcpdump or wireshark.  Anything in memory, no matter how much of a target in today's malware landscape, is not an impact on PCI compliance.

The search above was done in windows, using strings from SysInternals - by default this detects strings in both ASCII and Unicode.  If I repeat this in linux (which by default is ASCII only), the results change:
strings memdump.img | grep [mycardnumbergoeshere] | wc -l

To get the rest of the occurences, I also need to search for the Unicode representations,  which "strings" calls out as "little-endian" numbers:
strings -el memdump.img | grep [mycardnumbergoeshere] | wc -l

Which gives me the same total of 171.

Back over to windows, let's dig a little deeper - how about my CC number and my name tied together?
strings memdump.img | grep [myccnumbergoeshere] | grep -i vandenbrink | wc -l

or my CC number plus my PIN  (we're CHIP+PIN in Canada)
strings memdump.img | grep [mycardnumbergoeshere] | grep [myPINnumber]

Why exactly the POS needs my PIN is beyond me!

Next, let's search this image for a number of *other* credit cards - rather than dig by number, I'll search for issuer name so there's no mistake.  These searches are all using the Sysinternals "strings" since the defaults for that command lend itself better to our search:

CAPITAL ONE       85
VISA             565
MASTERCARD      1335

and for kicks, I also searched for debit card prefixes (I only search for a couple with longer IIN numbers):
Bank of Montreal   500766     245
TD CAnada Trust    589297    165

Looking for my number + my CC issuer in the same line gives me:
strings memdump.img | grep [myccnumbergoeshere] | grep [MASTERCARD] | wc -l
gives me a result of "5"

So, assuming that this holds true for others (it might not, even though the patterns are all divisible by 5), this POS terminal has hundreds, but more likely thousands of valid numbers in memory, along with names, PIN numbers and other informaiton

Finally, looking for a full magstripe in memory:

The search for a full stripe:
grep -aoE "(((%?[Bb]?)[0-9]{13,19}\^[A-Za-z\s]{0,26}\/[A-Za-z\s]{0,26}\^(1[2-9]|2[0-9])(0[1-9]|1[0-2])[0-9\s]{3,50}\?)[;\s]{1,3}([0-9]{13,19}=(1[2-9]|2[0-9])(0[1-9]|1[0-2])[0-9]{3,50}\?))" memdump.img  | wc -l


    -a = Processes a binary file as text
    -o = Shows only the matched text
    -E = Treats the pattern as an extended regular expression

or using this regex to find Track strings only:

gives us 0 results.

or this regex to find Track 2 strings only:

Gives us 162  (I'm not sure how much I trust this number)

Anyway, what this tells me is that this store isn't seeing very many folks swipe their cards, it's all CHIP+PIN (which you'd expect)

(Thanks to the folks at bromium for the original regular expressions and breakdown:

Getting system uptime (from the system itself) wraps up this simple analysis - the point of this being "how long does it take to collect this much info?"

net statistics server | find "since""
shows us that we had been up for just under 4 days.

Other ways to find uptime?
from the CLI:
systeminfo " find "Boot Time"
or, in powershell:
PS C:\> Get-WmiObject win32_operatingsystem | select csname, @{LABEL='LastBootUpTime';EXPRESSION={$_.ConverttoDateTime($_.lastbootuptime)}}
or, in wmic:
wmic get os last bootuptime
or, if you have sysinternals available, you can just run "uptime"

What does this mean for folks concerned with PCI compliance?
Today, not so much.  Lots of environments are still operating under PCI 2.0.  PCI 3.0 simply calls for education on the topic of good coding practices to combat memory scraping.  Requirement 6.5 phrases this as "Train developers in secure coding techniques, including how to avoid common coding vulnerabilities, and understanding how sensitive data is handled in memory.  Develop applications based on secure coding guidelines."

Personally (and this is just my opinion), I would expect/hope that the next version of PCI will call out encryption of card and personal information in memory specifically as a requirement.  If things play out that way, What this will mean to the industry is that either:
a/ folks will need to move to card readers that encrypt before the information is on the POS terminal
b/ if they are using this info to collect sales / demographic information, they might instead tokenize the CC data for the database, and scrub it from memory immediately after.  All  I can say to that approach is "good luck".  Memory management is usually abstracted from the programming language, so I'm not sure how successful you'd be in trying to scrub artifacts of this type from memory.

Rob VandenBrink, Metafore

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts
Syndicate content