Is building a better mouse trap (Signal Private Messenger) enough to win market shares?

I am please to see the release of Signal Private Messenger for Android and iOS, a messaging application that has earned full marks in the EFF security score sheet. I am a fan of this product and I like it very much for the following reasons:

• It is an open-source project offering the service for free. WhatsApp is not a free.

• As a result, it can be reviewed by anyone capable of doing it while WhatsApp is proprietary, even though it claims to be underpinning by Open Whisper Systems but no one has reviewed that. Recent event has indicated that WhatsApp messages have been intercepted and decoded.

• It is not owned by any company while WhatsApp is owned by Facebook, Skype by Microsoft. Thus all metadata in WhatsApp and Skype belongs to Facebook or Microsoft respectively.

According to well-known security researchers, Bruce Schneier and Matt Green, Signal is developed to a very high quality to provide end-to-end encryption (E2E) not only for messaging but also for voice and their endorsement must mean something.

I am not here to raise doubt of this product which I am using admittedly with very limited users to interact with and I have great trust. I hope it will do well.

But I am here to question whether it is enough to rely on technical superiority which is so well hidden from the users to induce them to switch to Signal and to grow its market shares. That's is: is building a smarter (more secure) mouse trap enough to win market shares? Other class of software such as web browser, anti-virus, media player, or mail client can draw people to switch based of superiority of features.

Looking at the landscape of messaging applications it is difficult to see how Signal can rely on security implementation, so out of sight of the user, to win market shares. Will this become a replay of VHS (WhatsApp, Skype, etc) vs BetaMax (Signal) of the 21st Century?

Messaging applications are like clubs or cults in which they only allow club members to interact and go to great length to discourage inducement to leave and definitely providing no facility to support inter-club interaction. This produces network effect to draw people in and that also becomes disincentive to leave and its nurture of human social interaction provides a positive feedback to increase the network effect.

Looking at the EFF Security score card, most of the popular messaging applications do not use security best practices and their inferiorities do not seem to matter to the users. The anecdotal conclusion one can draw is that users do not care with online privacy and security despite well publicised massive surveillance activities. Unlike other type of application, such as web browser, there is no report of people deserting one messaging application to another, despite vulnerabilities and caught not using secure messaging mechanism when they claim to use. For those entrenched players, they must feel like in a no-loss situation. The only way they can lose to a competitor is by a total annihilation of the enterprise.

Messaging applications have another unique characteristics that it is not the features that draw users to choose a particular application; there is a great degree of peer pressure exerted by those early adapters unwittingly forcing people to form that circle of friends. This peer pressure then forms a vortex to draw more and more people in. Their only concern is to be able to communicate with the club members.

Because of the lack support for inter-application interaction, the application through using proprietary communication protocol forms a natural barrier for their user to leave. Apart from that, the user does not see any benefit for using a different application that essentially providing the same things - messaging and may be voice - and having to desert their friends. So why leave? What is the benefit to them?

Many users of messaging applications also form the mistaken belief that they can only use one messaging application in their device. Perhaps it is this mistaken belief or blind fanaticism to their favourite application they are also reluctant to install other messaging applications to increase their reach to their friends. Since Signal is so similar to WhatsApp, it is simply a matter of installing and waiting for others in the contact to install their copy of Signal to re-establish communication. Even that simple is not enticing.

I have spoken to several users of messaging applications as well as non-users and recommending to switch over to a more secure application called Signal. But telling them the benefits of Signal is like talking about wine apprecThis is particularly difficult when Signal is so similar to the operations of WhatsApp separated by a thin veneer of technical features. In view of this, users of WhatsApp (or other app) are unwilling to desert their circle of friends to use something that to them is almost the same thing with minute user base, by comparison. iation to a group of teetotalers. To them the improve security and end-to-end encryption (E2E) are not enough to sway them. Even people that has not used messaging application seems to be reluctant to get onboard with Signal because they have not heard of it being mentioned by their friends.

So I wonder how a late comer like Signal can overcome these barriers to increase its market shares? How it can base on technical superiority to entice users who are disinterested of them that Signal relies on to distinguish it from others? What is the future of Signal apart from being a niche player at best? Clearly Signal needs to improve its image and marketing.

From the analysis, users of messaging applications place extremely high premium on their ability to reach their circle of friends and ignore other issues like security and privacy. Therefore if the new comer, like Signal, wanting to rise up, it must give their users a transparent way to interact with their circle of friends without requiring them to switch en masse like the present situation. How to achieve that is the real challenge in messaging application development in view of no standard communication protocol?

To install or not install an application - what are the pros and cons?

With the advent of USB devices, many applications that once require an installation process for deployment have been converted to run without one so that the user can use that program directly from the USB device on any machine and a large collection of them can be found here mostly utilizing their portable application framework.

Other program, such as TrueCrypt or its replacement VeraCrypt offers a much simpler model; it simply offers you a way to extract the files into a directory and one can execute the program from there.

I have been a fan of this convenient deployment model for a long time and in particular of avoiding any impact on the underlying operating system. It is particularly helpful in troubleshooting without the need to install anything. Just run!

However, recently I have been having second thoughts whether the benefits of this model is worth the risk of allowing malicious attacker to contaminate the program to do harm? When needing to a USB device in an environment that I do not know its sanity, I always probe it using tools carried by locked SD-Card. In this way, I am protected from being a carrier of attacks or being attacked.

Going back to the history of Windows beginning in Windows 2000 (aka NT5), Microsoft has been using the profile to define a set of file and registry security templates to protect executables and key information, although much of the good intention was discarded in favour of convenience and ignorance. Microsoft had to do something to rein in the unruly behaviour by introducing the UAC in Vista to the dismay of large unappreciative community.

Apart from other benefits, the main aim of the file system security is to protect key files from bring modify by user without administrative privilege. From Vista onwards, all applications run by default with standard user privilege and that means that they cannot make changes to program files or protected areas. This is a good thing and has improved the security of Windows a lot.

Now if instead of installing a program that requires administrative rights to carry out and deployed into designated protected areas, we modify the deployment model of the program to allow it to run from anywhere, doesn't such a practice is a throwback to the good old days of NT4/5/XP (run everything in admin account) style? Aren't we then essentially turning the file system protection off for these programs? Aren't we making our programs more vulnerable to attacks?

What caused me to ponder is my latest installation of VeraCrypt 1.16 that has fixed a couple of recently discovered critical vulnerabilities. In the past I have been using TrueCrypt in portable mode without installation. Then I wonder: wouldn't this mode of deployment makes it easier for others to attack the program or to use this program or this type of program, running at elevated privilege, to launch attacks?

In the end, I decided to install the program. What is your opinion on this issues?

In Linux, by default it does not allow programs to run from removable devices.

Caveat for Link Market Services Registry users using Password Manager

This is a note to any users of Link Market Services Share Registry service that use Password Manager to manage their password.

It seems Link Market Services discourages people using password manager, a practice that is recommended by security experts, and it expects the users to have some sort of psychic power to know why.

Recently, I have encountered an operation that requires me to supply the Transaction Password. Since I used a password manager to generate and record passwords, I simply asked the password manager to transfer the transaction password to the field in the Link Market Services web page. The transfer happened flawlessly but the confirm button remained disabled as if I had not type anything. That's strange. There was no textual guidance and no pop up message box to tell the user what to do.

Not deterred by this, I did some experiments and this is what you have to do if you want to use password manager:
1) Transfer the Transaction password to the field in the normal way your password manager offers.
2) Click on the field and press End key to force the cursor to be positioned to the end of your password. (Or enter a character to the end of the password and immediately removing it from the field)

The minute you have completed step 2, the confirm button is enabled! The web page at that stage does not have a clue if what you have entered a valid  transaction password.

It seems the web page has a user-interface bug failing to recognise the field change event.

This kind of bad user interface design makes your software sucks. If you do not want user to transfer data say via the clipboard, disable the paste operation and offer the users some form of guidance. If your web site does not have a general purpose help e-mail address, you need to make sure the user-interface of your web site to be perfect and idiot-proof.

On the subject of Transaction password, this is their mandated rule:

When you use the settings facility to change the Transaction password and if you use a password manager to generate the new password (highly recommended), after you have transferred the new password to the respective field, execute Step 2 mentioned above. Such action will trigger the script on that page to evaluate the supplied password. It seems the program has a bug similar to that mentioned above.

One wonders if the Link Market's mandated rule can encourage users to choose strong password. If Link Market discourages their users from using password manager, then the users will undoubtedly choose an easy to remember password (that will also ended up to be easily guessed by hacker).

For example the following passwords Pauline1, Password1 or Ab1234567 comply with the rule but according to Microsoft's password checker or Kaspersky's checker,  there are weak passwords. It is therefore better to encourage your users to use password manager rather than forcing them to choose easy to remember one.

Android is like the Windows XP days with little regards to user's protection

Months ago, I made a statement to my friends that effectively compared Android's operations or lack of security to the days of Windows XP and prior. The open neglect seems to follow the same excuse Windows use to make it easy for people to use. Now my observation is supported,

The Android threat landscape is starting to resemble that of Windows, according to F-Secure's Mobile Threat Report 

The Android threat landscape is growing in both size and complexity with cyber criminals adopting new distribution methods and building Android-focused malware services, according to a report from Finnish security vendor F-Secure.

The number of mobile threats has increased by nearly 50 percent during the first three months of 2013, from 100 to 149 families and variants, F-Secure said in its Mobile Threat Report for Q1 2013 that was released on Tuesday. Over 91 percent of those threats target the Android platform and the rest target Symbian.

What frightens me most and at the same annoying me is that when you install most applications, they demand access to your account, your phone, or other facilities that do not seem to be related to what the main function of the applications.

For example, I once wanted to install a PDF viewer and it demanded permission to access my phone contacts, etc. I have yet to see a PDF viewer in Linux/Windows demanding access to my Outlook or Thunderbird phone book, or my Google account. After all, it is just a program to render the PDF document and all it really need is read access to certain area where the document is held.

Then the other date I want to install a GPS logger but it too needed my Google Account, phone Contacts, phone logs, etc. Why? Is it just a program to jolt down the GPS location regular interval or on demand? All it really requires should be write access to the user's area and no more and no less.

If application demanding this kind of unnecessarily access of elevated privilege or to areas in Windows and Linux, they will be exposed as Trojan or Malware. But in Android, a form of Linux, it is an acceptable practice. Why?

As a result, I often do not install those applications that demand unreasonably access.

The only way to fix this rampant neglect of security is to turn everything off and then allowing the user to enable/disable access relating to features user requires. Ultimately it should be the responsibility of the phone owner. At the moment, the big switch is just too wide much like Windows XP where most people were using it without security.

Apple's way to fix iOS security vulnerability

Keep quiet and Shoot the messenger and this is a classic Security by Obscurity.

Charlie Miller recently found a security vulnerability in iOS and shows it on YouTube. This has embarrassed Apple.

I am wondering how many 'silent messengers' out there going about merrily exploiting holes without telling Apple. After this episode why would researcher bother to tell Apple, the ungrateful lot.

Using PasswordSafe in Windows 7

I am surprise to see the latest version (ver 3.25.0.4042) still does not have the embedded manifest file to tell the Windows 7 the execution level required. When you invoke the pwsafe.exe, it triggers the UAC's attention resulting in this message box:

Not nice. You can prevent this by unblocking it. To do this, you right mouse click on the program in Windows Explorer and then select the properties. On the general tab in the properties dialog box, you should see the 'Unblock" button as circled below:

Once unblocked, it will not throw up that frightening first message box.

Let's hope this annoying issue will be addressed soon.

gpg4win 2.1.0-rc1 making progress

It is nice to report that Gpg4Win 2.1.0-rc1 has made small progress in fixing some of issue unearthed previously with respect to its problem in running in TChinese XP. Now a user running TChinese can use the GPA's user interface to submit passphrase to create a key.

However, the Windows Explorer integration is still failing as reported. Sadly Kleopatra.exe still does not run when the "Language Settings for Non-Unicode Programs" is not set to English.

This Unix-Windows program still has a long way to go to achieve the environmental correctness of Firefox, Thunderbird, or TrueCrypt.

As a result, it is recommended users not to install GpgEX (the Windows Explorer integraion) as it is the very flaky and only works when your "Language Settings for Non-Unicode Programs" is set to English.

GPA is surprisingly usable if you can put up with some very foreign UI and appears to be unaffected by the "Language Settings for Non-Unicode Programs". It also works in TChinese Windows but not internationalized.

It stands out like a sore thumb when other programs in the TChinese XP have localized menu. Surely Unix/Linux is capable of handling Internationalization.

KeePass v1 or KeePass v2

The pros and cons of KeePass V2 and V1 have been discussed previously.

Finally I have decided to switch allegiance to V1. What sways me over is the problem in V2 needing .Net framework 2. While progressively more and more machines are running Windows Vista or Windows 7, but there are still plenty of WinXP machines out there.

In fact, I was using one that does not have .Net Framework 2 and I was going to use to configure my modem/router. In that situation, I could not use my KeePass v2 database and I did not feel like installing .Net Framework 2 just to run this program. It is kind of defeating the portability advantage of KeePass.

With XP, you cannot count on it having a .Net Framework 2 on it. Without it, your KeePass V2 database is as good as corrupted.

To avoid being left out in the cold, I exported the KeePass v2's kdbx file format to KeePass V1 database format and use the V1.17 instead.

Performance-wide, it starts a lot faster. Until the day when .Net Framework is so widespread that it is not a issue or KeePass organization stops maintaining V1, I will then upgrade to V2.

The figures are in - LUA is the best defence against attacks

The key finding in the report by BeyondTrust on Microsoft's operating system and Office paints an unambiguous picture that LUA is the best defense to protect your machine:

Key findings from this report show that removing administrator rights will better protect companies against the exploitation of:
• 90% of Critical Windows 7 vulnerabilities reported to date
• 100% of Microsoft Office vulnerabilities reported in 2009
• 94% of Internet Explorer and 100% of IE 8 vulnerabilities reported in 2009
• 64% of all Microsoft vulnerabilities reported in 2009

This graph taken from the report shows the impressive protection offer by LUA in various Microsoft operating systems:

It is worth repeating the conclusion of this report here:

This report demonstrates the critical role that restricting administrator rights plays in protecting against vulnerabilities. It is important to note that this increased protection is achievable in one simple step without any impact on productivity — by implementing a desktop Privilege Identity Management solution. As companies roll out Windows 7 they need to include plans to implement a desktop Privilege Identity Management solution in order to reduce the severity or prevent the exploitation of undiscovered or unpatched vulnerabilities and to ensure that their users can operate effectively without administrator rights.

One should also not to lose sight of the potential remaining vulnerabilities that allow malicious code to attack the users using the user account's privileges.

Notes on KeePass from a long time user of Password Safe

I have been a long time user of Password Safe and has great appreciation for its simplicity and usefulness. As my database grows over the years, the simplicity of Password Safe (I am using version 3.20) becomes an issue. The most obvious one is that there is no way to find an entry other than to scan one by one. This process becomes laborious with lots of entry nested deeply.

As a result, I have embarked unwillingly on a journey to find a replacement for my trusty companion. I came across the KeePass Password Manager program that operates and looks very similar to Password Safe and is also an open-source project. A search on the Internet does not seem to reveal any vulnerability of this and hence with some trepidation, I decided to give it a road test and below are my experience. It is by no mean an exhaustive comparison or even to gauge its security strength.

While KeePass supports AES-128 in both ver 1.x and 2.x and only supporting Two-fish in ver 1.x, out of the box, the implementation of them is the key to the strength and vulnerability and not so much as the declared algorithm used. This aspect is not examined. The notes below are more a guide for Password Safe users on how to migrate to KeePass painlessly and to become familiar with it.

The good things with KeePass (ver 2.09) vs Password Safe (ver 3.20)

KeePass from a developer's prospective appears to be a more active community than Password Safe and architecturally a better product. While some many argue that the availability of a plug-in architecture can weaken the security of the product, the fact remains that it is there to allow people to extend and to use them when needed. Out-of-the-box, no plug-in.

This plug-in architecture is exploited to the fullest, as described below, in migrating the Password Safe database over to KeePass.

KeePass has a large active community producing a variety of plug-ins while Password Safe is more a closed system. KeePass has also spawned off other projects to produce versions for mobile and other operating systems.

Both KeePass and Password Safe are essentially portable applications that do not need to install into the machine. Both products, only KeePass version 2.x, also produce installers that allow people to install them into their machine and uninstall them when not required. I used the portable version that does not require installation.

KeePass has two versions - ver 1.x and ver 2.x - that unfortunately use two different database technologies introducing compatibility issues. Version 2.x can handle version 1.x databases with no loss of data requiring a forward conversion but a version 1.x KeePass cannot open version 2.x database unless is exported into a 1.x format.

KeePass seems to embrace the Windows Security Model better than Password Safe. While Password Safe performs perfectly in a USB drive environment in which it has read-write access to the directory, in a share machine or machine using LUA, Password Safe is found struggling. Sure, you can use the -g option to re-route the configuration file location. But this is very clumsy that you have to specify each user's profile area.

As a digression, under the watchful eyes of Process Monitor, when Password Safe's program as a limited user, it seems to generate a lot of "Access Denied" error when opening system files such as Shell32.dll and others. Just very unusual and I am wondering if they are opening them with too much privilege.

KeePass understands the LUA principle and Windows Profile. It will automatically re-route the per user configuration files in situation that requires this. Password Safe lacks this capability. KeePass ver 2.x also runs fine in non-Windows environment using Mono.

The other nice touch with KeePass in handling multiple users or sharing between machines is the availability of this feature "Enforced Configuration" that allows an administrator to define system-wide settings that each user will inherit.

The bad part of KeePass

Ver 1.x is a native product while Ver 2.x is a .Net product using framework 2. So if you are taking KeePass on a USB drive to be used on some one else machine, such as in an Internet Cafe, and if that machine does not have .Net framework installed, you cannot run KeePass2. But if you have KeePass1.x you can run it on any machine.

Start up speed of version 2 is also very much in line with a typical .Net application. Once started, there is no noticeable performance difference.

If you intend on traveling and worry about the availability of the .Net framework issues, use KeePass1.x, which is still a supported product. Not as pretty as KeePass2 but as functional as KeePass2.x. The down side is the database are incompatible.

This issue with the availability of the .Net framework is only a transitional problem as all Vista and Win7 machines have .Net Framework 2 and higher installed by default and many XP machines are progressively supporting .Net Framework. It is only a matter of time.

What extra features I would like to see in KeePass

I would like to see an option that allows me to open the database in read-only format until I reopen it without that option. This prevents user from changing the data accidentally.

It would also be a nice feature not to reveal the password permanently until one decides to show it and that stays temporarily until that entry is closed. At the moment KeePass' show or hide state is persistent not only across entries but also for the KeePass installation; Password safe always hide the password when viewing/editing the entry and only shows the password until that entry is closed.

Migrating Password Safe database over to KeePass

If you have a database in Password Safe 1.x, 2.x and 3.x format, you can convert to using KeePass. The process depends on which final version of KeePass to use and below are the steps:
1) Download version 1.09 of KeePass into a temporary directory and unzipped it.
2) Download the Password Safe Import plug-in into the directory containing KeePass ver 1.09. Since this plug-in only works for KeePass versions 1.05 to 1.09, we have to use KeePass ver 1.09. If you drop this into newer version of KeePass, they will not recognize this as a valid plug-in.
3) Follow the installation instructions in the Password Safe Import Plug-in as described in the accompanied ReadMe.txt.
4) Create a new database with KeePass 1.09 and then use "Tools/PwSafe Database Import/Import" to import the Password Safe database into KeePass.

If you are going to use KeePass ver 1.x, you can use this database without any further steps.

