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

  • Recent Posts

  • Calendar

    October 2013
    S M T W T F S
    « Sep   Nov »
     12345
    6789101112
    13141516171819
    20212223242526
    2728293031  
  • Email Subscription

  • About Us
    TrendLabs Security Intelligence Blog(breadcrumbs are unavailable)

    Archive for October, 2013




    With Halloween just around the corner, everyone’s thinking about costumes and candy – including cybercriminals. We found several scams taking advantage of the upcoming holiday on popular sites like Facebook, Twitter, and YouTube.

    The scams we saw used free Halloween products as bait. Searching for the phrase “Halloween GET FREE” leads to a suspicious YouTube video:


    Figure 1. Suspicious YouTube video

    The URL advertised on the video’s page leads users to a scam site that asks for your personal information, including your email address.


    Figure 2. Scam site


    Figure 3. Survey scam

    Using similar keywords on Twitter yielded two suspicious accounts. Each account had a Halloween-themed Twitter handle, perhaps to entice users into checking out the accounts.


    Figure 4. Two suspicious Twitter accounts

    Each account advertises free Halloween candy with a corresponding URL to get the said candy. The advertised website leads users to survey scams, rather than candy.

    Facebook also became home to a Halloween-themed survey scam. We spotted a Facebook page that advertises free Halloween candy, like the scam on Twitter. To get the candy, users are supposed to click a link on the page.


    Figure 5. Website advertising free candy

    But much like the other scams, this simply leads to a survey site. It’s interesting to note that users are directed to the page used in the YouTube scam mentioned earlier. To further entice users, the site promises Apple products in exchange for finishing the survey.


    Figure 6. Apple products as “reward” for completed surveys

    It might be tempting to get free stuff online, but users should always be cautious when encountering these types of promos or deals. Cybercriminals are willing to promise anything and everything just to get what they want. When encountering deals that are too good to be true, users should err on the side of caution and assume that they are.

    Trend Micro protects users from this threat by blocking the websites involved in these scams. We are also still on the lookout for related and similar threats, which will also be blocked as appropriate. For more information about the Halloween-related scams and other scary facts about online threats, you may can check out our infographics here and here.

    With additional insights from Maela Angeles

     
    Posted in Bad Sites | Comments Off



    Over the years, the Hadoop development community has steadily added facilities to Hadoop and HBase that improve operational security. These features include Kerberos user authentication, encrypted data transfer between nodes in a cluster, and HDFS file encryption. Trend Micro has contributed several security features that were incorporated into the public Hadoop ecosystem(see our previous post Securing Big Data and Hadoop for details).

    Although these security facilities are important, they are primarily focused on protecting Hadoop data. They do not give IT staff visibility into security events inside their Hadoop clusters. That’s where a good host intrusion detection system comes into the picture.  We have been working on enhancing big data security by applying OSSEC, our open source host intrusion detection system (HIDS), to add security monitoring to Hadoop and HBase systems. In this post, we’ll go over the capabilities of OSSEC.

    OSSEC Overview

    OSSEC provides several important security capabilities including file integrity checking, system log analysis, and alert generation.  OSSEC has an agent/server architecture. Agents handle monitoring logs, files and (on Window systems) registries then sending back relevant logs in encrypted form to the server over UDP. Intrusions on agent systems are usually detectable though file changes or logged security events.

    Figure 1. Securing Hadoop with OSSEC
    (Image originally from http://vichargrave.com/securing-hadoop-with-ossec/)

    On the server, the logs are parsed with decoders and interpreted with rules that generate security alerts. OSSEC comes out of the box with a large number of decoders and rules that support a wide range of systems and events. OSSEC’s coverage can also be expanded by custom log decoders and security alert rules.

    Hadoop File Integrity Checking

    Hadoop and HBase systems rely on numerous configuration files and Java files to work properly.  Unauthorized changes to any of these files can adversely affect a cluster.  This is particularly true of the HDFS namenodes in a Hadoop system and HMaster nodes in a HBase system.  The former controls HDFS operations, while the latter is involved with I/O between HMaster and region servers.

    OSSEC can detect changes to these important Hadoop files. When an OSSEC agent is started, it recursively scans user specified directories and calculating MD5 and SHA1 hash values for each file it encounters. The file names and hashes are stored in a database on the OSSEC server.  The agent repeats this operation at user specified intervals (usually every few hours).  When the server receives a hash value for a given file that is different than the hashes were previously stored, the server will generate a security alert.  The OSSEC server records each security alert in its own alerts log file.

    Normally, the configuration files for Hadoop and HBase systems are located in the /etc directory while the Java files are located in /usr/bin and /usr/sbin. Out of the box, OSSEC is designed to do file integrity checking on all files in these directories.  However, if these files are stored in other directories it is a simple matter to check these directories as well by modifying the agent configuration file, ossec.conf.

    In the second part of this entry, we will discuss how these tools can be used to quickly detect and graphically show potential intrusion into Hadoop/HBase systems.

     
    Posted in Targeted Attacks | Comments Off



    One of the Mac OS X platform’s security features is Gatekeeper, which was first introduced in 2012 and works with Lion,  Mountain Lion, and Mavericks. If a program is downloaded from the Internet and launched, Gatekeeper will first validate its digital signature and choose whether to let it run based on the user’s settings. How has this changed in Mavericks?

    First, a background on how exactly Gatekeeper works. The user can allow only applications from the Mac App Store to be run, allow all applications, or applications from the Mac App Store and those with a valid digital signature, which means it comes from an Apple-certified developer. This last setting is the default in Mountain Lion.

    How does Gatekeeper know which files to check? It is designed to only operate on files that have the extension attribute of quarantine. When a file is downloaded, the downloading application (usually the browser) marks the program’s extension attribute of quarantine. The origin of the program and time when it was downloaded are also kept in the extension attributes:

    Figure 1. Extension attributes of a downloaded archive

    Even if the application is stored in an archive or disk image, the quarantine attribute is copied over from the original archive or image. The attribute also contains a UUID which can be used by OS X to trace it to the source file, and provide information to the user.

    Figure 2. Extracted file’s inherited attributes

    When the user attempts to run an application that does not satisfy Gatekeeper’s settings, it displays an alert as seen below. On previous versions, the alert shows the current Gatekeeper setting; on Mavericks this is not shown.

    Figure 3. New and old warning dialogs

    If the user wants to run an application blocked by Gatekeeper, they have several options. Gatekeeper could, in effect, be turned off by letting it run all applications. A power user may opt to remove the quarantine attribute or use the spctl command to add a new policy in the security assessment policy subsystem.

    Figure 4. Using the “spctl” command to change policies

    Mavericks provides a new option. In the Security & Privacy panel of System Preferences, a new option is provided to the user – they can opt to force-launch the last blocked app. Unlike removing the extension attribute or adding a new assessment policy, this is a more user-friendly way to allow the execution of a single unsigned program.

    Figure 5. New Mavericks dialog box

    The first part of the semicolon-separated quarantine value represents where the file came from. As earlier, Safari downloaded the test program and set the value to 0002. If the user uses the “Open Anyway” option above, this value is modified (the third digit is set to 6). Whatever the previous value is, if the third digit is 6, Gatekeeper will let the application run.

    However, this quarantine attribute can also be kept. If the file is transferred to another Mac (if copied using a compatible file system), this setting will also be honored by this other device.

    Figure 6. Quarantine value of allowed program

    This highlights a way for an attack to bypass Gatekeeper. If one user allows the execution of an unsigned program on their Mac, the file can be spread to other Macs via ways that keep this attribute (such as shared folders and USB flash disks). On these other systems, the program can be launched without any warning messages.

    Figure 7. Gatekeeper allowing an application to run

    To summarize: Mavericks provides users an easier way to create exceptions to Gatekeeper and allow unsigned programs to run. However, this was done in such a way that could put other users at risk. It would have been better for Apple to implement this in such a way to keep the exception from being enforced elsewhere; if I want to put myself at risk I shouldn’t be allowed to put other Macs at risk.

     
    Posted in Vulnerabilities | Comments Off



    After a week since our presentation at HiTB Kuala Lumpur 2013, our findings regarding Automatic Identification System (AIS) security have been picked up by notable media outlets, including ABC News, Softpedia, VesselFinder, Heise, Spiegel, and NetSecurity. It also raised some questions about AIS and, to a certain extent, our research. We want to briefly address some comments we received from Internet users concerning our recent research on AIS, a fundamental technology used by ships and vessel traffic services worldwide.

    AIS was made mandatory in 2002 to overcome the limits of existing technology such as radar. It was supposed to enhance the safety of ship traffic by using modern solutions like GPS and 3G/4G Internet connectivity. Because these devices proved to be useful, class-B devices were later introduced, which were designed for smaller boats such as yachts and sailing boats.

    As a result, crew members were indirectly persuaded to rely more on AIS as opposed to traditional devices, since it comes with a more recent and reliable technology. Or, at least, it should be.

    With our research, we actually showed the opposite. We showed that AIS, which is now deployed to over 400,000 installations globally, is not infallible. It is fundamentally broken and can be abused by attackers. Our first message, then, is that users must not completely trust AIS, as attackers can actively use it for malicious deeds,  such as piracy. In case of an attack, the final user (i.e. the captain), will not be able to distinguish between true and false information reported by the AIS transponder.

    Paradoxically, traditional equipment for collision avoidance like sonars and radars are actually more reliable. For example, think of how difficult it is to tamper with the waves they generate. It should be made mandatory to correlate AIS data with the other devices on board.  I have been told of vessels (both large and small ones like yachts) configured with autopilot running via AIS (for collision avoidance) –  which is very risky to say the least.  Please don’t do that!

    Apart from collision avoidance, AIS is largely used (and nowadays) a de facto standard for search and rescue operations. Search and rescue transponders (SARTs) are self-contained, waterproof transponders intended for emergency.

    Modern SART devices (AIS-SARTs) use AIS position reports to determine the presence and exact location of a man in water. The second type of SART devices (radar-SARTs) uses traditional radar technology. We believe that these modern SART devices can be misused, such as when an attacker (i.e. a pirate) triggers a AIS-SART alert and lure a vessel into moving to a hostile and attacker-controlled location. Note that by law, a vessel is required to join a rescue operation. Currently, for a targeted ship, there is no way to unmask a spoofed SART message because no correlation can be done.

    To conclude, our research disclosed fundamental flaws in the specification of AIS affecting all AIS transponders worldwide. Last August, we personally communicated with the International Maritime Organization (IMO), the  International Association of Marine Aids to Navigation and Lighthouse Authorities (IALA) and the  ITU Radiocommunication Sector (ITU-R) – the three international organizations behind AIS – but only received a response from the latter. According to the MIT Technology Review, “only a formal paper submitted via a government with IMO membership or an organization with consultative status would lead to any response”.

    However, waiting for a “formal submission” from a government/member organisation can be a roadblock in promptly addressing the issues surrounding AIS. This also shows that these organizations may be unaware of the more matured world of vulnerability disclosure that takes place in the security industry.  We believe that they should push for more discussions around AIS security, wherein groups such as Trend Micro can share their research and participate.

    With our work, we hope to raise awareness and lead the involved parties e.g. CERTs, maritime coastguards and authorities, into calling for a more robust and secure AIS standard.

     



    The recent zero-day exploit targeting a use-after-free vulnerability in Internet Explorer highlights one thing: how important it is to use the least-privilege principle in assigning user profiles.

    Imagine if most user accounts are configured to have administrator rights or root access on their endpoint. (This is surprisingly frequent with older OSes, like Windows XP.) A simple social engineering trick can allow a threat actor using this (or a similar) vulnerability to gain the same user rights as the current user. This may include anything from modifying system files, installing a new program, or managing other configuration settings.

    Network administrators must make it incredibly hard for threat actors to ever gain administrative rights.  After all, a user profile that is not allowed to install and run downloaded programs on his system is, conversely, less impacted in our example. This will cause some inconvenience for users and administrators, but the tradeoff in increased security is worthwhile. Because of the risks of threat actors gaining elevated rights, Microsoft recently introduced in Windows 8.1 certain measures to prevent this from happening and allows users better control of privileged account.

    Jim Gogolinksi’s earlier paper titled Suggestions to Help Companies with the Fight Against Targeted Attacks is a solid and much-needed treatise on why enterprises should take the time to review how their network infrastructures are set up. The paper focuses on five avenues: infrastucture, data, incident response teams, threat intelligence, and performing penetration testing.

    According to Gogolinski, a secure infrastructure is largely dependent on three factors: proper and logical segmentation of the network, the ability to log and analyze logs, and secure configuration of user profiles and workstations. The inability to lay the groundwork for security can be fatal to an enterprise. Our latest enterprise primer titled The Enterprise Fights Back: Securing Your Network Infrastructure Against Targeted Attacks talks about the security repercussions in relation to targeted attacks of not finding the time and resources towards this endeavor.

     
    Posted in Bad Sites | Comments Off


     

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