Diaries

Published: 2014-10-31

CSAM Month of False Positives: Appropriately Weighting False and True Positives

This is a "guest diary" submitted by Chris Sanders. We will gladly forward any responses or please use our comment/forum section to comment publicly. 

 
If you work with any type of IDS, IPS, or other detection technology then you have to deal with false positives. One common mistake I see people make when managing their indicators and rules is relying solely on the rate of false positives that are observed. While false positive rate is an important data point, it doesn't encompass everything you should consider when evaluating the effectiveness of a rule or indicator. For instance, consider a scenario where you have a rule that looks for a specific byte pattern in outbound traffic like this:
 
alert tcp $HOME_NET any -> $EXTERNAL_NET any (msg:"Random Malware"; flow:to_server,established; content:"|AB BF 09 B7|"; sid:12345; rev:1;)
 
You can see that this rule isn't incredibly specific as it examines all TCP traffic for four specific outbound bytes. As a result, there might be potential for false positives here. In this case, I ran this rule on a large network over the course of a month, and it generated 58 false positive alerts. Using that data point alone, it sounds like this rule might not be too effective. As a matter of fact, I had a few people who asked me if I could disable the rule. However, I didn't because I also considered the number of true positive alerts generated from this rule. Over the same period of time this rule generated 112 true positive alerts. This means that the rule was effective at catching what it was looking for, but it still wasn't entirely precise.
 
I mention the word precise, because the false positive and true positive data points can be combined to form a precision statistic using the formula P = TP / (TP + FP). This value, expressed as a percentage, can be used to describe exactly how precise a rule is, with higher values being more desirable. In the case of our example rule, the rule has 65.9% precision, meaning that it successfully detected what it was looking for 65.9% of the time. That doesn’t sound like a rule that should be disabled to me. Instead, I was able to conduct more research and further tune the rule by looking for the byte pattern in a specific location in the packet.
 
When examining rules and indicators for their effectiveness, be sure to consider both true and false positives. You might miss out on favorable detection if you don't.
 
Chris Sanders
Twitter: @chrissanders88
Blogs: http://www.appliednsm.com & http://www.chrissanders.org

5 Comments

Published: 2014-10-30

CSAM Month of False Postives - False Positives from Management

Often the start of a problem and it's solution is receiving a call from a manger, project manager or other non-technical decision maker.  You'll know going in that the problem is absolutely real, but the information going in might be a total red herring.

Some classic examples are:

"The network is slow – I ran a speed test, we should being seeing 10x the speed."

This is almost always a math error.  The speed was measured in Bytes (upper case B), instead of bits (lower case B).  Multiply by 8 and things should look better.

“the network is slow – our new web server takes 30 seconds to load the lead page”

As most of you know, in a modern gigabit network, even on a busy network there just isn’t anything on the network that will add a 30 second delay.  30 seconds in particular would have me checking for DNS issues first, especially for a new host or service.  However, in this case, the client was loading their entire Java application (including the business logic) before the login page.  The “appdev” answer to this would be to load the login page first, then load the app asynchronously in the background.  The security answer to this is to question why you would load the application logic to an untrusted workstation on a hostile network (public internet).

The network is slow – it must be a broadcast storm.

It’s exceedingly rare to see a broadcast storm.  Plus if the switches are configured correctly, if a broadcast storms does occur, it should be contained to a single Ethernet port, and it should either be rate limited or the port should be shut down, depending on your configuration.

When a non-technical person says “broadcast storm”, it really could mean anything that affects performance.  Almost always it will end up being something server side – DNS misconfigurations are a common thing (10-30 second delays on the first request), but it could also be an oversubscribed virtual infrastructure, coding errors, out of memory conditions, errors in programming, anything really.

The firewall is blocking our traffic

In some cases, especially if there is an egress filter, this can be the case.  However, in many other cases it could be something else entirely.  We recently worked on an issue where an AS400 (iSeries now I guess) was not connecting to the server.  It turned out that the certificate needed for the connection was incorrect - the vendor had sent us a cert for a different site entirely.  Wireshark did a great job in this case of saying "LOOK HERE- THE PROBLEM IS HERE" by giving us a "Bad Certificate" error - in bright red - in the main view.

We need port 443 open, in both directions

This is NEVER the case, but is commonly seen in vendor documentation.  Either you need an outbound port (possibly an update to the egress filter), or an inbound port open.  There are very few “in both directions” requirements - special cases like IPSEC VPN’s encapsulated in UDP (NAT-T) for instance will have both a source and destination port  of udp/500.  In most cases, when the requirement is “in both directions” or “bidirectional”, it’s a bit of a treasure hunt to figure out what they mean (usually it’s outbound).

The moral of the story?  I guess the first one is that if somebody tells you that the problem is the network, 70% of the time it’s not the network.   More importantly though, is that if you get a business problem from a business person, it’s not something to minimize.  You might not be able to count on all the information you get going in, but if they tell you something is slow or not usable, it’s their system, they are usually correct in at least identifying that the problem is real.

Please, use our comment form and fill us in on any recent false positives from a  non-technical source that you've seen.  Extra points if it was a real problem, but the initial info started you off in the wrong direction.

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

2 Comments

Published: 2014-10-30

Hacking with the Oldies!

Recently we seem to have a theme of new bugs in old code - first (and very publically) openssl and bash.  This past week we've had a bunch more, less public but still neat bugs.

First, a nifty bug in strings - CVE-2014-8485, with more details here http://lcamtuf.blogspot.ca/2014/10/psa-dont-run-strings-on-untrusted-files.html
a problem in wget with ftp: https://community.rapid7.com/community/metasploit/blog/2014/10/28/r7-2014-15-gnu-wget-ftp-symlink-arbitrary-filesystem-access
and now the ftp client (found first in BSD) -  http://cxsecurity.com/issue/WLB-2014100174

These all share some common ground, where data that the code legitimately should be processing can be crafted to execute an arbitrary command on the target system.  The other common thing across these as that these utilities are part of our standard, trusted toolkit - we all use these every day.

Who knew?  Coders who wrote stuff in C back in the day didn't always write code that knew how much was too much of a good thing.  Now that we're all looking at problems with bounds checking on input data, expect to see at least a couple more of these!

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

1 Comments

Published: 2014-10-29

The Wonderful World of CMS strikes again

I think that I will start this Diary with the following statement:

If you use an open source CMS, and you do not update it frequently, there is a very high chance that your website if not only compromised but also part of a botnet.

You probably already saw several of our diaries mentioning vulnerabilities in very well-known CMS systems like WordPress and Joomla, which are quite powerful and easy to use/install, and also full of vulnerabilities and requires frequent updates.

The third one in this list is Drupal. We mentioned last week, on our podcast about a critical vulnerability fixed by the developers, and today they released a "Public Announcement" in regards to that vulnerability. And it is scary (yes, Halloween pun intended...) .

The PSA mentions that within hours of the Patch announcement, there were already several automated attacks looking for the SQL injection vulnerability in the Drupal implementations.

As our reader Gebhard noted, there is a very interesting quote in the PSA:

"You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement"

This means, that by now, even if you updated your server, there is very high chance that your server is now part of a botnet...so, if you have a website with Drupal, I would highly recommend the Recovery section of the PSA document.

---

Pedro Bueno (pbueno /%%/ isc. sans. org)

Twitter: http://twitter.com/besecure

0 Comments

Published: 2014-10-28

Do you remember your "first love"?

I will never forget the name of my first server - Rachel. I was very proud to be the person whose job it was to defend Rachel from all types of disruption. To this day I still remember each IP address, user account, service account and application. When patches were installed, I manually verified they had been applied successfully. I diligently reviewed the logs and configured full auditing to let me know the success and failure of just about everything. 

I have administered many servers since Rachel, but do not remember as much about them as I do about my "first love”. Consider this an invitation to fall back in love with your servers. An invitation to return back to the time when you did everything possible to defend them. It may be possible that by returning to the diligence you once had, many problems and outages could be avoided.

How can you do this? The act of actively measuring how well you manage, secure and maintain your severs can very well be the catalyst you need to return back to your "first love”. Consider creating and sending yourself a daily report that clearly shows its current security posture. What are good candidates for this report? I am glad you asked, Some of my favorites include the following. 

  • Mean time to detect a network scan
  • Mean time to identify a new administrator account
  • Mean time to identify a new service running (or not running anymore)
     

There are certainly many metrics you could track. Pick a few and diligently check them every day for the next month. You'll be glad you did! 

Feel free to use our comment page to let us know what you are doing to remember your “first love”.

 

 

Russell Eubanks

@russelleubanks

2 Comments

Published: 2014-10-27

CSAM: False Positives, and Managing the Devils

Continuing our theme of False Positives this month, I’d like to talk about the process of managing false positives we encounter in the course of analysis.  False positives will almost always show at some point during a security analysis, which leads to unwanted additional work on the part of either the sysadmins, security teams, or both.  Even worse, continued false positives can lead to complacency during analysis, where things are ‘assumed’ false because they have been seen before, and allowed to pass as normal when indeed it would be a symptom of malicious behavior.

 

Managing false positives in our testing and analysis is part of the overall security process, which can be used to identify and eliminate false positives.  Pieces of the process which are key to the lifecycle management are:

-Configuration Management (we need to know what we have on our hosts, and what it should be doing)

-Ports, Protocols, and Services baseline (need to know what we have on the wire, and where it’s going)

-Continuous Monitoring (Either monitoring the wire, or the host; this will tell us when a condition occurs which requires our attention)

 

