We've received multiple reports regarding impact to UltraDNS services which are allegedly the result of a 100Gb/s attack on one of their customers, which in turn is causing latency for others. Monitor #ultradns for the time being as no official report has been released yet by UltraDNS. One reporting party did indicate that they learned that the management of UltraDNS had said that one of their customers was being attacked and that they black-holed that customer to get back on trend. Resolver nodes around the world are resetting.

We'll update here as we learn more.

Update as of 1045 PST: UltraDNS is still not stable as customers are still having intermittent DNS resolution failures

Update as of 1100 PST: UltraDNS still propagating changes from the attack this morning and hope to be complete as of approximately 11:30 PST. Intermittent issues still remain for customers. Always a bit ironic when those who sell DDoS protection are themselves adversely impacted by DDoS. :-)

Update as of 1240 PST: Direct quote from Neustar UltraDNS - "Currently, the Neustar UltraDNS Operations and Security teams continue to work with our Tier One Providers to further refine upstream mitigations within the Carriers networks. Additionally, the Neustar team is working on adding additional UltraDNS Name Servers into active mitigation. The DDoS traffic continues to shift attack vectors and our teams are working on altering countermeasures to insure stability of
service as quickly as possible.
At Neustar, we are committed to providing the highest levels of performance and reliability through the products and solutions we deliver. Please feel free to contact our 24x7 UltraDNS Support Team at ultrasupport@Neustar.biz with any questions or concerns."

Update as 1400 PST: "The Neustar UltraDNS Operations and Security teams have the majority of the UltraDNS customer base in mitigation on our DDoS mitigation
network. Currently, only customers utilizing a segment of UltraDNS Name Server addresses (PDNS1-PDNS6) are experiencing resolution latency due to intermittent network saturation in the Western US. We continue to aggressively refine mitigations for these customers and hope to have the issue resolved shortly."

NOTE: Customers are indicating that Neustar UltraDNS has been providing constant updates (5 or 6 now) which should be seen as a positive response to a difficult situation.

Update as of 2300 PST: "As of 00:26 GMT on May 1st, DNS traffic for customers on the PDNS1-PDNS6 Name Server segment has been resolving and stable. While we currently have no network related alerts or customer identified issues, the PDNS1-PDNS6 announcements will remain on the Neustar SiteProtect network and all proactive mitigations will continue to be active until Neustar deems the potential threat to be closed. Customers on non-PDNS announcements segments did experience higher than normal latency and DNS time outs as a side effect of this event, however, those announcements were stabilized as of 1849 GMT. The Neustar Network and Security Operations teams continue to monitor traffic on both the SiteProtect and UltraDNS network closely in case of a renewal of the attack traffic. A full Incident Report will be provided to customers as soon as possible once we complete our investigation with our internal teams and network providers."

Russ McRee | @holisticinfosec

We got an email from one of our readers, including an interesting port 53 packet. While Wireshark and TCPDump try to decode it as DNS, it is almost certainly not DNS. 

The payload of the packet is (I obfuscated the country the user is located in):

oracle:1c6F65E41DFC:www.kmplayer.com:192.168.1.2:[country of system]:SYSTEM:Windows XP:V139

The user does not have KMPlayer or Oracle installed in his network. This looks very much like some form of command and control traffic. At this point, we do not have any malware associated with it.

Here is how tcpdump decoded the packets (again, anonymized): 

$ tcpdump -r strange-udp.pcapng -nAt
reading from file strange-udp.pcapng, link-type EN10MB (Ethernet)
IP a.b.c.d.20510 > w.x.y.z.53: 28530 updateM+ [b2&3=0x6163] [14897a] [27749q] [25398n] [17974au][|domain]
oracle:1c6F65E41DFC:www.kmplayer.com:192.168.1.2:[country]:SYSTEM:Windows XP:V139.
IP a.b.c.d.11185 > w.x.y.z.53: 28530 updateM+ [b2&3=0x6163] [14896a] [27749q] [12337n] [17988au][|domain]
oracle:001FD0309751:www.kmplayer.com:192.168.1.102:doubleup-xp:SYSTEM:Windows XP:V139

The source was an RFC 1918 address in this case, and the target was close to the user's IP address, which is why both are anonymized here. I also removed the non printable part of the payload to make it fit the screen.

I installed KMPlayer on a virtual system and didn't see any traffic like this. 

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

ISC Handler Rob let us know that @hdmoore Tweeted out: "Upgraded to Ubuntu 14.04? Hold down enter to bypass the lockscreen (what is old is new again): https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1308572 â€¦"

The reporter indicates that he was running Ubuntu 14.04 with all the packages updated.
When the screen is locked with password, if holding ENTER, after some seconds the screen freezes and the lock screen crashes. After that the computer is fully unlocked.

The initial report states that the "bug is about the lockscreen being bypassed when Unity crashes/restarts, which is a critcal security issue. The crash will be handled from bug 1308750."

From the bug tracker, the fix has been committed and released. Be cognitive of this issue should you leave an Ubuntu 14.04 host unattended. :-)

Russ McRee | @holisticinfosec

Microsoft released a Security Advisory yesterday(1) which impacts Internet Explorer versions 6 through 11, taking advantage of a vulnerability in Flash.  The Microsoft advisory notes  that “The vulnerability is a remote code execution vulnerability. … The vulnerability may corrupt memory in a way that could allow an attacker to execute arbitrary code in the context of the current user within Internet Explorer. An attacker could host a specially crafted website that is designed to exploit this vulnerability through Internet Explorer and then convince a user to view the website.” 

This exploit is currently being seen in limited attacks at this time against versions IE9-IE11, according to the security vendor Fireeye(2), who is working with MS at this time.  At the time of this writing, a patch is not yet available.

Actions to take to limit the impact of the vulnerability:

- Install EMET . According to Fireeye's testing, EMET 4.1 and 5 do break the exploit.

- Disable Flash . Note that IE 10 and later on Windows 8 do include Flash. But you can still disable it. This is an IE vulnerability but Flash is needed to exploit it and bypass some of the protection techniques implemented in newer versions of IE/Windows.

- Enable the Internet Explorer "Enhanced Protection Mode" (EPM) which became available in Internet Explorer 10. But it may break some plugins.

 

(1)https://technet.microsoft.com/en-US/library/security/2963983

(2)http://www.fireeye.com/blog/uncategorized/2014/04/new-zero-day-exploit-targeting-internet-explorer-versions-9-through-11-identified-in-targeted-attacks.html

tony d0t carothers --gmail

Weekends are usually a good time to catch up on the dreaded “D” word of IT professionals everywhere…. Documentation.  Security is a process, and as such requires good documentation to drive those processes.  All organizations have (or should have) documentation to support their efforts and guide their work, typically in the form of a Site Security Plan, Change Control processes, Roles and Responsibilities, etc., etc. These process are in place to support constantly changing systems.  Updating the documentation is often a painful process that is left for less mundane and intriguing tasks, thus it is relegated to weekend work.  

 

The landscape of technology, requirements, threats, and vulnerabilities is changing every day, so the processes we use to support these need to adapt as well.  One key to managing the documents is establishing an annual review process of the document library.  These reviews can be broken up over the calendar year, to spread out the work; the larger documents can be sectioned out to team members for draft input and review over a period of time.  The review process, if possible, should include an objective review from a peer or colleague to assist in providing objective feedback and analysis.

 

Any process works best when it is known, documented, and implemented, and Security processes require the same care and feeding as the systems they serve.  

