Site Network:

Feed aggregator

Delivering an executable without an executable

vrt rules - Thu, 09/26/2013 - 15:04
The VRT looks at a massive amount of exploit kits a day, but this one caught our eye so we thought we'd share.  While this technique isn't new, it is very interesting and further illustrates what we all believe to be true in the security world, you can't trust anything.

With any exploit kit, the end goal is to drop malware on the victim host but unlike the majority of exploit kits we see, this one does it in a unique manner.  Instead of exploiting the victim through Java, Adobe Reader, or the browser, and using that foothold to fetch and run and executable; this attacker uses VBScript to write the executable to disk.  The end result is an executable on the victim machine without using an exploit to download the executable.

The link is still active at this time and is still serving malware.
VirusTotal results


Let's take a look at the VBScript.  First it declares the variable "DropFileName" with the string "svchost.exe". That's a nice descriptive variable name and it's not obfuscated. The next variable is "WriteData" and is a relatively large string.

Take a look at those first four characters: "4D5A" (in hex) or "MZ" (in ascii), the first two characters of an everyday Portable Executable or PE file.  Finally, another string is assembled called "DropPath". It uses the GetSpecialFolder method with a folderspec argument of 2, this holds the value of the "TMP" environment variable.  The file is created with CreateTextFile with the overwrite argument set to true.  The "WriteData" is then written out in hex and executed without an actual executable being downloaded or an exploit being used.

I tested this on Windows XP with IE 8 and Windows 7 IE 9. The user is presented with a warning on both systems. The name and publisher information presented in the warning shows that the add-on that was blocked is from Microsoft.  Any unsuspecting user may just click "Allow" on these.

The XP IE 8 and Win7 IE 9 warnings:

The malware itself is detected as Win.Trojan.Ircnite-27 with ClamAV and additional rules will be released to cover this method of executable delivery in the form of SIDs 28053 and 28054.

We are always interested in hearing about new and interesting methods used by attackers, so feel free to drop us a line if you'd like to share what you are seeing at:

Inquiring Minds: Exploratory road trips, malware, and cool tools and services

vrt rules - Wed, 09/18/2013 - 16:48
While browsing interesting sandbox reports, we here in the VRT uncovered a sample that dropped three files.  VirusTotal had no record of two of them, and the third was a DLL that was well covered.

The original sample from the report was MD5 7f431295bd212b9ec45241457bee58c9, which dropped these files:
  • MD5 216a5052900d40fee35763088bdfc88f    : C:\Windows\Tasks\wopqhhb.job
  • MD5 58a6e4f3375907295bb1070e9dac839c  : C:\Documents and Settings\All Users\Application Data\Mozilla\gtbcolk.exe
  • MD5 1f3a4ac5aafe5b4db0b72d1026615827  : C:\Documents and Settings\All Users\Application Data\Mozilla\vzsleki.dll
I had been wanting to test out some tools and ideas/approaches for investigating malware, so I packed up for a trip down exploratory lane.  The first two stops on the trip:
  1. Original sample from the report: 7f431295bd212b9ec45241457bee58c9
  2. The executable it dropped: 58a6e4f3375907295bb1070e9dac839c

I've got to PE

First, I compared the PE sections (using pedump) from both the original and the dropped PE executables and noticed they were the same:

  $ pedump --sections 7f431295bd212b9ec45241457bee58c9.exe

   === SECTIONS ===

    .text        1000     1110     1200      400     0        0     0        0  60300020  R-X CODE
    .data        3000    1e7f6    1ea00     1600     0        0     0        0  c0300040  RW- IDATA
    .bss        22000        c        0        0     0        0     0        0  c0300080  RW- UDATA
    .edata      23000       36      200    20000     0        0     0        0  40300040  R-- IDATA
    .idata      24000      48c      600    20200     0        0     0        0  c0300040  RW- IDATA

   $ pedump --sections 58a6e4f3375907295bb1070e9dac839c.exe

   === SECTIONS ===

    .text        1000     1110     1200      400     0        0     0        0  60300020  R-X CODE
    .data        3000    1e7f6    1ea00     1600     0        0     0        0  c0300040  RW- IDATA
    .bss        22000        c        0        0     0        0     0        0  c0300080  RW- UDATA
    .edata      23000       36      200    20000     0        0     0        0  40300040  R-- IDATA
    .idata      24000      48c      600    20200     0        0     0        0  c0300040  RW- IDATA

On a whim, I decided to compare the SHA1 sum of a full run of pedump on each sample.  This output includes:

  • MZ Header
  • PE Header

As you can see, the output from these two different samples were exactly the same:
$ pedump 7f431295bd212b9ec45241457bee58c9.exe | shasum
7d32da086a656917ab923604e7f4724fe131359d  -$ pedump 58a6e4f3375907295bb1070e9dac839c.exe | shasum
7d32da086a656917ab923604e7f4724fe131359d  -
From there I decided to look at the exports:

  $ pedump -E 7f431295bd212b9ec45241457bee58c9.exe 58a6e4f3375907295bb1070e9dac839c.exe
  # -----------------------------------------------
  # 7f431295bd212b9ec45241457bee58c9.exe
  # -----------------------------------------------

  === EXPORTS ===

  # module "kgufcbuni.exe"
  # flags=0x0  ts="2013-05-19 21:19:52"  version=0.0  ord_base=1
  # nFuncs=0  nNames=0

  # -----------------------------------------------
  # 58a6e4f3375907295bb1070e9dac839c.exe
  # -----------------------------------------------

  === EXPORTS ===

  # module "kgufcbuni.exe"
  # flags=0x0  ts="2013-05-19 21:19:52"  version=0.0  ord_base=1
  # nFuncs=0  nNames=0

Now this got me wondering how similar the original sample and the dropped EXE were, so I fired up vbindiff to take a look:

It seemed the only difference was the dropped EXE had an extra 8 bytes at the end of the file.  So, to confirm this, I copied the first 235,376 (0x039770) bytes of the file and checked the MD5.

Sure enough, stripping off the last 8 bytes resulted in the MD5 of the dropped sample (58a6e4f3375907295bb1070e9dac839c) and the original sample (7f431295bd212b9ec45241457bee58c9) to match up:
$ dd if=58a6e4f3375907295bb1070e9dac839c.exe bs=1 count=0x039770 2> /dev/null | md5
We have a winner?  No, but I'm searching for dinner.

Now I'm interested, in a cat-with-a-laser-pointer kind of way, but I need more samples.  This was a perfect opportunity to try out some VirusTotal Intelligence searches to find some more samples to play with.

I decided to try two different approaches:
  1. PE section searching
  2. "Similar to" searching
PE section searchFor the PE section searching, I got all of the PE section MD5s for the original sample and attempted a search for samples that had these same sections:

(sectionmd5:4f5944620a6fff416596982b2e6dec23 sectionmd5:d1c09bc7d834711d74aaf05770ba22cb sectionmd5:d41d8cd98f00b204e9800998ecf8427e sectionmd5:963a67c9ee55335c1fe3ee1322167430 sectionmd5:a1bbc87f2207a3aff4a78e65d64981b5) type:peexe 

As I held my breath, I tested the first sample returned, d5ccc595265f7706824b33c4729f3a9e.
$ pedump -E d5ccc595265f7706824b33c4729f3a9e === EXPORTS === # module "kgufcbuni.exe"
# flags=0x0 ts="2013-05-19 21:19:52" version=0.0 ord_base=1
# nFuncs=0 nNames=0

IT'S A BINGO!  Sweet, we had an obvious match, so I downloaded the first 300 samples the PE section search gave me.
"Similar to" searchBecause my two samples had no entries on VirusTotal, I used the first sample uncovered with the PE section search as the basis for my similar-to search:
similar-to:d5ccc595265f7706824b33c4729f3a9eI grabbed the second sample (8e9fe8499a2d7acaf1124ed20b101aee) because the first sample was the sample I used for my search.  So, I was confident that the similar-to search feature was good enough to search for itself, but I wasn't actually holding my breath on this one.

So, without expecting too much, I checked the exports of the selected sample:
$ pedump -E 8e9fe8499a2d7acaf1124ed20b101aee === EXPORTS === # module "kgufcbuni.exe"
# flags=0x0 ts="2013-05-19 21:19:52" version=0.0 ord_base=1
# nFuncs=0 nNames=0

Two bingos in one day?  I'm putting on a wig and going to a blue hair convention bingo tournament.  After that, I downloaded the first 300 samples the search results gave me.

Merge all the things!

Each of the two VirusTotal intelligence searches left me with 300 samples each; that's 601 total samples.  I then merged all of those samples into a directory so any overlapping samples would be removed.

The merge then left me with 491 unique samples, all with different SHA256 checksums.  These are the poor samples that were the unwilling patients that I poked, prodded, and probed.

Probe all the things?!

First I was curious what the pedump output for all of the samples looked like.  Were they all the same?  Were they all different?  Was the price of tea in China impacted?  Inquiring minds want to know.
$ for sample in *; do pedump $sample | shasum; done | sort | uniq -c | sort -n
  12  8f153c3902471bfc4935d49064b371bfcbb6d79a -
479 7d32da086a656917ab923604e7f4724fe131359d -

It's a landslide victory!  7d32da086a656917ab923604e7f4724fe131359d has it by 467 votes!  I wondered about the exports, so that was next:
$ for sample in *; do pedump -E $sample | grep module; done | sort | uniq -c | sort -n
 491 # module "kgufcbuni.exe"

Let's go deep, ssdeep.

Even though we were working with 491 unique samples, there have been a lot of similarities (or exact matches).  This got me wondering about how useful ssdeep might be in this particular situation.

So, I used ssdeep on the original sample and the exe it dropped.  The ssdeep hashes seem to be identical for a single byte:

  $ ssdeep -b 7f431295bd212b9ec45241457bee58c9.exe | tee 7f431295bd212b9ec45241457bee58c9.ssd

  $ ssdeep -b 58a6e4f3375907295bb1070e9dac839c.exe | tee 58a6e4f3375907295bb1070e9dac839c.ssd

Then I ran the ssdeep hashes against all 491 samples.  This resulted in a 488/491 detection:

  $ ssdeep -m 7f431295bd212b9ec45241457bee58c9.ssd -br intelligencefiles/merged/ | wc -l

  $ ssdeep -m 58a6e4f3375907295bb1070e9dac839c.ssd -br intelligencefiles/merged/ | wc -l

If I added the -a option (shows all matches even if the score is 0), and all 491 were matched:

  $ ssdeep -a -m 7f431295bd212b9ec45241457bee58c9.ssd -br intelligencefiles/merged/ | wc -l
  $ ssdeep -a -m 58a6e4f3375907295bb1070e9dac839c.ssd -br intelligencefiles/merged/ | wc -l

A dream within a dream?  We need to go deeper Yara.I wondered, what else I could do with these 491 samples?  I landed on extracting binary patterns from the samples and trying to do something cool with them using Yara.

Thankfully, all of the heavy lifting had already been done for me, so I went to work and copied 28 semi-randomly selected samples to a directory called yara-autosig-samples/.

Using the autorule Python script, I generated the Yara signature from the 28 samples:

  $ python autorule/ yara-autosig-samples/ > yara-autosig.yar
  CFileDiffer: Diffing a total of 30 file(s)
  CFileDiffer: Diffing file 1 out of 30
  CFileDiffer: Diffing file 2 out of 30
  CFileDiffer: Diffing file 29 out of 30
  CFileDiffer: Diffing file 30 out of 30

Lo and behold, Yara detected all 491 samples:

  $ yara -r yara-autosig.yar intelligencefiles/merged > yara-autosig.log

  $ wc -l yara-autosig.log
  491 yara-autosig.log

  $ head -1 yara-autosig.log
  test   intelligencefiles/merged/0034d872dca89c5b05b4eb4cca532a470473fbd793ab52fb745e4d69a5577516

  $ tail -1 yara-autosig.log
  test intelligencefiles/merged/fcedaf314f26112aaba5e255cfa8235209521a77cb570e02ed4b16c37c137775

Back to the future?

