Tweet

About two weeks ago, Oracle published a blog post describing – and promising – to improve the security of Java. Since then, I’ve been asked a few times: what exactly did they say, and what does it mean for end users?

First, Oracle talked about how they’re now handling security patches. They pointed out how recent patches had, in fact, solved more security holes than previous patches. What’s more important to take away is that Java’s update schedule has been brought in line with other Oracle products: it will receive patches every three months, starting in October of this year. This should help get potential problems fixed more quickly before they are exploited by attackers. Of course, Oracle will continue to deliver out-of-band updates as needed for critical vulnerabilities.

Java has also been brought under Oracle’s Software Security Assurance policies. As part of this, for example, Oracle will now use automated security testing tools to prevent regressions and new issues from showing up when a bug is fixed. This is welcome news, as it means that bugs will be patched more quickly in the future.

Next, they discussed how they had been working to improve the security of Java as it is used in browsers. More important than the discussion of what was done in the past is what Oracle will implement soon: future Java versions will no longer allow unsigned or self-signed apps to run. It’s not clear when this will happen, but if it does, it will be a significant increase in Java security. It means that attackers will have to acquire or compromise a code signing key to get their Java applets to run: while this will not stop a truly determined attacker, less targeted attacks will fail.  In addition, Oracle is also working to improve how Java processes revoked signing signatures, so that this process can be turned on by default at a later time.

For enterprise users, there’s good news too. Future versions will add support for security policies enforced by Windows itself, so that system administrators can set network-wide policies that can restrict or relax Java usage without having to set these per system. In addition, a new type of Java distribution – Server JRE – is being created specifically for servers running Java apps. This distribution will have several libraries removed to reduce the potential attack surfaces.

All of these changes are for the better – Oracle is acknowledging that there have been challenges when it comes to Java security in the past, and they’re working hard to improve it moving forward. We appreciate these efforts and hope that they succeed in reducing the threat from Java exploits, which is completely in line with Trend Micro’s goal of creating a world safe for exchanging digital information.

In the meantime, we strongly urge that users do their part to keep their Java installs safe: update to the latest version of Java. We earlier discussed how to secure Java in the blog post How to Use Java – If You Must.

Tweet

At the end of May, two Google security engineers announced Mountain View’s new policy regarding zero-day bugs and disclosure. They strongly suggested that information about zero-day exploits currently in the wild should be released no more than seven days after the vendor has been notified. Ideally, the notification or patch should come from the vendor, but they also indicated that researchers should release the details themselves if the vendor was not forthcoming.

This is a pretty aggressive goal. Microsoft, for example, does not set public deadlines for critical patches: a balance needs to be found between quality and speed. Balancing the two is not that easy. On one hand, an actively exploited vulnerability will be used by malware writers aware of the vendor’s vulnerability. On the other hand, a quick patch could have negative side effects and could cripple the application or the entire system.

Almost every security vendor has false positives that result in negative side effects. We have lots of safeguards in place – such as checking against whitelists – but Murphy’s law applies. Our industry has crippled the computers of users. What more an operating system vendor – they need to be extra careful in patching. They need to conduct proper quality assurance, as the patch will affect millions of computers.

In my opinion, disclosure after 7 days is reasonable and OK, but expecting a patch in this time frame is unreasonable. Let’s see how Google itself will manage. Currently, there’s a Google Android Trojan spreading which is able to hide itself from the “Device Administrator”, which renders it invisible from security programs and clean up attempts. This was possible because of a security flaw in Android. Will Google be able to fix this within 7 days? Let’s see…

The bigger debate is not just about how long it should take to report and fix vulnerabilities. It’s about how vulnerabilities should be reported in the first place. If you believe a recent media report, the US government is now the biggest purchaser of malware. How do we ensure that the affected vendors are informed, that these are not used for offensive uses like Stuxnet? How do we ensure that these same vulnerabilities don’t end up in the hands of the underground, which will use these threats widely?

What needs to take place is a bigger discussion around how discovered vulnerabilities are dealt with at all. These should be between all those involved in this field – developers, governments, and researchers – to determine how we can deal with security vulnerabilities in the future.

To watch the video of me talking about this topic, click the thumbnail above.

Tweet

Online banking threats have been prevalent for many years, but recently they seem to be determined to expand beyond their usual targets. In the past few weeks and months, we’ve seen various attacks target Korean banks using various techniques.

The latest attack we’ve found uses a Trojan that redirects users of various Korean banks to malicious phishing sites. It does this by modifying the system’s HOSTS file and redirecting users to an IP address located in Japan. We detect the Trojan responsible for this attack as TSPY_QHOST.QFB, while the related batch file (which actually modifies the HOSTS file) is detected as BAT_QHOST.QFB. (This technique has been used for many years by other banking threats.)