tony d0t carothers --gmail

 

After the OpenSSL Heartbleed vulnerability [1] that sent lots of products scrambling to issue a patch to prevent data leakage, the Linux Foundation formed a new initiative [2] with some of the major technologies leaders, to support critical open source projects to like OpenSSL to provide funding and ensure greater reliability.

"The first project under consideration to receive funds from the Initiative will be OpenSSL, which could receive fellowship funding for key developers as well as other resources to assist the project in improving its security, enabling outside reviews, and improving responsiveness to patch requests."[2]

Do you think this kind of initiative will improve open source project?

[1] https://isc.sans.edu/diary.html?storyid=17917
[2] http://www.linuxfoundation.org/news-media/announcements/2014/04/amazon-web-services-cisco-dell-facebook-fujitsu-google-ibm-intel

-----------

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

It has been reported that Bitcoin mining malware has been found in the Google Play store. If your battery is draining faster than usual, your phone maybe running a copy of the BadLepricon Bitcoin mining malware. "The malware comes in the form of a wallpaper app. Google promptly removed five of these applications after we alerted them to the issue. The apps had between 100-500 installs each at the time of removal."[1]

[1] https://blog.lookout.com/blog/2014/04/24/badlepricon-bitcoin/

-----------

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

Thanks to Gebhard for letting us know about a new vulnerability in Apache Struts.

If you recall the classloader vulnerability of few months ago, the fix for that seems to be case and punctuation sensitive (using [] instead of "."  was not accounted for)

In any case, they have posted a mitigation how-to here: http://struts.apache.org/announce.html#a20140424

This affects all versions up to 2.3.16.1

Find more information on this here:
http://www.pwntester.com/blog/2014/04/24/struts2-0day-in-the-wild/

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

 

As systems administrators and security folks, we've all had our fill of our users and customers using simple passwords.  Most operating systems these days now enforce some level of password complexity by default, with options to "beef up" the password requirements for passwords.

The prevailing wisdom today is to use passphrases - demonstrated nicely by our bud at xkcd - http://xkcd.com/936/

So I routinely have very long pass phrases for public facing accounts.  Imagine my surprise when I was creating a new account on major cloud service (the one that starts with an "O" and ends with a "365"), and found that I was limited to a 16 character password. 

Needless to say I have a case open to see if that limit can be removed.  I'm not looking for no limit / invitation to a buffer overflow status on the password field, but something bigger than 16 would really be appreciated !

 

 

After some fun and games at one customer site in particular, I found that the SSL services on the earlier versions of the HP Proiliant Servers iLo ports (iL01 and iLO2) are not susceptible to heartbleed.

However, their implementation of SSL is fragile enough that scanning them for the Heartbleed vulnerability will render them inoperable.  This affects Proliants from G1 all the way up to G6, as well as many of the HP Bladesystems. 

A complete power down of the entire system - as in remove both of the AC cables - is required to reset the iLo card and bring it back to life.  While this may seem  like a quick fix for a single server, if that server is running a Hypervisor, or if it's a bladesystem with Hypervisors running on the blades, this can multiply to be a huge issue.  Especially if your client scanned the server subnet, and effectively bricked all their iLO cards before they realized there was a problem (oops)

(And yes, the fact that we worked this out Easter weekend is somewhat ironic.)

Full details are in HP Support Document c04249852

This illustrates that even when scanning for simple things (with NMAP, Nessus or any other scanning tool really), it's best to scan a few test systems first - or if you have a test VLAN that replicates your production systems, even better!   This isn't a problem with the scanners, almost always the problem is the fragility of the service being scanned.  Many services are only written to deal with "the right" inputs, which is not how most scanners (or most attackers) tend to operate.

Safe Scanning Everyone!

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

In IPv6, DHCP is taking somewhat a back seat to router advertisements. Many smaller networks are unlikely to use DHCP. However, in particular for Enterprise/larger networks, DHCPv6 still offers a lot of advantages when it comes to managing hosts and accounting for IP addresses in use.

One of the big differences when it comes to DHCPv6 is that a host identifies itself with a DUID (DHCP Unique Identifier) which can be different from a MAC address. There are essentially three ways to come up with a DUID:

Link Layer + Time: In this case, the host will on first boot create a DUID using one interfaces link layer address (MAC address for Ethernet), as well as the timestamp (seconds since Epoch) to derive a DUID. This DUID will be saved to disk and remain constant even if the network card is swapped later.

Link Layer: Some hosts may not be able to retain a DUID between reboots in this case, the link layer address is used.

Vendor Assigned: You can also just assign an arbitrary DUID, maybe a host name, to identify the host.

Regardless which method you use, the sad part is that each operating system, and in some cases different software on the same operating system, chooses to display the DUID differently, making correlation hard.

Here are a few examples:

Linux seems to like a mix of octal and ASCII characters (if the value represents a printable character). For example:

\000\001\000\001\032\336\306\373\000\014)g\317\002

However, in Linux configuration files for DHCPv6 servers and clients, you may find a simpler hex format:

option dhcp6.client-id 0:1:0:1:1a:de:c6:fb:0:c:29:67:cf:2;

OS X on the other hand displays the time part in decimal, and the MAC address part in hexadecimal:

ipconfig getv6packet en0
CLIENTID (1) Length 14 DUID LLT HW 1 Time 389824106 Addr 40:6c:8f:11:d7:5c

Windows prefers to display the hexadecimal version as output for "ipconfig /all"

DHCPv6 Client DUID. . . : 00-01-00-01-13-0D-1E-A2-00-0C-29-A3-D3-30

To help myself a bit with this confusion, I started a little script that will convert DUIDs from different formats. It isn't quite done yet, but good enough to see if anybody finds it helpful and would like to test it. You can download the script from https://isc.sans.edu/diaryimages/duidconvert.pl

,

[To learn more about IPv6 Security, check out my class IPv6 Security Essentials]

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

Unlike announced a few month ago, the infamous "Port 32764" backdoor was not fully patched in new routers [1]. As a reminder, the original backdoored allowed unrestricted/unauthenticated root access to a router by connecting to port 32764. The backdoor was traced back to components manufactures by Sercomm. Sercomm delivers parts for a number of name brand routers sold under the brands of Cisco, Linksys, Netgear, Diamond and possibly others.

An analysis of an updates router by Synacktive revealed that the code implementing the backdoor is still present, and can be activated to listen again by sending a specific Ethernet packet. The packet would not be routed, so an attacker has to have access to the local network the router is connected to, which significantly lowers the probability of exploitation, but doesn't eliminate it.

The packet activating the backdoor is identified by an Ethernet type of 0x8888.

[1] http://www.synacktiv.com/ressources/TCP32764_backdoor_again.pdf

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

Apple today released patches for OS X, iOS and Apple TV. The OS X patches apply for versions of OS X back to Lion (10.7.5). Vulnerabilities fixed by these patches can lead to remote code execution by visiting malicious web sites.

For more details, see Apples security update page [1]. Links to the actual update details should become available shortly.

[1] http://support.apple.com/kb/HT1222

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

Here's one yardstick that I use before signing up for any new online service: I first search the Interwebs for stories from users who tried to close their account and to leave same service, and were given a hard time.  I understand that commercially it is "rewarding" to show 300 million subscribers, even if 90% of them are stale accounts. But from a privacy and data security point of view, it does NOT make any sense for a user to leave an account behind that he/she knows for sure will never be used again.  Some services, also larger ones, are handling this issue professionally, and have a decently findable link on their home page that allows the closing of an account and deletion of stored data. Others .. give you the run-around via six levels of customer "service", and in the end, they basically change your username to username.inactive, but leave everything else as-is. And keep spamming you, too.

