Tuesday 6 October 2015

IT security in near future

These are just thoughts that came to my mind. Being in the security industry for past 2 years, I've got to learn a lot about computer security.
There was a age when computer security was only confined to some sectors of government organizations. After internet flourished between the common people, viruses, bots etc(commonly termed as malware) become more prevalent. And now as the days pass on, the e-commerce has taken a good pace. Just imagine of how much of online transactions are carried on every day. Every bit and piece of information is being digitized. Attracting more and more looters to get in cyber crimes. This has tremendously increased the number of malware's in the market. And this is why, computer security applications entered the market.

Signature based detection

The very basic logic of finding a malware is to create a signature of a malware, and then use this signature to detect the malware.

What are signatures?
Signatures are basically the bit patters present in the files of the malware. These signatures are designed by the industry experts so wisely, such that it matches only the malware's binary file. You will find a lot of information pertaining to this on the web.

In-fact, today there are more than millions of malware's in the online market, may be even more. That means millions of signatures, and scanning each binary file on the machine against each signature, though this can be reduced by using some techniques, its a substantial count. This count will increase day by day as the new malware's are added to the detection list. How long can this be supported, is a difficult question to answer.
The very basic logic how these malware's infect a machine is by exploiting the vulnerabilities on the machine. Vulnerability in a software (can be operating system) is a security bug (flaw), that allows the malware to enter in the system and execute itself.

Ingenious Techniques

Vulnerability Scanning

This type of detection technique scans for the vulnerabilities present in the system. The users are educated about the various vulnerabilities present on the system. These type of scanners usually categorize the vulnerabilities on the basis of their risk. And also informs how to fix these vulnerabilities, if a fix (patch) is available.
The advantage of vulnerability scanning is that it helps the user to identify the flaws before the malware even finds your machine. However, the fix needs to be applied, only vulnerability scanner is no good. The updates that you usually get for any application not only contains new features, but also contains security patches, that fix the existing known vulnerabilities in the application.
Some scanners actually attack the system to detect the vulnerabilities, these innovative techniques sometimes find the flaws even before an attacker can find them. These vulnerability scanner range from desktop clients, mobile to network devices.

Vulnerabilities need to be fixed. 

Behavioral Based Detection

As most of the malware's are just designed to exploit the system for resources (data, processing power, storage etc), it has to do some task that is apart from the normal functioning of major applications. This makes it stand out from others. Security researchers found this as a novel technique to detect an existence of a malware on the system. eg. if a software other than the mail client is trying to send an email, its operations are blocked and the user is queried if the application sending the email is a legitimate application. If the user identifies it to be known application, it is allowed to proceed, else the application is terminated and stopped from getting executed in future.
The major advantage of this technique is that, its a very generic way of detection. Even a malware that is not yet known in the market can be stopped effectively.

You misbehave and you are thrown out.

As of today, the above 2 techniques seem to take over the IT security industry in the near future. As the malware writers bring in new techniques, the computer security industry is also emerging with new ways to defend it. And this is going to go on for ever and ever and ever.
I have just tried to touch some basic aspects of these techniques, so that they can be understood easily. Actually these topics are as big as, one can write huge reference books on each. These methods have been in the industry since a while, however, it might not totally replace the traditional signature based scanning, but will surely gain much more importance, in near future.

If you have any thoughts about this, surely add it into the comments.

Monday 17 August 2015

Multilingual support in MSI, using ORCA tool.

I am writing this into a blog because, as usual this took a lot of time for me to get through. I am new to MSI, and started with the ORCA tool to edit it. Not one of the good tools to start with, as said on the web. I think understanding ORCA takes some time, but once you understand, you know the very basics of MSI.
Below i have discussed, how one can create MSI installers in languages that are not supported in visual studio by default.


What do i mean by localization of MSI

By default the MSI installer project in visual studio, builds the project in english. That is, all the strings displayed on the UI(User Interface) of the installer are in english language (English U.S.).

The term localization refers to the language used in the UI should be in the local language of the customer, or to be more precise, it should be in the same language as his operating system.
Example: If a arabic build of windows is installed, the strings in the UI should be in arabic. The people in france will see the strings in french. This adds more value to the product, in terms of ease in use.

The image is the snapshot of visual studio, that shows the localization setting in visual studio.
Actually visual studio itself supports some languages apart from english.

The Following is the list of languages supported by visual studio for a deployment project, i.e. msi project.

Lets get known to some tools that are used while creating a msi.


The ORCA tool:

ORCA is a very basic, but a usefull tool to edit the MSI tables. Almost all the information in the MSI is displayed in ORCA, in form of tables, Each table is described on MSDN, in detail over here.
Example: The file table lists all the files that are packaged in the MSI installer.
When the project is built, the default language is english.

MSI Language:

The ORCA tool can be used to edit the strings in the MSI installer. The Property table contains a row named ProductLanguage, that tells the language for which the MSI was built.

Code Page:
The code page setting is not shown in the ORCA tables, instead it is present in the menu bar. To change the code page of the current MSI file,

Tools->Code Page...
Set the new code page in the New Code Page text box.


1. If the code page of the installer is not changed, some unreadable characters will get displayed on the UI.
2. Each language requires its own transform file, generated from the MSI of the code page for that language
Eg: Transform file generated from language L, cannot be applied on MSI of any language, other than L.


This script can be used to change the current language and the code page of the MSI file
More Info: https://msdn.microsoft.com/en-us/library/aa369791(v=vs.85).aspx


This tool can be used to apply the transform file generated from the ORCA tool.
More Info: https://msdn.microsoft.com/en-us/library/aa370495(v=vs.85).aspx


Create a MSI with localization value set to neutral.
For each a language ‘L’,
Change the code page of the MSI to CodePage(L), using orca/wilangid.vbs
Change the language of the MSI to language L, using orca/wilangid.vbs
Open the MSI in orca tool
Do the necessary string localization related changes,
Generate the base transform file T(L)


Once the base transform files are created for each language.
Following steps can be used to create a MSI for language L.
Create a MSI with localization set to neutral.
Change the codepage using wilangid.vbs script.
Change the language to L using wilangid.vbs script.
Modify the transform file for L, if required.
Apply the T(L) on MSI

All of this process can be easily automated.


Keep Exploring.. :)

Tuesday 23 June 2015

Found XSS vulnerability in Manage Engine Asset Explorer v6.1.

ManageEngine Asset Explorer v6.1 - XSS Vulnerability



Product & Service Introduction (Taken from their homepage):
ManageEngine AssetExplorer is a web-based IT Asset Management (ITAM) software that helps you monitor and manage assets in your network from Planning phase to Disposal phase. AssetExplorer provides you with a number of ways to ensure discovery of all the assets in your network. You can manage software & hardware assets, ensure software license compliance and track purchase orders & contracts - the whole nine yards! AssetExplorer is very easy to install and works right out of the box.
(Homepage: https://www.manageengine.com/products/asset-explorer/ )

Abstract Advisory Information:
Cross site scripting attack can be performed on the manage engine asset explorer. If the 'publisher' name contains vulnerable script, it gets executed in the browser.

Affected Products:
Manage Engine
Product: Asset Explorer - Web Application 6.1.0 (Build 6112)

Severity Level:

Technical Details & Description:
  1. Add a vendor with a script in it to the registry.
  2. Login to the product.
  3. Scan the endpoint where the registry is modified.
  4. In the right pane, go to software->Scanned Software
  5. The script gets executed.
Vulnerable Product(s):
Manage Engine Asset Explorer

Affected Version(s):
Version 6.1.0 / Build Number 6112
(Earlier versions i did not test)

Vulnerability Type(s):
Persistent Cross Site Scripting

Add the following registry entry in the machine, for targeted attack.

Windows Registry Editor Version 5.00
"DisplayName"="A fake software 2 installed"
"UninstallString"="C:\\Program Files\\fake\\uninst.exe"
"Publisher"="<script> alert(\"XSS\"); </script>"

Security Risk:

Credits & Authors:
Suraj Krishnaswami (suraj.krishnaswami@gmail.com)

Discovered at Wed, March 3, 2015
Informed manage engine about the vulnerability: March 4, 2015
Case moved to development team: March 4, 2015
Asked for updates: March 9, 2015
Asked for updates: March 13, 2015
Asked for updates: April 14, 2015
Public Disclosure at Mon, June 22, 2015