The malicious site looks like this:

Figure 1. Page of malicious site

The malicious site has an additional window in the middle.

Figure 2. Additional window of malicious site

The image roughly translates to:

• Did you install the certificate of authentication in your PC (computer)?
• Are you using the security card for identification?

• You can safely use the Internet banking of WOORI-Bank if you obtain this security certificate.
• You will move to the security verification page, if you click the following button.
• Start Date: August – September Planned.

Unsuspecting users might believe they do need to perform this verification and thus click the button. Initially, the user will be directed to the following page that will ask for their name and Korean resident registration number:

Figure 3. Information is asked

The following screen asks for more information such as their cell phone number, account number, account password, user ID, user password, and certificate password:

Figure 4. Additional information is asked

These phishing sites abuse the trust that users have in their banks to get financial and personal information from users. They are made to think that they are entering their information in the bank’s real online banking site, when in fact they are not. Instead, the information ends up in the hands of the attackers who created this malware. (The phishing site and associated malware are all detected by Trend Micro products.)

While these may represent an evolution in terms of the chosen targets, the malware used is still not as sophisticated as what is typically used elsewhere. In addition, banking threats using various methods to steal information from Korean users have been seen multiple times recently.

Banking threats in general were described in our crimeware paper last year. However, it is likely that we will see these more sophisticated threats hit these banks in the future.

Tweet

We have been seeing apps that exploit vulnerabilities in Android, with most of them attempting to gain higher privileges on user devices. In recent days, a stronger and a far more advanced Android malware named ANDROIDOS_OBAD has come into play. What seems to be a product from the same malware authors behind ANDROIDOS_JIFAKE, ANDROIDOS_OBAD is found to be equipped with ability to avoid being uninstalled from devices and triggers more malicious code.

Newer and more improved stealth routines 

This new malware family has overall stealth and anti-reverse methods for both normal users and security researchers. When installed, it asks for root privileges and activates the device administrator. Because of ANDROIDOS_OBAD’s gaining root privilege, the malware takes complete control of the device and may allow an attacker to utilize this fully.

If the user does not activate as instructed, the malware displays frequent pop-up messages when the device restarts. Additionally, if users press the back button, pop-ups appear once again. If the if home button pressed, the pop-ups appear any time later.

Here, users will finally have the chance to uninstall it, but if device administrator is activated, the malware will instead run fully in stealth mode.

Figure 1. Activating device administrator allows the malware to run in stealth mode

Still, you can carefully distinguish the malicious app from the mixed Android system apps under Apps Management. However, you won’t be able to uninstall it because it’s a device admin app.

Figure 2. Malware’s app information

The “anti-uninstall” tricks also work on Android’s vulnerability by hiding itself from Device Administrator management view:

Figure 3. The malware hides itself from the Device Administrator management view

From a security researcher’s perspective, it seems that the malware author tested ANDROIDOS_OBAD against traditional analyze tools.

The Android OS recognizes AndroidManifest.xml but major decoding tools fail to precisely parse it. Most sandboxes encounter problems loading this malware because ANDROIDOS_OBAD has the ability to initially detect them.

A new obfuscation technique

The app’s Dalvik code is obfuscated in a new way – almost every Class file has a unique, embedded obfuscated decryption routine. This means that every string and function called must be first decrypted while the app runs. Some parts of the code – like string constants – are encrypted multiple times. Current decompilers have problems to illustrate the execution order correctly.

An example of unordered execution code snippet from one decrypt routine:

Figure 4. Code sample

The upper IF statement intersects with WHILE loop. The IF condition cannot be true, so consequent code will never be executed, but WHILE loop will loop back to the middle of IF consequent code (p6 = (p6 + 1); ). The correct order is append last two lines of IF consequent  code to the WHILE loop, and disable IF statement.

Once we were able to decrypt the code and analyze it, we found that the malware is capable of the following behavior:

• Hiding the launcher, and run as a background service with the highest priority.
• Automatically try to open Wi-Fi connections and connect to remote server (http://www.{BLOCKED}ofox.com/load.php).
• Collect user’s contacts, call log, SMS inbox and installed apps.
• Download, install and uninstall apps (with root privileges, this can be done silently).
• Distributing malware to other phones via Bluetooth

ANDROIDOS_OBAD vs. ANDROIDOS_JIFAKE

ANDROIDOS_OBAD shares similar features with that of its predecessor ANDROIDOS_JIFAKE. The latter is a fake app installer that tricks user into installing and executing them, after which it will silently register as a service connecting to remote servers as it waits for commands. The remote server can then trigger sending premium text messages and do the same “anti-uninstall” tricks.

The anti-uninstall trick is exploited through Android’s Device Administration feature. If one app is installed and enabled as the device admin application, it will be entrusted with more power to constrain user’s device, including enforcing security policy, lock or wipe user’s device. Under this level, app cannot be easily uninstalled, which contributes much for the anti-uninstall tricks.

To uninstall the device application app, users need to deactivate under Settings->Security->Device Administrators. But an unpublished Android vulnerability can be exploited to hide the deactivation option. Users are then forced to enable the malware as device admin application with no way to disable it.

Trend Micro Mobile Security already detects this malware family upon installation.

Tweet

Last month, the hacker collective Anonymous announced their intention to launch cyber attacks against the petroleum industry (under the code name #OpPetrol) that is expected to last up to June 20.

Their claimed reason for this attack is primarily due to petroleum being sold with the US dollar instead of currency of the country where petroleum originates. However, some chatter indicates there was a desire to launch new attacks due to both #OpIsrael and #OpUSA being regarded as ineffective.

Users should note that June 20 is only the day that most attacks are expected to occur and/or be made public. Similar to last month’s #OpUSA, they have begun mobilizing prior that date. Since the announcement of this operation, targets have been hit, credentials have been stolen, and the list of targets is already growing.

It is also not uncommon for these activities to be used as a distraction to mask other attacks. Based on the collateral damage recorded from previous operations and data leaks outside publicized attack dates, their targeting and timing aren’t always precise either.

An announced operation like this is a good opportunity for all current existing and potential targets to exercise the necessary steps to protect themselves. Everyone is a target eventually; there will always be vulnerabilities to be exploited for cause or profit.

If your organization or country you defend is a potential target in this operation, you should consider doing the following steps (see below) and possibly more. If you’re in anyway connected to the targeted industries or located in one of the potential target countries, we advise that you consider going through these steps anyway. However, if you are not affected or linked to the expected targets, you may use these steps as proactive measures against attacks like #OpPetrol.

Before June 20:

• Ensure all IT systems (OSs, applications, websites, etc.) are updated.
• Ensure IT security systems are current, have as wide a view as they can, and can inspect deeply. Can they detect and prevent phases of attack plan and can they be integrated into part of a kill-chain? Can they observe indicators over the network, on disk, and in memory?
• Ensure relevant third party vendors are aware and accessible.
• Probe any anomalous network and system behavior and examine it. Reconnaissance phases of the attack are already in play. Opportunities for exploit are being logged and credentials are already being stolen. Solutions such as Trend Micro Deep Discovery can help you examine dubious network activities.
• Remind your users to be particularly careful and watch out for phishing and spear-phishing emails.
• Plan or review your incident response procedures with all necessary parties (not only IT groups). Explore how the planned response differs among DDoS, defacement, and disclosure.
• Have IT Security, Attorneys, and External Communications departments prepare or review public statements in the event your organization is affected. Ask the question of “how your statements and response might differ if it wasn’t a hacktivist group, but a criminal, nation state, insider, or terrorist?”
• Monitor the many Anonymous sources for any changes in targeting, tools, or motives, lists of accomplishments, or data dumps.

On June 20:

• Note that attackers may attack across different time zones, so it can last longer than the 24 hours in your time zone.
• Continue to monitor the Anonymous’ sources for any changes in targeting, tools, motives, lists of accomplishments, or data dumps.
• Exercise a high level of awareness of your IT and IT Security systems and their logs; continue to apply questioning curiosity to anything interesting.
• If you think your organization is affected, assume that you are affected by DDoS, defacement, and disclosure – and not just one of them.

After June 20:

• Continue to monitor Anonymous’ sources for any lists of accomplishments or data dumps.
• If you’ve made it into Anonymous’ news, you’ll be remediating and designing against future occurrence.
• If you didn’t make it in Anonymous’ news, review for any sign of breach, compromise, or excessive probing.
• Remain vigilant, especially if you’re in the target list. The attacks may not be over.

Similar to how DDoS, defacement, and disclosure tactics can distract and mask each other, so can threat actors. A hacktivist group’s activity can mask or distract criminal, nation state, insider, or even terrorist activity.

Announced operations like these with their relative open disclosure of tactics, tools, and procedures are golden opportunities for evaluation and improvement of countermeasures in real world scenarios. Taking advantage of these opportunities helps train people, process, and technology to recognize signals of a targeted attack regardless whether it is publicly disclosed or covert.

For more information on how targeted attacks work and how organizations can better protect themselves from such threats, you may refer to some of our previous entries here.