If you have stories to share about online services that don't let you leave, please do so below. Keep it PG-13 and factual, please, but if a little ire shines through, we understand ...

Now that the frantic frenzy around "Heartbleed" has calmed, and most sites are patched, it is time to circle back. For a server at a community college that I knew had been affected, I wanted to see if someone had pulled any data via Heartbleed during the roughly 36 hours between when the vulnerability became widely known, and when IDS signatures and patches were deployed to protect the site.

Problem is, Heartbleed leaves basically no traces in the httpd server log, so checking there for attacks didn't help. After a bit of pondering, we came up with the idea to correlate the firewall log with the web server log. If the firewall had seen a number of tcp/443 (HTTPS) connections to the web server from a certain IP, but these same connections were not in the web server log, chances were that we had found ourselves a bleeder.

The first IP that the correlation script identified as potentially fishy turned out to be owned by SSLlabs, and likely belongs to their public SSL scanner that everyone was using at the height of the panic. So .. the script seemed to be working well, and was pulling out the "right" types of connections.

A bit later, we found another IP, registered to an ISP in Malaysia. Twenty minutes of hits only on the firewall, at a rate of about one every 5 seconds, followed by a 5 minute pause, followed by hits both on the firewall and on the web server. Hmm, peculiar :). Chances are high this was in fact someone who tried to steal cookies of active sessions first, and then tried to re-use the cookies to break in. For the second part of the attack, the web server log shows GET requests to the application, followed by a 302 redirect to the "login" page, so "something" must have gone wrong on the attacker's side in either stealing the cookies, or in splicing them back into his fake requests. After another 20 minutes and about 60 requests which all were answered with a redirect, the attacker gave up.

Which tools or methods did you use to identify "heartbleed" leaks that occurred in the time span where your site was vulnerable, but IDS instrumentation and patching wasn't really available yet?  Feel free to let us know via the contact form, or share in the comments below!

OpenSSL, in spite of its name, isn't really a part of the OpenBSD project. But as one of the more positive results of the recent Heartbleed fiasco, the OpenBSD developers, who are known for their focus on readable and secure code, have now started a full-scale review and cleanup of the OpenSSL codebase.

If you are interested in writing secure code in C (not necessarily a contradiction in terms), I recommend you take a look at http://opensslrampage.org/archive/2014/4, where the OpenBSD-OpenSSL diffs and code changes are coming in fast, and are often accompanied by cynical but instructive comments. As one poster put it, "I don't know if I should laugh or cry". The good news though definitely is that the OpenSSL code is being looked at, carefully and expertly, and everyone will be better off for it.

Yes, I know that by now you are really tired of hear and read about Heartbleed. You probably already got all testing scripts and tools and are looking on your network for vulnerable servers. 

I was just playing with the Shodan transformer for Maltego and looking for some specific versions of OpenSSL. The results are not good...

Somethings to keep in mind when checking your network is that the tools may not detect all vulnerable hosts since they may be buggy themselves :)

According some research, one of the first scripts released to test the vulnerability, and that most of people still use to identify vulnerable servers contains some bugs that may not detect correctly the vulnerable servers.

The heartbeat request generated on the proof of concept script is:

18 03 02 00 03 01 40 00 <-- the bold bytes basically tell the server to use TLS 1.1, so if the server only supports TLS 1.0 or TLS 1.2 it won't work. Of course that 1.0 and 1.2 are not widely used, so the chance of you having it on your network is small, but still, there is a chance. 

Early last week, while testing different online and offline tools, I also came across different results, so you may want to use different tools on your check.

Network signatures may also provide additional check to help you identify vulnerable hosts. Again there is a chance of False Positives, but it is worth to provide you with more info on your checks.

Snort signatures and network parses for products like Netwitness can also be very effective to detect not only when an exploit was used against your hosts, but most importantly, when your vulnerable host provided information back (the leaked info). 

Happy hunting to you because the bad guys are already hunting!

--------------------

Pedro Bueno (pbueno /%%/ isc. sans. org)
Twitter: http://twitter.com/besecure

We have received reports by many readers about buggy tools to test for the heartbleed vulnerability. Today I want to show you how easy it is to check for this vulnerability using a reliable tool as nmap.

You just need to trigger a version scan (-sV) along with the script (ssl-heartbleed). The following example with show a command that will scan 192.168.0.107 for this bug:

nmap -sV 192.168.0.107 --script=ssl-heartbleed

This will be the output for a non-vulnerable website. As you can see, no warnings are shown:

If you are vulnerable, you will get the following:

For vulnerability testing, always use reliable tools which won't contain malicious code infecting your computer and won't give you false positive messages.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

I received this week a very valuable e-mail from the DNP Technical Committee Chair, Mr. Adrew West, who pointed an excellent observation and it's the very slow adoption of DNP3 Secure Authentication Version 5, which is the latest security enhancement for the DNP3 protocol. I want to talk today about this standard and the advantages of adopting it into your DNP3 SCADA system.

This standard has two specific objectives:

• Help DNP3 outstation to determine beyond any reasonable doubt that it's communicating with an authorized user.
• Help DNP3 master to determine beyound any reasonable doubt that it's communicating to the correct outstation.

This standard minimize the following risks:

• Spoofing to outstation or master: Since the original specification includes only the DNP3 outstation address as the only way for identification, the new standard uses crypto keys to enforce the authentication to each end.
• Modification: The standard includes the concept of Message Authentication Code (MAC) as shown in ISO/IEC 9798-4. This standard allows to determine if a message has been modified before arriving to the destination, ensuring integrity.
• Replay attack: Valid traffic cannot be retransmitted anymore by any third party as authentication information would not be the same.
• Eavesdropping: Crypto keys are securely exchanged. Data being transmitted goes still in clear-text, so confidentiality is not ensured. You need additional gear like crypto-boxes on each end of the communication link.

The following diagram shows the implementation architecture for this standard:

 

As seen, an additional level before application layer is added, providing the new security features.Unfortunately, there are two specific reasons that is preventing this standard for being widely deployed in the world:

• ICS systems are still being planned to last from 10 to 20 years: Technology has arrived to that world and most ICS people have not noticed that yet. They still think that air gap is enough to protect the ICS systems and won't consider new investements to implement new security features. United States is one of the leaders in regulation for critical infrastructure. However, this does not happen in most countries and unless governments produce new laws for enforcing cybersecurity on critical infrastructure, adoption of such standards will keep slow.
• DNP3 equipment manufacturers do not offer the same references and features in all countries of the world, and most of them even claim that this standard is not yet supported (for example, in south america).

Cybersecurity is not still mature in the ICS industry and has a long way to go. Information Security Professionals working with the ICS world has a really big challenge: We need to demonstrate that Information Security Controls like this standard will have a return of investment to the company and the risk of not having them, if operating a critical infrastructure to a Country, could be catastrophic and impacts incalculable. This standard works, won't put at risk any ICS facility and we all have a responsability of ensuring its implementation to our companies.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

Update: CloudFlare posted in their blog twice today claiming responsibility for the majority of this spike. Quoting: "If you assume that the global average price for bandwidth is around $10/Mbps, just supporting the traffic to deliver the CRL would have added $400,000USD to Globalsign's monthly bandwidth bill."