An ideal scenario in an operating environment may run something like this: “A Continuous Monitoring program alerts that a vulnerability exists on a host.  A review of the configuration of the host shows that the vulnerability does not exist, and a verification can be made from the traffic logs which reveal that no traffic associated with the vulnerability has transited the wire.  The Continuous Monitoring application should be updated to reflect that the specific vulnerability reported on that specific host is a false positive, and should be flagged accordingly in future monitoring.  The network monitoring would *not* be updated, because it did not flag a false positive, leaving the defense-in-depth approach in tact.”

 

Now, this is *ideal*, and a very high level, but it hopefully gives some ideas on how false positives could be managed within the enterprise, and the processes that contribute.  We would really like to hear how false positives are managed in other enterprise environments, so let us know. :)

tony d0t carothers --gmail

1 Comments

Published: 2014-10-24

Scanning for Single Critical Vulnerabilities

Where I work, we have a decent sized IP space and scanning can be problematic.  Within our IP space, we can have ~20 Million IP’s available.  Traditional scanning using NMAP, while effective, can take a long time even with aggressive scan setting.  By leveraging new scanning technologies like Masscan (hxxps://github.com/robertdavidgraham/masscan), this scanning can be done in minutes.  With moderate settings, I don’t want to crash firewalls, it takes about 15 min per port.

While this example is specific to Heartbleed, I use this technique for any of the exploit-of-the-day.  By using a fast port scanner to reduce the number of hosts to only the systems running the service in question, you can dramatically speed up your scan time. Additionally, within the first couple of days of an exploit,  you may be using a custom script to scan rather than a plugin from an enterprise solution.

Another use case is a vulnerability found during incident response.  If I determine a specific vulnerability was used to compromise a server, I then use this technique to determine other possible compromised systems. If they were not compromised, then we have them patch.

Masscan

Installing  the utility is easy

>git clone https://github.com/robertdavidgraham/masscan

>cd masscan/

>make; make install

Masscan uses a similar command line to nmap.

            >masscan -p 443,448,456,563,614,636,989,990,992,993,994,995,8080,10000

              10.0.0.0/8 -oG 10-scan-ssl - -max-rate 10000

 

-oG Grepable output

-p port to scan

10.0.0.0/8 network to scan

-oG Output in grepable format

10-scan-443 is filename created by scan

--make-rate sets the speed of the scan

Once Masscan has quickly identified targets for deeper inspection, you can use your more specific tool to determine if the system is vulnerable.  In this example, its an nmap plugin.

 

NMAP

cd /tmp

>svn co https://svn.nmap.org/nmap

>cd nmap

>./configure;make;make install


To get the input file in the correct format, use the following command to get just a file with a single IP per line.

            >grep -v '#' 10-scan-443 |awk '{print $2}' >/tmp/nmap

 

To run nmap, make sure you have the right ports specified, the specific script you need and specify the correct input file.

>nmap -p 443,448,456,563,614,636,989,990,992,993,994,995,8080,10000 --script=ssl-heartbleed.nse -iL /tmp/nmap -oA /tmp/ssl-vul-test


I've had mixed results with other scanners (scanrand ect..).  Any other large scale scanners with which you have had  good success?

--

Tom Webb

0 Comments

Published: 2014-10-24

Shellshock via SMTP

I've received several reports of what appears to be shellshock exploit attempts via SMTP.  The sources so far have all be webhosting providers, so I'm assuming these are compromised systems.  The emails headers look something like this (thanks Justin for the anonymized headers, no thanks to Outlook for helpfully trying to make the links live):

The payload is an IRC perl bot with simple DDoS commands and the ability to fetch and execute further code.

 

0 Comments

Published: 2014-10-24

Are you receiving Empty or "Hi" emails?

    I wanted to perform a little unscientific information gathering, I'm working with a small group who think they're being specifically targeted by these, while I think it's more widespread and opportunitistic.  If you've recently received these no content probe emails, or a simple "Hi" message, please send a simple comment below in this format:

  • Industry
  • Order of magnitued in size (e.g. <10, <100, <1000)
  • Sending domain

    Feel free to use our comment page to add extra analysis comments here: https://isc.sans.edu/contact.html

15 Comments

Published: 2014-10-23

Digest: 23 OCT 2014

A number of items for your consideration today, readers. Thanks as always to our own Rob VandenBrink for pointing out a number of these.

In case you missed it, What's New in Window's PowerShell.

A new Snort release is available: Snort 2.97.

VMWare has released a security advisory: VMSA-2014-0011 - VMware vSphere Data Protection product update addresses a critical information disclosure vulnerability.

There's a Whitehouse petition to unlock public access to research on software safety through DMCA and CFAA reform. Needs 98,000 signatures, currently has just over 1000. The synopsis for your consideration:

Software now runs consumer products and critical systems that we trust with our safety and security. For example, cars, medical devices, voting machines, power grids, weapons systems, and stock markets all rely on code. While responsible companies cooperate with the technical community and the public to improve the safety of code, others do not. They instead try to prevent researchers and others from sharing safety research, threatening criminal and civil actions under the Digital Millennium Copyright Act and the Computer Fraud and Abuse Act. Chilling research puts us all at risk. Protect the public from unsafe code and help us to protect ourselves. Reform the DMCA and CFAA to unlock and encourage research about potentially dangerous safety and security weaknesses in software.

If you agree, sign the petition here.

NIST just released a draft of NIST Special Publication 800-125-A Security Recommendations for Hypervisor Deployment. You denizens of the cloud should give this one a good read through.

0 Comments

Published: 2014-10-22

telnetd rulez: Cisco Ironport WSA Telnetd Remote Code Execution Vulnerability

We received the following vulnerability advisory for a remote code execution vuln identified and reported in Cisco's Ironport WSA Telnetd.

Vendor: Cisco
Product web page: http://www.cisco.com
Affected version: Cisco Ironport WSA - AsyncOS 8.0.5 for Web build 075
Date: 22/05/2014
Credits: Glafkos Charalambous
CVE: CVE-2011-4862
CVSS Score: 7.6
Impact: Unauthenticated Remote Code Execution with elevated privileges
Description: The Cisco Ironport WSA virtual appliances are vulnerable to an old FreeBSD telnetd encryption Key ID buffer overflow which allows remote attackers to execute arbitrary code (CVE-2011-4862).
Cisco WSA Virtual appliances have the vulnerable telnetd daemon enabled by default.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4862
http://www.freebsd.org/security/advisories/FreeBSD-SA-11:08.telnetd.asc
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120126-ironport

Nice work by Glafkos but what you can't see is me shaking my head. *sigh*
I'll repeat the facepalm-inspiring statement again: "Cisco WSA Virtual appliances have the vulnerable telnetd daemon enabled by default."
Still, with the telnets? And on by default?
From the related FreeBSD advisory:
"The FreeBSD telnet daemon, telnetd(8), implements the server side of the
TELNET virtual terminal protocol.  It has been disabled by default in
FreeBSD since August 2001, and due to the lack of cryptographic security
in the TELNET protocol, it is strongly recommended that the SSH protocol
be used instead."

See if this sums up for you, courtesy of Glafkos:
Trying 192.168.0.160...
Connected to 192.168.0.160.
Escape character is '^]'.

[+] Exploiting 192.168.0.160, telnetd rulez!
[+] Target OS - FreeBSD 8.2 amd64
[*] Enjoy your shell

Remediation:
Patch
Disable telnetd!

3 Comments

Published: 2014-10-21

CSAM Month of False Positives: Ghosts in the Pentest Report

As part of most vulnerability assessments and penetration tests against a website, we almost always run some kind of scanner.  Burp (commercial) and ZAP (free from OWASP) are two commonly used scanners.  Once you've done a few website assessments, you start to get a feel for what pages and fields are "likely candidates" for exploit.  But especially if it's a vulnerability assessment, where you're trying to cover as many issues as possible (and exploits might even be out of scope), it's always a safe bet to run a scanner to see what other issues might be in play.

All too often, we see people take these results as-is, and submit them as the actual report.  The HUGE problem with this is false positives and false negatives.

False negatives are issues that are real, but are not be found by your scanner.  For instance, Burp and ZAP aren't the best tools for pointing a big red arrow at software version issues - for instance vulnerability versions of Wordpress or Wordpress plugins.  You might want to use WPSCAN for something like that.  Or if you go to the login page, a "view source" will often give you what you need. 

Issues with the certificates will also go unnoticed by a dedicated web scanner - NIKTO or WIKTO are good choices for that.  Or better yet, you can use openssl to pull the raw cert, or just view it in your browser.

(If you're noticing that much of what the cool tools will do is possible with some judicious use of your browser, that's exactly what I'm pointing out!)

NMAP is another great tool to use for catching what a web scanner might miss.  For instance, if you've got a Struts admin page or Hypervisor login on the same IP as your target website, but on a different port than the website, NMAP is the go-to tool.  Similarly, lots of basic site assessment can be done with the NMAP  --version parameters, and the NSE scripts bundled with NMAP are a treasure trove as well!  (Check out Manuel's excellent series on NMAP scripts).

False positives are just as bad - where the tool indicates a vulnerability where there is none.  If you include blatant false positives in your report, you'll find that the entire report will end up in the trash can, along with your reputation with that client!  A few false positives that I commonly see are "SQL Injection" and "OS Commmand Injection".

SQL Injection is a vulnerability where, from the web interface, you can interact with and get information from a SQL database that's "behind" the website, often dumping entire tables.

Website assessment tools ( Burp in this case, but many other tools use similar methods) commonly tests for SQL Injection by injecting a SQL "waitfor delay '0:0:20'" command.  If this takes a significantly longer time to complete than the basic statement, then Burp will mark this as "Firm" for certainty.  Needless to say, I often see this turn up as a false positive.  What you'll find is that Burp generally runs multiple threads (10 by default) during a scan, so can really run up the CPU on a website, especially if the site is mainly parametric (where pages are generated on the fly from database input during a session).  Also, if a site's error handling routines take longer than they should, you'll see this get thrown off.

So, how should we test to verify this initial/preliminary finding?  First of all, Burp's test isn't half bad on a lot of sites.  Testing Burp's injection with curl or a browser after the scanning is complete will sometimes show that the SQL injection is "real".  Test with multiple times, so that you can show consistent and appropriate delays for values of 10,30,60, 120 seconds.

 If that fails - for instance if they all delay 10 seconds, or maybe no appreciable delay at all, don't despair - SQLMAP tests much more thoroughly, and should be part of your toolkit anyway - try that.  Or test manually - after a few websites you'll find that testing manually might be quicker than an exhaustive SQLMAP test (though maybe not as "thorough").

If you use multiple methods (and there are a lot of different methods) and still can't verify that SQL injection is in play after that initial scan's finding, quite often this has to go into the "false positives" section of your report.


OS Command Injection - where you can execute unauthorized Operating System commands from the web interface - is another common false positive, and for much the same reason.  In this vulnerability, the scanner will often use "ping -c 20 127.0.0.1"  or "ping -n 20 127.0.0.1" - in other words, the injected command tells the webserver to ping itself, in this case 20 times.  This will in most operating systems create a delay of 20 seconds.  As in the SQL injection example, you'll find that tests that depend on predictable delay will often get "thrown off" if they are executed during a busy scan.  Running them after the scan (again, using your browser or curl) is often all you need to do to prove these findings as false.  Testing other commands, such as pinging or opening an ftp session to a test host on the internet (that is monitoring for such traffic using tcpdump or syslog) is another good "sober second thought" test, but be aware that if the website you are testing has an egress filter applied to it's traffic, a successful injection might not generate the traffic you are hoping for - it'll be blocked at the firewall.  If you have out of band access to the site being assessed, creating a test file is another good test.

Other tests can similarly see false positives.  For instance, any tests that rely only on service "banner grabs" can be thrown off easily - either by admins putting a false banner in place, or if site updates update packages and services, but don't change that initially installed banner.

Long story short, never never never (never) believe that initial finding that your scanning tool gives you.  All of the tools discussed are good tools - they should all be in your toolbox and in many cases should be at the top of your go-to list.  Whether the tool is open source or closed, free or very expensive, they will all give you false positives, and every finding needs to be verified as either a true or false positive.  In fact, you might not want to believe the results from your second tool either, especially if it's testing the same way.  Whenever you can, go back to first principals and verify manually.  Or if it's in scope, verify with an actual exploit - there's nothing better than getting a shell to prove that you can get a shell!

For false negatives, you'll also want to have multiple tools and some good manual tests in your arsenal - if your tool misses a vulnerability, you may find that many or all of your tools test for that issue the same way.  Often the best way to catch a false negative is to just know how that target service runs, and know how to test for that specific issue manually.  If you are new to assessments and penetration tests, false negatives will be much harder to find, and really no matter how good you are you'll never know if you got all of them.

If you need to discuss false positives and negatives with a non-technical audience, going to non-technical tools is a good way to make the point.  A hammer is a great tool, but while screws are similar to nails, a hammer isn't always the best way to deal with them.

Please, use our comment form tell us about false positives or false negatives that you've found in vulnerability assessments or penetration tests.  Keep in mind that usually these aren't an indicator of a bad tool, they're usually just a case of getting a proper parallax view to get a better look at the situation.

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

3 Comments

Published: 2014-10-20

Apple Multiple Security Updates


Apple released security update today for iOS 8 and Apple TV 7.

iOS 8.1 (APPLE-SA-2014-10-20-1 iOS 8.1) is now available for iPhone 4s and later, iPod touch (5th generation) and later, iPad 2 and later, to addresses the following:

Bluetooth               CVE-2014-4448
House Arrest          CVE-2014-4448
iCloud Data Access CVE-2014-4449
Keyboards               CVE-2014-4450
Secure Transport     CVE-2014-3566

Apple TV 7.0.1 (APPLE-SA-2014-10-20-2 Apple TV 7.0.1) is now available for Apple TV 3rd generation and later, to address the following:

Bluetooth              CVE-2014-4428
Secure Transport   CVE-2014-3566

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

-----------

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

Teaching SEC 503 end of October in Ottawa

0 Comments

Published: 2014-10-19

Microsoft MSRT October Update

This past week Microsoft MSRT push contains detections/removals for several widely used APT tools. The coalition (led by Novetta) that brought about the inclusions of these tools in this month MSRT, are encouraging enterprises to push/execute this month MSRT update. Some of malware included in this month MSRT update have a preliminary report posted here.  

If you are using either Snort or Sourcefire, the ruleID's to detect some of the threat/family in this month MSRT release are listed below and can be downloaded from Snort or from Sourcefire VRT subscription.

Derusbi -- 20080
Fexel -- 29459
Hikit -- 30948
DeputyDog -- 28493
Hydraq -- 16368, 21304
DarkMoon -- 7816, 7815, 7814, 7813, 12715, 12724
Zxshell -- 32180, 32181

[1] http://blogs.technet.com/b/mmpc/archive/2014/10/14/msrt-october-2014-hikiti.aspx
[2] http://www.microsoft.com/security/pc-security/malware-removal.aspx
[3] http://novetta.com/commercial/news/resources/
[4] https://www.snort.org/downloads/#rule-downloads

-----------

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

Teaching SEC 503 end of October in Ottawa

0 Comments

Published: 2014-10-17

Apple Updates (not just Yosemite)

Apple yesterday released the latest version of its operating system, OS X 10.10 Yosemite. As usual, the new version of the operating system does include a number of security related bug fixes, and Apple released these fixes for older versions of OS X today.

This update, Security Update 2014-005 is available for versions of OS X back to 10.8.5 (Mountain Lion). 

Among the long list of fixes, here a couple of highlights:

Apple doesn't turn off SSLv3 in this release, but restricts it to non-CBC ciphers, limiting its exposure to attacks like POODLE and BEAST. The list of trusted certificate authorities has also been updates [2]

802.1x no longer supports LEAP by default due to weaknesses in this authentication method.

The bash fix, that was released as a standalone fix earlier to counter "Shellshock", is included in this update.

An arbitrary code execution vulnerability in CUPS was fixed. (CVE-2014-3537)

And a quick note about OS 10.10 Yosemite:

After installing it, all security relevant settings I checked where untouched (good!). Among security relevant software, GPGMail will not work with Yosemite yet, but according to the developers, a fix is in the work and may be release in a few weeks, but GPGMail may no longer be free. If you rely on software that you compiled with MacPorts: Wait for the release of XCode 6.1, as it is required to recompile the software for OS X 10.10. In general, it is adviced that you FIRST update all your software and then upgrade to Yosemite. Little Snitch, another popular piece of security software for OS X, works well with Yosemite, but I recommend you turn off the network filter during the upgrade (it works with it enabled, but you need to approve a lot of new connections from new software).

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

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

3 Comments

Published: 2014-10-16

Logging SSL

With POODLE "behind us", it is time to get ready for the next SSL fire drill. One of the questions that keeps coming up is which ciphers and SSL/TLS versions are actually in use. If you decide to turn off SSLv3 or not depends a lot on who needs it, and it is an important answer to have ready should tomorrow some other cipher turn out to be too weak.

But keep in mind that it is not just numbers that matter. You also need to figure out who the outliers are and how important (or dangerous?) they are. So as a good start, try to figure out how to log SSL/TLS versions and ciphers. There are a couple of options to do this:

In Apache, you can log the protocol version and cipher easily by logging the respective environment variable [1] . For example:
CustomLog logs/ssl_request_log  "%t %h \"{User-agent}i\" %{SSL_PROTOCOL}x %{SSL_CIPHER}x "

Logs SSL protocol and cipher. You can add this to an existing access log, or create a new log. If you decide to log this in its own log, I suggest you add User-Agent and IP Address (as well as time stamp).

In nginx, you can do the same by adding $ssl_cipher $ssl_protocol to the log_format directive in your nginx configuration. For example:

log_format ssl ''$remote_addr "$http_user_agent" $ssl_cipher $ssl_protocol

Should give you a similar result as for apache above. 

If you have a packet sniffer in place, you can also use tshark to extract the data. With t-shark, you can actually get a bit further. You can log the client hello with whatever ciphers the client proposed, and the server hello which will indicate what cipher the server picked.

tshark -r ssl -2R 'ssl.handshake.type==2 or ssl.handshake.type==1' -T fields -e ssl.handshake.type -e ssl.record.version -e ssl.handshake.version -e ssl.handshake.ciphersuite

For "extra credit" log the host name requested in the client hello via SNI and compare it to the actual host name the client connects to.

Now you can not only collect "Real Data" as to what ciphers are needed, but you can also look for anomalies. For example, user agent's that request very different ciphers then other connections that claim to originate from the same user agent. Or who is asking for weak ciphers? Maybe a sign for an SSL downgrade attack? Or an attack tool using  and older SSL library...

[1] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#logformats[2] 

 

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

5 Comments

Published: 2014-10-16

Cisco Security Advisory: SSL Padding Oracle On Downgraded Legacy Encryption (POODLE) Vulnerability



Advisory ID: cisco-sa-20141015-poodle

Revision 1.0

For Public Release 2014 October 15 17:30  UTC (GMT)

+---------------------------------------------------------------------

Summary
+======

On October 14, 2014, a vulnerability was publicly announced in the Secure Sockets Layer version 3 (SSLv3) protocol when using a block cipher in Cipher Block Chaining (CBC) mode. SSLv3 is a cryptographic protocol designed to provide communication security, which has been superseded by Transport Layer Security (TLS) protocols. By exploiting this vulnerability, an attacker could decrypt a subset of the encrypted communication.

This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141015-poodle


 

0 Comments

Published: 2014-10-15

Multiple Vulnerabilities in Cisco TelePresence Video Communication Server and Cisco Expressway Software

Multiple Vulnerabilities in Cisco TelePresence Video Communication Server and Cisco Expressway Software
Advisory ID: cisco-sa-20141015-vcs

Cisco TelePresence Video Communication Server (VCS) and Cisco Expressway Software includes the following vulnerabilities:
•    Cisco TelePresence VCS and Cisco Expressway Crafted Packets Denial of Service Vulnerability
•    Cisco TelePresence VCS and Cisco Expressway SIP IX Filter Denial of Service Vulnerability
•    Cisco TelePresence VCS and Cisco Expressway SIP Denial of Service Vulnerability
Succesfull exploitation of any of these vulnerabilities could allow an unauthenticated, remote attacker to cause a reload of the affected system, which may result in a Denial of Service (DoS) condition.

Cisco has released free software updates that address these vulnerabilities. Workarounds that mitigate these vulnerabilities are not available. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20141015-vcs

Note: This security advisory does not provide information about the GNU Bash Environment Variable Command Injection Vulnerability (also known as Shellshock). For additional information regarding Cisco products affected by this vulnerability, refer to the Cisco Security Advisory at the following link: http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140926-bash



 

0 Comments

Published: 2014-10-15

POODLE: Turning off SSLv3 for various servers and client.

Before you start: While adjusting your SSL configuration, you should also check for various other SSL related configuration options. A good outline can be found at http://bettercrypto.org as well as at http://ssllabs.com (for web servers in particular)

Here are some configuration directives to turn off SSLv3 support on servers:

Apache: Add -SSLv3 to the "SSLProtocol" line. It should already contain -SSLv2 unless you list specific protocols. 

nginx: list specific allowed protocols in the "ssl_protocols" line. Make sure SSLv2 and SSLv3 is not listed. For example: ssl_protocols TLSv2 TLSv1.1 TLSv1.2;

Postfix: Disable SSLv3 support in the smtpd_tls_manadatory_protocols configuration line. For example: smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3

Dovecot: similar, disable SSLv2 and SSLv3 in the ssl_protocols line. For example: ssl_protocols = !SSLv2 !SSLv3

HAProxy Server: the bind configuration line should include no-sslv3 (this line also lists allowed ciphers)

puppet: see https://github.com/stephenrjohnson/puppetmodule/commit/1adb73f9a400cb5e91c4ece1c6166fd63004f448 for instructions

For clients, turning off SSLv3 can be a bit more tricky, or just impossible.

Google Chrome: you need to start Google Chrome with the "--ssl-version-min=tls1" option. 

Internet Explorer: You can turn off SSLv3 support in the advanced internet option dialog.

Firefox: check the "security.tls.version.min" setting in about:config and set it to 1. Oddly enough, in our testing, the default setting of 0 will allow SSLv3 connections, but refuses to connect to our SSLv3 only server.

For Microsoft Windows, you can use group policies. For details see Microsoft's advisory: https://technet.microsoft.com/en-us/library/security/3009008.aspx

To test, continue to use our "POODLE Test" page at https://poodletest.com or the Qualys SSLLabs page at https://ssllabs.com

To detect the use of SSLv3, you can try the following filters:

tshark/wireshark display filters: ssl.handshake.version==0x0300

​tcpdump filter: (1) accounting for variable TCP header length: 'tcp[((tcp[12]>>4)*4)+9:2]=0x0300'
                       (2) assuming TCP header length is 20: 'tcp[29:2]=0x0300'

We will also have a special webcast at 3pm ET. For details see

https://www.sans.org/webcasts/about-poodle-99032 

the webcast will probably last 20-30 minutes and summarize the highlights of what we know so far.

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

3 Comments

Published: 2014-10-15

OpenSSL Releases OpenSSL 1.0.1j, 1.0.0o and 0.9.8zc

This update to the OpenSSL Library addresses 4 vulnerabilities. One of these is the "POODLE" vulnerability announced yesterday.

CVE-2014-3513: A memory leak in parsing DTLS SRTP messages can lead to a denial of service. You are vulnerable, unless you specificly compiled your OpenSSL library with the "OPENSSL_NO_SRTP" option. All 1.0.1 versions of OpenSSL are affected.

CVE-2014-3567: Another memory leak that can lead to a DoS attack. In this case, memory is not free up if an SSL session ticket fails an integrity check. OpenSSL 0.9.8, 1.0.0 and 1.0.1 are affected.

CVE-2014-3566 (POODLE): OpenSSL now supports TLS_FALLBACK_SCSV to prevent a MitM from downgrading an SSL connection. This affects OpenSSL 1.0.1, 1.0.0 and 0.9.8.

CVE-2014-3568: The "no-ssl3" build option, which is intended to disable SSLv3, may actually not work as advertised. This one is of course particularly important if you try to disable SSLv3.

Also, OpenSSL 0.9.8 is now officially end-of-life. Don't expect any more patches for 0.9.8.

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

0 Comments

Published: 2014-10-15

October 2014 Critical Patch Update Released

Oracle have released its critical patch update for October 2014, this series of patches will provide fixes for 154 vulnerabilities across a number of product families including: Oracle Database, Oracle Fusion Middleware, Oracle Enterprise Manager Grid Control, Oracle E-Business Suite, Oracle Supply Chain Product Suite, Oracle PeopleSoft Enterprise, Oracle JDEdwards EnterpriseOne, Oracle Communications Industry Suite, Oracle Retail Industry Suite, Oracle Health Sciences Industry Suite, Oracle Primavera, Oracle Java SE, Oracle and Sun Systems Product Suite, Oracle Linux and Virtualization, and Oracle MySQL.

 For more details please refer to the following link:

http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html

 

0 Comments

Published: 2014-10-14

SSLv3 POODLE Vulnerability Official Release

Finally we got an official announcement. For all the details, jump straight to the original announcement [1]. Below see the TL;DR; version:

The problem is limited to SSLv3. SSLv3 is often considered similar to TLSv1.0, but the two protocols are different.

SSLv3 had issues in the past. Remember the BEAST attack? It was never resolved (other then moving to TLS 1.1/2). The only alternative was to use a stream cipher like RC4, which had its own problems.

But this POODLE issue is different. With block ciphers, we have a second problem: What if the block to be encrypted is too short? In this case, padding is used to make up for the missing data. Since the padding isn't really considered part of the message, it is not covered by the MAC (message authorization code) that verified message integrity.

So what does this mean in real live? The impact is similar to the BEAST attack. An attacker may either play MitM, or may be able to decrypt parts of a message if the attacker is able to inject data into the connection just like in the BEAST attack. The attack allows one to decrypt one byte at a time, if the attacker is able to inject messages right after that byte that include only padding.

What should you do: Disable SSLv3. There is no patch for this. SSLv3 has reached the end of its useful life and should be retired. 

This isn't a "patch now". Give it some time, test it carefully, but get going with it. The other problem is that this is a client and a server issue. You need to disable SSLv3 on either. Start with the servers for highest impact, but then see what you can do about clients.

The other option to "fix" this problem is to use SSL implementations that take advantage of the TLS_FALLBACK_SCSV feature. This feature notifies the other side that you first tried the stronger cipher. This way, they can reject the downgrade attempt that may have been introduced by a MitM attack. But it isn't clear which implementations use this feature at this point, and which don't. A patch for OpenSSL 1.0.1 was released earlier today implementing TLS_FALLBACK_SCSV

FAQ

To test if your server is vulnerable: Use https://ssltest.com

To test if your client is vulnerable: We setup a test page at https://www.poodletest.com . If you can connect, then your client supports SSLv3 .

So far, we tested :

  Firefox 32 IE 11 Safari 7.1 Chrome 37 Opera
Windows 7  ok vuln vuln vuln  
OS X 10.9.5 ok N/A vuln vuln  
iOS 8.0.2 vuln N/A vuln vuln vuln

To turn off SSLv3 support in Internet Explorer 11:

Setting -> Internet Options -> Advanced Tab -> Uncheck "SSLv3" under "Security".

 

[1] https://www.openssl.org/~bodo/ssl-poodle.pdf

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

3 Comments

Published: 2014-10-14

OpenSSL Vulnerability leaked via OpenBSD patch (NOT!)?

Yesterday, a number of news sites published speculative reports about a possible OpenSSL bug to be fixed today. According to these reports, the bug affects SSL 3, and is "critical". Can't wait for the official announcement to see what is actually happening here ;-)

Initially, it looked like an OpenBSD patch lead to an answer, but turns out the patch was old (thx to those who wrote in and responded, in particular based on the tweet by @martijn_grooten ). But instead, there are new leads now, in particular a discussion on Stackexchange [1]. In this discussion, a comment by Thomas Pornin outlines how padding in SSLv3 can lead to MitM attacks. This would be an outright attack against the SSLv3 protocol, and less against a specific implementation. It would affect clients as well as servers. 

We will update this post as we learn more. At this point: Don't panic and wait for a patch from your respective vendor. We are not aware of any active exploitation of this problem, but please let us know if you see any evidence of that happening.

If you choose to disable SSLv3 on a server, but leave TLS 1.0 enabled, Windows XP with IE 6 will no longer be able to connect (but older versions of IE will be able to connect from Windows XP machines).

How can you test if a server supports SSLv3? Either use ssllabs.com, or using the openssl client: (if it connects, it supports SSLv3)

openssl s_client -ssl3 -connect [your web server]:443 

How can I check if my browser can live without SSLv3? If you can read this, then you support TLSv1 or higher. I turned off SSLv3 support on this site for now. But pretty much all browsers support SSLv3.

You tell us not to panic, but you turned of SSLv3? Yes. I wanted to see what happens if I turn off SSLv3. So far, the only issue I found was Windows XP with IE 6, a configuration I probably don't want to support anyway.


[1] http://chat.stackexchange.com/transcript/message/18152298#18152298

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

0 Comments

Published: 2014-10-14

Adobe October 2014 Bulletins for Flash Player and Coldfusion

Adobe published two security bulletins today:

APSB-22 [1] : fixes 3 vulnerabilities in Adobe Flash Player as well as in Adobe Air. The vulnerabilities are rated with a priority of "1" for Flash Player running on Windows and OS X , which means they have already been exploited in targeted attacks.

APSB-23 [2] : another 3 vulnerabilities, but this time in Cold Fusion. The priority for these updates is "2" which indicates that they have not yet been exploited in the wild. 

[1] http://helpx.adobe.com/security/products/flash-player/apsb14-22.html
[2] http://helpx.adobe.com/security/products/coldfusion/apsb14-23.html

 

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

0 Comments

Published: 2014-10-14

Microsoft October 2014 Patch Tuesday

Microsoft only published 8 instead of the promised 9 bulletins. Also, of particular interest is MS14-060 which was pre-announced by iSight Partners. iSight has seen this vulnerability exploited in some "APT" style attacks against NATO/US military interests and attributes these attacks to Russia. Attacks like this have happened with many Office vulnerabilities in the past, but it is unusual for a company to announce the respective attacks and CVE numbers ahead of Microsoft's bulletin release. Note that we got a total of 3 already exploited vulnerabilities in this month's release. Don't believe patching fast will protect you. You are probably a few weeks if not months behind at the time the patch is released.

Overview of the October 2014 Microsoft patches and their status.

# Affected Contra Indications - KB Known Exploits Microsoft rating(**) ISC rating(*)
clients servers
MS14-056 Cumulative Security Update for Internet Explorer (replaces MS14-052)
Microsoft Windows, Internet Explorer
CVE-2014-4123, CVE-2014-4124, CVE-2014-4126, CVE-2014-4127, CVE-2014-4128, CVE-2014-4129, CVE-2014-4130, CVE-2014-4132, CVE-2014-4133, CVE-2014-4134, CVE-2014-4137, CVE-2014-4138, CVE-2014-4141, CVE-2014-4123, CVE-2014-4124, CVE-2014-4126, CVE-2014-4127, CVE-2014-4128, CVE-2014-4129, CVE-2014-4130, CVE-2014-4132, CVE-2014-4133, CVE-2014-4134, CVE-2014-4137, CVE-2014-4138, CVE-2014-4140, CVE-2014-4141
KB 2987107

CVE-2014-4123 has been exploited.

Severity:Critical
Exploitability: 1
Critical Important
MS14-057 Vulnerabilities in .NET Framework Could Allow Remote Code Execution (replaces MS12-016)
Microsoft Windows, Microsoft .NET Framework

CVE-2014-4073
CVE-2014-4121
CVE-2014-4122
KB 3000414 No. Severity:Critical
Exploitability: 2
Critical Critical
MS14-058 Vulnerability in Kernel-Mode Driver Could Allow Remote Code Execution (replaces MS14-015)
Microsoft Windows

CVE-2014-4113
CVE-2014-4148
KB 3000061 Yes. Used in Limited Attacks Severity:Critical
Exploitability: 0
Critical Critical
MS14-059 Vulnerability in ASP.NET MVC Could Allow Security Feature Bypass 
Microsoft Developer Tools

CVE-2014-4075
KB 2990942

Publicly disclosed,not
exploited. 

Severity:Important
Exploitability: 3
Less Important Important
MS14-060 Vulnerability in Windows OLE Could Allow Remote Code Execution  (replaces MS12-005)
Microsoft Windows

CVE-2014-4114
KB 3000869 yes. against powerpoint. See iSight disclosure. Severity:Important
Exploitability: 0
Critical Important
MS14-061 Vulnerability in Microsoft Word and Office Web Apps Could Allow Remote Code Execution (MS14-034, MS14-017)
Microsoft Office, Microsoft Office Services, Microsoft Office Web Apps

CVE-2014-4117
KB 3000434 No. Severity:Important
Exploitability: 1
Critical Important
MS14-062 Vulnerability in Message Queuing Service Could Allow Elevation of Privilege (MS09-040)
Microsoft Windows

CVE-2014-4971
KB 2993254 publicly disclosed but not exploited. Severity:Important
Exploitability: 1
Important Important
MS14-063 Vulnerability in FAT32 Disk Partition Driver Could Allow Elevation of Privilege 
Microsoft Windows

CVE-2014-4115
KB 2998579 No. Severity:Important
Exploitability: 1
Important Important
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
  • We use 4 levels:
    • PATCH NOW: Typically used where we see immediate danger of exploitation. Typical enviro\ nments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical \ deployments make it vulnerable and exploits are being used or easy to obtain or make.
    • Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to t\ est and deploy ASAP. Workarounds can give more time to test.
    • Important: Things where more testing and other measures can help.
    • Less Urt practices for servers such as not using outlook, MSIE, word etc. to do traditional office or lei\ sure 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.
STI|Twitter|LinkedIn

3 Comments

Published: 2014-10-13

CSAM: Be Wary of False Beacons

[This is a guest diary published on behalf of Chris Sanders]

Hunting for evil in network traffic depends on the analysts ability to locate patterns and variances in oceans of data. This can be an overwhelming tasks and relies on fundamental knowledge of what is considered normal on your network as well as your experienced-based intuition. These dark waters are navigated by finding glimmers of light and following them where they lead you by carefully investigating all of the data sources and intelligence in your reach. While hunting the adversary in this manner can yield treasure, following some of these distant lights can also land you in the rocks.

One scenario that often puts analysts in murky waters occurs when they chase patterns of network traffic occurring over clearly visible intervals. This periodic activity often gets associated with “beaconing”, where analysts perceive the timing of the communication to mean that it may be the result of malicious code installed on a friendly system.

As an example, consider the flow records shown here:

 

figure 1
Figure 1 (click on image for full size)

If you look at the timestamps for each of these records, you will see that each communication sequence occurs almost exactly one minute from the previous. Along with this, the other characteristics of the communication appear to be similar. A consistent amount of data is being transferred from an internal host 172.16.16.137 to an external host 173.194.37.48 each time.

So, what’s going on here? Less experienced analysts might jump to the conclusion that the friendly device is compromised and that it is “beaconing” back out to some sort of attacker controlled command and control infrastructure. In reality, it doesn’t take a lot of research to determine that the mysterious external entity is a Google hosted IP address. In this case, this traffic actually represents the periodic updating of a Google Finance stock ticker.

Figure 2
Figure 2 (click on image for full size)

As analysts, we are taught to identify patterns and hone in on those as potential signs of compromise. While this isn’t an entirely faulty concept, it should also be used with discretion. With dynamic content so prevalent on the modern Internet, it is incredibly common to encounter scenarios where devices communicate in a periodic nature. This includes platforms such as web-based e-mail clients, social networking websites, chat clients, and more.

Ultimately, all network traffic is good unless you can prove it’s bad. If you do need to dig in further in scenarios like this, try to make the best use of your time by looking for information you can use to immediately eliminate the potential that the traffic is malicious. This might include some basic research about the potentially hostile host like we did here, immediately pivoting to full PCAP data to view the content of the traffic when possible, or by simply examining the friendly host to determine which process is responsible for the connection(s). The ability to be selective of what you choose to investigate and to quickly eliminate likely false positives is the sign of a mature analyst. The next time you are hunting through data looking for evil, be wary when your eyes are drawn towards “beaconing” traffic.

Chris Sanders
Twitter: @chrissanders88
Blogs: http://www.appliednsm.com & http://www.chrissanders.org

2 Comments

Published: 2014-10-13

For or Against: Port Security for Network Access Control

I had an interesting discussion tonight with fellow handler Manuel on the pros and cons on port security as it relates to Network Access Control.  I thought it would be interesting to see where others in the security field stand on the issue.  Is it worth the effort or not?  Is it a valuable tool in Defense in Depth?  Here are some of the For and Against arguments we discussed:

For Arguments:

  • Stops others from being able to plug into your infrastructure, they would have to search to find a port that has not been configured correctly
  • Can audit logs to determine if empty ports are turned on or off
  • Can alert you more quickly to rogue devices being plugged into your infrastructure
  • Not a perfect solution but should be part of your defense in depth solution, its not meant to be a "stand alone" solution

Against Arguments:

  • If you fake the MAC address to the host, you are in
  • Insider/outsider threat is great since physical security to equipment is not well controlled in many organizations
  • Have to take into account failover scenarios or you can DoS yourself
  • Hard to manage large number of switch ports to ensure they are configured correctly at all times

So, is port security worth the effort or do many of you find its too time consuming and the benefits are not that great?  If you using it and have tips for successful implementation, please share them so others can benefit.  It is Cyber Security Awareness Month and this would be a good opportunity to help educate each other on issues you have encountered with port security or how it has helped protect your organization.

 

4 Comments

Published: 2014-10-10

CSAM: Month of False Positives - Breach Emails?

With all the high profile breaches pretty much every one of us has received a breach notification email in the recent past.  But how many of you could tell if it was legitimate?

Take this email from Target from early in 2014. 

With all the Target Phishing  campaigns going around at the time many people questioned the legitimacy of this email.  At first glance it looks pretty legitimate.  

With all the garbage email we receive most of us have been diliigent that at a minimum we check two things: 

- links in the email point to where the link says it points and that where the link points looks legitimate, 

- sender address, and reply-to, address does not look spoofed

In this case there is only one link in the email and it  points to creditmonitoring.target.com, which is a page in the target.com website.   What made people question the legitimacy was the from email address.  It was sent from TargetNews@target.bfio.com.  Clearly not a Target domain.

It turns out this email is legitimate. bfi0.com is a part of Epsilon Interactive a marketing service that Target uses for customer marketing.  If you check Targets FAQ page it says:

q: how do I prevent Target emails from going to my bulk or junk folder?
A: To make sure you continue to receive Target emails in your personal inbox (not bulk or junk folders), please take a moment to add Target.com [TargetNews@Target.bfi0.com] to your email address book.
 
This one from Fisher Price also looks, and is, legitimate.  
 
---------------
From: "customerservice@fisher-pricestore.com " <service@service.fisher-pricestore.com>
Subject: Important Request from Fisher-Price Online Store
Reply-To: service@service.fisher-pricestore.com


To ensure you receive our Fisher-Price e-mails in your inbox (not bulk or junk folders), please add
service@eservice.fisher-pricestore.com to your address book

Dear Valued Customer,

In order to improve your Fisher-Price Online Store website experience, we have transitioned to a different technology platform. As part of the transition, existing password information has been removed from your account. Before you can login to your account on the new site, you will need to reset your password using the "Forgot Password?" link.

As an added measure of security during the transition, all payment information was also removed from your account. After logging in, please feel free to re-enter that information for fast and easy checkout.

Thank you for your immediate attention to this matter and your continued interest in Fisher-Price Online Store. We look forward to serving you soon!

Sincerely,

Fisher-Price Online Store Customer Service

Please note that this does not affect your password for Fisher-Price.com.  No changes are needed for your Fisher-Price.com account.


Questions? Please contact Customer Service at 1-800-747-8697.
US postal mail address: Mattel Direct, Inc., Attn: Customer Service, PO Box 620978, Middleton, WI 53562-0978
Fisher-Price Privacy Statement | Legal Terms and Conditions
©2014 Mattel, Inc. All Rights Reserved
 
---------------------
 
As far as I know this email did not have anything to do with a breach, just an upgrading of their website security, but Chris, who sent this to the ISC, indicated that it "stank of Phishing".  I must admit that something about this email gave me the heebee jeebees  at first, but at second glance this is one of the better ways of getting users to change credentials.  There are no links in the email only a recommendation to use the websites "Forgot Password" link.
 
What emails have you received that at first glance you thought were phishing/Spam and at second glance you realized were legitimate?
 

-- Rick Wanner - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)

2 Comments

Published: 2014-10-10

Microsoft Security Bulletin Advance Notification for October 2014

Microsoft have announced the heads-up for this month security patches. With nine bulletins three are rated as critical, one as moderate and five as important.

https://technet.microsoft.com/library/security/ms14-oct

 

 

0 Comments

Published: 2014-10-09

CSAM: My servers started speaking IRC, and that is when I started to listen!

Hassan submitted this story:

While reviewing our IDS logs, we noticed an alert for IRC botnet traffic coming from multiple servers in a specific VLAN.

Ouch! One thing I keep saying in our IDS Class: If your servers all for sudden start joining IRC channels, then they are either very bored, or very compromised. But lets see how it went for Hassan. Hassan had what every analyst wants: pcaps! So he looked at the full packet capture of the traffic:

The traffic wasn't 100% IRC. But it looked suspect

Further analysis showed that the traffic originated from servers that were currently in the process of being moved between hosts via vMotion. The content of the memory / disk being transferred included IRC traffic like strings! Oops. We may not have active IRC traffic, but why are these strings present? Maybe malware lingering on the system? Hassan went all in and used volatility to examine the memory dump.

Using volatility we took a vaddump of the memory dump and searched the individual process dumps for the string pattern to identify the infected process. we found out that this part of the memory belongs to the AV process :). Apparently part of its signatures expanded in the memory during the scan.

