With Java going through another embarrassing zero-day vulnerability recently, it has become a common bit of advice for users to “uninstall Java”.

In general, this is sound advice. If possible, users should uninstall Java if they don’t need it. Unfortunately, for many users this simply isn’t an option. Many enterprises have custom apps built on the Java platform. Consumers may also need access to Java for banking sites (many of which are Java-based) or software (Minecraft needs Java to run.)

So, how can you use Java safely? First, the Java threat largely comes from malicious applets that come from malicious websites. If you have Java installed because an application needs it, then you can disable Java in your browser(s) without affecting your user experience.

It used to be that you would have to do this on a browser-by-browser basis, but that isn’t the case anymore. In the current version of Java, you can do this in the Java Control Panel. Instructions on how to access this can be found here. Applets in webpages will no longer work, but Java apps will continue to run without any problems.

What if you need Java for a website, like an internal company site or your bank?

Read the rest of this entry »

Last month, a Georgia Tech study found that mobile browsers frequently left even expert users insufficient information to judge if a site was potentially dangerous, because of user interface limitations.

The item that is most problematic is how SSL information is displayed. Compared to desktops, mobile browsers have far more limited ways to show if a site is using SSL. While the basic padlock is displayed if SSL is being used, other more advanced features may not be immediately apparent. For example, desktop browsers highlight the organization for extended-validation certificates quite prominently; for mobile browsers this is not always immediately apparent.

The reason for this is simple: user interface limitations. The space on a mobile device is much more limited compared to any conventional PC; in addition the interfaces of mobile UIs tend to be explicitly designed with simplicity in mind. This may limit the amount of information the user is shown in the browser that would be able to help them judge if a site is real or not.

This may be why studies suggest that mobile users are more likely to fall victim to phishing attacks than desktop users. More than the technical reasons, however, user attitudes may be responsible.

It’s very easy for users to consider mobile devices as simple devices that “just work” and don’t pose a security risk. Nothing could be further from the truth. Today’s mobile devices are full-fledged computers, with all the capabilities that implies. A mobile browser is as capable of running advanced scripts as a desktop browser. As our Product Manager Warren Tsai noted at an APEC workshop in April, “The mobile browser is super capable and the performance is as powerful as the desktop.”

Read the rest of this entry »

Developers at the xda developers forum have discovered a vulnerability in Android devices using the Exynos family of System-on-Chip (SoC) processors. Our researchers have independently verified the vulnerability and as a result, we have released the relevant protection for Trend Micro Mobile Security users.

The vulnerability allows any installed app to access the entirety of the phone’s memory. An attacker could trivially use this vulnerability to gain root access, thereby gaining complete control over the device. Potentially, this is as serious as remote code execution vulnerability on Windows.

The underlying cause is because Samsung’s memory device driver has no protection, making it open to all installed app with default privilege. Thus, all processes can read and write the whole system memory that may compromise the device.

Currently, the following devices and their variants are known to be vulnerable to this problem:

• Samsung Galaxy Note
• Samsung Galaxy Note 2
• Samsung Galaxy Note 10.1
• Samsung Galaxy S2
• Samsung Galaxy S3
• Samsung Galaxy Tab Plus

However, it is possible that any device running an Exynos SoC and running newer versions of Android (Ice Cream Sandwich or later) could be at risk. (Earlier versions of Android did not have the kernel device which was called in newer versions, so they are not at risk from this issue.)

As a practical matter, there are no good steps users can take to mitigate this threat. (It is possible to download apps that disable access to system memory, but this also breaks key functions like the phone’s camera.) It is up to Samsung to patch this threat permanently.

In the meantime, we have released a pattern which will detect apps that attempt to exploit this vulnerability. Users whose devices have Trend Micro Mobile Security are encouraged to update their devices with the latest pattern for protection until the said vulnerability is fixed.

Last week, many people made posts like this on Facebook:

While this was quickly debunked as being entirely untrue, the fact that millions of people made the very same post speaks volumes about how worried people about their privacy on Facebook.

It’s probably not helping that Facebook just finished soliciting comments on their new Data Use Policy and their Statement of Rights and Responsibilities. Privacy groups in the US – specifically, the Electronic Privacy Information Center (EPIC) and the Center for Digital Democracy (CDD) – have objected to the changes.

The most significant part of the changes would deal with how Facebook is (notionally) governed. In theory, changes to its policies are subject to votes by Facebook users. In practice, the process has been unsuccessful – there have been two previous votes since April 2009 (when it was announced). However, turnout has been low, with less than one percent of Facebook users participating. The changes would remove the voting process entirely.

Other changes include making it explicit that information can be shared with Facebook affiliates like Instagram and changes in how messages are handled (instead of a blanket setting on who can and can’t send messages to a user, filters will be offered instead).

This is all just part of the greater debate surrounding privacy and Facebook. News events like this merely bring it to the forefront of people’s minds. The question really is: how much of our data should be online? How much of our data that is online should be able to be used by the free social media networks that we’re part of?

Read the rest of this entry »

We discussed last week the risks that out-of-office notifications pose for organizations – namely, that they could serve as leaks that an attacker could use to conduct successful attacks.

However, the threats from automatic e-mail replies don’t stop with out-of-office notifications. Two other types of automatic replies also pose a threat: bounce messages, and read notifications. Let’s deal with them one at a time.

Bounce messages – more formally known as non-delivery reports (NDRs) – have long been known to be a spam problem. However, they too can become a source for information leakage: improperly configured mail servers can leak details such as their host name, IP address, and software configuration. A skilled attacker can use this information in various ways – whether it’s technical (i.e., attack the server) or non-technical (build an org chart).

However, the primary usage of bounce messages would be to provide real-time confirmation of e-mail addresses. While e-mail addresses found online will probably work, bounce messages can be a more effective and accurate way to confirm email addresses.

Read receipts are even more problematic. For an attacker, it tells them whether an attack “succeeded” or not: i.e., if a human read the email. (Implicitly, it also tells the attacker that the email address does exist.) This is some of the most valuable information an attacker can get – he can use this information to gauge what kind of email his victims will read. In combination with web bugs, the attacker can even determine what software the victim is running.

Read the rest of this entry »