If you are going to use KeePass 2.x, you have to import this KeePass 1.x database into ver 2.x format. Once that is completed you can wipe the KeePass 1.x's directories and database. This completes the migration process.

Malware attacks in LUA

It probably has something to do with the security model of Vista that recently more and more Malwares and Trojans are attacking and surviving in user's account. The reason it is possible is largely explained by the paper "Problems of Privilege: Find and Fix LUA Bugs":

Prior to Windows 2000, HKCR was just a symbolic link to HKLM\Software\Classes that only administrators could write to. This meant that operations performed on HKCR\.txt actually occur in HKLM\Software\Classes\.txt. Windows 2000 introduced per-user registration data, so now HKCR is a merged view of HKLM\Software\Classes and HKCU\Software\Classes (which the user can write to). If a key exists in the latter, it takes precedence. So now an operation on HKCR\.txt occurs in HKCU\Software\Classes\.txt if that key already exists; if it doesn’t, the operation occurs in HKLM\Software\Classes\.txt as it had in the past.

Note that HKCU keys take precedence over HKLM and user has all the rights to modify HKCU\Software\Classes. It is this implementation that now opens up a 'vulnerability' for Malware writer to exploit. Even rogue antivirus "XP Guardian" is exploiting this hole. This support note from Microsoft shows how to exploit this hole.

Most of these Malwares also use the "%Temp%" or even "Temporary Internet Files" folders to park their malicious executable code with total impunity.

Since most computer only serves one user, particularly notebook and netbook, it is pointless to struggle so hard to gain control of the HKLM and protected resources that required elevated privileges. The end result is almost the same - carrying out the dirty deed with total impunity. Anti-Virus program are often of little help.

This problem allowing HKCR to take precedence, even in Vista, allows attackers to exploit this hole in XP, Vista and Windows 7. Even running LUA will not be a good defense against this form of attack and anti-virus is even more ineffective.

Love-hate relationship with Fingerprint recognition system

I harbor a love-hate relationship with finger print recognition system both of government or commercial grade because I have yet met one that reliably recognizing my print. Hence when I come across this research paper, I want to know more particularly the performance of the deployed system, etc.

A fingerprint matcher can make two types of errors: a false match, in which the matcher declares a match between images from two different fingers, and a false nonmatch, in which it does not identify images from the same finger as a match. A system’s false match rate (FMR) and false nonmatch rate (FNMR) depend on the operating threshold; a large threshold score leads to a small FMR at the expense of a high FNMR. For a given fingerprint matching system, it is impossible to reduce both these errors simultaneously.

Fingerprint identification system performance is measured in terms of its false positive identification rate (FPIR) and false negative identification rate (FNIR). A false positive ident i f icat ion occur s when the system finds a hit for a query fingerprint that is not enrolled in the system. A false negative identification occurs when it finds no hit or a wrong hit for a query fingerprint enrolled in the system. The relationship between these rates is defined by FPIR = 1 - (1 - FMR)^N, where N is the number of users enrolled in the system. Hence, as the number of enrolled users grows, the fingerprint matcher’s FMR needs to be extremely low for the identification system to be effective. For example, if an FPIR of 1 percent is required in a fingerprint identification system with 100 million enrolled users, the FMR of the corresponding fingerprint matcher must be on the order of 1 in 10 billion. Such a stringent FMR requirement can usually be met only when fingerprints from all 10 fingers of a person are used for identification. This explains the need to continuously decrease the error rates of fingerprint matchers employed in large-scale identification systems.

It also lists some US government's systems' performance and the FNMR seems to be higher than FMR in just about all system. Does this means that the system will not match more often than finding a match?

I always want to know why my Fujitsu P1510's fingerprint log in system always rejects me with a rate like 20-25 tries to get one successful log in (I have not disabled that system). This paper offers some plausible explanation:

Fingerprint sensors embedded in consumer electronic devices tend to have a smaller sensing area. This factor, combined with users’ improper placement of their finger on the sensor, results in a limited overlapping area between two impressions of the same finger, as Figure 5c shows. Given the very small number of minutiae in the overlapping area, it is difficult to determine if two fingerprints are from the same finger.

One way to alleviate this problem is to utilize level 3 features to improve the matching accuracy in cases where there is only a small overlapping area between the two impressions. However, level 3 features may not be suitable for commercial applications because the sensors used in such applications usually provide only low-resolution images.

Why do I have so much trouble with fingerprint recognition system? This paper offers these suggestions:

In some cases, a fingerprint recognition system may not even successfully capture the user’s fingerprint. Failure to enroll (FTE) and failure to acquire (FTA) refer to the fraction of users who cannot be enrolled or processed by a particular system due to the poor quality of their fingerprints— for example, people such as manual laborers or the elderly with “worn-out” fingers. In practice, FTE can be rather high (a few percentage points) depending on the target population and the occupation of users in the population.
[...]
Due to nonideal skin conditions, inherently low-quality fingers, and sensor noise, a significant percentage of fingerprint images are of poor quality. Extracting features from and matching low-quality fingerprints, like those shown in Figures 5a and 5b, is a challenging problem that will require significant research.
[...]
Pressing soft finger skin on a sensor always introduces some distortion, which is generally not repeatable. Matched fingerprints may appear very different under severe distortion, as Figure 5d shows.