Great work Hassan! This one was a good one and yes, anti-virus patterns will often contain "malicious strings" and can trigger an IDS if it spots these strings in transfer. The signatures as downloaded from the vendor are often encrypted, compressed or otherwise obfuscated, so your IDS usually doesn't recognize these patterns. But once loaded into memory on the host, the signatures are in the clear.

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

0 Comments

Published: 2014-10-08

CSAM Month of False Positives - Our ISP Says We're Hosting a BotNet!

It's a note that many of us have received.  If we're unlucky, it's a note that your (not-a-packet-expert) boss has received and we've had to explain it.  It usually goes like this:

We recently received 1 complaint(s) regarding the article below. This issue appears to have originated from your domain (IP address: x.x.x.x).
 
Please take the appropriate action with your customer or the account in question, enforcing your Acceptable Use Policy.
 
Regards,
 
Sincerely,

Bob the Administrator

Internet Abuse Team
Some ISP Communications
Email abuse@someisp.com


Please include your original email to SOMEISP.com in any replies.
 

We have traced activity to your connection that is likely caused by Botnet traffic. Botnets are programs that allow virus writes to take control of other computers. Please take all appropriate steps to eliminate this virus. The communication request may include attempted synchronization between the virus and the controller, spamming activities, network scanning, or spreading the virus to other connections.