Update: We've also seen articles from ZDNet and WIRED today in response to the below insights, with further analysis therein.

It looks like, as I had suspected, the CRL activity numbers we have been seeing did not reflect the real volume caused by the OpenSSL Heartbleed bug.

This evening I noticed a massive spike in the amount of revocations being reported by this CRL: http://crl.globalsign.com/gs/gsorganizationvalg2.crl

The spike is so large that we initially thought it was a mistake, but we have since confirmed that it's real! We're talking about over 50,000 unique revocations from a single CRL:

This is by an order of magnitude the largest spike in revocation activity seen in years, according to our current data.

I have set up a new page for everyone to monitor the activity as well as see how we are obtaining this data. The page can be found at https://isc.sans.edu/crls.html.

How will you use this page in your projects or general analysis? We'd love to hear some ideas.

If you know of other CRLs that we can add, please let us know in the comments! Additionally, if you would like to see an API call added so that you can automatically query us for this information, please let us know so that we are aware of the demand.

On a side note, we can see a clear upward trend in revocations over the past 3 or 4 years:

What do you attribute this consistent growth in revocations to? What do you think caused the previous spikes?

-- 
Alex Stanford - GIAC GWEB,
Research Operations Manager,
SANS Internet Storm Center
/in/alexstanford | @alexstanford

Reader Philipp reported today a bug affecting his remaining Windows XP machines and Windows 2003 servers. Seems to be that all Windows XP and Windows 2003 machines with SC Forefront Endpoint Protection definition update 1.171.1.0 and later are affected. You might want to test definition update 1.171.64.0, as we have received reports stating that it fixes the problem. However, we have not seen yet any official statement from Microsoft regarding this issue.

If you disable Forefront because it's not letting your machine work, please place other controls that minimize the associated risk. Otherwise, your computers could be so easily hacked.

We also receive questions on which AV is the best. Since the answer is it depends on the company and the information security assets, you might want to check the Magic Quadrant for Endpoint Protection from Gartner Group and try to find yourself what is the best answer for your company. If you want to read the entire file, you can have it from Mcafee or Computerlinks.

We will update this diary if more information becomes available.

More information available at:

• http://msmvps.com/blogs/kenlin/archive/2014/04/16/winxp-and-or-win2003-with-sc-forefront-endpoint-protection-installed-msmpeng-exe-crashes-after-definition-update.aspx
• http://social.technet.microsoft.com/Forums/forefront/en-US/08cdcadc-5d7c-48c5-95d5-6e47291ddef0/scep-2012-432150-with-sigs-117110-causes-xp-to-hang-until-msmpeng-finally-crashes?forum=FCSNext

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter:@manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org

Oracle released its quarterly Criticical Patch Update (CPU) yesterday [1]. As usual, the number of patches is quite intimidating. But remember these 104 fixes apply across the entire Oracle product range.

Some of the highlights:

CVE-2014-2406: A bug in Oracle's Database which allows a remotely authenticated user to gain control over the database.

