Monthly Archives: October 2013

Episode #171: Flexibly Finding Firewall Phrases

Old Tim answers an old email

Patrick Hoerter writes in:
I have a large firewall configuration file that I am working with. It comes from that vendor that likes to prepend each product they sell with the same "well defended" name. Each configuration item inside it is multiple lines starting with "edit" and ending with "next". I'm trying to extract only the configuration items that are in some way tied to a specific port, in this case "port10".

Sample Data:

edit "port10"
set vdom "root"
set ip 192.168.1.54 255.255.255.248
set allowaccess ping
set type physical
set sample-rate 400
set description "Other Firewall"
set alias "fw-outside"
set sflow-sampler enable
next
edit "192.168.0.0"
set subnet 192.168.0.0 255.255.0.0
next
edit "10.0.0.0"
set subnet 10.0.0.0 255.0.0.0
next
edit "172.16.0.0"
set subnet 172.16.0.0 255.240.0.0
next
edit "vpn-CandC-1"
set associated-interface "port10"
set subnet 10.254.153.0 255.255.255.0
next
edit "vpn-CandC-2"
set associated-interface "port10"
set subnet 10.254.154.0 255.255.255.0
next
edit "vpn-CandC-3"
set associated-interface "port10"
set subnet 10.254.155.0 255.255.255.0
next
edit 92
set srcintf "port10"
set dstintf "port1"
set srcaddr "vpn-CandC-1" "vpn-CandC-2" "vpn-CandC-3"
set dstaddr "all"
set action accept
set schedule "always"
set service "ANY"
set logtraffic enable
next

Sample Results:

edit "port10"
set vdom "root"
set ip 192.168.1.54 255.255.255.248
set allowaccess ping
set type physical
set sample-rate 400
set description "Other Firewall"
set alias "fw-outside"
set sflow-sampler enable
next
edit "vpn-CandC-1"
set associated-interface "port10"
set subnet 10.254.153.0 255.255.255.0
next
edit "vpn-CandC-2"
set associated-interface "port10"
set subnet 10.254.154.0 255.255.255.0
next
edit "vpn-CandC-3"
set associated-interface "port10"
set subnet 10.254.155.0 255.255.255.0
next
edit 92
set srcintf "port10"
set dstintf "port1"
set srcaddr "vpn-CandC-1" "vpn-CandC-2" "vpn-CandC-3"
set dstaddr "all"
set action accept
set schedule "always"
set service "ANY"
set logtraffic enable
next

Patrick gave us the full text and the expected output. In short, he wants the text between "edit" and "next" if it contains the text "port10". To begin this task we need to first need get each of the edit/next chunks.

PS C:\> ((cat fw.txt) -join "`n") | select-string "(?s)edit.*?next" -AllMatches | 
select -ExpandProperty matches

This command will read the entire file fw.txt and combine it into one string. Normally, each line is treated as a separate object, but we are going to join them into a big string using the newline (`n) to join each line. Now that the text is one big string we can use Select-String with a regular expression to find all the matches. The regular expression will find text across line breaks and allows for very flexible searches so we can find our edit/next chunks. Here is a break down of the pieces of the regular expression:

  • (?s) - Use single line mode where the dot (.) will match any character, including a newline character. This allows us to match text across multiple lines.
  • edit - the literal text "edit"
  • .*? - find any text, but be lazy, not greedy. This means it should match the smallest chunks that will match the criteria.
  • next - literal text next

Now that we have the chunks we use a Where-Object filter (alias ?) to find matching objects to pass down the pipeline.

PS C:\> ((cat .\fw.txt) -join "`n") | select-string "(?s)edit.*?next" -AllMatches | 
select -ExpandProperty matches | ? { $_.Captures | Select-String "port10" }

Inside the Where-Object filter we can check the Value property to see if it contains the text "port10". The Value property is piped into Select-String to look for the text "port10", and if it contains "port10" it continues down the pipeline, if not, it is dropped.

At this point, we have the objects we want, so all we need to do is display the results by expanding the Value and displaying it again. The expansion means that it just displays the text and no data or metadata associated with the parent object. Here is what the final command looks like.

PS C:\> ((cat .\fw.txt) -join "`n") | select-string "(?s)edit.*?next" -AllMatches | 
select -ExpandProperty matches | ? { $_.Value | Select-String "port10" } |
select -ExpandProperty Value

Not so bad, but I have a feeling it is going to be worse for my friend Hal.

Old Hal uses some old tricks

Oh sure, I know what Tim's thinking here. "It's multi-line matching, and the Unix shell is lousy at that. Hal's in trouble now. Mwhahaha. The Command-Line Kung Fu title will finally be mine! Mine! Do you hear me?!? MINE!"

Uh-huh. Well how about this, old friend:

awk -v RS=next -v ORS=next '/port10/' fw.txt

While we're doing multi-line matching here, the blocks of text have nice regular delimiters. That means I can change the awk "record separator" ("RS") from newline to the string "next" and gobble up entire chunks at a time.

After that, it's smooth sailing. I just use awk's pattern-matching operator to match the "port10" strings. Since I don't have an action defined, "{print}" is assumed and we output the matching blocks of text.

The only tricky part is that I have to remember to change the "output record separator" ("ORS") to be "next". Otherwise, awk will use its default ORS value, which is newline. That would give me output like:


$ awk -v RS=next '/port10/' fw.txt
edit "port10"
set vdom "root"
set ip 192.168.1.54 255.255.255.248
set allowaccess ping
set type physical
set sample-rate 400
set description "Other Firewall"
set alias "fw-outside"
set sflow-sampler enable


edit "vpn-CandC-1"
set associated-interface "port10"
set subnet 10.254.153.0 255.255.255.0


edit "vpn-CandC-2"
set associated-interface "port10"
...

The "next" terminators get left out and we get extra lines in the output. But when ORS is set properly, we get exactly what we were after:


$ awk -v RS=next -v ORS=next '/port10/' fw.txt
edit "port10"
set vdom "root"
set ip 192.168.1.54 255.255.255.248
set allowaccess ping
set type physical
set sample-rate 400
set description "Other Firewall"
set alias "fw-outside"
set sflow-sampler enable
next
edit "vpn-CandC-1"
set associated-interface "port10"
set subnet 10.254.153.0 255.255.255.0
next
edit "vpn-CandC-2"
set associated-interface "port10"
...

So that wasn't bad at all. Sorry about that Tim. Maybe next time, old buddy.

Ad Vulna: A Vulnaggressive (Vulnerable & Aggressive) Adware Threatening Millions

FireEye researchers have discovered a rapidly-growing class of mobile threats represented by a popular ad library affecting apps with over 200 million downloads in total. This ad library, anonymized as "Vulna," is aggressive at collecting sensitive data and is able to perform dangerous operations such as downloading and running new components on demand. Vulna is also plagued with various classes of vulnerabilities that enable attackers to turn Vulna's aggressive behaviors against users. We coined the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics. Most vulnaggresive libraries are proprietary and it is hard for app developers to know their underlying security issues. Legitimate apps using vulnaggressive libraries present serious threats for enterprise customers. FireEye has informed both Google and the vendor of Vulna about the security issues and they are actively addressing it.

Recently FireEye discovered a new mobile threat from a popular ad library that no other anti-virus or security vendor has reported publicly before. Mobile ad libraries are third-party software included by host apps in order to display ads. Because this library’s functionality and vulnerabilities can be used to conduct large-scale attacks on millions of users, we refer to it anonymously by the code name “Vulna” rather than revealing its identity in this blog.

We have analyzed all Android apps with over one million downloads on Google Play, and we found that over 1.8% of these apps used Vulna. These affected apps have been downloaded more than 200 million times in total.

Though it is widely known that ad libraries present privacy risks such as collecting device identifiers (IMEI, IMSI, etc.) and location information, Vulna presents far more severe security issues. First, Vulna is aggressive—if instructed by its server, it will collect sensitive information such as text messages, phone call history, and contacts. It also performs dangerous operations such as executing dynamically downloaded code. Second, Vulna contains a number of diverse vulnerabilities. These vulnerabilities when exploited allow an attacker to utilize Vulna’s risky and aggressive functionality to conduct malicious activity, such as turning on the camera and taking pictures without user’s knowledge, stealing two-­factor authentication tokens sent via SMS, or turning the device into part of a botnet.

We coin the term “vulnaggressive” to describe this class of vulnerable and aggressive characteristics.

The following is a sample of the aggressive behaviors and vulnerabilities we have discovered in Vulna:

  • Aggressive Behaviors

    • In addition to collecting information used for targeting and tracking such as device identifiers and location, as many ad libraries do, Vulna also collects the device owner's email address and the list of apps installed on the device. Furthermore, Vulna has the ability to read text messages, phone call history, and contact list, and share this data publicly without any access control through a web service that it starts on the device.

    • Vulna will download arbitrary code and execute it when instructed by the remote server.

  • Vulnerabilities

    • Vulna transfers user’s private information over HTTP in plain text, which is vulnerable to eavesdropping attacks.

    • Vulna also uses unsecured HTTP for receiving commands and dynamically loaded code from its control server. An attacker can convert Vulna to a botnet by hijacking its HTTP traffic and serving malicious commands and code.

    • Vulna uses Android’s WebView with JavaScript-­to-­Java bindings in an insecure way. An attacker can exploit this vulnerability and serve malicious JavaScript code to perform harmful operations on the device. This vulnerability is an instance of a common JavaScript binding vulnerability which has been estimated to affect over 90% of Android devices.

      Vulna’s aggressive behaviors and vulnerabilities expose Android users, especially enterprise users, to serious security threats. By exploiting Vulna’s vulnaggressive behaviors, an attacker could download and execute arbitrary code on user’s device within Vulna's host app. From our study, many host apps containing Vulna have powerful permissions that allow controlling the camera; reading and/or writing SMS messages, phone call history, contacts, browser history and bookmarks; and creating icons on home screen. An attacker could utilize these broad permissions to perform malicious actions. For example, attackers could:

      • steal two-factor authentication token sent via SMS
      • view photos and other files on the SD card
      • install icons used for phishing attacks on the home screen
      • delete files and destroy data on demand
      • impersonate the owner and send forged text messages to business partners
      • delete incoming text messages without the user’s notice
      • place phone calls
      • use the camera to take photos without user’s notice
      • read bookmarks or change them to point to phishing sites

      There are many possible ways an attacker could exploit Vulna’s vulnerabilities. One example is public WiFi hijacking: when the victim’s device connects to a public WiFi hotspot (such as at a coffee shop or an airport), an attacker nearby could eavesdrop on Vulna’s traffic and inject malicious commands and code.

      Attackers can also conduct DNS hijacking to attack users around the world, as in the Syrian Electronic Army’s recent attacks targeting Twitter, the New York Times, and Huffington Post. In a DNS hijacking attack, an attacker could modify the DNS records of Vulna’s ad servers to redirect visitors to their own control server, in order to gather information from or send malicious commands to Vulna on the victim’s device.

      Despite the severe threats it poses, Vulna is stealthy and hard to detect:

      • Vulna receives commands from its ad server using data encoded in HTTP header fields instead of the HTTP response body.

      • Vulna obfuscates its code, which makes traditional analysis difficult.

      • Vulna's behaviors can be difficult to trigger using traditional analysis. For example, in one popular game, Vulna is executed only at certain points in the game, such as when a specific level is reached, as shown in the figure below. (The figure has been partially blurred to hide the identity of the app.) When Vulna is executed, the only effect visible to the user is the ad on top of the screen. However, Vulna quietly executes its risky behaviors in the background.

        Vulna's screen shot

      FireEye Mobile Threat Prevention applies a unique approach and technology that made it possible to discover the security issues outlined in this post quickly and accurately despite these challenges. We have provided information about the discovered security issues,  the list of impacted apps and suggestions to both Google and the vendor of Vulna. They have confirmed the issues and they are actively addressing it.

      In conclusion, we have discovered a new mobile threat from a popular ad library (codenamed "Vulna" for anonymity). This library is included in popular apps on Google Play which have more than 200 million downloads in total. Vulna is an instance of a rapidly­-growing class of mobile threat, which we have termed vulnaggressive ad libraries. Vulnaggressive ad libraries are disturbingly aggressive at collecting users’ sensitive data and embedding capabilities to execute dangerous operations on demand, and they also contain different classes of vulnerabilities which allow attackers to utilize their aggressive behaviors to harm users. App developers using these third-party libraries are often not aware of the security issues in them. These threats are particularly serious for enterprise customers. Furthermore, this vulnaggressive characteristic is not just limited to ad libraries; it also applies to other third-party components and apps.

      Acknowledgement

      Special thanks to FireEye team members Adrian Mettler, Peter Gilbert, Prashanth Mohan, and Andrew Osheroff for their valuable help on writing this blog. We also thank Zheng Bu and Raymond Wei for their valuable comments and feedback.

      Appendix: Sample code snippet of collecting and sending call logs in Vulna

       

      class x implements Runnable

       

      {

      run(){

      List localList = get_call_log();

      construct_JSON_and_send_to_remote(localList);

      }

      }

      List get_call_log()

      {

      ArrayList localArrayList = new ArrayList();

      Cursor cur1 = getContentResolver().query(CallLog.Calls.CONTENT_URI,

      new String[] { "number", "type", "date" }, null, null,

      "date DESC limit 10");

      cur2 = cur1;

      if (cur2 != null){

      int i = cur2.getColumnIndex("number");

      int j = cur2.getColumnIndex("type");

      while (cur2.moveToNext()){

      String str = cur2.getString(i);

      if ((cur2.getInt(j)==2) && (!localArrayList.contains(str)))

      localArrayList.add(str);

      }

      }

      return localArrayList;

      }