Here is a general description of botnets: http://en.wikipedia.org/wiki/Botnet

We have included the name of the bot below where possible.

--Incident--
IP: x.x.x.x Port 41425
Timestamp: 2014-08-17 00:10:02 GMT
Infection: zeus-p2p

-


A note like this takes a fair amount of explanation when discussing it with your client (or manager), who usually isn't a packet guru.  Usually the narrative goes something like this:

While (maybe) it's a good thing that an ISP is looking at traffic to find malicious patterns, unfortunately, in this case the ISP just plain gets it wrong.  Their entire conclusion is based on the source port.  Unfortuntately, the source port in most TCP communications is what is called an "ephemeral" port - it's either the next free port available after 1024, or a random free port above 1024. 

Add to that, in outbound communications, most TCP sessions are run through a firewall that NAT each session ( NAT = Network Address Translation), so that each of these ephemeral ports is mapped to yet a different ephemeral port.

As you can see, from the outside network's perspective, the source port could be just about anything.  So if you are looking for a "suspicious" port, you'll find it as a source port on any corporate firewall most days.

OK, so should the abuse@ folks look at the port at the other end?  Umm- sort-of.  Say someone is sending you an email or browsing to your website - in this case, the ephemeral port is at their end, and the target port is at your end.

Really, what you want to do is look at the ports at both ends - but not to make a final determination.  You might use that method to narrow down your search, before you then look at the contents of the actual packets.  An even better approach is to *start* by looking at the contents of the packets - but if you're an ISP that adds up to a lot of packets which needs a corresponding amount of CPU and disk to deal with it.