37 new patches for Java SE, 35 of which allow remote execution as the user running the Java Applet (according to Oracle: "The CVSS scores below assume that a user running a Java applet or Java Web Start application has administrator privileges (typical on Windows)".

4 of the Java vulnerabilities have a base CVSS score of 10 indicating not only full remote code execution but also easy exploitability.

[1] http://www.oracle.com/technetwork/topics/security/cpuapr2014-1972952.html

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

When infosec guys are performing intrusion detection, they usually look for attacks like portscans, buffer overflows and specific exploit signature. For example, remember OpenSSL heartbleed vulnerability? The following is the snort alert for this vulnerability, taken from the snort community rules:

alert tcp $EXTERNAL_NET any -> $HOME_NET [25,443,465,636,992,993,995,2484] (msg:"SERVER-OTHER OpenSSL SSLv3 heartbeat read overrun attempt"; flow:to_server,established; content:"|18 03 00|"; depth:3; detection_filter:track by_src, count 3, seconds 1; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service ssl; reference:cve,2014-0160; classtype:attempted-recon; sid:30510; rev:5;)

When you perform inline detection within electrical SCADA networks, latency is a big issue. That means you need to fully optimize the amount of checks so latency does not increase more than 3 ms. We also need to include other threats that could materialize from other threats different to malware, exploits and buffer overflows. I will detail in this diary some specific SCADA protocol packets that could be malicious traffic and cause terrible consecuences to the process infrastructure. Today I will detail malicious packets from DNP3 protocol.

The following text details DNP3 packet structure:

Source: Practical Industrial Data Communications

• Start: This is the starting delimiter of the DNP3 datalink layer. It is always set to 0x564
• Length: This is the number of bytes for user data inside the DNP3 packet, plus 5 and does not count CRC bytes.
• Control: This is the DNP3 Frame Control Byte, which provides control of data flow between the master and slave over the physical link. It identifies the type of the message and the flow direction for the communication.
• Destination: DNP3 outstations are identified by a two-byte address. These two bytes are the little-endian representation for the outstation destination address .
• Source: These two bytes are the little-endian representation for the outstation source address
• CRC: Little-endian representation of the CRC-16 DNP3. This is calculated for each block and placed in the end of it.
• Transport control: This DNP3 Frame Control Byte provides control of data flow between the master and slave in the transport level.
• Userdata for block n:
  • Application Layer: Control byte: Duplicates the control byte in the transport control field.
  • Application layer: Function code: Defines the function being invocated by the packet
  • Application layer: structures: Defines the structures being written or queried.
• CRC: Little-endian representation of the CRC-16 DNP3 for block n user data.

The following DNP3 functions could be used in a malicious way:

1. DNP3 Warm Restart: When this packet is received by the outstation and recognize that it comes from the master, it performs a partial restart on completition of the communications sequence. If this packet is received several times per second, the IED will experiment a denial of service and won't be able to perform actions to the industrial process, send events to the HMI or receive commands from the HMI. A typical DNP3 Warm Restart packet looks like the following: 

The following filters recognize these packets:

• Wireshark: dnp3.al.func==14
• Snort: alert tcp $DNP3_CLIENT any -> $DNP3_SERVER $DNP3_PORTS (flow:from_client,established; content:"|0E|"; offset:12; depth:1; msg:"SCADA_IDS: DNP3 Warm Restart From Authorized Client"; classtype:attempted-dos; sid:1111112; rev:1; priority:2;)

2. DNP3 Cold Restart: When this packet is received by the outstation and recognize that it comes from the master, it performs a full restart on completition of the communications sequence. If this packet is received several times per second, the IED will experiment a denial of service and won't be able to perform actions to the industrial process, send events to the HMI or receive commands from the HMI. Packet looks same as previous one with one little change: count three bytes from the last to the first and change 0E (DNP3 Warm Restart) to 0D (DNP3 Cold Restart).The following filters recognize these packets:

• Wireshark: dnp3.al.func==13
• Snort: alert tcp $DNP3_CLIENT any -> $DNP3_SERVER $DNP3_PORTS (flow:from_client,established; content:"|0D|"; offset:12; depth:1; msg:"SCADA_IDS: DNP3 Cold Restart From Authorized Client"; classtype:attempted-dos; sid:1111112; rev:1; priority:2;)

3. DNP3 Time Change: When this packet is received, the IED or RTU can change the internal clock time and so orders received with specific timestamp won't be executed and logs will be placed in other different places so the operator can't see them in real time. A typical DNP3 Warm Restart packet looks like the following: 

Wireshark can't fully filter this packets so the following tcpdump filter is provided: ip[52]=2 and ip[53]=0x32 and ip[54]=1

SCADA Information Security is different from the regular IT information security practices. We need to cover the specific vectors to improve the security level of the associated industrial process.

Manuel Humberto Santander Pelaez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org 

We are going back to INFOCon Green today.   Things have stabilized and the INFOCon is used to indicate change.  Awareness of Heartbleed is well saturated and Internet teams everywhere appear to be responding appropriately.  

Some points to be aware:

• Patching will continue and hopefully fill remaining gaps.
• Certificate Revocation Lists (CRLs) will grow, which may lead to slower load times in some cases. Please let us know if you are observing CRL issues.
• There is no practical way to identify if a certificate has actually been updated, unless you recorded the certificate serial number.   It is common to check the creation date, BUT a CA can re-issue a new certificate and keep the original creation date. This is silly but should be noted.
• The client side (wget, curl, etc...) of Heartbleed is mostly a non-issue, but there are a few exceptions. Watch for VPN client updates.
• Certificates continue to be revoked.  We have taken the liberty to look at the CRL counts of sixteen different CA's since April 1, 2014. 

In summary,  please keep scanning and patching all of your servers and encourage all end users to change their passwords after a site's certificate has been updated.

-Kevin
--
ISC Handler on Duty

I wanted to know if the tools/software I execute regularly are vulnerable to scraping my system memory.  Now the reverse heartbleed scenario is very possible, but the likelihood seems to be much more of a non-issue.  

Seeing is still believing in my book.  So I set out to see what the interweb world was doing to test this out.  There are some very reputable services/organizations out there offering up a fresh url to the reverse heartbleed and others offering to 'test' a given url.   These are a black box.  Trust is hard to earn at times, especially when you are dealing with an exploit like this one.  I wanted to see source code, or at least pseudocode so I could craft my own.  I found a script out there called Pacemaker [1] that was written and provided by Peter Wu.  I liked it because it was transparent, simple, and it can be used exclusively under my control (the ultimate first step of developing trust).

So simple, I was able to review it for harm and function, and cut and paste it into vi.  Escape, write, quit, and I was off and running.   Basically it works like a simple webserver, very simple.  The script is executed and listens on port 4433.  You point your client software at it with a localhost url and the server script reports on STDOUT what it finds.  

I did not have any vulnerable client software readily available to give a whirl, but I did try all my curl and wget installs that I use regularly.   I also hit it with Chrome and Safari to see the error messages.

Here is what I tested with it.

wget 1.11.4:  

I am interested in seeing more output from known vulnerable client software.  Feel free to give this a ride and share your results.  If I get a chance to spin out a new VM with some vulnerable OpenSSL on it today, then I will share my experiences too.

[1]   https://github.com/Lekensteyn/pacemaker

-Kevin
--
ISC Handler on Duty

CloudFlare lunched a challenge yesterday: Can You Get Private SSL Keys Using Heartbleed?[1]  The site created by CloudFlare engineers is located here and is intentionally vulnerable to heartbleed. If you manage to steal the private key from the site, they will post the full details on that site. So far two individuals have succeeded: Fedor Indutny (@indutny) and Ilkka Mattila of NCSC-F.[2]

If you have time and bandwidth, this might be a fun weekend project.

[1] http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed
[2] https://www.cloudflarechallenge.com/heartbleed

-----------

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

The following Cisco products that were previously identified as vulnerable and have been remediated:

Cisco Registered Envelope Service (CRES)
Cisco Webex Messenger Service
Cisco USC Invicta Series Autosupport Portal

This following software has been fixed and is available for download, for all affected products:

Cisco AnyConnect Secure Mobility Client for iOS - Fixed in version 3.0(9353)
Cisco WebEx Messenger Server - Fixed in 2.0MR2
Cisco TelePresence Video Communication Server (VCS) - Fixed in X8.1.1

For additional information on Cisco product, follow this Cisco Security Advisory.

[1] http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed

-----------

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

We're getting reports of client applications that are vulnerable to the heartbleed issue.  Just as with server applications, these client applications are dependant on vulnerable versions of OpenSSL.

Another "patch soon" problem, you say?  The patch will be installed when the vendor ...  oh, wait a minute.  Just exactly when will your TV's manufacturer update the web browser on your TV?  And when will you be applying that patch?  How about your in-laws TV?  This vulnerability on the client side has the potential to be much longer-lived than on servers.

This combines the problem of the specific heartbleed vulnerabilty with the problem of embedded devices that may never be updated.  Or devices that are updated by vendors for a year or two after release, then abandoned when the new model comes out - home routers and TV sets are great examples of this situation, but so are medical devices.

To add to that list, there is a large contingent of Android phones that have updates maintained by the carrier instead of the manufacturer (google), and do not see frequent updates, or may never see an update.  These devices are used daily for almost everything - online banking comes immediately to mind.  The combination of a general purpose device and a vulnerability that exposes memory to an attacker (in this case, a malicious or infected server) has the potential for some widespread mayhem, for as long as that device remains in service (years instead of weeks or months)

Other applications that encrypt but we don't often think of as "clients" include traditional database software, cloud services clients, dedicated / custom browsers for online services like entertainment, even device drivers for hardware all need to be assessed.  It's also easy to say "client application XX is vulnerable", but that client application might exist on your PC, multiple tablet or phone platforms, TVs, DVRs, excercise equipment, fridges, thermostats - the list grows to include things that are smaller and smaller, that are less and less likely to be updated.

Client applications that are currently reported as vulnerable are:

•     MariaDB 5.5.36
•     wget 1.15 (leaks memory of earlier connections and own state)
•     curl 7.36.0
•     git 1.9.1 (tested clone / push, leaks not much)
•     nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
•     links 2.8 (leaks contents of previous visits!)
•     OwnCloud

(from http://security.stackexchange.com/questions/55119/does-the-heartbleed-vulnerability-affect-clients-as-severely )

If you've got confirmation of other vulnerable client applications, please post the relevant information (with links) in our comment section. 

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

With more mass-media attention to the heartbleed bug, we are getting more questions from "normal users" about the heartbleed bug.

The "Heartbleed" bug is not affecting end users using Windows. It does not affect standard Windows browsers (Internet Explorer, Firefox, Chrome). It may affect some selected third party software, but most likely, you do not need to patch anything. The only widely used consumer platform vulnerable is Android 4.1.1, but there isn't much you can do about it but wait for a patch for your phone.

However, it is possible that a web site you used is or was affected by "Heartbleed". The result may be that the password you are using on the site was captured by someone attacking this site. So you may need to change the password that you used on the site.

How do I know if a site is/was vulnerable?

Your best bet is https://lastpass.com/heartbleed/ . They will show you if a site is vulnerable right now, or may have been vulnerable in the past. Tehre is a chance that the site received a new certificate that still uses the old issue date, which can lead to sites being identified as "not fixed". 

Should I change my password?

If you think the site was vulnerable, and is no longer vulnerable, then you should change your password. If in doubt, change your password. Changing your password while the site is still vulnerable probably doesn't hurt, but the new password may leak again, so the change may not help.

Should I avoid sites that are still vulnerable?

Yes

I received an e-mail from a site I use asking me to change my password. Should I do so?

First of all: Don't click on any links in this email. Then go to the website and change your password (even if the e-mail was a fake, it doesn't hurt to change your password as long as you are sure you go to the right site). Use the "lastpass" URL above to check if the site is/was vulnerable.

What else should I do?

Standard "safe computing" practices: use difficult to guess passwords, keep your system up to date, use anti-malware, be cautious with links distributed via e-mail.

And how do I explain the problem that caused all this?

XKCD has a great cartoon explaining it: http://imgs.xkcd.com/comics/heartbleed_explanation.png . The short summary: If an SSL connection is idle, heartbeat messages are used to chck if the other side is still listening. For example, the browser sends a message "if you are still alive, reply by sending the 3 letter word 'dog'", and the server replies with "dog". To trigger the bug, the client would send "reply with the 500 letter word 'cow'". Since "cow" only got 3 letters, the server will make up the missing 497 bytes with data from memory, and this data may contain other things the server was working on, like users passwords or private encryption keys.

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

I started getting emails yesterday asking me to change passwords on services I do not have accounts on - complete with helpful links - back-ended by malware and/or credential harvesting of course

Just a few minutes ago, I also received a legit email along the same lines, from a security organization.  Unfortunately, they also included links (OOPS), this time legit links, but that's still a big miss on their part.

It's worth a reminder to your user community, clients and even family if you support their machines (and bad computing habits) also. 

Helpful emails with links in them are in most cases NOT helpful.  Don't click that link!

If it's legitimate, and especially this week, by all means browse to the affected site and change your password.  That's always a good idea.  But following an email link to a password change page is a good way to get your credentials stolen, or a good way to pick up a nice "gift" of malware.

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

We were talking yesterday that with the Heart Bleeds issue front and center, what about the "everything else" factor?

With everyone so focused on this one issue, coupled with the knowledge that *lots* of folks still have XP and in the all the OpenSSL excitement might not have patched.  In particular, the horde of XP machines we call ATMs would be a particularly good target this week (or any other week until they get updated really).  So please folks, let's do what we can on the OpenSSL side, but keep the needed focus on other areas too!

Mark's story yesterday on OpenSSL "check" sites makes the great point that these sites can be collecting information as well as giving you info.  Keep in mind that we expect to see some bogus sites pop up to - I'd expect to see some fake check sites distributing malware if we don't see them already

How about SSL and other site issues that aren't vulnerable to Heartbleed?

As I'm assessing client sites and products for Heartbleed, I'm taking the time to do a more complete (but still quick) assessment.  So the client gets a list of:

• sites that have self-signed certs
• broken cert chains
• sites that allow a less than desireable SSL Encryption level
• and so on, you get the idea

In short, all those SSL things that were in the last several assessment reports, but were never fixed for some reason.  Folks have the perception that "SSL is hard", so I often see admins avoid anything changing anything that affects it, even when it's called out in a security assessment report.  But this weeks focus on SSL is forcing these issues into the light of day, and allowing us to get a lot of them resolved.

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

There are a fair few sites popping up testing for this issue.  I know this is possibly overly motherly, sorry, but be careful.  You may not know who is running the site, what they are actually testing for and what is done with the information collected.  Consider sticking to the main sites and known security organisations.  

Metasploit now has a module out (https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb). NMAP likewise has a check.  QUALYS has their SSLLABS page.  Other security vendors are also providing checks in their scanning products.  

Not saying the free scanners are "evil", just saying be careful what you use.  

Cheers

Mark H

• CACert - https://blog.cacert.org/2014/04/openssl-heartbleed-bug/
• Cisco - http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed
• Fortinet - http://www.fortiguard.com/advisory/FG-IR-14-011/
• Gentoo Linux - http://www.gentoo.org/security/en/glsa/glsa-201404-07.xml
• Juniper -  http://kb.juniper.net/InfoCenter/index?page=content&id=KB29004 (login required)
• Juniper - http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10623
• F5 - http://support.f5.com/kb/en-us/solutions/public/15000/100/sol15159.html
• Novell - http://support.novell.com/security/cve/CVE-2014-0160.html 
• OpenVPN - https://community.openvpn.net/openvpn/wiki/heartbleed
• Aruba - http://www.arubanetworks.com/support/alerts/aid-040814.asc
• CheckPoint - https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk100173
• openssl - https://www.openssl.org/news/secadv_20140407.txt
• redhat - https://access.redhat.com/security/cve/CVE-2014-0160
• Slackware - hxxp://www.slackware.com/security/viewer.php?l=slackware-security&y=2014&m=slackware-security.533622
• sparklabs/viscosity openvpn client - https://www.sparklabs.com/viscosity/releasenotes/
• watchguard - http://watchguardsecuritycenter.com/2014/04/08/the-heartbleed-openssl-vulnerability-patch-openssl-asap/
• viscosity - https://www.sparklabs.com/blog/

Overview of the April 2014 Microsoft patches and their status.

------

(this article is work in progress and will be updated as we have new information. Also see the comments for links to signatures and other information provided by readers)

We decided to go to Infocon Yellow to alert readers of this vulenrability.

For those of you using OpenSSL 1.0.1 (most recent Unix systems), it is critical that you patch the openssl library, as well as binaries compiled statically with openssl, as soon as possible. [1] 

The attack will allow a remote attacker to read up to 64kBytes of system memory from your system per attack attempt. The attack works against servers as well as against clients. While not all software using SSL necessarily uses the OpenSSL library, many do. (see our prior diary)

A proof of concept exploit has been made available and I have tested it. It can be used to remotely scan for vulnerable systems. [1] We have not yet detected wide spread use of the exploit, but it is literally hours old. At this point, we don't think the vulnerability was known in the underground before the official release, but it is possible.

What should you do first:

Check if you are vulnerable. "openssl version -a" will return the version information. If your version is 1.0.1, you MAY be vulnerable. Only version 1.0.1g is NOT vulnerable. Other major versions (0.9x, 1.0.0 ...) are not vulnerable. 

Rule of thumb: If you are using OpenSSL, and if you are supporting TLS 1.2 (check ssllabs.com) , then you are vulnerable unless patched.

If I am vulnerable, what should I do:

Patch! Ubuntu, CentOS and others have patches available. OS X Mavericks has NO PATCH available. Windows is likely not vulnerable, but if you are running open source software like Apache that uses OpenSSL, then you may be vulnerable.

You may want to consider replacing SSL certificates if you are afraid that the exploit was already used against your site. But the exploit is not limited to secret SSL key. All data in memory is potentially at risk.

Can I test remotely?

The PoC exploit above can be used to scan your network remotely.

How Can I Tell if Someone is Using the Exploit Against Me

We don't have IDS signatures (yet... wait for updates here). There is no log entry in your web server log as the exploit happens after the SSL session is established, and before the HTTP request is sent.

nginx, after being patched, logs the following from the PoC exploit:

2014/04/08 12:37:18 [info] 4151#0: *724561 peer closed connection in SSL handshake while SSL handshaking, client: 70.91.145.11, server: 0.0.0.0:8443

[1] http://heartbleed.com
[2] http://s3.jspenguin.org/ssltest.py
 

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

OpenSSL 1.0.1g has been released to fix "A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64kB of memory to a connected client or server. This issue did not affect versions of OpenSSL prior to 1.0.1."[1] known as the Heartbleed Bug [3].

/*** update by Johannes Ullrich ...: ***/

Ubuntu released a patch for affected versions:

http://people.canonical.com/~ubuntu-security/cve/2014/CVE-2014-0160.html

Ubuntu also updated OpenSSH.

CentOS/RHEL has a patch available. 

https://rhn.redhat.com/errata/RHSA-2014-0376.html

For CentOS, the OpenSSL version did not change. Instead, only the compile time changed. To test if you are running the right version, look at the second line of the "openssl version -a" output:

Fixed version:

---

The quickest way to figure out which version of OpenSSL you are using is:

openssl version -a

But not that some software may be compiled statically with openssl.

For a vulnerable system, this will return a version of 1.0.1f (or anything but 'g'). Also there will be no complier flag-DOPENSL_NO_HEARTBEATS.

For example, on a current OS X Mavericks system, you will get:

[1] http://www.openssl.org/news/secadv_20140407.txt
[2] http://www.openssl.org/news/vulnerabilities.html#2014-0160
[3] http://heartbleed.com

-----------

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

Reviewing my logs, I found this odd request:

GET /infocon.htmlppQ/detail/20130403164740572kode-til-boozt-10/basura-que-va-acumulando/_medium=twittersideIM&lang=en&brand=nokiaokseen-fortumin-joensuun-voimalaitokselle/)&utm_term=inspirationfeedistan%20Tehreek-e-Insaf)%e0%b9%89%e2%86%90_%c3%96k%e2%98%bc%e0%b9%84%e0%b8%a1%e0%b9%88%e0%b9%84%e0%b8%8a%e0%b9%88%e2%99%a5His%c3%b6%e2%86%94ll%e0%b8%95%e0%b9%88%e0%b8%81%e0%b9%89%c3%b6%e0%b8%a1%e0%b8%b1%e0%b9%88%e0%b8%a2%e0%b8%94%e0%b9%89%e0%b8%b2E%e2%86%90n%c3%96%e2%86%90m%c3%96neY%c2%ae%e2%97%84%e2%97%84--html26eu1=0&eu2=0&x=50&y=16&dataPartenzaDa=20121001&dataPartenzaA=20121010&orderBy=Prezzo HTTP/1.0" 302 154 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "2a03:2880:20:4ff7::"

