Archive for August, 2013

Hand of a Thief is a new malware in the world of Linux operating systems that’s targeting user’s bank accounts. According AVAST antivirus, the malware is a Linux Trojan that was first discovered on August 7th by RSA researchers and was named ‘Hand Of Thief’. This trojan is quite interesting – first it’s targeting only Linux operating systems (about 15 different flavors) and second, it’s targeting bank accounts of the affected users. Security experts found out that the trojan is capable of gaining back-door entry on Linux specific browsers and can grab data entered in forms. In addition, it’s equipped with anti-virtualization and anti-monitoring techniques. The level of sophistication of this malware has surprised the security experts and it can be compared to the infamous FlashBack trojan that affected Apple’s OSX installations and Obad for Android in the recent times.

slide. ​

Linux operating system, has been designed to offer high level of security for mission critical applications and even to the normal users. However, in the recent times, there were several attacks, or at least attempts, to gain access to the user computers. It looks like most of the malware was targeting sensitive information like banking credentials on compromised systems. Linux users should be aware of this trojan.

Source :

The US National Institute of Standards and Technology (NIST) has updated two of its computer security guides to help system managers protect their systems from hackers and malware.Vulnerabilities in software and firmware are the easiest ways to attack a system, of course, and the two revised publications approach the problem by providing new guidance for software patching and warding off malware.

NIST has first updated its guide to identifying, acquiring, installing and verifying patches for products and systems. The earlier guidance on patching, ‘Creating a Patch and Vulnerability Management Program’, was written when patching was a manual process. The revision, ‘Guide to Enterprise Patch Management Technologies’, is instead designed for agencies that take advantage of automated patch management systems, such as those based on NIST’s Security Content Automation Protocol (SCAP). The guide explains the technology basics and covers metrics for assessing the technologies’ effectiveness.

The second security document, NIST’s ‘Guide to Malware Incident Prevention and Handling for Desktops and Laptops’, was updated to help agencies protect against modern malware attacks that are more difficult to detect and eradicate than when the last version was published in 2005. The new guidance reflects the growing use of social engineering and the harvesting of social networking information for targeting attacks.

The new malware guide also provides information on how to modernize an organization’s malware incident prevention measures and suggests recommendations to enhance an organization’s existing incident response capability to handle modern malware. NIST suggests that organizations should plan and implement an approach to malware incident prevention based on the attack vectors that are most likely to be used currently and in the near future.

Because the effectiveness of prevention techniques may vary depending on the environment (i.e., a technique that works well in a managed environment might be ineffective in a non-managed environment), organizations should choose preventive methods that are well-suited to their environment and hosts. An organization’s approach to malware incident prevention should incorporate policy considerations, awareness programs for users and information technology (IT) staff, vulnerability and threat mitigation efforts, and defensive architecture considerations.

Organizations should also ensure their policies address prevention of malware incidents, NIST added. An organization’s policy statements should be used as the basis for additional malware prevention efforts, such as user and IT staff awareness, vulnerability mitigation, threat mitigation, and defensive architecture.

If an organization does not state malware prevention considerations clearly in its policies, it is unlikely to perform malware prevention activities consistently and effectively throughout the organization. Malware prevention-related policy should be as general as possible to provide flexibility in policy implementation and to reduce the need for frequent policy updates, but should also be specific enough to make the intent and scope of the policy clear. Malware prevention-related policy should include provisions related to remote workers – both those using hosts controlled by the organization and those using hosts outside of the organization’s control (e.g., contractor computers, employees’ home computers, business partners’ computers, mobile devices).

Source :

Everyday millions of computers solve the same problem; these machines try to check if you are actually you and not some other person. The most popular tool to do that is password checking. But it’s quite easy to steal a password as well as forget it. Problems with passwords highlight the need for another system of user identification. A very simple and appealing solution is biometric authentication, which allows a user to place his finger on top of a scanner, look at the camera or say a passphrase. Your fingers, your eyes and voice are always with you, right? And others people cannot imitate this. Unfortunately, this appealing idea has numerous cons and that is the reason why we don’t still use fingerprints to login to Google or withdraw cash from an ATM.


The major difference of any biometric authentication from an ordinary password-based one is the absence of a perfect match between the original (master) sample and the sample being checked. You simply can’t obtain two fully identical fingerprints of the same finger. It becomes even more troublesome when you try to match faces. Face characteristics might become different or just unreadable depending on lighting conditions, time of the day, presence of glasses, beards, bloodshot eyes, make-up, to say nothing about natural aging. Voice is also affected by numerous factors, e.g. the flu. In these conditions it’s extremely difficult to build a system that is able to accept the legitimate owner all the time and never admit strangers.

To solve this problem, each biometric system tries to clean the scanned sample of noise, effectively leaving only characteristic features acceptable for mathematical comparison. Nevertheless, even this “skeleton” should be matched with the original in terms of probability. For medium security systems, it’s assumed normal to admit a stranger once in 10,000 tries and block the legitimate user once in 50 cases. When it comes to mobile platforms, unstable external conditions, e.g. lighting and vibration dramatically increase the error rate, that’s why Android facial recognition fails in 30-40% cases.


A password for a lifetime

If you forgot your password or it has been stolen, you can change it. If you lost your keys, you can change a door lock. But what could you do, if your bank account is “locked” using the image of your palm as some banks in Brazil or Japan do, and this database of palm prints was stolen?

There will be a fingerprint scanner in the new iPhone while Android will use facial recognition to unlock. Is this protection worth your trust?

It’s extremely challenging to change your palm. Even if palm forgery technology doesn’t exist today, no one can guarantee it won’t emerge in five or ten years.

This fundamental problem might be partially solved with fingerprints – you can enroll only 2-4 fingers instead of 10, so there will be some ability to change the password. But this supply is quite short, probably too short considering a lifetime. Online account hacks happen just too often, so it’s a little bit scary to trust them with precious biometric information. The fact that most services store just a “skeleton,” a biometric derivative, doesn’t really make things easier – numerous studies have proven that it’s possible to rebuild, e.g. a fingerprint, that won’t be identical to original one, but still able to pass the check.


In addition, online biometric authentication raises privacy concerns. A biometric “password” clearly identifies you as you and it becomes impossible to have two separate accounts on the same social network – a site has enough tools to figure out that it’s the same person. Strictly speaking, hundreds or even thousands of users might have practically indistinguishable biometric features. But with help of a Geo-IP and other metadata that accompanies user requests, it’s well possible to set up completely unique user profiles for each user. If someone manages to implement biometric authentication on every popular web service, online user tracking will be a piece of cake.


A digital locker

Primarily, usage of passwords and, potentially, biometrics can assist to restrict access to various devices and services. Secondly, it can help restrict access to data that is stored on the device. However, it is difficult to utilize biometric features in the second case.

When you put your documents in a safety box with a fingerprint-based door lock, the box walls protect your data. You would have to use a powerful drill to overtake the fingerprint-scanning lock. If you access control of a computer, it’s ridiculously easy to avoid any check, so the computer equivalent of those steel walls is encryption. When you encrypt something with a password, a special encryption key is generated using your password. If you change only one character of the password, the encryption key will be totally different and useless. But a biometric “password” is slightly different on each access request, so it’s very complicated to directly use it for encryption. That’s why existing mass market “digital lockers” rely on cloud-based help – biometric matching happens on the server side, and, if successful, the server provides the decryption key to the client. Of course, that poses a significant risk of a massive data leak – a server hack might lead to the compromising of both encryption keys and biometric data.


Biometrics IRL

Leaving aside sci-fi movies and military developments, we can think of two cases of automatic biometric authentication you might encounter. There are trials being run in some banks – they might use palm scans on ATMs as well as voice authentication on phone-based service desks. The second type of biometrics is embedded scanners in consumer electronics, typically laptops and smartphones. The front camera might be used for facial detection and a sensor that can recognize fingerprints. A couple of systems also utilize voice authentication. In addition to the aforementioned general problems of biometrics, those consumer-grade implementations have limits, imposed by such constraints as CPU power, sensor price and physical dimensions. To deal with these constraints developers must sacrifice system security and robustness. That’s why it’s easy to fool some scanners with a wet paper with fingerprints generated using an ordinary printer or gelatin cast. And when it comes to gaining profits, fraudsters might produce a convenient fake finger – criminal schemes involving such tools already exist. On the other hand, legitimate users often try to swipe their fingers multiple times to have their access granted – most sensors might fail if a finger is wet, covered with lotion, slightly unclean or has scratches or burns.