If you are an organization who needs to get a handle on outbound traffic (which is just about every organization), consider implementing an IPS on the traffic to/from the inside interface of your firewall - at that location you can see the true IP addresses and ports of all traffic, both source and destination. 

Another great thing to look at implementing is a Netflow collector (or sFlow or jFlow or IPFIX, depending on your gear) - a tool like this helps you to slice and dice your network traffic statistics to get quick answers, or in many shops  netflow graphical display is the most used feature, allowing a quick, visual way to identify "odd" traffic or trends.

Also an egress filter goes a long way to containing problems - if you only allow permitted traffic and have a default deny policy for all "mystery" traffic, you'll find that your problems are more likely to stay contained within your network, and if you are looking at your logs you'll be alerted much earlier in the process.

What you'll find with proper monitoring like this (IPS, Netflow, egress filtering and log monitoring) is that very likely you *do* have infected machines here and there.  For instance we did the "log check" thing last week at a client site and found 1 station trying to infect the neighbors with shellshock.  The difference between your logs and the ISP's logs though is that your logs will properly identify the problem workstation, and the alerts in your logs will be a lot less likely to be a false positive.

The sad thing that I've found is that once you get a false positive note like this from an ISP, you're generally in for a few weeks of them before you can escalate to a support person who understands enough to know that they're getting it wrong, and has the clout to fix the ISP's process.

Please, use our comment form to let us know if you've gotten a note like this, and if it was a false positive or not. 

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

4 Comments

Published: 2014-10-07

CSAM: Scary ports and firewall remote administration

Have you ever done a "quick vulnerability" check only to discover that someone found that vulnerability before you did and already had the system compromised?

During the early stages of a vulnerability scan, nmap is your friend just to quickly confirm what you got. In this case, the big surprise was that the firewall responded on port 4444. Anybody who ever dabbled with pentesting may be familiar with this port: Metasploit uses port 4444 by default for its remote shell. Other then that, it is typically not used by any "well known service". 

At this point, with a possible compromised network firewall, there isn't much point in going much further. A quick connect with netcat oddly enough let to an HTTP error. Upon further investigation, it tuns out that Sophos firewalls use port 4444 for https remote administration. Typically, ports like 8000, 8080 or 8443 are used, but then again, maybe Sophos wanted to "hide" their port, or just be different.

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

1 Comments

Published: 2014-10-07

Belkin Router Apocalypse: heartbeat.belkin.com outage taking routers down

