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


  • Recent Posts

  • Calendar

    April 2015
    S M T W T F S
    « Mar    
     1234
    567891011
    12131415161718
    19202122232425
    2627282930  
  • Email Subscription

  • About Us

    Security researchers Luca Carettoni and Mauro Gentile recently found during their research that even though Adobe has fixed an old vulnerability found in 2011 (CVE-2011-2461), its side effects still linger around the Internet. Your favorite websites might still be affected by this bug.

    They have shared great details in their blog post. Let’s take a quick look at the issue and how the vulnerability impacts both site owner and end users.

    What’s the issue?

    The vulnerability was in the Adobe Flex SDK, which is used to create Internet applications based on Flash (it is now owned by the Apache Software Foundation). Users who don’t typically read the fine print or the gory details probably thought patching the Flex SDK put an end to the issue. However, that was just part of it. Other departments aside from IT had to act on it as well. Application/website developers also had to review the Flash files they were hosting. Let’s take a closer look at the Adobe advisory:

    An important vulnerability has been identified in the Adobe Flex SDK … This vulnerability could lead to cross-site scripting issues in Flex applications. Adobe recommends … update their software, verify whether any SWF files in their applications are vulnerable, and update any vulnerable SWF files using the instructions and tools provided as outlined in the tech note linked in the “Solutions” section below.

    Adobe clearly recommends that users update their Flex SDK, and check any SWF in their applications that may be vulnerable and fix them too. The issue is that an unpatched Flex SDK would produce Flash files that are vulnerable, and these vulnerable Flash files could be used to launch a Same-Origin Request Forgery attack on another site.

    In simpler terms, a user could be forced to visit a malicious site, which would eventually load the vulnerable Flash file from a good site and steal the user’s cookies and data for that good site.

    How can an attacker take advantage of this vulnerability?

    If an attacker can convince you to click on a link to his malicious site, they can force you to load a vulnerable Flash file from the victim site (the site you trust, but is hosting a vulnerable Flash file) after loading a Flash object from his malicious site. Due to a bad check for origin rule this (vulnerable) Flash allows for cross domain “interaction” with the malicious site.

    Carettoni and Gentile noted: “Practically speaking, it is possible to force the affected Flash movies to perform same-origin requests and return the responses back to the attacker. Since HTTP requests contain cookies and are issued from the victim’s domain, HTTP responses may contain private information including anti-CSRF tokens and user’s data.”

    How am I affected by this vulnerability?

    You can be affected either as a web site owner and an end user. As a website owner, your users can be exploited. Their session cookies and anti-CSRF tokens can be stolen, and as a site owner, you will be liable for the consequences. As an end user, you suffer from the same issues and someone can impersonate you and carry out transactions on your behalf.

    Note that the version of Flash Player you are using doesn’t matter. It’s all about the Flash file itself being vulnerable.

    What are the recommended actions?

    As a website administrator you may opt to scan your web servers for Flash files using the ParrotNG tool. If you do have vulnerable files, you have two options:

    • Recompile your Flash files using a patched version of Adobe Flex.
    • If you don’t wish to recompile these files, use the Adobe-provided tool to patch the vulnerable SWF files.

    Adobe’s tool can also be used as an alternative to the ParrotNG one.

    There is no action for end users that is specific to this problem. In general, they should use the same techniques used to avoid becoming a victim of malicious sites in general – be careful about what links you click. Be watchful of the links you receive via social media and chat, and consider disabling Flash altogether.

    Trend Micro Deep Security and Vulnerability Protection customers are protected by the following rule.

    • 1004866  – Flash Authoring Flex SWF Files XSS (UPDATE: As of  Apr 1, 2015, 5:40 AM PST, this has been updated to 1004866 – Adobe Flex SDK Cross Site Scripting Vulnerability (CVE-2011-2461))

     

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

    The security of an enterprise is not only dependent on the organization itself, but also on the security of their IT supply chain and contractors. These represent potential weak points into the security of any organization.

    Third-party contractors and suppliers have been used to compromise larger organizations. Target’s breach began with a breach of a contractor involved in heating, ventilation, and air conditioning (HVAC) solutions.  A 2011 hack on Lockheed Martin was blamed in part on information stolen from a hack on RSA that compromised SecureID tokens. HAVEX has been tied to attacks on Industrial Control Systems (ICS).

    These reported cases are only the tip of the iceberg. Many supply chain vendors have insufficient personnel or resources to dedicate to security; they may have no good ways to determine if they have been the victims of a targeted attack.

    Twists and Turns

    The threat actors who would target parts of the IT supply chain use various “twists and turns” as part of their Tactics, Techniques and Procedures (TTP). These can include:

    • Compromising source code
      • If hackers can access and modify the source code of a vendor, they can easily insert a backdoor into the source code. This would provide easy access to any customers of that vendor via persistent backdoors. This can be done via compromising servers holding source code, systems used for research and development, or acquiring credentials to source control services in use. The HAVEX malware family (known externally as Dragonfly/Energetic Bear) is known to have used Trojanized versions of ICS software.
      • While such an attack would be of immense value, multiple systems and accounts would need to be compromised. For example, credentials for source code control systems should be separate from other credentials (like email). Alternately, the servers themselves may be attacked (whether these are located on premise or in the cloud). This kind of access would require a fairly wide-ranging breach of the target organization.
    • Compromising firmware
      • If attackers are able to access and modify the binary code of systems provided by a vendor, an attacker may choose to modify the code to add backdoors, which can then be pushed out via existing autoupdate mechanisms. Customers will receive this malicious code when the update is pushed out to their systems. The Equation Group is believed to have used malicious hard drive firmware in their attacks.
      • The challenges to compromising firmware would be similar to compromising source code, with an additional problem to consider: technical information would be necessary to actually create firmware that would actually run on target devices. This would have to be acquired within the organization itself, or by analysis of existing publicly available hardware.
    • Compromising websites and internal portals
      • Attackers can also attempt to compromise websites and internal portals used by a vendor to communicate with their customers. This can be used in a watering hole attack against the vendor’s customers. HAVEX also used this tactic to target organizations using specialized ICS/SCADA equipment.
      • For this attack to be successful, the attacker must be able to gather some information about the normal browsing patterns of both the vendor and the customer. In addition, to actually compromise any web servers, credentials for webmasters or server administrators need to be obtained as well. This poses some burdens on an attacker to be familiar with the vendor’s network, but not as difficult as the two preceding scenarios.
    • Spear phishing from trusted vendor email accounts
      • An attacker that controls vendor systems and credentials can easily send emails to clients that appears to be legitimate. High-level personnel can be easily victimized in this manner.
    • Direct network access from trusted vendors
      • A vendor’s access to their client’s network can also be abused. For example, if a vendor has access to a client network via VPN, an attack at the vendor could compromise the credentials needed to access the VPN. Similarly, secure tunnels could be accessed via compromised credentials.

    An attacker would enter the IT supply chain as he would any other organization. We’d earlier discussed how organizations become the victim of targeted attacks. Email is still a favored infection vector, with both malicious attachments and links to sites used to lure in users. These messages are made to appear to come from other organizations (which are preferably relevant to the target).

    Potential Solutions

    Some might say that the security of vendors is not part of the responsibilities of a network administrator, who already has to worry about their organization’s security. While this may be true, the security of vendors has a direct impact on an organization’s security. Here are some guidelines that can be used:

    • Protect your own network
      • Does your own organization already have sufficient defenses against targeted attacks? Are sensors and an incident response team in place to mitigate any attacks? Are security solutions in place on both endpoints and gateways? Before an organization can even consider discussing security issues with vendors, they must be sure that their own house is in order.
    • Coordinate security policies
      • As much as possible, vendors and clients should have reasonably similar security policies. Inconsistent policies can create security weaknesses in one organization that can be used for lateral movements to the other.
    • Code, binary, and firmware auditing
      • Patching and updating procedures should be examined to ensure that proper auditing is performed before new software/hardware is introduced into an organization. Source code audits can find hidden backdoors, hardcoded credentials, and other potential vulnerabilities. Binary audits can check file hashes to ensure that only unmodified versions of software are installed.
    • Coordinate security teams
      • Security resources of vendors and clients should work together to protect their overlapping networks. Sharing of threat intelligence and regular meetings can ensure that any potential threats are dealt with adequately and as quickly as possible.

    We’ve earlier discussed how companies need to focus on protecting what is most important to them – their core data – and do so in a well-thought out manner. An aspect of data protection that can be overlooked is how others access your data. If an organization fails to consider that, then their data protection is only as good as the weakest link. A complete security and privacy risk assessment must consider the security of an organization’s third-party IT providers.

    Aside from the above, vendors should undertake steps to protect their own systems. Products such as the InterScan™ Messaging Security software and virtual appliance, Hosted Email Security, and ScanMail™ for Microsoft Exchange™ are all designed with the technology designed to help detect threats that enter via email. Combined with Web reputation and advanced sandboxes to inspect attachments, these tools are able to help detect various threats that attempt to enter an organization’s network. Solutions such as Deep Discovery can also be used as part of a custom defense strategy to help organizations discover and mitigate attacks as well.

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

    Recently, we’ve come across an interesting spam campaign aimed at French users. The campaign itself uses a well-crafted lure that is likely to catch the attention of its would-be victims. In addition, the malware used – the GootKit backdoor – contains several unusual technical characteristics. Both of these highlight how this campaign was quite well thought-out on the part of the attackers.

    Spam: Using the French Ministry of Justice

    This campaign starts with email in French that uses varying subject lines:

    • Copy du jugement (translated to: “Copy of judgment”)
    • L’information sur la comptabilité (translated to: “The information on accounting”)
    • Paiement (translated to: “Payment”)
    • Urgent 

    The email’s text reads as follows:

    Selon la décision du tribunal n° 184, afin de recouvrir les sommes dues auprès du débiteur, et en vertu des procédures d’exécution n° 135-01, la saisie de votre propriété a été prononcée.

    Vous pouvez obtenir une copie de cette décision auprès du greffe du tribunal.

    Une copie du jugement se trouve dans le fichier ci-joint.

    This content can be roughly translated as:

    According to the court decision No. 184, to cover the amounts due from the debtor, and under enforcement proceedings No. 135-01, seizure of your property has been pronounced.

    You can obtain a copy of the decision to the court registry.

    A copy of the judgment is in the attached file.

    The email contains a Microsoft Word document (alternately named copy du jugement.doc or paiment.doc) which the user is asked to open. This file has the SHA1 hash of 9b7cf1b6255a7dc26b346fdcccbfc4755db020bf.

    Once opened, this document downloads and opens a decoy image from the file hosting site savepic.su (which is displayed below). It also contains a macro which downloads and runs a backdoor.

    Figure 1. Decoy image shown when opening the Microsoft Office document

    The image is a reproduction of a letter from the French Ministry of Justice. It is a letter typically sent to individuals stating that the Ministry cannot assist with cases that are already before courts. This letter could have been obtained from a compromised system or email inbox, or by an accomplice working on behalf of the attackers. (References to the individual who originally received this letter were already blurred when downloaded.)

    It’s worth noting that the text used in the email contained no typos or grammar mistakes. This is unusual, as spammed messaged frequently included such mistakes (whatever language they use). This suggests that a French speaker, or someone well-versed in French was responsible for writing the above text. Combined with the authentic decoy image, it’s not difficult to see how a French user would not instantly realize he had been a victim of spam.

    (more…)

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

    Yahoo recently rolled out a new way for users to access their services without entering a password. Their new system uses a cellphone to authenticate the user. Instead of entering a password, the user receives a verification code via text message on their phone. (The user would have provided their phone number to Yahoo when setting this option up.) Once the user receives this code, they enter it on the Yahoo login page and voilà!, they’re logged in.

    So what’s wrong with this? Is this a wonderful advance in the field of authentication?

    The intentions are good. It is encouraging that online services are putting thought and effort into making their users’ lives easier and more secure. However, a cold analysis of this method finds that it’s not a particularly secure solution.

    Fundamentally, it’s still a single-factor method of authentication. This means that it does not offer any additional security by itself. If the single factor is compromised, you still lose control of your account. In the same way that losing/forgetting your password prevents you from accessing your email, losing or forgetting your phone does the same.

    However, that’s something we already knew. The real question is: is this method more secure than ordinary passwords?

    What this method means is that an attacker who has control of the user’s phone has complete access to his Yahoo account as well. However, some people (like me) forget phones more than they forget passwords. In that case, someone who has my phone would also be able to access my Yahoo account if I left an indication what my Yahoo user name is on the phone. (While the email can be easily accessed from an app, other Yahoo services may be best used via a browser.)

    More than that, text messages themselves can also be intercepted by mobile malware. Sometimes it’s for blackmail and extortion. Other times, it’s to steal online banking transaction codes. Other times, it’s to hide premium subscriptions. It’s not out of the question that a Yahoo user’s account credentials could be stolen in this manner.

    This authentication process can also be used (and abused) for various purposes, for example, if your phone can’t be found but is nearby – if it’s tied to a Yahoo account this way, it can be used as an impromptu phone locator. Similarly, the authentication process can be used to spam or annoy someone who’s tied their phone to their Yahoo account.

    Overall, is it more convenient to use this method? Sure. Is it more secure? Not at all. If you’re going to do this at all, make sure you never forget your phone anywhere – or at least leave it behind less often than you forget your password. Don’t forget to use any security features your phone has (such as screen lock, etcetera) to keep it as secure as possible if it is lost.

    If you do want to secure your Yahoo account, there’s a better way to do so. Yahoo has supported two-step verification since 2011. This also uses a code sent to the phone to log the user in, but this is in addition to the user’s existing password.

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

    The URSNIF malware family is primarily known for being a data-stealing  malware, but it’s also known for acquiring a wide variety of behavior. Known URSNIF variants include backdoors (BKDR_URSNIF.SM), spyware (TSPY_URSNIF.YNJ), and file infectors (PE_URSNIF.A-O).

    December 2014: Rise in URSNIF infections brought about by file infection routines

    In December 2014 we discussed a rise in URSNIF infections, primarily in North America,  which were due to the addition of file infection to URSNIF’s routines.

    The virus inserts the host file into its resource section, instead carrying out typical file infection routines like patching host files (via inserting malicious code). These variants targeted the following files:

    February 2015: Another URSNIF outbreak seen

    The February outbreak showed that the malware widened its scope and improved its stealth mechanism. The URSNIF variants are detected as PE_URSNIF.B-O and PE_URSNIF.B.

    It uses strings already found in legitimate system files for its properties such as its file name, folder name, and registry entries. This is done to hide itself alongside other legitimate system files. The file names it uses are a combination of legitimate system file names; for example, the malware will name itself cmdlnsta.exe, a combination of legitimate file names cmdl32.exe and rwinsta.exe. URSNIF was known to exhibit this behavior before it became a file infector.

    It also injects its code separately into each target process, perhaps to avoid memory scanners. We also noted that the hardcoded strings in this URSNIF wave are the same ones found in the December variants.

    March 2015: URSNIF variants seen infecting more file types

    URSNIF variants seen this month (PE_URSNIF.E-O and PE_URSNIF.E) have further widened their scope. This new wave now infects more file types, including Microsoft Office documents, spreadsheets, and presentation files. It uses strings from system files (as the earlier variants did), and uses existing folder names to name the dropped files in order to trick fool users into running them. This technique was not particularly effective, as it did not hide the original folder.

    The table below compares the recent URSNIF variants:

    Pre-file infector December 2014 February 2015 March 2015
    Infected files None *.PDT, *.MSI, *SETUP*.EXE *.PDF, *.MSI, *.EXE *.PDF, *.MSI, *.EXE, *.PPT, *.PPTX, *.DOC, *.DOCX, *.XLS, *.XLSX
    Name used in removable drive propagation None Temp.exe Temp.exe {Folder Name}.exe
    Use random strings for file names? Yes No Yes Yes
    Inject routines separately? No No Yes No
    Polymorphic? No Yes Yes Yes

    URSNIF’s known hooking functions

    URSNIF is traditionally also known for hooking various executable files in order to monitor browsers. It hooks WS2_32.DLL and KERNEL32.DLL or CHROME.DLL to monitor Google Chrome, NSS3.DLL and NSPR4.DLL to monitor Mozilla Firefox, and WININET.DLL to monitor Internet Explorer. It also monitors other browsers like Opera and Safari.

    Recent URSNIF variants have significantly modified the exact system APIs that it’s been hooking for years. Hooking these APIs allows the malware to perform a wide variety of information theft, such as taking screenshots, by intercepting the data contained in various normal commands. Together with the hooked APIs, this allows for powerful information theft capabilities. The list of hooked APIs is below.

    2012-2013 2013-2014 2014-2015
    InternetReadFile InternetReadFile HttpOpenRequestA
    InternetReadFileExA InternetReadFileExA HttpOpenRequestW
    InternetReadFileExW InternetReadFileExW HttpSendRequestA
    HttpSendRequestA HttpSendRequestA HttpSendRequestW
    HttpSendRequestW HttpSendRequestW HttpQueryInfoA
    HttpOpenRequestA HttpQueryInfoA HttpQueryInfoW
    HttpOpenRequestW HttpQueryInfoW InternetReadFile
    InternetConnectA HttpAddRequestHeadersA InternetReadFileExA
    InternetConnectW HttpAddRequestHeadersW InternetReadFileExW
    InternetQueryDataAvailable InternetConnectA InternetQueryDataAvailable
    InternetConnectW PR_Read
    InternetQueryDataAvailable PR_Write
    PR_Read PR_Close
    PR_Write PR_Poll
    PR_Close PR_Available
    WSARecv LoadLibraryA
    WSASend LoadLibraryW
    Closesocket LoadLibraryExA
    LoadLibraryExW LoadLibraryExW
    ssl_write
    ssl_read
    ssl_close

    URSNIF has been constantly evolving in recent months, showing multiple faces of itself and displaying a wide variety of behavior. It shows no clear signs of dying down, which means that the malware will continue to pose risks to users across various segments.

     
    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