So, after all of that I decided to look at the exports again and see if the location of "kgufcbuni.exe" was static:

  $ grep -aob kgufcbuni.exe intelligencefiles/merged/* | cut -f2- -d: | uniq -c | sort -n
   491 131112:kgufcbuni.exe

These samples all seem to drop the same DLL (1f3a4ac5aafe5b4db0b72d1026615827), so I decided to look at the exports for the offset of "ckdhgsuwa.dll":

  $ grep -aob ckdhgsuwa.dll 1f3a4ac5aafe5b4db0b72d1026615827.dll

Now that I was armed with these offsets, I decided to test my theory with a simple ClamAV LDB signature:

  $ cat local.ldb

Which decoded looks like this:

  $ cat local.ldb | sigtool --decode
  VIRUS NAME: Win.Trojan.Kryptik
  TDB: Engine:51-255,Target:1
   * SUBSIG ID 0
   +-> OFFSET: 17458
   * SUBSIG ID 1
   +-> OFFSET: 131112

For those of you who haven't gouged your eyeballs out, or taken up underwater basket weaving, here are the results of our LDB signature scan:

  $ clamscan -rid local.ldb 7f431295bd212b9ec45241457bee58c9   58a6e4f3375907295bb1070e9dac839c 1f3a4ac5aafe5b4db0b72d1026615827 intelligencefiles/merged/ | tail -10

  ----------- SCAN SUMMARY -----------
  Known viruses: 1
  Engine version: 0.97.8
  Scanned directories: 1
  Scanned files: 494
  Infected files: 494
  Data scanned: 97.44 MB
  Data read: 97.43 MB (ratio 1.00:1)
  Time: 2.549 sec (0 m 2 s)

So, there you have it.  A little bit of exploration and tinkering and who knows what you might uncover?

Bytecode - Covering the Android Vulnerabilities Master Key and Extra Field

vrt rules - Thu, 08/22/2013 - 19:11
This post will walk through our coverage for the Master Key and Extra Field vulnerabilities. Both vulnerabilities allow arbitrary files to be added to signed APKs without breaking the digital signature. ClamAV bytecode signatures allow for flexible coverage when a vulnerability or malware family is too complex to detect with any of the other signature formats. The bytecode signature language is a subset of C with an API for interfacing with ClamAV.

The vulnerabilities have been written about exhaustively elsewhere online, the most comprehensive of which are from @saurik: Master Key and Extra Field.
Zip File FormatZip files contain a central directory pointing to all of the files stored in the archive. The central directory is located at the end of the file. Each file stored within the Zip file has a header immediately before its stored bytes, as well, each file has a more verbose header stored in the central directory. You can see the specifics on Wikipedia.
Master Key VulnerabilityThe Master Key vulnerability is exploited by having multiple files with the same name in an APK. Android's verifier and loader handle duplicate entries differently. The verifier will check only the last duplicate entry against the SHA1 digest stored in META-INF/MANIFEST.MF. The loader will load the first entry.

The fact that any file could be replaced is what led to the decision to use a bytecode signature to cover this vulnerability. The vulnerability creates a complex situation where the APK / Zip needs to be parsed and each file name checked against the others.

The bytecode signature first finds the last end_of_central_directory entry's file magic in the file. The end_of_central_directory section has information about the starting offset and size of the central_directory. This is the equivalent of scanning backward to find the end_of_central_directory entry.

        // find the last end_of_central_directory file magic
    while(end_central_dir_off != -1) {
        // keep track of the previous one
        last_end_off = end_central_dir_off;
        // seek past it
        if(seek(last_end_off+1, SEEK_SET) < 0)
            return 0;
        // keep doing this until the magic PK\x05\x06 is not found
        end_central_dir_off = file_find("\x50\x4b\x05\x06", 4);
    // set to the last one found
    end_central_dir_off = last_end_off;

After some seeks and reads the bytecode signature reaches the while loop for detecting duplicate file names. For security reasons there is no malloc in the ClamAV bytecode engine, because of this, an O(n2) comparison was used. There are two buffers used since each filename is tested against all those that follow it. Only when the file name lengths are equal are the names read in to their respective buffers. Then, the names are compared to each other looping backward in order to break as soon as possible on differences. This avoids iterating over similar paths. The read in and comparison can be seen below:

    // if the lengths are the same, do the comparison
    if(file_name_length == compare_name_length) {

        // seek to entry name
        if(seek(zip_entry_off + 46, SEEK_SET) < 0)
        // read name
        if(read(file_name_buffer, file_name_length) != file_name_length)
        // seek to the compare entry name
        if(seek(compare_entry_off + 46, SEEK_SET) < 0)
        // read name
        if(read(compare_buffer, file_name_length) != file_name_length)
        // compare names from end backward to avoid wasting time, ex:
        // /res/drawable-hdpi/btn_call_1.png
        // /res/drawable-hdpi/btn_call_2.png
        for(i=(file_name_length-1); i > -1; i--) {
            // if any character does not match, break
            if(file_name_buffer[i] != compare_buffer[i])
        // if reached the end of the loop (didn't break on any comparison)
        if(i == -1) {
Extra Field Vulnerability The Extra Field vulnerability is exploited by a signed / unsigned handling error in the Android's verifier. A Zip file's central directory points to all of the files stored in the archive. Each file has a header which has extra space available, called the extra_field. The extra_field, when present, is between a file's header and the stored file. When its size is interpreted as a negative value, the verifier will try to skip past it to the file bytes by jumping backward. If you store the original file at the location the verifier jumps backward to, it will be verified. Then you can place some arbitrary file into the original file's position, causing the new file to be loaded.

The most popular way to exploit this is to store the classes.dex file uncompressed. Then the extra_field_length is set to 0xFFFD (65533 unsigned, -3 signed). This causes the original file's magic (example: dex\x0A035\x00) to overlap with the file name classes.dex. When the verifier jumps over the extra_field, it will jump backward 3 bytes into the file name, these bytes are shared with the start of the dex file. It will verify that the original dex file, which has been stored in the extra_field, is unchanged. When the loader goes to load the file, it will correctly treat the extra_field_length as unsigned short and jump forward to the new dex file.

I also realized that you could jump backward into another entry's extra_field. It would constrain your file sizes even more, but it would still be possible. Instead of only covering 0xFFFD, the bytecode was initially looking for any value that could be interpreted as negative in the dex entry's extra_field_length.

After reading @saurik's blog post on the Extra Field vulnerability I realized that this coverage needed to be expanded. My logic was, initially, that the file classes.dex (the executable code) was the only serious threat when replaced. In hindsight, this was a strange decision as I thought to cover any file for the Master Key vulnerability but only one file for Extra Field. There are a lot of files that could be dangerous when replaced.

The really mind blowing thing that @saurik demonstrated was an almost complete replacement of the central directory. The entries in the central directory also have an extra_field. When its size is large enough to be interpreted as negative, the verifier will instead interpret it as zero. The usage of this vulnerability in the central directory pivots off the first entry in order to split the paths of the verifier and the loader. Each is then just directed to every other file entry using valid, specially crafted extra_field and comment lengths. This allows a near total replacement of a signed application's contents. This paragraph by no means does this bug technical justice, if you are interested, I highly suggest you visit the post linked above.

What does all this mean for coverage? It means we should look at every file entry in the zip file, as well as every entry in the central directory. The safest way to reach every entry in a Zip file is by reading the central directory and getting the offset from there. For this reason, coverage has been integrated into the loop checking for the Master Key vulnerability.

    // get the offset of the file header for this central dir entry
    zip_entry_off = *(uint32_t *)&cd_header[42];
    zip_entry_off = le32_to_host(zip_entry_off);
    if(seek(zip_entry_off, SEEK_SET) < 0)
        return 0;
    if(read(zip_header, 30) != 30)
        return 0;
    // check the extra field size
    extra_field_size = *(uint16_t *)&zip_header[28];
    extra_field_size = le16_to_host(extra_field_size);
    if(extra_field_size > 0x7FFF)
    // go back to where we were previously
    if(seek(cd_entry_off + 46, SEEK_SET) < 0)
        return 0;
    // check extra field size for the central directory entry
    extra_field_size = *(uint16_t *)&cd_header[30];
    extra_field_size = le16_to_host(extra_field_size);
    if(extra_field_size > 0x7FFF)

Once the code has read in the central directory header to the variable cd_header, it then retrieves the offset of that file entry in the Zip file. It seeks to that location and reads in the local file header to the variable zip_header. It casts the extra_field_size safely using le16_to_host(). This function converts a 16bit little endian value to the equivalent in the host architecture's endianness. If the value is greater than 0x7FFF, that is, if it can be interpreted as a negative value, then we alert that the Extra Field vulnerability has been found. If not, we seek back to the central directory entry and do the same check for the negative extra_field value in the central directory.
Examples Following are some examples of the two vulnerabilities on VirusTotal.

MD5: 04EEF623255A7CEBD943435ACF237456 - The first central directory entry at offset 0x7A5F4 has a negative extra_field value (0x8000). Alternate central directory entries have been inserted into that space.

MD5: C9F4C62521C04B8ADD796A1D5CEE08B0 - This sample was the first usage of the Extra Field vulnerability spotted in the wild. It was detailed in our blog post here. It is interesting to see the variety in names used by different vendors.

MD5: D816596A70A7117346A2DFB6F8850E39 - This example of the Master Key vulnerability triggers because the file /res/drawable-xhdpi/icon.png has been inserted twice. While this is not a malicious exploitation of the Master Key vulnerability, it demonstrates how thorough coverage needs to be for this vulnerability.

MD5: DAA9C49A4645CE109B1E36DC6233DB07 - For this Master Key sample, it looks like someone took an already malicious APK and added an extra classes.dex file and a second AndroidManifest.xml file.

Microsoft Update Tuesday August 2013: More font issues, some interesting DoSes

vrt rules - Tue, 08/13/2013 - 18:26
It's a pretty standard month for Update Tuesday this time around. There's a total of 8 bulletins, covering 23 CVE issues. This bulletin addresses the final 2 issues reported during CanSecWest's Pwn2Own.

As usual, there's the requisite IE bulletin (MS13-059), which covers 11 CVEs. This includes the 1 open IE Pwn2Own issue. The issues cover IE6-IE10 on all versions of Windows. All issues were privately reported to Microsoft, so they haven't been exploited in the wild yet. Several vulnerabilities are the result of a use-after-free, but there's also a stack-based buffer overflow when handling a specific font type (CVE-2013-3181).

This month we also have another font issue (MS13-060), this time in a Unicode font. The vulnerability is only present in XP SP3, XP Professional 64-bit and Windows Server 2003. It can be exploited by embedding a font in a document or a webpage.

There's also an update for Exchange (MS13-061), which is actually just a downstream Oracle Outside In update that Microsoft is applying. The issues were described in CVE-2013-2393, CVE-2012-3776 and CVE 2013-3781.

Bulletin MS13-062 covers an interesting vulnerability (CVE-2013-3175) in the handling of Remote Procedure Calls (RPC). The vulnerability can only be exploited post authentication though: an attacker needs an account and needs to log in before being able to exploit this vulnerability. As such, it's only a potential privilege escalation instead of remote compromise.

There are also a number of kernel vulnerabilities that are being fixed in bulletin MS13-063, affecting most supported Windows versions, including XP up to 8, and Server 2003 and 2008. This bulletin deals with 4 CVEs. Most vulnerabilities result in memory corruption that could allow an an escalation of privileges for the attacker (CVE-2013-3196, CVE-2013-3197, CVE-2013-3198). However, one of the issues being fixed is the final Pwn2Own issue that allowed VUPEN to bypass ASLR (CVE-2013-2556).

There are also 2 interesting denial of service vulnerabilities that are being addressed by MS13-064 and MS13-065. Both can result in a system crash and require a reboot when an attacker sends a maliciously crafted ICMP packet. The first vulnerability (CVE-2013-3182) occurs on servers with the Windows Nat Driver Service running (MS13-064). If the attacker sends a maliciously crafted ICMP packet that contains a truncated IPv6 header, this can cause read access violation, resulting in a system crash. The second vulnerability (CVE-2013-3183) is in the ICMPv6 implementation (MS13-065) and can also result in a system crash if an attacker send a maliciously crafted ICMPv6 Router Advertisement packet that contains an invalid prefix length field.

Finally MS13-066 deals with an information disclosure (CVE-2013-3185) in ADFS. The issue occurs when an attackers visits a specific URL associated with the ADFS service, resulting in a disclosure of account information.

We are releasing rules SID 27605-27616, 27618-27620 and 27624 to address these issues.

Android Extra Field Vulnerability Spotted in the Wild

vrt rules - Tue, 07/30/2013 - 15:47
It has been 20 days since the Extra Field vulnerability (also known as Chinese Master Keys) was first reported (translated link) by the Android Security Squad. It has now been spotted in the wild. The linked sample (MD5: C9F4C62521C04B8ADD796A1D5CEE08B0), which will be referred to as Arctic.apk, contains another APK named DoubleRainbow.apk (MD5: 1B14AD438375E6C25F645A855828D78F). DoubleRainbow.apk contains the Extra Field vulnerability. This APK is not malware. It is designed to root the Kobo Arc tablet.
A Brief Overview The Extra Field vulnerability exists because of a signed / unsigned error when verifying the cryptographic signature of an APK's files. In a Zip file (APKs are Zip files) there is an entry Extra Field in each file's local header (see header structure here). When checking the signature of the file, the Extra Field Length is treated as a signed short. The verifier attempts to jump over the Extra Field to the file's bytes. When set to 0xFFFD (-3) the verifier will jump 3 bytes backward into the file name (classes.dex) which shares three bytes (dex) with the start of the Dex file. The loader treats the Extra Field length correctly, as an unsigned short. So the loader will jump forward, over the Extra Field, to load the file. If you place the original Dex file, overlapping the file name, into the Extra Field it will be verified. You may then place a different Dex file in  the original file's place. This injected Dex file (likely malicious) will be loaded and run without breaking the APK's signature.
The SampleChecking the files inside of Arctic.apk, it is fairly obvious that it is up to something. Inside the /assets/ folder we see the following files:
wifiScript.shThe presence of Superuser.apk indicates that Arctic will likely be rooting the device. Artic is fairly simple, it installs and runs DoubleRainbow.apk, which was originally a system package for the Kobo Status Bar. Since it is a system package, it is granted elevated privileges on the device. The Extra Field exploit allowed the author to inject custom code to be run by this package. In order to match the size of the replaced classes.dex, the injected Dex file was padded out with a 2599 byte string, "LOLOLOL...". Once executed, the custom classes.dex executes, the contents of which can be seen here:
#!/system/bin/sh mount -o rw,remount /system
cat /data/data/ >/system/xbin/su
chmod 6755 /system/xbin/su
cat /data/data/ >/system/app/Superuser.apk
chmod 644 /system/app/Superuser.apk
pm uninstall com.kobo.statusbarSince DoubleRainbow.apk is running in a privileged mode, all it needs to do is copy over su and Superuser.apk.
ConclusionThe APK was authored by @zhuowei and can be found on their Github. None of the source code was being returned by Google since it was posted so recently. The repository was found through the author's name on Arctic.apk's certificate. As we can see from the following, the Kobo Status Bar APK (DoubleRainbow.apk) still contains the certificate issued by Jason Gamblen from Kobo Inc.
Issuer: C=CA, ST=British Columbia, L=Vancouver, O=Unknown, OU=Unknown, CN=Zhuowei Zhang
Issuer: C=CA, ST=Ontario, L=Toronto, O=Kobo, OU=Android Team, CN=Android/emailAddress=jgamblen@kobobooks.comWhile this APK is not malicious, it demonstrates how easy it is to gain root access using the Extra Field vulnerability. It is expected that this vulnerability and the Master Keys vulnerability will become common occurrences in Android malware.

Androrat - Android Remote Access Tool

vrt rules - Tue, 07/16/2013 - 21:11
AndroratAndrorat is an appropriately named remote access tool (or RAT) for Android. In case you're unfamiliar, RATs provide backdoor functionality to an operator, giving access to your system and private data. Androrat recently fell into the spotlight thanks to this Webroot blog post that highlights a user-friendly Android trojan maker. According to the post, Androrat is the default malicious package provided with this software.

Androrat was the project of four university students from France. According to their README, it was completed in one month. It has since been removed from the Github account on which it was hosted, and for privacy reasons these students will not be named here.

A law enforcement agency provided us with a zip file that appears to be a dump of the Github repository. It contained two compiled debug versions of the Androrat APK, the source code for these, and some class files. Additionally, it contained all of the source code for the server as well as its dependencies.
BuildingTo get the server running, I was able to simply drop all of the source files into an Eclipse project, add the dependencies, and fix up one import that didn't agree with my system. I was pleasantly surprised at how easy this was to get working.
RunningTo test that everything was working I ran the server from Eclipse and simply loaded up the debug APK. The debug APK conveniently allows the user to set the server's IP and port. Here we can see the debug apk and the server program:

FunctionalityAndrorat covers the breadth of Android malware features. From the README:

    ### All the available functionalities are
    * Get contacts (and all theirs informations)
    * Get call logs
    * Get all messages
    * Location by GPS/Network
    * Monitoring received messages in live
    * Monitoring phone state in live (call received, call sent, call missed..)
    * Take a picture from the camera
    * Stream sound from microphone (or other sources..)
    * Streaming video (for activity based client only)
    * Do a toast
    * Send a text message
    * Give call
    * Open an URL in the default browser
    * Do vibrate the phone

After setting up a contact list, a few fake conversations, and a call log I went to test these out. A few of the functions gave errors, but most worked. As well, a few were not compatible with the Android emulator (for example, vibrate).
CommunicationIn the file inout/ the request and response codes are listed. For requests the base number is 100, then a value ranging from 0 to 23 is added to it for the code. This is wrapped with the target channel (multiplexed) and arguments in CommandPacket. Then it is wrapped with other meta info in TransportPacket. The resulting packet data size for requests hovers around 21 bytes.

The APK gives an acknowledgment to requests received. The response message is packed into a custom packet via the following function call sequence (format: ClassName.function):
-> Client.sendInformation 
-> Connection.sendData 
-> Mux.send 

This packet includes the acknowledgement data, total length, data length, the channel (multiplexed), as well as a short and bool for following the packet sequence.

The response codes have a base of 200 and add a value ranging from 0 to 15 to that base. Data being sent is generally built into an array or hash table, then the response is written using ObjectOutputStream.writeObject() and placed into a custom packet. The packet includes the type that was packed. For example, when dumping an SMS to the server, the object type java.util.ArrayList will be included in the packet to indicate what has been written. The fields used in these structures prior to packing are very verbose. As an example, PhoneNumber, SimOperator, and IMEI are used when dumping device information to the server.

The information is sent over TCP with this custom protocol. The default server port is 9999, however, this is configurable.
ConclusionSince the source code was public, this project provides a significant starting point for new Android malware authors. However, it does not contain any root exploits, it does not attempt to obfuscate the code or communication, and it has not been refined to a point that I would call reliable.

Microsoft Update Tuesday: July 2013: an issue of TrueType fonts

vrt rules - Wed, 07/10/2013 - 03:20
This month's Update Tuesday looks pretty interesting. As usual, there's quite a few CVEs covered and most of them are once again in IE: there's a total of 7 bulletins, covering 34 CVE issues. However, one CVE is shared between 3 bulletins.

MS13-052 covers the .NET framework and Silverlight. There's a total of 7 CVEs fixed by the update associated with this bulletin. The bulletin is marked critical and could result in remote code execution or escalation of privileges if one of these vulnerabilities is exploited.

There's a total of 8 CVE isusues this month that pertain to the Windows Kernel, described in MS13-053. This bulletin is considered critical and can result in remote code execution, specifically due to vulnerability  related to TrueType fonts, which we discuss as part of MS13-054. Other vulnerabilities include a use-after-free and an overflow that can result in a potential escalation of privileges for an attacker.

One particularly interesting bug is described in MS13-054. While that bulletin specifically covers GDI+, the single CVE (CVE-2013-3129) associated with this bulletin is also shared by bulletins MS13-052 and MS13-053. This vulnerability is the result of a bug when handling maliciously crafted TrueType fonts.  The interesting part here is that a previous TrueType font issue was a 0-day exploited by the Duqu malware. Because TrueType fonts can exploited via a malicious Word document (or anything that can embed TrueType fonts - like Silverlight), this means that the issue can result in remote code execution.

MS13-055 is the bulletin that deals with IE. This one covers all supported versions of Internet Explorer (i.e., IE6-IE10) and covers 17 CVE issues. The bulletin is rated critical and covers a number of issues, mostly resulting in memory corruption which could allow an attacker to execute arbitrary code. As with previous IE vulnerabilities, the memory corruption issues are mostly the result of use after free issues, where an attacker can potentially access an object after the memory for it has freed. This type of vulnerability can result in a kind of type confusion, where in one part of the program the memory is still considered to be a particular object, while in another part it may have been reallocated and used as a different object. It can then potentially corrupt sensitive information (like a pointer) in the new object, which could allow attackers to overwrite arbitrary memory locations.

Windows DirectShow is updated through bulletin MS13-056. It patches a vulnerability that can result in memory corruption and that is potentially exploitable on all supported Windows versions except RTE and Server Core.

There's also a bulletin covering Windows Media Format (WMF): MS13-057, this bulletin handles a single CVE issue related to a potential underflow vulnerability in a DLL when opening a malicious WMF file, potentiall resulting in remote code execution. The patch for this vulnerability modies the way in which Windows Media Player opens media files.

Finally, the last bulletin released this month covers Windows Defender (MS13-058). This is the only bulletin marked as important: all the rest were considered critical. The bulletin is made up of a single CVE issue, that can result in a local vulnerability, potentially allowing an attacker to gain increased privileges.

We have detection for many of these vulnerabilities through SIDs: 27126-27139, 27147-27154, 27156-27157.

Microsoft Update Tuesday, June 2013: mostly about Internet Explorer

vrt rules - Tue, 06/18/2013 - 20:06
Another month brings us another Update Tuesday. This month is pretty light with respect to the updates that Microsoft is releasing. They're releasing a total of 5 bulletins, covering 23 CVEs.

First and foremost are the critical updates for Internet Explorer (MS13-047). They are releasing updates for 19 CVEs, some of which could allow for remote code execution. These issues cover all supported IE versions, ranging from IE6 to IE10. Unlike last month, these issues do not seem to have been exploited in the wild and were all reported through Microsoft's "Coordinated Vulnerability Disclosure" program. While most issues are triggerable in default configurations of IE, one issue (CVE-2013-3126) requires the user to have enabled script debugging and can only exploited when this mode is active. This is interesting because the target audience running in this mode are probably web developers, potentially exposing them to increased threat of attack.

There's also an update for the Windows Kernel (MS13-048) that fixes an information disclosure vulnerability, covering all currently supported versions of Windows Desktops, ranging from XP to 8 as well as all Windows Server versions.

Another interesting update is to fix a vulnerability in a Windows Kernel Driver (MS13-049) which can result in a Denial Of Service attack. The Denial Of Service attack is possible only after first triggering protection against another potential Denial Of Service: a SYN flood. Once the system detects that a SYN flood is occurring it goes into "SYN Attack Protection" mode, which will reduce the timeout for the system to wait for ACKs. Once the system enters this mode, it is possible to trigger a Denial Of Service that requires a reboot to correct by sending a maliciously crafted packet.

An update is also being issued for a vulnerability in the Windows Print Spooler (MS13-050), that can allow an authenticated user to gain increased privileges.

Finally, the last update this month is for an issue in both Office 2003 and Office for Mac 2011 (MS13-051), that has been exploited in the wild. The vulnerability allows an attacker to gain remote code execution through a maliciously crafted file.

We have detection for many of these vulnerabilities through SIDs: 6700, 26843-26849, 26851-26853, 26867-26878, and 26882-26890.

DDoS Gone...

Emergingthreats - Wed, 11/03/2010 - 13:44

The DDoS has gone, thanks to everyone that helped with intel and takedowns. We are extremely lucky to have such good friends!

Back to normal business. Rule distribution wasn't ever disrupted, but our documentation site was out for the duration of the ddos. We're going to look at moving more of the infrastructure to ddos-proof facilities as we get the revenue flowing through ET Pro. More on that as it develops!

And again, a huge thanks to all who saved our bacon. You know who you are, and we all owe you one.


Daily Update Summary 10/31/2010

Emergingthreats - Sun, 10/31/2010 - 22:12
2007765 - ET POLICY Host List Download (policy.rules)
2007766 - ET POLICY Update Activity (policy.rules)
Pulled these out of DELETED. It appears they may still be applicable.

2011886 - ET WEB_SPECIFIC_APPS Webspell wCMS-Clanscript staticID Parameter SQL Injection Attempt (web_specific_apps.rules)
by dave richards

2011887 - ET SCAN Medusa User-Agent (scan.rules)
by will metcalf. Definitely hostile if seen. Blockable.

2800847 - ETPRO POLICY SSL Remote Control Access (policy.rules)
2800848 - ETPRO POLICY SSL Client Communication (policy.rules)
2800849 - ETPRO POLICY SSL Client Communication (policy.rules)
New sigs written at a Pro client's request. Not perfect as does everything by SSL, but we can see their cert and detect beaconing clients at least.

The Emerging Threats Update Summary

Emergingthreats - Sat, 10/30/2010 - 00:16

A brief summary of what we've covered today. 


2011872 - ET USER_AGENTS Suspicious Gbot UA Detected (user_agents.rules)

New for Gbot, uses a unique user-agent like gbot/2.1. Very nice of them to make that easy for us. 


2011873 - ET CURRENT_EVENTS Suspicious HTTP GET to JPG with query string (current_events.rules)

Also Gbot related, please report falses on this. As was noted on the list this is related to hostile ad serving activity and may false on real ads.


2011874 - ET POLICY NSPlayer User-Agent Windows Media Player streaming detected (policy.rules)

New policy sig to know when someone is streaming using WMP.


2011875 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter SELECT FROM SQL Injection Attempt (web_specific_apps.rules)

2011876 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter DELETE FROM SQL Injection Attempt (web_specific_apps.rules)

2011877 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter UNION SELECT SQL Injection Attempt (web_specific_apps.rules)

2011878 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter INSERT INTO SQL Injection Attempt (web_specific_apps.rules)

2011879 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter UPDATE SET SQL Injection Attempt (web_specific_apps.rules)

2011880 - ET WEB_SPECIFIC_APPS phpBazar picturelib.php Remote File inclusion Attempt (web_specific_apps.rules)

2011881 - ET WEB_SPECIFIC_APPS Open Web Analytics mw_plugin.php IP Parameter Remote File inclusion Attempt (web_specific_apps.rules)

2011882 - ET WEB_SPECIFIC_APPS Open Web Analytics owa_action Parameter Local File inclusion Attempt (web_specific_apps.rules)

2011883 - ET WEB_SPECIFIC_APPS Open Web Analytics owa_do Parameter Local File inclusion Attempt (web_specific_apps.rules)

2011884 - ET WEB_SPECIFIC_APPS iGaming CMS loadplugin.php load Parameter Local File inclusion Attempt (web_specific_apps.rules)

New specific apps stuff rom Stillsecure, thanks guys!


2800837 - ETPRO WEB_CLIENT Adobe Shockwave Director tSAC Chunk Parsing Memory Corruption (web_client.rules)

2800838 - ETPRO WEB_CLIENT Adobe Shockwave Director tSAC Chunk Parsing Memory Corruption (web_client.rules)

2800840 - ETPRO WEB_CLIENT Adobe Shockwave Director dcr access (web_client.rules)

2800841 - ETPRO WEB_CLIENT Adobe Shockwave Director pamm Chunk Memory Corruption (web_client.rules)

For the latest Adobe 0-days of the... day. We'll have another one tomorrow I'm sure. 


2800839 - ETPRO EXPLOIT HP Data Protector Express DtbClsLogin Stack Buffer Overflow (exploit.rules)

CVE 2010-3007, significant local threat. 


2800842 - ETPRO EXPLOIT IBM Rational Quality Manager and Test Lab Manager Policy Bypass (exploit.rules)

Bugtraq 44172. Not sure how much this one will be exploitable, but still worth seeing. 


2800843 - ETPRO WEB_CLIENT RealNetworks RealPlayer CDDA Access (web_client.rules)

2800844 - ETPRO WEB_CLIENT RealNetworks RealPlayer CDDA Access 2 (web_client.rules)

2800845 - ETPRO WEB_CLIENT RealNetworks RealPlayer CDDA URI Uninitialized Pointer Code Execution (web_client.rules)

These may produce some load, so we'll keep an eye on it. They shouldn't be too prone to falsing as far as web-client style signatures go. If you see these it'll be worth checking out. 


2800846 - ETPRO TROJAN Worm.Win32.Faketube Activity (update request) (trojan.rules)

This worm's CnC channel is very good at looking like normal traffic. Could be some falses here, and we'll try to adjust if so. 


More tomorrow!! We'll try to do these updates each day, Please send in suggestions for what to cover and discuss here. The ET Pro research team is up to speed and covering everything new that we find, or comes across the wire. IT'S ON!!! These guys are good!



New Platforms Available!

Emergingthreats - Fri, 10/29/2010 - 22:39

We now officially have support for Snort 2.4.0 and higher, and Snort 2.9.0 current available in both the et Open, open-nogpl, and ET Pro rulesets!

Appreciate everyone's patience in getting these final 2 platform's qa'd and out the door. Please give them a run and let us know how they fare!

You can find the rules at:

Choose your version and platform and you're all set!


The ET Pro Team 

The New Rulesets are Ready!!!!

Emergingthreats - Sat, 10/09/2010 - 17:36


Thanks to all for your patience, and to everyone who's chipped in to help do this work. It's been about 4 months of converting and testing, but we FINALLY have the open ruleset all ready to re-launch. 


The updated rules can be found at:


For this conversion to 2.8.4, 2.8.6, and suricata we've ingested the old Snort GPL rules (sid 3464 and prior) to convert as well as some of the valuable community sigs in order to keep complete coverage on older platforms. They'll no longer be available from VRT in 2.8.6 and prior, so we're doing so here.


All have been converted and tweaked to provide a more complete ruleset. But of course if you're staying with VRT as your primary ruleset and want to add the ET Open rules you'll have GPL sid duplication. So to make it possible for you to choose to stay with VRT we have provided a version of the ruleset that does NOT contain the GPL or community rules that would overlap. We will support this for the long term, so if you do choose to stay with VRT please continue to use the free ET rules! 


Some notes:

1. The dns name is a round robin to a couple of servers now, and we'll be adding a few more over time. So we won't have the bandwidth crush issues when we would publish on the old systems.


2. The old ruleset at / zip will remain there, but they WILL NOT BE UPDATED ANY FURTHER. In a couple of weeks, based on feedback, we may set up a redirect to the snort-2.8.4 tarball so we don't lose a lot of automated sensors out there updating on their own. The problem is though that the filenames inside the tarball have changed to reflect our full use of categories. 


3. The open rulesets retain the file naming convention emerging-<category>.rules. (The et pro rules do not have emerging- to avoid confusion) We have added a lot of categories though, so check the included emerging.conf to make sure you're including all you want to run.


4. You must choose your platform. 2.8.4 is where the rulesets USED to be. No http_*, file_data, fast_pattern, etc. While 2.8.4 did support some of the http_* functions, the 2.8.6 version of the ruleset is the first that we've brought all of this together. 


5. Snort 2.4 support will be available soon, as will snort 2.9.0. Keep an eye out for both in the open and pro rulesets! 


6. The version file at will continue to be updated and picks up from where we were, no rollback. We encourage you to use that file to sense when your scripts need to pull an update! The old files that were for the compromised list, rbn list, and dshield rev won't be continued. They all incremented at the same time, and will continue to, so we're just going to rely on the master version counter if no one objects. 


I'll get the backlog of sigs sent to the list committed. We will continue to update the ruleset as often as possible. Likely we'll settle into a once a day update cycle. No less than that for sure!


Thanks again to everyone for your patience. Please grab the new tarball, beat it up. I am CERTAIN we have mistakes in there because my hands have been in it, so please let me know!!


Emerging Threats Sells Out!!

Emergingthreats - Mon, 09/27/2010 - 15:07

We are adding a full coverage premium subscription ruleset. So not really selling out I suppose, it's just us still. No outsiders... so we're kind of selling out to ourselves. If you have to sell out that's the way to do it I think!

We are building a new ruleset, one that has full vulnerability coverage. We have a professional research team on full time now, and we've bought the Telus Security Labs feed (the guys that supply the entire industry with research, rules, and intel, the big brains!). This has allowed us to fill in the historical gaps in coverage of the open ET ruleset, and will assist us in keeping completely up to date with new vulnerabilities and new exploits as they happen.

But wait, there's more!!!

What's the biggest security threat on your network, and every network these days? (besides your users) 

It's malware. I don't think there's any argument there, and that's why the ET ruleset has been so useful, because we all focus on malware. You don't get the malware coverage in the existing commercial rulesets because it just moves too quickly. And all the commercial rulesets are built for an appliance the same company sells, so adding more rules day after day doesn't make the appliance they also sell look good as it slows down. So the result: we have commercial rulesets with only minimal malware coverage, so we all use the ET ruleset to augment.

So we're changing that, we're making THIS the one ruleset you need, not the one you add on to the others. We have the full time research team, we have the intelligence feeds, and we have enough coffee to keep the state of Washington awake for a year straight. We're on it! We've hired most of our researchers from the Emerging Threats Community (and we're still hiring, shoot me a resume if you want to play with us!). So it's the people you already know and trust. We've been doing this for 10 years now. 

We're JUST doing rules, not hardware. This is a major difference. You now have a CHOICE in what ruleset you use just like you choose the hardware that fits your needs.

We're rebuilding and expanding the ET Sandnet that's been feeding us so much good intel over the years, and we're partnering with all the names you already know in the industry to share intel, samples, and more.

But wait, there's more!!!

We're publishing in many engine formats. One of the drivers to do this was to get a full coverage ruleset out there that could take advantage of the new capabilities of Suricata. It's pretty clear no one else is going to do that, so we're going to make it happen. 

At launch we are covering Snort 2.8.4 era, 2.8-CURRENT, and Suricata. We'll have a Snort 2.4 ruleset out shortly to support those of you using an older engine. And here's the big thing.... We'll support 2.4, and all of our platforms, until no one needs it anymore! If you can't upgrade, fine. Not everyone needs to, can, or wants to upgrade. As long as people need it we'll keep putting out a 2.4. 

The Existing and future ET ruleset will also be published in these formats! 

We'll be introducing new platforms and languages later this year as well, so keep an eye out.

But wait, there's more!!!!

Emerging Threats Pro exists because of the community, ET *is* the community, it's been my honor to be the moderator all these years. We will stay part of that community. So here's my personal commitment, and the commitment of the new company Emerging Threats Pro, to the community. Write this down, frame it whatever. (I'm hanging it on my office wall)

1. ET Pro will support the Emerging Threats open project as long as needed. Hosting, infrastructure, manpower, everything. 

2. The Emerging Threats Ruleset will remain FREE, BSD licensed as it always has been. That will not change unless we all agree we need to change it.

3. Every rule that comes from the community will immediately go through the ET Pro QA and load testing rig, and be converted to all the platforms we support as a company, and be IMMEDIATELY distributed to the community in ALL of those formats. All rules, in all formats, QA'd and converted, IMMEDIATELY. We'll do the grunt work. 

4. I will turn over control of the project to a board of five community members to make the decisions, those board members will be elected. (I will stand for election as well. VOTE JONKMAN! :) )


We'll set up that board for ET soon and get an election going. The reason I want to do that is we've seen things go bad in many other open source projects over the years when money and company interests come before keeping the community the project came from happy. I believe I will do a good job taking care of both projects for the long term, but I'm human like everyone else. I don't think anyone that's gone through this process of building a business behind an open project and ended up alienating a community went into it intending to do so. I would regret it forever if that happened to us. So to make SURE that doesn't happen I am going to give full control of the open project to the community. 

That means you still have a stake in the project, and you have to step up and help govern it. You have to nominate responsible board members, and these board members have to put a little work into it now and then. And if you don't like how things are going you have to speak up, offer solutions, or get yourself elected to the board and make changes. If the you or the board really don't like how I and the ET Pro team are taking care of things then you may take over and manage the project. You'll have full power to do so at any time.

It of course worries me to give up full control of Emerging Threats. It's been my baby for many years now (8, 9?). But I have faith in this community. I KNOW we will take care of this thing we've built, and I KNOW it will last a very long time and continue to do good things. Because of that faith I think I can get over having sole control and let this thing live it's own life. (Maybe this is what it'll be like when my daughters go to college...)

So, more details coming soon on the technical changes. Your download url won't change if you want the 2.8.4 ruleset as it is now. I'll get the charter for this board out soon and we can get some nominations and election going.

Bottom line:

1. ET Pro will offer a complete ruleset based on and expanding the ET open ruleset

2. ET Pro will support the open project in all it needs

3. You are going to have a say in how we run the open project from here out

4. You have a choice where to get your rules now!


Comments welcome as always. 

NVIDIA Partners with the OISF

Emergingthreats - Thu, 09/09/2010 - 14:41

The OISF is proud to announce that NVIDIA has joined the foundation as a technology partner to help develop and enhance CUDA GPU based acceleration within Suricata. This exciting development gives the foundation access and assistance from NVIDIA engineers and designers to bring you Suricata IDS/IPS GPU acceleration on standard hardware.

Watch for new developments with GPU acceleration to hit the streets very soon!