Facial recognition systems are rarely able to distinguish real faces from photos (although there is a workaround if the system has a liveliness check, e.g. requires blinking). But when using facial recognition to unlock your mobile device, programs are often already sensitive to lighting conditions and the overall environment that you don’t want to make things worse by enabling extra checks. And you must have a backup – an old password – otherwise you won’t be able to unlock your device in the dark.

Most developers of voice authentication systems say that they are able to detect fakes – both recordings and impersonators. In fact, only the most powerful systems perform all required computational-heavy checks, and some researchers say that voice alteration software might fool authentication systems in 17% of the time. It’s complicated to implement full, real time analysis on a mobile device, so it requires help from the cloud, but cloud-based authentication is slower, depends on internet connection quality (and mere existence) and is prone to additional attacks like man-in-the-middle. By the way, an MITM attack is especially dangerous for voice authentication systems, because it is much easier to obtain voice samples than other biometric samples.

This combination of practical inconveniences for legitimate users and insufficient security prevents biometric authentication from becoming a standard in mobile device security, replacing traditional passwords and electronic tokens. Secure and reliable identity checks using biometrics is now possible only in controlled conditions, i.e. in a border control booth in an airport or security checkpoints at an office entrance.

Source :

It’s that time of the month again, with Microsoft Patch Tuesday just 24 hours away.

In point form, August 2013 brings you:

  • Eight bulletins
  • Three critical due to potential remote code execution
  • Critical #1: All Internet Explorer versions from 6 to 10
  • Critical #2: Exchange Server versions 2007, 2010 and 2013
  • Critical #3: Windows itself, but only XP and Server 2003
  • Patches for Server Core, but none critical
  • Reboot required

It’s hard to say just how severe (or how widely exploited, if at all) any of the critical vulnerabilities are, since Microsoft plays its cards close to its chest until the patches actually ship.

And even though some of the bulletins are listed with a Restart Requirement of “maybe,” you should assume you’ll be rebooting every Windows box within your remit.

That’s because all your systems will either have Internet Explorer on them, or be Server Core installs.

Both of those require a reboot.

As usual, SophosLabs will be publishing its own vulnerability assessments once Microsoft has officially issued its updates. (Redmond always gets to go first. Understandably, that’s the way it is.)

Although Naked Security generally recommends getting a move on with patching, lest you get sucked into a Change Control Resistance Vortex, SophosLabs gives you a Threat Level assessment for each patch.

All other things being equal, if you have to delay one or more of the eight Bulletins, the Threat Level helps you choose by assessing the likelihood that each security hole will be actively exploited.

Source :

Microsoft has warned that vulnerability in Windows Phone operating systems could allow hackers to access your login credentials.

The vulnerability resides in a Wi-Fi authentication scheme known as PEAP-MS-CHAPv2, which Windows Phones use to access wireless networks protected by version 2 of the Wi-Fi Protected Access protocol.

Cryptographic weaknesses in the technology can allow attackers to gain access to users encrypted domain credentials. These credentials could potentially give the attackers access to sensitive corporate networks.

The bulletin, advisory says:

To exploit this issue, an attacker controlled system could pose as a known Wi-Fi access point, causing the targeted device to automatically attempt to authenticate with the access point, and in turn allowing the attacker to intercept the victim’s encrypted domain credentials. An attacker could then exploit cryptographic weaknesses in the PEAP-MS-CHAPv2 protocol to obtain the victim’s domain credentials. Those credentials could then be re-used to authenticate the attacker to network resources, and the attacker could take any action that the user could take on that network resource.

Microsoft does not intend to patch this vulnerability. Microsoft has not received any reports of this vulnerability being used to steal corporate data, passwords or breach a network to date. Rather, it simply advises users of Windows phones to require a certificate before joining wireless networks, and includes instructions for enforcing this in the phone settings.

Source : THN