The paper's conclusion is reassuring to know that it is not totally my fault:

Although fingerprint recognition is one of the earliest applications of pattern recognition, the accuracy of state-of-the-art fingerprint-matching systems is still not comparable to human fingerprint experts in many situations, particularly latent print matching. Significant advances require not only a deeper understanding of friction ridge formation, but also adaptation of new developments in sensor technology, image processing, pattern recognition, machine learning, cryptography, and statistical modeling. While successful commercial applications have driven fingerprint-matching technology, more breakthroughs could be achieved with greater investment in fundamental research.

My view on the effectiveness of antivirus software is vindicated

I have always formed the opinion that antivirus is a very ineffective and blunt device in protecting one from being attacked. This is not to say that I am flirting carelessly with danger on the Internet. What I am saying is that there are far better and efficient way to protect oneself than to rely on antivirus software.

Recent attack on Google in China invoked a number of comments and postmortem analysis and one of them has vindicated my view,

nCircle's Storms believes that one "lesson from this breach is that antivirus software really is dead. For quite a while it's been the least effective tool in the IT enterprise security toolset because it's only effective against known malware. It only takes one piece of customized malware to infiltrate your network."

In my e-mails with Kurtz he wasn't as bold about declaring the death of antivirus tools, but he did suggest a new approach as well. "There are technologies like whitelisting--McAfee Application Control, that would have prevented successful exploitation of this zero day and many others--without signatures. Companies really need to start augmenting their blacklisting with whitelisting protection technologies."

Antivirus is often like looking in the rear vision mirror. It is totally useless until its database has been updated.

How do you secure your .Net Application?

Here is a very comprehensive set of guidelines to show how to secure your .Net application after it has been developed.

Guidelines to develope secure ADO.Net application

This is a very comprehensive set of guidelines in making your ADO.Net secure.

Writing a secure ADO.NET application involves more than avoiding common coding pitfalls such as not validating user input. An application that accesses data has many potential points of failure that an attacker can exploit to retrieve, manipulate, or destroy sensitive data. It is therefore important to understand all aspects of security, from the process of threat modeling during the design phase of your application, to its eventual deployment and ongoing maintenance.

Developing program in non-Administrator account

Here is another recommendation from Microsoft:

The Windows user accounts that developers use normally should be added to either the Users or Power Users Groups. Developers should also be added to the Debugging Group. Being a member of the Users group allows you to perform routine tasks including running programs and visiting Internet sites without exposing your computer to unnecessary risk.

I am puzzled and disturbed why Microsoft suggests adding that account into Power Users' group given the result of a detail investigation of its exploit opportunities that concludes:

a determined member of the Power Users group can fairly easily make themselves full administrator using exploits in the operating system and ones created by third-party applications.
[...]
The lesson is that as an IT administrator you shouldn’t fool yourself into thinking that the Power Users group is a secure compromise on the way to running as limited user.

With the availability of runas, /netonly option, there is no need for the default log in account to be a member of Power User. Therefore one should disregard the 'Power User' group in the recommendation.

Pouring cold water on 'hacked' Climate Research Unit's E-Mail

I am skeptical that the recent publication of the collection of e-mail exchanges between scientists in the Climate Research Unit is the work of a hacker. My skepticism is now supported by a forensic analysis by a Unix System Administrator.

The only reasonable explanation for the archive being in this state is that the FOI Officer at the University was practising due diligence. The UEA was collecting data that couldn't be sheltered and they created FOIA2009.zip.

It is most likely that the FOI Officer at the University put it on an anonymous ftp server or that it resided on a shared folder that many people had access to and some curious individual looked at it.

If as some say, this was a targeted crack, then the cracker would have had to have back-doors and access to every machine at UEA and not just the CRU. It simply isn't reasonable for the FOI Officer to have kept the collection on a CRU system where CRU people had access, but rather used a UEA system.

Occam's razor concludes that "the simplest explanation or strategy tends to be the best one". The simplest explanation in this case is that someone at UEA found it and released it to the wild and the release of FOIA2009.zip wasn't because of some hacker, but because of a leak from UEA by a person with scruples.

 It is most likely an inside job.

Fingerprinting to prove ID online

I hope they will not introduce fingerprinting recognition system as described here as I have yet to encounter one that worked reliability on me - from immigration to notebook. This part is true:

"The public is sending an important message to governments and the private sector that they are willing and ready to use sophisticated technology in order to protect themselves against these types of threats."

But that does not mean systems out there are "sophisticated". I am willing to be their beta tester anytime.

Tools to help you to make your code secure

Microsoft has released two tools BinScope and MiniFuss.

these tools to show you how easy it is to use them to improve the security of your software. BinScope Binary Analyzer is a Microsoft verification tool that analyzes binaries on a project-wide level to ensure that they have been built in compliance with the requirements and recommendations of the Microsoft Security Development Lifecycle (SDL). At Microsoft, use of BinScope is a requirement of the Verification Phase of the SDL.

The best way to learn them is to start from this article.

Hunting Trojan/Virus experience

Several days ago, I was asked to deal with a Virus/Trojan infection situation.

The machine has AVG8 installed but seemed to be unable to protect the Trojan attack. I know with the right kind of anti-Trojan/Malware programs in hand one can make light works in eliminating them. Or could it?

This blog message is not so much about which Anti-Virus program is better than the other but is a collection of experience gained from hunting down a number of Trojans. It also contains description on how best to protect oneself from being infected and secured practices that were actually put to test in slaying the Trojan.

It is most unfortunate that different anti-virus program uses different name for the same Trojan and Virus. I am using Avira and it has identified the Trojans I am confronting as TR/Dldr.FraudLoad.fmb and TR/Crypt.ZPack.Gen. Others like AVG8 calls them SHeurs.BDEF. These are classified as downloader and in particular the FraudLoad is a fake anti-virus often called Scareware that causes the infection.

Below are some of records of my experience and lessons learned.

Always use offline Anti-Virus download link instead

Many Anti-virus program has now switched over to downloading a small stub download program and with which then downloads the remaining components. Do not use this stub program if you want to inoculate the infected machine offering it some protection because this kind of program requires a connection to the Internet, see the attack description below.

Thankfully AVG8 has offer a offline download link which allows one to download the full version.

TR/Crypt.ZPACK.Gen spreading infection mechanism

This trojan utilises the Microsoft's provided AutoRun mechanism to spread the infections to other machine. This is how it is done:

• A process located in C:\Recycler\<SID>\WmiPrvse.exe launched and attached to Explorer.exe is responsible for spreading, where <SID> represents the SID of the user.
• The Trojan creates an entry in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon!Taskman=C:\Recycler\<SID>\WmiPrvse.exe and the trojan causes Explorer.exe to query this registry entry periodically. You should remove this as Taskman is not a valid Microsoft Windows entry.
  
• When Windows senses a new USB device is plugged into the machine, this evil process will create a fake \Recycler on the USB drive even when it is formatted with FAT/FAT3 partition.
  
• It is also structurally incorrect designed to hide the malicious code using a well known folder name and to fool people.
• It then copies the malicious code called Explorer.exe to the fake recycler folder.
• It creates an autorun.inf file on the root directory that contains instruction to launch the malicious code with the help of Microsoft's Autorun support when it is inserted into another machine, thus completing the spread.
• No doubt this Explorer.exe will contain code to load it into some less obvious location to burrow into that machine to infect it.
  

I have always thought of disabling autorun permanently is sufficient to protect oneself. This is proven to be half correct.

Disabling autorun on a machine only disabling the launching mechanism that was used by malicious code to infect the machine. It does not prevent the malicious code already entrenched in an infected machine from infecting a USB drive making it the unwitting carrier of the malicious spreading code. Therefore it is so important not to plug a USB drive into any machine that

1. You do not know if it has autorun enabled
   
2. If the USB Drive carries the attacking code.
   

If you do not know, hold down the shift key while inserting the USB Drive into the machine and maintain holding it for a minute or two. This is will stop Windows from executing the instructions in the autorun.inf file.

Afterward make sure you scan it on a machine that has autorun disabled to ensure that it is not a carrier.

After seeing this and examining the content of the autorun.inf, it is certainly dicing with danger in leaving autorun enabled on all drives; it must therefore be disabled.

This is the content of the fake Recycler folder captured on the USB drive I was using it (a different USB drive from the tools carrier) to retrieve data from the infected machine.

Volume in drive K has no label.
Volume Serial Number is AE6B-BD53

Directory of k:\recycler

11/09/2009  06:05 PM    <DIR>          .
11/09/2009  06:05 PM    <DIR>          ..
12/09/2009  11:55 AM                64 Desktop.ini
12/09/2009  11:56 AM           106,496 explorer.exe
       2 File(s)        106,560 bytes
       2 Dir(s)     112,531,456 bytes free

Use a write-protected medium to carry tools

My practice is always to use a USB Drive that has hardware write-protection mechanism to transport tools to analyze the infected machine preventing malicious code from subverting the tools. When that is not available, I frequently use a SD-Card which always has the hardware lock mechanism to protect my tools and hosted it in a SD-Card reader like this.

The above observation proves that a write-protected USB drive is a must have device in carrying out investigation.

Furthermore, it is highly desirable to have tools that

• do not have to installed into the target machine.
• runs from a write-protected device
• run as command-line utility as they can then be chained into one submission.
• Do not need the access of the Internet during installation.
  

Sadly not one anti-virus scanner meeting the above stringent requirement. The Panda Command line scanner one comes near, except that it needs to write to the device. Avira also has one but to get the full benefit one needs to supply the licence key to it.

What does TR/Dldr.FraudLoad.fmb do?