It does look like a valid request from Facebook. "facebookexternalhit" is used by Facebook to screen links people post for malware. However, the link "doesn't make sense". Doesn't really look like an attack to me, just weird. Any ideas how this may happen?

------

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

In the past few years one of the major improvements in the Windows environment was PowerShell. With Unix-style scripting capabilities automating windows administration tasks become possible. One of the major advantages of PowerShell is that it’s support most of Microsoft products from MS Office to Enterprise level applications such as MS SharePoint and MS Exchange.

But is it possible to use PowerShell for malicious purpose? If you remember the Melissa which was written in MS Office macro but that was in 1999 is it still possible?  

According to TrendMicro[1] a new malware has been discovered that written in PowerShell. CRIGENT (aka Power Worm), TrendMicro has detected two malicious files (W97M_CRIGENT.A and X97M_CRIGENT.A) .These files arrived in an infected Word or Excel file.

The malware will download and install tor and Polipo then connect to Command and Control server. The malware collect some information from user’s machine (such as IP address, User account privileges Version, latitude...) and send it to its C&C server. In addition Power worm will infect other Word/Excel files, disable macro alerts and it will downgrade the infected file from Docx/xlsx to Doc/xls.  

The best way to stop such a malware is disabling macro and don’t open any file from untrusted source.

You've probably gotten a few of these e-mails over the last few months (I saw the first one of this latest kind in early Feb), we got one to the handlers list earlier this week which prompted this diary.  They seem pretty innocuous, they have little or no text and a URL like the one shown below. 

Note: the above link doesn't lead to the malware anymore, so I didn't obscure it.

Most seem to be sent from Yahoo! (or Yahoo!-related e-mail addresses), so they may be coming from addresses that were compromised during the breach of Yahoo! back in January.  The odd thing about this is that, if you follow the URL from a Linux, Windows, or Mac you get a spammy website (I don't remember if it was Canadian pharmacies, or what), but what a colleague of mine at $dayjob (all credit goes to Stan) discovered is that if you opened the e-mail on an Android device (or followed the links with an Android user-agent and referrers), this instead leads to downloading of the latest version of the DroidNotCompatible Android malware (which is, itself, and interesting specimen, but I'll leave that for another diary).  The first URL led to a 302 redirect to a page that included the malicious APK in a META refresh tag.  You can change the user-agent string with the -U switch to wget or the -A switch to curl if you want to try grabbing things from the Linux/Unix commandline (which is, of course, how you all surf the internet anyway, right?).

The take away, if there is one, is that when tracing suspicious URLs, don't just assume the site is not interesting just because nothing bad happened when you looked at it from your sacrificial browsing environment (you all have one of these whether you realize it or not, the bad news is it may be your main system).  Try with additional user-agents (and/or referrers) and see what happens.  Do you have a collection of your favorite user-agent strings you like to use?  If there is enough interest, perhaps we'll put up a page either here on the main site or over on the handlers server with some of the more useful ones.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

Thanks to Susan, one of or readers, who dropped us a line today to tell me that we (and by "we" I mean "I") missed that Windows 8.1 was released on April 2.

This is an important update for all of the Windows 8 folks out there for a couple of reasons:

• The base 8.1 update includes 2 out-of-band security updates (KB2922229 and KB2936068, both available separately)
• More importantly, it's the service baseline for 8.x, so you should have the 8.1 update installed before you applying the in-band updates coming this Tuesday.

Before installation, the 8.1 update requires a prerequisite of KB2919442  http://support.microsoft.com/kb/2919442

More on 8.1 here (amongst lots of other Microsoft posts):
http://blogs.windows.com/windows/b/windowsexperience/archive/2014/04/02/windows-8-1-update-important-refinements-to-the-windows-experience.aspx
http://blogs.windows.com/windows/b/springboard/archive/2014/04/02/windows-8-1-update-the-it-pro-perspective.aspx

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

I had a client call me recently with a full on service outage - his servers weren't reachable, his VOIP phones were giving him more static than voice, and his Exchange server wasn't sending or receiving mail - pretty much everything was offline.

I VPN'd in (I was not onsite) and started with the firewall, because things were bad enough that's all I could initially get to from a VPN session.  No surprise, I saw thousands of events per second flying by that looked like:

So right away this looks like malware, broadcasting on UDP ports 137 and 138 (netbios name services and datagrams).  You''ll usually have some level of these in almost any network, but the volumes in this case where high enough to DOS just about everything, I was lucky to keep my SSH sessions (see below) going long enough to get things under control.  And yes, that was me that was behind Monday's post on this if this sounds familiar

To get the network to some semblance of usability, I ssh'd to each switch in turn and put broadcast limits on each and every switch port:

On Cisco:
interface gigabitethernet0/x
  storm-control broadcast level 20  (for 20 percent)
or
  storm-control broadcast level pps 100  (for packets per second)

On HP Procurve:
interface x
   broadcast-limit 5  (where x is a percentage of the total possible traffic)

On HP Comware:
int gig x/0/y
 broadcast-suppression pps 200
or
storm-constrain broadcast pps 200 200
(you can do these in percent as well if you want)

Where I can, I try to do this in packets per second, so that the discussion with the client can be "of course we shut that port down - there's no production traffic in your environment that should generate more than 100 broadcasts per second."

With that done, I now could get to the syslog server.  What we needed was a quick-and-dirty list of the infected hosts, in order of how much grief they were causing.

First, let's filter out the records of interest - everything that has a broadcast address and a matching netbios port in it - it's a Windows host, so we'll use windows commands (plus some GNU commands):

type syslogcatchall.txt | find "172.xx.yy.255/13"

But we don't really want the whole syslog record, plus this short filter still leaves us with thousands of events to go through

Let's narrow this down:
first, let's use "cut" to pull out the just source IP out of these events of interest.  

cut -d " " -f 7

Unfortunately, that field also includes the source port, so let's remove that by using "/" as the field delimeter, and take only the source ip address (field one)

cut -d "/" -f 1

Use sort and uniq -c (the -c gives you a count for each source ip)
then use sort /r to do a reverse sort based on record count

Putting it all together, we get:

type syslogcatchall.txt | find "172.xx.yy.255/13" | cut -d " " -f 7 | cut -d "/" -f 1 | sort | uniq -c | sort /r > infected.txt

This gave us a 15 line file, sorted so that the worst offenders were at the top of the list, with a record count for each.  My client took these 15 stations offline and started the hands-on assess and "nuke from orbit" routine on them, since their AV package didn't catch the offending malware.

What else did we learn during this incident?

• Workstations should never be on server VLANs.
• Each and every switch port needs basic security configured on it (broadcast limits today)

and, in related but not directly related lessons ...

• Their guest wireless network was being used as a base for torrent downloads
• Their guest wireless network also had an infected workstation (we popped a shun on the firewall for that one).
• Their syslog server wasn't being patched by WSUS - that poor server hadn't seen a patch since December's patch Tuesday

What did we miss?
By the time I got onsite, the infected machines had all been re-imaged, so we didn't get a chance to assess the actual malware.  We don't know what it was doing besides this broadcast activity, and don't have any good way if working out for sure how it got into the environment.  Though since this distilled down to one infected laptop, my guess would be this is malware that got picked up at home, but that's just a guess at the moment.

Just a side note, but an important one - cut, uniq, sed and grep are all on your syslog server if it's a *nux host, but if you run syslog on Windows, these commands are still pretty much a must-have.  As you can see, with these commands we were able to distill a couple of million records down to 15 usable, actionable lines of text within a few minutes - a REALLY valuable toolset and skill to have during an incident.  Microsoft provides these tools in their "SUA" - Subsystem for Unix Based Applications, which has been available for many years and for almost every version of Windows.  
Or if you need to drop just a few of these commands on to a server during an incident, especially if you don't own that server, you can get what you need from gnutools (gnuwin32.sourceforge.net) - I keep this toolset on my laptop for just this sort of situation.
Once you get the hang of using these tools, you'll find that your fingers will type "grep" instead of find or findstr in no time!

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

Microsoft has posted their regular pre-announcement for Patch Tuesday here:  http://technet.microsoft.com/en-us/security/bulletin/ms14-apr

We can expect:

• The final, yes final patches for XP
• The final patches for Office 2003 also - this has gotten a lot less press than XP but is just as critical ( http://office.microsoft.com/en-ca/help/support-is-ending-for-office-2003-HA103306332.aspx )
• The usual patches for other Windows and IE versions
• A couple of updates for WSUS and Windows Update.  Changes to Windows Update often result in Tuesday's updates coming two parts - we'll see on Tuesday I guess

So after Tuesday, XP and Office 2003 join the ranks of the "internet of hostile things" - platforms that are no longer being patched by the vendor as new issues arise, so quickly become compromised.   This includes things like your TV, your DVR or home internet router, your fridge, treadmill, IV pump, heart monitor or pacemaker - oh, and likely your phone as well  - -  read our stories over the last couple of months (or years really) for more on these.  Unfortunately, this XP event happens all in one fell swoop - millions of hostile hosts being added to the opposing army all at once. 

Fortunately, we can do something about this.  Updating to Windows 7 or 8 is cheap, if your hardware is up to the task.  If you've got older hardware, I'm seeing used Windows 7/8 capable desktop hardware for $100-$200 these days, and laptops seem to be in the same range.  If going to a new Windows platform isn't in your future, you're probably already looking at one of the more popular Linux distributions - distros like Unbuntu, or  Xubunto or Mint that try to mimic the UI that many home users are familiar with.  There is a similar range of options for Office (upgrades and alternatives).

Use our comment form to let us know what you are doing or have done for your user community (or family members) that might still be on XP or Office 2003 after Tuesday.

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

A new version of PHP has been released. The announcement comments:

"The PHP development team announces the immediate availability of PHP 5.4.27.  6 bugs were fixed in this release, including CVE-2013-7345 in fileinfo module."

Details of CVE-2013-7345 are available at Mitre.

Steve Hall ISC Handler www.tarkie.net

• We can automatically download eicar.com and see if the IDS/IPS detected the malicious file.
• We can perform an automatic scan with nmap or execute any NSE nmap script. Typically, a normal scan (a SYN scan) should trigger the IDS/IPS. This is also a good test to see if the IDS/IPS is detecting network behavior.
• We can send an exploit over the network. While thinking what to send I browsed through pytbull, which is an IDS/IPS testing framework (more at http://pytbull.sourceforge.net/). Pytbull comes with a bunch of attacks that can be used to test your IDS/IPS installations. At the end I decided that it was too complex, so it was much easier just to take some shellcode, prepend NOP sled to it (yea, so it looks real) and use scapy to send it.

--
Bojan
@bojanz

One of our readers have reported that he has seen a broadcast traffic to udp/137 . He suspected that the traffic cause a denial of service to some of his systems.

If you have seen such traffic and you would like to share some packets we would appreciate that.

A new study[1][2] by Indiana University Bloomington show that updating any Android device can allow an attacker to escalate apps privileges.

The researchers have discovered a new type of vulnerability called Pileup flaws, the vulnerability exist in the Package Management Service.

When a new app installed on old version of Android request a permission for features that don’t exist on that version of Android, however when the user upgrade to the new version, Android keeps all the permissions which mean that they will work in the new version of Android.

The researchers have developed a detection service, called SecUp, which deploys a scanner on the user’s device to capture the malicious apps designed to exploit Pileup vulnerability.

Like many other threats, the best mitigation is installing trusted software only.

Yesterday, we talked about a scanner looking for Synology devices that was running on a ARM CPU equipped DVR. Looking at a few other sources of these scans, we did see a couple that didn't originate from similar DVRs. The first guess was that the scan originated from a device that was sitting behind a NAT gateway and wasn't exposed. At this point, it could have been "anything", even a good old infected Windows PC. 

To our surprise, at least in one case it turned out that a binary by the same name, "cmd.so", was running on the NAT router itself. In addition, a second process was running that looked just like the bitcoin miner we saw running in the infected DVRs. Sadly, we were not able to retrieve the binaries, but the processlist looks similar enough to make us believe that this is the same basic binary just compiled for MIPS in this case (the router in question uses a MIPS CPU).

The first image shows the processlist with "cmd.so". In this case, the binary was dropped in /var/run, not /dev, likely due to the different architecture of the router allowing write access to /var/run. The screen show shows a partial output of the "ps" command executed using the routers web based admin interface.

Figure 1: Partial Process List with "cmd.so". Click on image for larger version.

Figure 2: Partial "ps" output showing the suspected bitcoin miner. In this case, it is called TgW66Q.

The process we think is a copy on minerd uses the same command line parameters as the process we identified as minerd on the DVR.

If you got a router like this, take a look what you find. We do still need a copy of the respective executables to confirm our suspicion. 

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