According ot various reports, many users of Belkin routers are having problems connecting to the internet as of last night. It appears that the router will occasionally ping heartbeat.belkin.com to detect network connectivity, but the "heartbeat" host is not reachable for some (all?) users. Currently, the host responds to ICMP echo requests, but apparently, many Belkin routers are still down.

As a workaround, you can add an entry to the routers host file pointing heartbeat.belkin.com to 127.0.0.1. This appears to remove the block. The "block" only affects the DNS server on the device. It will route just fine. You can still get hosts on your network to work as long as you set a DNS server manually, for example using Google's DNS server at 8.8.8.8. .

For a statement from Belkin, see https://belkininternationalinc.statuspage.io

In a tweet, Belkin also pointed to this page on its community forum: http://community.belkin.com/t5/Wireless/Belkin-Routers-Internet-Outage/m-p/5796#M1466

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

0 Comments

Published: 2014-10-07

Confusion over SSL and 1024 bit keys

Yesterday and today, a post on reddit.org caused quite a bit of uncertainty about the security of 1024 bit RSA keys if used with OpenSSL. The past referred to a presentation given at a cryptography conference, stating that 1024 Bit SSL keys can be factored with moderate resources (“20 minutes on a Laptop”). It was suggested that this is at least in part due to a bug in OpenSSL, which according to the post doesn't pick the random keys from the entire space available.

It looks more and more like the assertions made in the presentation are not true, or at least not as wide spread as claimed.

However, this doesn't mean you should go back to using 1024 bit keys. 1024 bit keys are considered weak, and it is estimated that 1024 keys will be broken easily in the near future due to advances in computer technology, even if no major weakness in the RSA algorithm or its implementation are found. NIST recommended phasing out 1024 bit keys at the end of last year.

So what should you do?

- Stop creating new 1024 bit RSA keys. Browsers will start to consider them invalid and many other software components already do so or will soon follow the browser's lead (I don't think any major CA will sign 1024 bit keys at this point)
- Inventory existing 1024 bit keys that you have, and consider replacing them.

There may be some holdouts. Embedded systems (again) sometimes can't create keys larger then 1024 bits. In this case, you may need to look into other controls.

With cryptograph in general, use the largest key size you can afford, for SSL, your options for RSA keys are typically 2048 and 4096 bits. If you can, got with 4096 bits.

[1] https://www.reddit.com/r/crypto/comments/2i9qke/openssl_bug_allows_rsa_1024_key_factorization_in/

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

3 Comments

Published: 2014-10-06

CSAM: Patch and get pw0ned (not OR).

"Patch as fast as you can" appears to be yet another common security practice leading to network doom. Bricked machines can't be hacked easily, so this may help a bit with "security". But then again, how insecure do you want your machines to be in order to support the latest and greatest patching tools.

Nice story from Lyalc:

"Some years ago, vulnerability scanning a production environment for the first time found about half of the critical production servers in this payment environment had the Windows File protection feature disabled via a registry key."

Ok. This would get me a bit scarred too. Windows File Protection (WFP) is a great feature to keep those Win2k and 2k3 systems a bit more secure, and make hacking them hard enough that some script kiddies may not bother. I like it, and wouldn't want it to be disabled all for sudden.

"Needless to say, incident response processes kicked in very quickly. ?During initial analysis, it was observed that the affected servers had ?patches applied to a critical payment component, several weeks prior to the vulnerability scanning. ?This software, from a global vendor of payment products, is used by a large portion of the payment industry, making it a natural target for malware and rootkit purveyors."

Ok. this would get me excited too (and excitement is never good in security. I like my security operations to be boring...). Payment systems, I think I heard of a couple cases where they got attacked. Yes, they appear to be patched. But what patch? How long were they vulnerable before the patch was applied? And well, defense in depth is for people who can't do incidents response as Lyalc?coninues:

...the site did not have FIM installed, nor had vulnerability scanning been undertaken previously. [FIM: Forefront Identity Manager]

So what happened? How can this possibly be a false positive?

Following this line of investigation identified that the patch package installer was disabling WFP, but neglecting to re-enable the feature, leaving the servers vulnerable to modifications of system files.

Ah! The patch system.?

Just a word about patches, in a week where we just got done with a good number of highly critical emergency patches for shellshock: Stop worrying about speed alone. You will lose. Think about shellshock and heartbleed: You can't possibly patch an enterprise fast enough. What you need instead is:

  • a well thought out patching process. How are we patching, how are we avoiding down systems, how do we make sure the patch got actually applied?
  • a comprehensive inventory. You can't secure (or patch) what you don't have
  • solid controls to detect attacks and exploited systems. You need network visibility to be able to detect attacks and more importantly, exploited systems.

?

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

0 Comments

Published: 2014-10-06

Shellshock: More details released about CVE-2014-6277 and CVE-2014-6278. Also: Does Windows have a shellshock problem?

Michal Zalewski did publish more details about the two vulnerability he discovered in the aftermath of Shellshock. He used a fuzzer to discover both vulnerabilities, and now published PoC exploits for both. [1]

To check if you are vulnerable, Michal points to this test string:

foo='() { echo not patched; }' bash -c foo

A quick test shows up-to date OS X, CentOS and Ubuntu as not vulnerable.

The first one, CVE-2014-6277, is a more "traditional" use of uninitialized memory. In most cases, this will just cause a crash. However, it can also be exploited to achieve arbitrary code execution. At its core, this is again due to how functions are parsed in environment variables, so this would be exploitable via HTTP requests.

The second one, CVE-2014-6278, is closer to the original shellshock bug. The PoC exploit posted by Michal is:

HTTP_COOKIE='() { _; } >_[$($())] {echo hi mom; id;}' bash -c :

Just like the first bug, the parser is confused as to where the function definition ends, and it executes the code in { }.

Late last week, a blog post about a similar flaw in Windows suggested to some that the Windows shell is vulnerable as well [2]. The vulnerability is however slightly different. It is not passed to other shells spawned from the original one. Also, in Windows, it is even less likely then in Unix to have cgi-bin scripts call a shell directly. The only realistic exploit vector in Windows remain environments like cygwin that install bash on Windows.

[1] http://lcamtuf.blogspot.com/2014/10/bash-bug-how-we-finally-cracked.html
[2] http://thesecurityfactory.be/command-injection-windows.html

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

1 Comments

Published: 2014-10-06

Spoofed packets with Window Size 6667: Anybody else seeing this?

Thanks to Tim for providing some packet captures. Anybody else seeing "weird" TCP packets? In particular we are interested if you see them OUTBOUND. We are looking for the likely broken tool that may generate these packets.

Some of the packet properties:

  • Packet size of 60 bytes (IP Headers + TCP)
  • Protocol is always TCP
  • various TOS values
  • various (random?) IP IDs. But repeating for same source IP
  • various TTLs (possible that packets from different IPs actually originate from different host)
  • DF flag is set
  • some source IPs are clearly "odd", e.g. multicast?source IPs like 255.127.0.0
  • TCP source and dest port is 0
  • Sequence numbers sometimes repeat even if source IPs change (argument for likely spoofed sources)
  • overall malformed TCP headers (e.g. header size < 20, various bad flag combinations).
  • Window size of 6667 (maybe this was supposed to be the source or dest. port?)
  • The packets arrive at relatively high rate (couple packets/sec with breaks... )

Quick tshark?output?of a sample with obfuscated target IP:

85.133.23.50 -> x.y.z.14 TCP 74 [TCP Retransmission] 0?0 [SYN, RST, ACK, URG, ECN, CWR, NS, Reserved] Seq=0 Ack=1 Win=6667 Urg=0 Len=0
85.133.23.50 -> x.y.z.14 TCP 74 [TCP Retransmission] 0?0 [SYN, RST, ACK, URG, ECN, CWR, NS, Reserved] Seq=0 Ack=1 Win=6667 Urg=0 Len=0
192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
192.99.37.41 -> x.y.z.119 TCP 74 [TCP Retransmission] 0?0 [FIN, SYN, RST, PSH, URG, CWR, NS, Reserved] Seq=0 Win=6667 Urg=0 Len=16
192.95.30.185 -> x.y.z.24 TCP 74 0?0 [FIN, PSH, ACK, URG, ECN, Reserved] Seq=1 Ack=1 Win=6667, bogus TCP header length (0, must be at least 20)
137.118.96.23 -> x.y.z.70 TCP 74 0?0 [FIN, SYN, RST, PSH, URG, ECN, CWR, NS, Reserved] Seq=0 Win=6667, bogus TCP header length (12, must be at least 20)

