Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:


  • Recent Posts

  • Calendar

    July 2015
    S M T W T F S
    « Jun    
     1234
    567891011
    12131415161718
    19202122232425
    262728293031  
  • Email Subscription

  • About Us

    We have discovered a vulnerability in the integrated Android debugger Debuggerd that can be used to expose the contents of the device’s memory in devices running Ice Cream Sandwich to Lollipop.

    A specially crafted ELF (Executable and Linkable Format) file can crash the debugger and expose the memory content via tombstone files and corresponding logd log files. This information can be used in denial of service attacks, as well as to help bypass ASLR for arbitrary code execution. By itself, the vulnerability cannot be used for code execution. However, the information leaked here may be combined with other flaws for that purpose.

    This vulnerability can be exploited by a malicious or repackaged app downloaded onto the device, although the impact would be relatively limited (as no code execution is possible by itself). No malicious code can be executed if this vulnerability is exploited. This vulnerability is present from Android 4.0 (Ice Cream Sandwich) up to Lollipop (5.x). However, the vulnerability has been resolved in the next version, Android M.

    Vulnerability Description

    The root cause of the vulnerability is that Debuggerd will use sym->st_name as an offset for a string copy command without any error checking. This value can be easily controlled by the malformed ELF file in such a way that if the offset value points to inaccessible memory, Debuggerd will crash. Repeated crashes would cause a denial-of-service attack;  it would disable other normal crashes which cannot be connected to Debuggerd anymore. A carefully designed offset will cause Debuggerd will expose the corresponding memory contents to related dump and log files.

    For Android 5.0-5.1:, the vulnerability can be found in external/libunwind/src/elfxx.c:


    126       for (sym = symtab;
    127            sym < symtab_end;
    128            sym = (Elf_W (Sym) *) ((char *) sym + syment_size))
    129         {
    130           if (ELF_W (ST_TYPE) (sym->st_info) == STT_FUNC
    131           && sym->st_shndx != SHN_UNDEF)
    132         {
    133           if (tdep_get_func_addr (as, sym->st_value, &val) < 0)
    134             continue;
    135           if (sym->st_shndx != SHN_ABS)
    136             val += load_offset;
    137           Debug (16, "0x%016lx info=0x%02x %s\n",
    138              (long) val, sym->st_info, strtab + sym->st_name);
    139
    140                   /* ANDROID support update */
    141                   if ((Elf_W (Addr)) (ip - val) < *min_dist
    142                       && (Elf_W (Addr)) (ip - val) < sym->st_size)
    143                   /* End of ANDROID update */
    144             {
    145               *min_dist = (Elf_W (Addr)) (ip - val);
    146               strncpy (buf, strtab + sym->st_name, buf_len);  //the address st_name may be easily controlled by malformed  ELF
    147               buf[buf_len - 1] = '';
    148               ret = (strlen (strtab + sym->st_name) >= buf_len
    149                  ? -UNW_ENOMEM : 0);
    150             }
    151         }
    152         }

    To reproduce the vulnerability, an ELF file whose main function directly crashes can be used. This can be done by modifying the symbol offset. After the ELF is embedded into an APK, the former will be executed in a loop. This will trigger the vulnerability, as seen below:

    Figure 1. Trigger of vulnerability

    Similar issues are also found in older versions of Android (specifically, 4.x versions such as Ice Cream Sandwich, Jelly Bean, and KitKat). These do not use the libunwind third-party library. In Android 4.0:, the vulnerability is in system/core/debuggerd/symbol_table.c: 

    155     int j = 0;
    156     if (dynsym_idx != -1) {
    157         // …and populate them
    158         for(i = 0; i < dynnumsyms; i++) {
    159             if(dynsyms[i].st_shndx != SHN_UNDEF) {
    160                 table->symbols[j].name = strdup(dynstr + dynsyms[i].st_name);//st_name is not carefully checked before using
    161                 table->symbols[j].addr = dynsyms[i].st_value;
    162                 table->symbols[j].size = dynsyms[i].st_size;
    163                 XLOG2(“name: %s, addr: %x, size: %x\n”,
    164                     table->symbols[j].name, table->symbols[j].addr, table->symbols[j].size);
    165                 j++;
    166             }
    167         }
    168     }
    169
    170     if (sym_idx != -1) {
    171         // …and populate them
    172         for(i = 0; i < numsyms; i++) {
    173             if((syms[i].st_shndx != SHN_UNDEF) &&
    174                 (strlen(str+syms[i].st_name)) &&
    175                 (syms[i].st_value != 0) && (syms[i].st_size != 0)) {
    176                 table->symbols[j].name = strdup(str + syms[i].st_name);//st_name is not checked before using
    177                 table->symbols[j].addr = syms[i].st_value;
    178                 table->symbols[j].size = syms[i].st_size;
    179                 XLOG2(“name: %s, addr: %x, size: %x\n”,
    180                     table->symbols[j].name, table->symbols[j].addr, table->symbols[j].size);
    181                 j++;
    182             }
    183         }
    184     }

    In Android 4.1-4.4, the vulnerability is in system/core/libcorkscrew/symbol_table.c: 

    150     size_t symbol_index = 0;
    151     if (dynsym_idx != -1) {
    152         // …and populate them
    153         for (int i = 0; i < dynnumsyms; i++) {
    154             if (dynsyms[i].st_shndx != SHN_UNDEF) {
    155                 table->symbols[symbol_index].name = strdup(dynstr + dynsyms[i].st_name);//st_name is not checked before using
    156                 table->symbols[symbol_index].start = dynsyms[i].st_value;
    157                 table->symbols[symbol_index].end = dynsyms[i].st_value + dynsyms[i].st_size;
    158                 ALOGV(”  [%d] ‘%s’ 0x%08x-0x%08x (DYNAMIC)”,
    159                         symbol_index, table->symbols[symbol_index].name,
    160                         table->symbols[symbol_index].start, table->symbols[symbol_index].end);
    161                 symbol_index += 1;
    162             }
    163         }
    164     }
    165
    166     if (sym_idx != -1) {
    167         // …and populate them
    168         for (int i = 0; i < numsyms; i++) {
    169             if (syms[i].st_shndx != SHN_UNDEF
    170                     && str[syms[i].st_name]
    171                     && syms[i].st_value
    172                     && syms[i].st_size) {
    173                 table->symbols[symbol_index].name = strdup(str + syms[i].st_name);//st_name is type of uint32_t not be checked
    174                 table->symbols[symbol_index].start = syms[i].st_value;
    175                 table->symbols[symbol_index].end = syms[i].st_value + syms[i].st_size;
    176                 ALOGV(”  [%d] ‘%s’ 0x%08x-0x%08x”,
    177                         symbol_index, table->symbols[symbol_index].name,
    178                         table->symbols[symbol_index].start, table->symbols[symbol_index].end);
    179                 symbol_index += 1;
    180             }
    181}
    182     }

     

    Figure 2. Memory exposure snapshot

    We first reported this vulnerability to Google on April 27 of this year; they acknowledged the issue the following day and assigned it a low severity rating. A fix was included in the Android Open Source Project (AOSP) code on May 15.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    In our recent research, Piercing the HawkEye, we uncovered various ways cybercriminals were able to exploit information they gathered from monitoring victims’ mailboxes in order to steal money from businesses. One of the examples we shared, the “change of supplier” fraud, was one of the most notable, as this type of scheme has been known to earn cybercriminals millions of dollars of stolen money. In this post, we will flesh out the details of this particular scheme, and what makes it a big threat to small businesses and users alike.

    Choosing targets

    Our monitoring of this kind of scheme reveals that it is more targeted and goes far longer than the average attack. Cybercriminals often do the “shotgun approach” when deploying out their attack — sending out their crafted emails to email lists that were probably bought from other cybercriminals. It was quite different in the case we monitored, as the cybercriminals specifically targeted the publicly-available email addresses of small businesses. Our data reveals that these are the “official” company email addresses, usually formatted as info@companyname.com or sales@companyname.com.


    Figure 1. Breakdown of email address types targeted

    We found this to be an interesting strategy because official company email addresses are often positioned to receive possibly unsolicited emails from unknown senders, which creates an advantage for the cybercriminals. If the team managing the email account are not savvy enough to be able to identify socially-engineered emails, they will most likely open those sent by cybercriminals.

    Making contact

    How cybercriminals made initial contact with their targets in this scheme is also quite different from those frequently seen. The cybercriminals did not immediately send their malicious payload, instead they sent actual emails meant to engage with the target.

    hawk1
    Figure 2. Sample of initial email sent by cybercriminals to their target

    We called this technique “The Long Con” in our research since it resembles the real-life example — the attacker approaches the target coming off as a harmless entity, and attempts to achieve the target’s trust. Once that is achieved, the attacker will then send the malicious file (in this case, HawkEye) to the target under the guise of a file related to their ongoing conversation. In the scheme that we monitored, the cybercriminal even used the holidays as part of the lure to raise the urgency of the request.

    holiday
    Figure 3. Sample of email with malicious payload sent by cybercriminals to their target

    Timely interception

    Once the victim is infected with HawkEye, the cybercriminal is then able to monitor the target’s activities and check for information he can leverage to run scams. As we’ve previously shared, the target of the attacker here is to get access to the victim’s company email account. This is done to monitor any ongoing transactions that they can hijack to conduct “change of supplier” fraud.

    What happens is that the cybercriminal looks for ongoing conversations where payment is being discussed, then intercept the conversation to give false account information to the customer. Below is a screenshot of such an email, captured in monitoring of similar cases executed with the use of Predator Pain, HawkEye’s predecessor:

    change
    Figure 4. Sample of email where the attacker diverts the payment to their own account

    In successful attacks, the customer sends the payment to the account owned by the cybercriminal instead of the actual vendor.

    Big payout

    Although this scam looks less sophisticated in a technical sense, since it requires mostly taking advantage of the victim’s information, it doesn’t make it less dangerous for businesses. IC3’s advisory on similar scams last year has revealed that the average loss for this kind of scheme is $55,000, with some victims even losing as much as $800,000. If, for example, the cybercriminal is able to attack multiple targets at any given time, it’s easy to assume that they’ve earned millions from running this kind of scheme.

    For our full analysis of this scheme and the tools cybercriminals used to execute it, check our research paper,
    Piercing the HawkEye: How Nigerian Cybercriminals Used a Simple Keylogger to Prey on SMBs.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Most victims of the Stegoloader Trojan, which has recently been making its rounds in the news, are observed to come from healthcare organizations in North America.  The malware known as TROJ_GATAK has been active since 2012 and uses steganography techniques to hide components in .PNG files.

    Looking at recent victims of the Stegoloader malware, we observed that majority of the infected machines counted for the last three months came from the United States (66.82%), followed by Chile (9.10%), Malaysia (3.32%), Norway (2.09%), and France (1.71%).

    In the same duration, we saw that the most affected organizations came from the healthcare, financial, and manufacturing industries.


    Figure 1. TROJ_GATAK infection count per industry in the last three months

    Notably, all healthcare organizations affected by the malware came from the North American region. Trend Micro researchers are currently looking into how cybercriminals can use this for organized attacks, although evidences are yet to be found.

    There have been recent successful breaches exposing millions of customer files of healthcare organizations like Anthem and Premera Blue Cross. Although yet to be seen in attacks, steganography can potentially be a new technique cybercriminals looking to perform healthcare attacks can use to expose medical records in the future.

    Steganography, a Picture of Spying

    In a previous article on steganography and malware, we noted how the technique of embedding malicious code in image files to evade detection will only become more popular especially among the more industrious malware groups out there.

    The reemergence of TROJ_GATAK and its apparent focus on certain regions and industries show that cybercriminals continually experiment with the creative uses of steganography for spreading threats.

    When we first blogged about the malware in January 2014, the TROJ_GATAK.FCK variant was bundled with key generators for various applications and FAKEAV is its final payload.

    The final payload for the three recent samples of the malware, TROJ_GATAK.SMJV, TROJ_GATAK.SMN, and TROJ_GATAK.SMP are under analysis.

    Note that the routines from variants of past years remain the same. The malware is downloaded from the Internet by users who believe it to be key generators or keygens. Once downloaded, it poses as a legitimate file related to Skype or Google Talk. It eventually downloads the stock photo where a huge part of its routines is embedded. The following are samples of photos used by the malware to embed malicious components:


    Figure 2. Sample images downloaded by TROJ_GATAK

    The malware has anti-Vm and anti-emulation capabilities, allowing it to avoid analysis.

    Past attacks using steganography have been noted to use interesting but seemingly harmful sunset and cat photos to target online bank accounts. Although the technique of using photos quite old, its ability to help cybercriminals and threat actors evade detection remain a strong reason for its continuous use in the wild.

    Here are the SHA1 hashes related to the malware reported above:

    TROJ_GATAK.SMJV

    • bce6a9368f7b90caae295f1a3f4d3b55198be2e2
    • b8db99cf9c646bad027b34a66bb74b8b0bee295a
    • d5d0a9ecf1601e9e50eef6b2ad25c57b56419cd1

    TROJ_GATAK.SMN

    • 2d979739fbf4253c601aed4c92f6872885f73f77
    • 11f25bee63a5493f5364e9578fa8db9ed4c4b9c9

    TROJ_GATAK.SMP

    • 24b2da2aaa97228e0670fc6d5bda037cf127a284
    • 36c00d11e6c51b0174addb5f38e559022bf1a16a
    • 490043a6e903dbd5ddca9c86abba41abeae2edbe

    You can read more about steganography in the following posts:

    Update as of June 29, 2015, 12:32A.M. PDT (UTC-7)

    The following keyloggers (detected as TROJ_DROPPER.GTK) are confirmed related to this attack:

    • CompuApps_SwissKnife_Premium_v3_37_keygen.exe (790528 bytes)
      SHA1: BFE821A91CD7B6E9488D46741630ED91752910CA
    • DigiEffects_Suite_AEX_v3_0_0_CE_64_bit_keygen.exe (865842 bytes)
      SHA1: AF5AE925758B629E594FB8F01EF89D113354A130

    We also added hashes for TROJ_GATAK.SMP above.

     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Earlier we talked about the out-of-band update for Flash Player that was released by Adobe (identified as APSB15-14) that was released to fix CVE-2015-3113. This update raised the Flash Player version to 18.0.0.194.

    Our analysis of the current flaw reveals that the root cause of CVE-2015-3113 is similar to CVE-2015-3043. Both cause a buffer overflow within the Flash Player code. In fact, code targeting the previous exploit can also cause crashes in version 18.0.0.160 (the version immediately before this emergency update).

    Both vulnerabilities can be used to run arbitrary code (i.e., malware) on user systems if they visit a site with a malicious Flash file. Users who visit a malicious or compromised site containing malicious Flash files that still use older, unpatched versions of Flash Player are at risk.

    Vulnerability comparisons

    Both CVE-2015-3113 and CVE-2015-3043 are heap overflow vulnerabilities in the FLV audio parsing flow. They are both in how Flash Player processes audio with the Nellymoser codec; they can be triggered by modifying the FLV file’s audio tag. They both overflow a hardcoded length heap buffer with a length of 0x2000.

    CVE-2015-3043 and CVE-2015-3113 both trigger this bug using sample_count * sample_size > 0x2000, and bypass the length check.

    Old Patch for CVE-2015-3043

    CVE-2015-3043 was originally patched in 17.0.0.169. This was done by limiting the sample count acquired from the FLV audio tag.

    Figure 1. Original patch

    We can see that the sample count is limited to 0x400. We can compute the biggest buffer size needed from this: FLV specifies a size of 4 as the biggest size per sample. The Nellymoser codec has a hardcoded multiple size of 2 (as seen in the code below). Therefore, the biggest buffer needed is 0x400 * 4 *2 = 0x2000.

    Figure 2. Nellymoser doubling

    New Patch in 18.0.0.160

    However, the code underwent significant changes in 18.0.0.160. The code now looks like this:

    Figure 3. New patch

    The GetSampleCount function checks the final buffer size needed. If the final buffer size is larger than 0x2000, it will limit it to 0x2000. However, this ignores the Nellymoser decode function’s hardcoded double operation; this can be used to trigger a heap buffer overflow once again.

    Conclusion

    The analysis above shows that both the previous Flash zero-day and the current incident share the same underlying root cause. In fact, code targeting the previous zero-day will cause 18.0.0.160 to crash.

    This incident highlights how important careful development of patches is, to prevent patched bugs from being re-exploited at a later time. Regression testing must also be a part of software development in order to check that old bugs do not threaten new versions of software.

    Update as of June 24, 2015, 8:08 A.M. (PDT):

    Trend Micro Deep Security and Vulnerability Protection protect user systems from threats that may leverage this vulnerability with the following DPI rule:

    • 1006810 – Adobe Flash Player Heap Buffer Overflow Vulnerability (CVE-2015-3113)

    Update as of June 26, 2015, 3:10 P.M. PDT (UTC-7):

    Trend Micro solutions are available to help protect users against threats that may leverage this vulnerability. Endpoint products detect malware that attempt to exploit this vulnerability as SWF_EXPLOYT.S. The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can be used to detect this threat by its behavior without any engine or pattern updates.

    Hashes of related files:

    • 5f6a2521c6bfd5becfefc3a3db74d0a23d382f0e
    • 5f28787f60c5f8d9f3aa9163975422d1ff55f460
     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  

    Adobe has just released an update to address a vulnerability found in its Flash Player browser plug-in. In its security advisory (APSB15-14), Adobe notes that this vulnerability “is being actively exploited in the wild via limited, targeted attacks. Systems running Internet Explorer for Windows 7 and below, as well as Firefox on Windows XP, are known targets.”

    The critical flaw (CVE-2015-3113) could potentially allow an attacker to take control of the affected system. The affected software versions are the following:

    • Adobe Flash Player 18.0.0.161 and earlier versions for Windows and Mac
    • Adobe Flash Player Extended Support Release version 13.0.0.292 and earlier 13.x versions for Windows and Macintosh
    • Adobe Flash Player 11.2.202.466 and earlier 11.x versions for Linux

    Adobe has stated that the latest version of Flash Player Desktop Runtime for Windows and Mac (v. 18.0.0.194) will address this issue. Users who may be unsure of the version of their Flash software may use this link to check.

    Adobe Flash Player on Google Chrome and Internet Explorer on Windows 8.1 and later should automatically update to the latest version.  Updates, including those for Windows XP, are also available in the Adobe Flash Player Download Center. We would also recommend that users opt for automatic updates whenever possible so that their applications are updated as soon as possible.

    We will update this entry should any additional information be made available.

    Update as of June 24, 2015, 8:12 A.M. (PDT):

    Trend Micro Deep Security and Vulnerability Protection protect user systems from threats that may leverage this vulnerability with the following DPI rule:

    • 1006810 – Adobe Flash Player Heap Buffer Overflow Vulnerability (CVE-2015-3113)

    More information can also be found in our entry, New Adobe Zero-Day Shares Same Root as Older Flaws.

    Update as of June 26, 2015, 3:10 P.M. PDT (UTC-7):

    Trend Micro solutions are available to help protect users against threats that may leverage this vulnerability. Endpoint products detect malware that attempt to exploit this vulnerability as SWF_EXPLOYT.S. The existing Sandbox with Script Analyzer engine, which is part of Trend Micro™ Deep Discovery, can be used to detect this threat by its behavior without any engine or pattern updates.

    Hashes of related files:

    • 5f6a2521c6bfd5becfefc3a3db74d0a23d382f0e
    • 5f28787f60c5f8d9f3aa9163975422d1ff55f460
     
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon  



     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice