Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2014-02-28 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Fiesta!

Published: 2014-02-28
Last Updated: 2014-02-28 17:10:58 UTC
by Daniel Wesemann (Version: 1)
2 comment(s)

No, we haven't broken out the beer or decided to start the weekend early. This ISC diary isn't about party time, but rather about the "Fiesta Exploit Kit". We are recently seeing an uptick of it being used on compromised web sites.

Fiesta has been around in one form or another since 2012, when it branched off the "NeoSploit" kit, and is regularly being retrofitted with new exploits to stay effective. The first stage is usually just a redirect, to the actual exploit site from where a heavily encoded/obfuscated JavaScript file gets downloaded. This JavaScript file checks the locally installed software, and then triggers or downloads the matching exploit(s).

The currently most prevalent version of Fiesta seems to use the same five exploits / vulnerabilities since about November last year:

  • CVE-2010-0188 Adobe Reader TIFF vulnerability. The code checks for Adobe Reader versions >= 800 < 821 and >= 900 < 931, and only triggers if a matching (ancient) Adobe version is installed.
  • CVE-2013-0074 Microsoft Silverlight (MS13-022, March 2013). The code checks for Silverlight versions >= 4050401 and < 5120125, and triggers the exploit if applicable. Silverlight 5.1.201.25.0 is the version after patch MS13-022 has been applied
  • CVE-2013-2465 Oracle Java. Of course - there had to be a Java sploit in the mix. The code checks for Java > 630 < 722
  • CVE-2013-0634 Adobe Flash Player. The code checks for Flash Player >= 110000 <= 115502.
  • CVE-2013-2551 Microsoft Internet Explorer (MS13-037, May 2013). The code in this case just checks for IE Versions 6 to 10, and if found, tries the exploit.

A system with reasonably up to date patches should have nothing to fear from the above. The fact that Fiesta has not widely re-tooled to newer exploits suggests though that the above set of vulnerabilities are still netting the bad guys plenty of newly exploited bots.

The existing Snort EmergingThreat signatures for Fiesta are doing a reasonable job at spotting the attack. As for the Snort standard (VRT) ruleset, rule SID 29443 seems to work well right now, it was added in January to match on the URL format: "/^\/[a-z0-9]+\/\?[0-9a-f]{60,66}[\x3b\x2c\d]*$/U" used, and is still triggering frequently on the current Fiesta wave.

One further characteristic of the current Fiesta is also its heavy use of dynamic DNS. Seen this week so far were *.no-ip.info, *.no-ip.org, *.myvnc.com, *.no-ip.biz, *.myftp.com, *.hopto.org and *.serveblog.net. These are DynDNS providers, so obviously not all sites hosted there are malicious. But Fiesta is making extensive use of these services to rapidly shuffle its exploit delivery hosts. The host names used are random character sequences of 10 or 6 chars, current example "ofuuttfmhz.hopto.org". The corresponding sites are sometimes active for less than a hour before the DNS name used in the sploits changes again.

What seems to be reasonably static are the IP addresses - 209.239.113.39 and 64.202.116.124 have both been used for the past two weeks, and the latter hoster seems to be particularly "popular", because the adjacent addresses (64.202.116.122, 64.202.116.125) were in use by Fiesta in late January. Also quite common are landing pages hosted on *.in.ua (Ukraine) domains, like ujimmy.in.ua, aloduq.in.ua, etc. These domains should be infrequent enough in (western) web proxy logs to make them easier to spot.

If you have any other current Fiesta intel (not involving cerveza :), let us know via the contact page or comments below!

 

Keywords: exploit kit malware
2 comment(s)

Oversharing

Published: 2014-02-28
Last Updated: 2014-02-28 16:46:16 UTC
by Daniel Wesemann (Version: 3)
3 comment(s)

When ISC reader Michael contacted us about "odd UDP traffic from all over" that he was suddenly seeing in his firewall log, we at first assumed that his Internet connection had "inherited" a dynamic IP address that had before been used by a rampant file sharing user, and that Michael was now seeing the "after glow".

We still asked for a PCAP (tcpdump) file though, and when we looked at what Michael sent back, we saw to our surprise ...

... that Michael's network was responding to the traffic. Hmm. Oops!

Closer inquiry then revealed that they had recently updated the firmware on their QNAP TS-659 NAS (network storage) server .. and this new version came with the ability to act as a media and streaming server. It isn't quite clear if the corresponding functionality had been "on" by default, or had been turned on by accident. But once turned off, the "odd UDP traffic" stopped right away.

Lesson learned - after an upgrade, check if things are still how you expect them to be. While most vendors have thankfully learned to keep new "features" turned off by default, you can't quite rely on it. For home use, investing in a small network tap or hub, and every now and then checking the traffic leaving your house is (a) a good security precaution and (b) helps to keep your Wireshark Packet-Fu skills current :)

And while we are on the topic of NAS and storage servers: A CERT vulnerability note released today states that some versions of Synology DiskStation contain a hard-coded password which can be used by remote attackers to establish a VPN into the DiskStation. I wish vendors - prominently including Cisco - would get their bleeping act together, and, after years of "security advisories" on the subject, eventually stop shipping products with hard coded credentials/backdoors!  Details on the Synology mess here: http://www.kb.cert.org/vuls/id/534284

 

3 comment(s)
Diary Archives