The purpose of this trojan is to download malicious payload and is believe to belong to a class of software called Scareware to allow it to gain a foothold of the machine. It monitors if the machine is connected to the Internet and if not it becomes dormant. Hence I exploited this behavior to study this program and to defeat it. This is a record of its evil doings:

• Downloads the payload, called windows_update[1].exe into the temporary internet file directory. The numeral inside the bracket may be different.
• It creates a copy of itself in the %Temp% directory with a file name of this format [0-9][0-9][0-9]\.exe, e.g. 126.exe, and these numbers are randomly generated.
  
• It then launches this program, say the 126.exe, to begin the attack.
  
• The program then checks to see if system set up is in progress by examining the HKLM\System\SystemSetipInProgress registry value.
• It also seems to have scan of which IE patches have been applied.
• It also check for the presence of other fake anti-Virus programs such as AntiVirusXP, RealAV, AVR.
• It also disable the ability for the user to launch the Task Manager from the task bar by setting this HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\System!DisableTaskMgr=1. Hence to study this trojan you have to launch the TaskManager before connecting the machine to the Internet.
• It creates the following named values NoSetActiveDesktop, NoChangingWallpaper, NoActiveDesktopChange intending on controlling the desktop in this registry key: HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer.
• It copies itself as winupdate.exe to C:\Windows\System32. I have managed to disrupt this trojan's progress by using a custom built program that hold a file of this name opened with deny share access attribute before the machine is connected to the Internet and maintaining that hold during the attack. It failed to copy the attacking code to this directory.
  
• It then creates the following registry entry intended on launching this malicious code when the machine is restarted: HKLM\Software\Microsoft\Windows\CurrentVersion\Run!WinUpdate.exe=C:\Windows\System32\WinUpdate.exe.
• The program with the 3-digit name, like 126.exe, then launches winupdate.exe and drops out of the scene. The Trojan do not attempt to delete the instance of this file with a 3-digit name in the %Temp% directory, not very smart.
  
• Winupdate.exe then register the malicious COM component called C:\Windows\System32\WinHelper.dll by calling Regsvr32 /s.
• It also looks for C:\Windows\System32\AdvancedVirusRemover\PAVRM.EXE, a well known fake anti-virus program that is in fact a virus.
  
• Winupdate.exe, then launches fake warning of malicious code detected and advising user to press the balloon to download protection code, which is nothing more than a ploy.
• It also attempts to shut down CMD instances but failed to take care of Command.com instance, which I exploited this mistake to regain control.
• It also attempts to block launching of other GUI applications until this winupdate.exe is terminated.
• It also then creates a file with 2-digit name, like 41.exe, of 0 byte in C:\Windows\System32 whose purpose remains unknown.
• Winupdate.exe remains running to disrupt the desktop and one can only regain control of it by terminating this process. PsKill is the ideal tool to do this.

Are these two Trojans related?

On the infected machine, AVG8 did not seem to offer any protection at all. There are even signs that they subverted Spybot Search & Destroy because their scanning and TeaTimer.exe offering only token protection. My observations of the operations of these Trojan were made while they were in operations showing little effect in detecting these key files containing malicious code.

I suspect these trojans are either related or utilizing one single malicious process to attack the machine. They seemed to be using C:\Recycler\<SID>\WmiPrvse.exe as a main source of maintaining control and attack. Because it is controlled and held opened by Explorer.exe it cannot be terminated easily.

The way I eliminated this process is to use DOS command chaining technique as follows:

pushd C:\Recycler\<SID> & j:\PsKill Explorer & del /A:S wmiprvse.exe

where <SID> represents the SID of the user. This sequence of commands does the following:

• Change the directory to where wmiprvse.exe is located
• Terminate the Explorer process that is holding onto the wmiprvse.exe process
• Delete the malicious code which is marked as a system file called WmiPrvse.exe.
  

Bear in mind that when I submitted these command, the process WinUpdate.exe was not running and it was not connected to the Internet.

Once this malicious code is removed and terminated, the system becomes normal and reinstallation of AV is possible allowing them to do the job to get rid of files such as WinHelper.dll and other relatively less stubborn malware lurking around.

Dangerous & foolish not using LUA

My experience in this involvement further vindicates my view that people not using LUA is really asking for trouble. It also reinforces my view that it is dangerous leaving Autorun enabled.

Sure one can rely on Anti-Virus to protect oneself but can it be all that effective? What about the window of opportunity available to exploit code that is not yet protected by Anti-Virus when your machine's operating system's security defense shield is turned off?

As reported above, all those exploits they used are so simply and effectively blocked by not running in administrator's account. That's the defense shield, if allowed to operate, will block the above exploit without even the aid of anti-virus program.

Sure, it can still disable the task manager from being invoked but it could not succeed in planting anything more malicious in system folders and registry keys. All it can do is to inconvenient you that dirty deed could easily be removed.

It is impossible to determine if the ACLs of the system files and registry areas have been tempered with prior to the infection or as a result of the attack. A detail scan using AccessChk of the vital areas show that it is impossible to switch the just rescued machine to operate effectively in LUA mode without a full reinstallation. That part of security appears to have been irreversibly damaged.