Internet Protocol Version 4, Src: 137.118.96.23 (137.118.96.23), Dst: x.y.z.70 (x.y.z.70)
Version: 4
Header Length: 20 bytes
Differentiated Services Field: 0x10 (DSCP 0x04: Unknown DSCP; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0001 00.. = Differentiated Services Codepoint: Unknown (0x04)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 60
Identification: 0xa2c7 (41671)
Flags: 0x02 (Don't Fragment)
0... .... = Reserved bit: Not set
.1.. .... = Don't fragment: Set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 49
Protocol: TCP (6)
Header checksum: 0x0cde [validation disabled]
[Good: False]
[Bad: False]
Source: 137.118.96.23 (137.118.96.23)
Destination: x.y.z.70
Transmission Control Protocol, Src Port: 0 (0), Dst Port: 0 (0), Seq: 0
Source Port: 0 (0)
Destination Port: 0 (0)
[Stream index: 872]
[TCP Segment Len: 28]
Sequence number: 0?(relative sequence number)
Header Length: 12 bytes (bogus, must be at least 20)

09:16:46.687528 IP 137.118.96.23.0 > x.y.z.70.0: tcp 28 [bad hdr length 12 - too short, < 20]
0x0000: 4510 003c a2c7 4000 3106 0cde 8976 6017 E..<..@.1....v`.
0x0010: xxyy zz46 0000 0000 c0f1 59ce 0000 0000 .3.F......Y.....
0x0020: 3bef 1a0b ff7f 0000 6cf6 2346 0000 0000 ;.......l.#F....
0x0030: 0000 0000 0000 0000 a002 7d78..........}x

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

10 Comments

Published: 2014-10-05

Detecting irregular programs and services installed in your network

When the corporate network becomes target, auditing for security policy compliance can be challenging if you don't have a software controlling irregular usage of administrator privilege granted and being used to install unauthorized software or to change configuration by installing services that could cause an interruption in network service. Examples of this possible issues are additional DHCP Servers (IPv4 and IPv6), Dropbox, Spotify or ARP scanning devices.

We can use nmap to detect all protocols that sends broadcast packets and are supported by packetdecoders.lua:

  • Ether
    • ARP requests (IPv4)
    • CDP - Cisco Discovery Protocol
    • EIGRP - Cisco Enhanced Interior Gateway Routing Protocol
    • OSPF - Open Shortest Path First
  • UDP
    • DHCP
    • Netbios
    • SSDP
    • HSRP
    • DropBox
    • Logitech SqueezeBox Discovery
    • Multicast DNS/Bonjour/ZeroConf
    • Spotify

The following example shows how to use nmap with the broadcast listener script and we can see the result of a device with dropbox installed, a device sending ARP request (a router in this case) and a device sending DHCPv6 requests:

nmap broadcast detection script

You can run this program periodically to track common security issues in your network, just in case your IPS could be missing something ;)

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

0 Comments

Published: 2014-10-04

Testing for opened ports with firewalk technique

There is an interesting way of knowing what kind of filters are placed in the gateway of a specific host. It is called firewalk and it is based on IP TTL expiration. The algorithm goes as follows:

  • The entire route is determined using any of the traceroute techniques available
  • A packet is sent with the TTL equal to the distance to the target
  • If the packet times out, it is resent with the TTL equal to the distance to the target minus one.
  • If an ICMP type 11 code 0 (Time-to-Live exceeded) is received, the packet was forwarded and so the port is not blocked.
  • If no response is received, the port is blocked on the gateway.

Let?s see this with a real example. Consider the following network diagram:

Firewalking happens with the following steps:

  1. Traceroute packets are sent to determine the gateway with decremental TTL:

....

2. An ICMP Time Exceeded message is received from the default gateway for the TTL=2 and TTL=1 packet, which means there are two gateways between origin and destination and TTL=3 is the distance to the destination

3. Several packets are sent with TTL=3 to the destination varying the destination port. The sequence goes as follows: A first packet is sent with TTL=3. If a timeout occurs, a second packet is sent with TTL=1. If an ICMP type 11 code 0 (Time-to-live exceeded) is received, the gateway is forwarding the packet.

Let?s see the first packet to port 1 and TTL=3:

Timeout occurs, so same packet is sent with TTL=2:

ICMP type 11 code 0 is sent from the gateway routing the destination host, which means the packet was forwarded and the port is opened:

How can we use this technique? Nmap has a firewalk script that can be used. For this example, the following command should be issued:

nmap --script=firewalk --traceroute 172.16.2.165

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

0 Comments

Published: 2014-10-03

CSAM: The Power of Virustotal to Turn Harmless Binaries Malicious

We all know that anti virus, the necessary evil of basic computer security, isn't a stranger to false positives. So no big surprise here when John is writing that he ran into such a false positive during an incident response:

I was scanning a forensic drive image with clamav and scored a positive hit on a file.

Great. ClamAV, a free anti-virus product. Of course, we don't trust it. So John did what most of use would have done, and submitted the suspect binary to Virustotal:

Virustotal showed 14 out of other 50 AV vendors' products thought it was malware as well.

Ouch! 14 out of 50? Many actual malware samples I submit get a lower rate then that. Turns out the binary in question was a desktop management software, "lunchwrapper.exe", and the AV tools picked up on it's file download component (the famous "generic downloader" signatures).

But you think this is bad? Listen what happened next according to John:

The scary part was that after I submitted the sample, other major AV vendors decided that the submitted sample was malicious and our endpoint software starting quarantining the program after the AV dats had updated.

After all, as my fellow developer can attest?too: The reason we allow people to use our applications is so that we don't have to do any testing ourselves.

(BTW: Virustotal/Google are doing great work, and I think it is a good thing that they are distributing samples. The problem is how AV vendors use this information.)

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

0 Comments

Published: 2014-10-02

Why is your Mac all for sudden using Bing as a search engine?

Even as a Mac user, you may have heard about Bing, at least you may have seen it demonstrated in commercials [1]. But if your default search engine on your Mac is all for sudden switched to Bing, this may be due to another piece of legacy software that some Mac users may have a hard time living without : Microsoft's Internet Explorer. So why not just search ("google") if there is a version for OSX:

Google Search for "mac internet explorer"

Sure enough, there is a FREE! Internet Explorer for Mac available. Lets download it, and see what happens. 

As it turns out, the page that you are going to download (the usual .dmg file) is signed by a valid Apple developer signature. It will install fine with Maverick's default "gate keeper" setting. Upon installation, it offers a couple additional free product. A "Shopping and Search Helper" as well as some software that will clean your Mac and make it run faster and safer.

In some ways, I have to say I admire how honest the search optimizer is in its EULA. The software will (the original uses all upper case for this section, like shown below):

.. RESET YOUR HOME PAGE AND/OR DEFAULT SEARCH FOR INTERNET EXPLORER, FIREFOX AND CHROME TO TROVI SEARCH...

... BLOCK AND NOTIFY YOU OF ATTEMPTS BY OTHER SOFTWARE TO CHANGE YOUR SELECTED HOME PAGE AND/OR DEFAULT SEARCH...

The Trovi privacy policy is similarly explicit, and not hiding must. The software will collect among other items [2]:

  • IP Address and device identifiers like UDID 
  • web pages you visit and the content you see, access and utilize... 
  • interactions on social networks
  • registration information you provide like name, address, e-mail, phone number, gender birthday

In the end, you end up with a bunch of adware, and , an actual legit version of Internet Explorer 5, which used to run on Mac OS, but doesn't really run on OS X Mavericks. 

For a full walk through see this YouTube video: https://www.youtube.com/watch?v=bVwyxaYJgKY

​

In short: I don't think this software does anything illegal. It clearly advertises what it does. If you feel otherwise, you can file a complaint with courts in Cyprus where the company is located.

[1] https://www.youtube.com/user/bing
​[2] http://info.trovi.com/Privacy

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

4 Comments

Published: 2014-10-02

CSAM: My Storage Array SSHs Outbound!

Kuddos to Matthew for paying attention to egress traffic. We keep emphasizing how important it is to make sure no systems talk "outbound" without permission. Just this last week, various Shellshock exploits did just that: Turn devices into IRC clients or downloading additional tools via HTTP, or just reporting success via a simple ping.

So no surprise that Matthew wrote us: "... the first time I saw the storage array SSH to the internet I about fainted. ..."

I would be surprised too! And turns out that isn't the only person that experienced this. Mark noted:

"Had the seem freak moment when I saw it happen.  The SAN happily communicating to an outside entity.  Though the company had been well and truly hosed."

Luckily, before going too far down the incident handling road, Matthew realized that this was a false positive. The storage array in question called "back home" to the vendor to report on its status. The purpose of this communication is to report failed disks or other critical events that may trigger a service call. Vendors will agree to turn off this feature, but then of course it is up to you to recognize faulty disks.

Got anything like that? Let us know. (if possible with log snippet / packet capture or other show-and-tells)

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

3 Comments

Published: 2014-10-02

Cyber Security Awareness Month 2014: Scary False Positives

To "celebrate" cyber security awareness month, we decided to focus on "scary false positives" during October. If you have any to share, please let us know. What we are looking for is preferably a lot entry, or another "indicator" that led you to believe that your system was compromised, but in the end turned out to be a false positive.

Please e-mail your stories to handlers-at-isc.sans.edu or use out Contact form.

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

0 Comments

Published: 2014-10-01

Xen Security Advisory - XSA 108 - http://xenbits.xen.org/xsa/advisory-108.html

Xen has issued an advisory and a related patch to address an issue that allows a "buggy or malicious HVM guest to crash the host or read data relating to other guests or the hypervisor itself."

Xen 4.1 and onward are vulnerable, only x86 systems are vulnerable. ARM systems are not vulnerable.

Applying the patch resolves this issue.

2 Comments

Published: 2014-10-01

Security Onion news: Updated ShellShock detection scripts for Bro

Per Security Onion's Doug Burks, Seth Hall has developed some comprehensive ShellShock detection scripts for Bro.
These scripts "detect successful exploitation of the Bash vulnerability with CVE-2014-6271 nicknamed "ShellShock" and are more comprehensive than most detections in that they're watching for behavior from the attacked host that might indicate successful compromise or actual vulnerability."
Seth has updated these scripts again today to "Add shellscripts as a post-exploit detection mechanism."
Doug has updated the securityonion-bro-scripts package to include these changes and has also updated the securityonion-web-page package to include some ELSA queries for "ShellShock Exploits" and "ShellShock Scanners".

This is great for current Security Onion users, and even better for readers who have not yet investigated and invested in Security Onion. Now's the time to become familiar and improve your situational awareness, particularly given the fact that it's National Cyber Security Awareness Month. :-)

Everything you need is available on Doug's blog: http://blog.securityonion.net/2014/10/new-securityonion-bro-scripts-and.html

0 Comments