Checkmate » Case Studies

Risk Analysis of Android Based Appliance

Pralhad Chaskar — Thu, 24 Nov 2011 10:40:16 +0000

Overview

I had to do the risk analysis of the Android 2.2 – Froyo based appliance and check for any security flaws exist in it before the XYZ Ltd. (just the example) company could launch that product in the market.

Background

How I get connected to appliance
At start of my task I first assign an IP address (here 192.168.1.88) to the appliance, and ensure I have necessary connectivity to the appliance. The next obvious task is to run a port scan. I use NMAP and to my dismay I find no open ports. I now enabled USB debugging in android appliance by browsing this path of appliance.

Settings > Applications > Development > USB Debugging

Again port scanning the device I found Port No. 5555 Open.

Then I figured out that by Enabling USB debugging opens Port no. 5555 by default. Odd-numbered range of ports from 5555 to 5585 are usually used by emulators/devices (let Nmap to find’s it out for you).

Intermediate between my machine and appliance: ADB

My next step was to place the bridge between my machine and appliance. Here Google helped me by providing us the Android Debug Bridge (ADB) which is freely available .

Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. It is a client-server program that includes three components:
1] A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command.
2] A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.
3] A daemon, which runs as a background process on each emulator or device instance.

Following is the snippet of ADB.

Commands of my interest were as follows:-
1] adb connect device_ip:port_no – connects to attached device
2] adb devices – List all connected devices/emulator
3] adb push – Copy file/dir to device/emulator
4] adb pull [] – Copy file/dir from device/emulator
5] adb shell – Run remote shell interactively
6] adb logcat – View device log
7] adb install [-l] [-r] [-s] – push this package file to the device
8] adb uninstall [-k] – remove this app package from the device
9] adb help – Always helps to view all switches available

What do you mean rooting the android appliance?
Android is basically a reworked Linux. Rooting means getting super user privilege to android device. Rooting thus provide you with access to system files and the ability to change things that normally are marked read only. This allows you to change all kinds of things that normally you wouldn’t be able to, along with install custom versions of Android.

There are multiple applications available for rooting the android eg: z4root, EasyRoot, SuperOneClick and many more.

In my case z4root helped me to become root user, it allows for temporary / permanent root using Sebastian Krahmer’s RageAgainstTheCage method.

Tools help
Android Reversing Toolkit (ART) by Deurus which used to Compile, De-Compile, Re-compile the applications.

Manitree (by IntrepidusGroup) is a tool that will review an AndroidManifest.xml file, APK package, or an entire device (or devices) for insecure values in the AndroidManifest.xml file. This is not the exact way to analyze the APK’s but this tool will help you want to analyze 100′s of APK’s in short span of time and pluck out low hanging fruits.

dex2jar is a tool for converting Android’s .dex format to Java’s .class format which is readable by using Java Decompiler GUI utility.

Let’s Get Started
Here our appliance [Target] IP address was 192.168.1.88. Then I connected to the appliance using ADB.

Are we connected? Let’s verified the same

Uhhh….Finally our appliance is talking to us and we are also able to talk. By using the ADB we get the shell access of the appliance by using the command as follows.

Firstly I got the non-rooted (not able to browse all directories and files) appliance and want to pull out all the application (apk). Hence in order to get the path of each application’s installed, I need the packages.xml file. This file helped me to figure the exact path (codePath) of each apk located under /data/app directory (not available usually for non-rooted) of android. Following is the command for the same.

adb pull /data/system/packages.xml

In my case the desired application was in /data/app directory, so i was able to pull APK file from the appliance even if my appliance was non-rooted. But suppose your desired application is located in /data/app-private directory, and then you cannot pull out applications (apk) from non-rooted appliance.

Then i thought of rooting the appliance using the z4Root to get deeper insight of appliance and underlying OS.

And following are the directories and files we could find under root directory. Here our ADB daemon is only running with privilege of root by default.

Under the /system/app we could find all the applications installed in the appliance.

Then we can pull the respective *.apk file via ADB.

An .apk file extension denotes an Android Package (APK) file. This file format, a variant of the JAR format, is used for distributing and installing bundled components onto the Android operating system.

After pulling the desired apk, I used ART (one method to look into apk) to decompile the apk can be used to Compile, De-Compile & Re-Compile the applications. The steps involved in De-compilation are as follows:-

Now my concern was to dig in this APK file. So just rename the *.apk to *.zip (it is another way to look into apk). Unzip the respective file. Following are the contents of the same.

AndroidManifest.xml is a required file for any application. It describes the name, version, access rights, referenced library files, and other information of the application. The AndroidManifest.xml contained in the .apk file has been compressed.
META-INF Directory, where signature data is stored, is used to ensure the integrality of the .apk package and system security.
Classes.dex is a java byte code file generated after the compilation using java source codes.
Res directory is used to store resource files.
resources.arsc is a binary resource file after compilation.

By just supplying the AndroidManifest.xml file to Manitree, it will generate the report mentioning the improper permissions granted to application with severity. Following is the usage for the same.

So let’s check in the code of AndroidManifest.xml which is pointed out by the Manitree.

In above image means that anything that is located in a path that starts with “/” is able to access the content-provider of any other application. For better understanding ContentProvider are used to provide data from an application to another (eg: – Social networking app which could access the photos from Gallery, so here Social Networking app & Gallery are sharing the common resource). ContentProvider do not store the data but provide the interface for other applications to access the data. Hence in our case instead of it should be ” />

Now let’s concentrate on Classes.dex file. This file can be decompressed using the tool dex2jar.

Now open generated classes.dex.dex2jar.jar file using Java Decompiler GUI [jd-gui].

Expanding each tab we could actually read the code.

Going through the non-obfuscated code we can understand the flow of code and working of Application. In order to prevent this we can use “ProGuard” tool which shrinks, optimizes and obfuscates your code and renaming classes, fields, and methods with semantically obscure names. The result is a smaller sized .apk file that is more difficult to reverse engineer. After usage of Proguard code looks as follows.

Next step was is there any database in backend for application to store the data. This I could figure out in /data/data//databases/ folder. Then by using the ADB we can pull the desired database file on our machine.

Android as whole uses SQLite database to store the data for each application. We can view the contents of extracted database file of desired “package_name” using the addon in Mozilla Firefox named SQLite Manager 0.7.4 or tool named SQLite Maestro.

Now I can read the un-encrypted database entries and also execute the SQL queries to refine your result.

While this entire activity is running always keep “logcat” open in one of the terminal/command-prompt. Logcat has mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command. Following is the command for the same.

adb logcat [

Exercise ended with following Risks
1] Root-level Access to system
2] Installation of 3rd-Party APKs
3] No authentication to access to system
4] Remote Connection/Management of Device
5] Vulnerability in the underlying OS
6] Insecure Coding Practices
7] Unrestricted Browsing permissions
8] Manual Vendor Updates
9] Loss of the Device
10] Database entries are not encrypted

Best Coding Practices for building secure Android application (Source: Google)
1] Maintain a privacy policy
2] Minimize permissions
3] Give your users a choice regarding data collection
4] Don’t collect unnecessary information
5] Don’t send data off the device
6] Use encryption and data minimization
7] Don’t use code you don’t understand
8] Don’t log device or user specific information
9] Use Proguard- Code obfuscation mechanism
10] Performing Input Validation

Social Engineering & “Influence”, by Dr. Cialdini

K K Mookhey — Thu, 03 Jun 2010 07:10:40 +0000

Over the past few years, we have completed a number of social engineering tests as part of advanced penetration testing at various organizations. Coincidentally, I recently read an excellent book called “Influence – the Psychology of Persuasion” by Dr. Robert Cialdini.and realized that it has some excellent lessons for anyone wanting to guard themselves from social engineering attacks.

Dr. Cialdini’s book is an excellent coverage of what he calls “compliance professionals” – people engaged in hard-core door-to-door selling such as second-hand car salesman, multi-level marketing (read Amway) professionals, etc. He talks about the following 6 techniques adopted by these professionals to convince people to buy things they were never going to buy in the first place. The same techniques can also afford the social engineer easy access to information, and it is worthwhile for information security professionals to examine what the other breed of “compliance professionals” is up to!

1. Reciprocation: We are hard-wired to respond to a favor, often not in direct proportion to the size of the favor done to us. One such example given by Cialdini is the aid given in 1985 by Ethiopian Red Cross to earthquake victims in Mexico as repayment of aid given by Mexico when Ethiopia was invaded by Italy, way back in 1935! For the original news article click here.
Practical exploitation:
We used this technique to deadly effect by inducing a systems administrator to disclose highly confidential information about their set up after providing him with lots of study material for the upcoming CISA exam.

2. Commitment and Consistency: Once we have made a choice or taken a stand, we will encounter personal and inter-personal pressures to behave consistently with that commitment.
Practical exploitation:
During one such test, we posed as auditors and started interviewing the system administrators. After a couple of days of helping us out with information, they led us to the other departments in the organization and further facilitated our “audit”. It was only on the 5th day that someone raised an alarm, but during the first few days once the personnel had hard-wired themselves into co-operating with us, they just went all the way, without even checking our credentials!

3. Social Proof: One means we use to determine what is correct is to find out what other people think is correct. The principle applies especially to the way we decide what constitutes correct behavior.
Practical exploitation:
This is most simply exploited during a social engineering test by leveraging the power of social networking sites such as LinkedIn and Facebook. An attractive enough profile with other members of your organization linked to it is highly likely to make you add it to your network as well, with no clue as to the profile’s veracity.

4. Liking: Few people would be surprised to learn that, as a rule, we most prefer to say yes to the requests of someone we know and like.
Practical exploitation:
Our most successful attempts have involved sending our more likeable people across asking for help or requesting for information to complete a “college project”. These individuals are usually well-groomed, smart, personable, and possess decent levels of charm or naivete to get the other person to comply.

5. Authority: The famous Milgram experiments show the power of authority in comparison to all the other factors listed here. The real culprit is our inability to resist the psychological power wielded by the person in authority.
Practical exploitation:
We have seen this work in numerous ways by faking authority letters purporting to come from some government agency or from the managing director of the company. A lot of the times the recipient will simply comply with the request. The same effect is seen when depending on which car one is in, and how one is dressed, the security guard at the gate will adjust his level of obsequiousness.

6. Scarcity: Collectors of everything from baseball cards to antiques are keenly aware of the influence of the scarcity principle in determining the worth of an item.
Practical exploitation:
One of the most common tactics is to build time pressure. The scarcity of time often makes people comply with requests in violation of their policies and their own common sense. We have used this on numerous occasions be it with a security guard or with a system or network administrator.

For other interesting social engineering experiments, search for “the real hustle” on YouTube for the BBC program that shows how as humans we easily fall prey to the smart hustler who sweet-talks his or her way into social engineering us.

Hacking Microsoft Windows 2003 Server with Microsoft SQL Server 2005

TAS — Tue, 08 Dec 2009 05:30:53 +0000

This post is a complete switch over from my previous post on phishing modus operandi. A little background on the hack. I was doing an assessment of a financial application; the objective was to evaluate the security of the complete infrastructure on which the application will be hosted once it goes live. As oppose to the routine list of findings this particular hack took the limelight. It was system compromise with Administrator access to the system. Yeah!

It was last day of our assessment; I had little time on hand before I could wind up for the day. So I thought why not bash the ‘sa’ account. I open the Microsoft SQL Server 2005 Management Studio and try some brute forcing for ‘sa’ account with common passwords, I get errors and disappointments. But this was short lived, it dint take me more than 7 tries to get the combination right. And that opens my way into the system.

Once I was inside, the next step was to use the stored procedure xp_cmdshell. The “xp_cmdshell” extended stored procedure runs operating system commands from within the database engine. You can use the query analyzer or T-SQL code to run the command. Back to the hack, I than open the query analyzer and type the following command

exec xp_cmdshell ‘dir C:\’

Though I was logged in ‘sa’ account (the highest privilege account in SQL server), as expected I get this long error message.

Msg 15281, Level 16, State 1, Procedure xp_cmdshell, Line 1
SQL Server blocked access to procedure ‘sys.xp_cmdshell’ of component ‘xp_cmdshell’ because this component is turned off as part of the security configuration for this server. A system administrator can enable the use of ‘xp_cmdshell’ by using sp_configure. For more information about enabling ‘xp_cmdshell’, see “Surface Area Configuration” in SQL Server Books Online

In short the error means, I cannot use the xp_cmdshell stored procedure to do my hack. Microsoft (MS) has turned this stored procedure OFF in the version above SQL 2000 as a part of the security configuration. The previous versions of SQL Server 2005 had full access to xp_cmdshell turned ON in the default setup. And hence it was easy to do the system compromise. One obvious advantage of disabling the xp_cmdshell is, once a hacker gets access to the SQL server, the system compromise would not become a cake walk. But let’s check out how you can still do cake walk on version above Microsoft SQL Server 2000. Just a little tricky but easy

If you read the error carefully it gives out a lot more than it should. Check the last line of the error message. It says xp_cmdshell can be enabled using the “Surface Area Configuration”. I further Google and get plenty of articles that tell me how to use Surface Area Configuration wizard to enable the stored procedure. They would ideally work but it dint work for me for whatever reason. If you want to enable xp_cmdshell with Surface Area Configuration method on your own system, try the following

Goto Microsoft SQL Server 2005
Configuration Tools > SQL Server Surface Area Configuration > Surface Area Configuration for Feature > Expand the SQL server Instance name > Under Database engine goto xp_cmdshell > Check “Enable xp_cmdshell” and Apply

That’s it, you can have now enabled xp_cmdshell for your own box. You can again run the command mentioned above. You should not get any error now. The image below summarizes this

Fig: Enabling xp_cmdshell using the Surface Area Configuration Wizard

I had to enable xp_cmdshell on the remote system. I open my SQL Server Surface Area Configuration wizard and click on “Change computer” and specify the remote system SQL server instance name (or IP). It popped me with some error. I tried a few time but phew! It does not work for me. It was time, I try something else. I go back and start to find if there was some a command line to do the same thing. Again a few searches and I get my results. You can enable the xp_cmdshell in 4 simple steps.

1) EXEC master.dbo.sp_configure ‘show advanced options’, 1 (ONE means ON, ZERO means OFF)
2) RECONFIGURE
3) EXEC master.dbo.sp_configure ‘xp_cmdshell’, 1
4) RECONFIGURE

sp_configure displays or changes global configuration settings for the current server. And the ‘sa’ account has privileges on this stored procedure. Eh! sp_configure is my key inside the system. So I first enable all the advance options than enable the xp_cmdshell. The image below shows my ‘xp_cmdshell’ in action on the remote system.

Fig: xp_cmdshell in action on victim system

Once I enabled xp_cmdshell, it was time for me to add user. So I type the following commands at the query analyzer console,

1) EXEC xp_cmdshell ‘net user pwnsauc3 h3ll0w0rld$ /ADD’
2) EXEC xp_cmdshell ‘net group Administrators pwnsauc3 /ADD’

In case the remote terminal service is not ON, goto to Start > Run and type service.msc. Right click on the parent node and connect to remote services and use the above username and password. Start the Terminal Services. You can now sit and relax; you are a step away from administrator access to the system. Fire up your remote terminal client and type in the IP and login with the user name and password we created. The images below conclude my hack.

Fig: Verify the user addition from command line

Fig: Remote terminal to the victim system

Fig: Verifying the user added to Administrators group

Adios!
Taufiq Ali

A Phishy Story

TAS — Thu, 05 Nov 2009 12:17:40 +0000

Phishing sounds similar to fishing. Fishes are to the volume of internet users today much like fishermen are to phishers. Zillions of fishes falling prey the nets is nothing less compared to internet users being phished through their own in boxes and messengers. Phishers tend to have some personal favorites – personal information, credit cards numbers, debit cards numbers with ATM pins, etc. Though phishing has been around for a long time, it became more prominent back in 2003. You can read more here on the big scams here.

How does it all work?

A typical modus operandi:

1) The Phisher would either go out and buy a phishing kit from the underground channels or create a look alike page himself.

2) He would then need hacked websites or a server where the pages can be hosted. This can also be easily made available. He would pay or trade for a list of hacked websites on IRC channels, underground forums etc. These are some very common sources for such deals. He could also target systems that are vulnerable to a particular vulnerability or weakness in the website – vulnerability in the hosting providers control panel software, exploit for popular CMS like Joomla, 0day vulnerability in web server, etc. A zero-day (or zero-hour) attack or threat is a computer threat that tries to exploit computer application vulnerabilities that are unknown to others, undisclosed to the software vendor, or for which no security fix is available. (ref : http://en.wikipedia.org/wiki/Zero_day_vulnerability)

3) Once the hacked infrastructure is ready it’s time to spam. They would ideally send out emails in large volumes. These emails are crafted to perfection. They would have the company logo, an appealing message in the email; use the CSS as the company that is phished, etc. All this together make it look perfect. It’s like decorating the devils face with cosmetics to make it look innocent. But not to forget the devil under a thin layer of cosmetics. They will have a crafted link and the hyperlink actually pointing to some website where the pages are hosted.

However, the entire process is a gamble. Some may fall prey to their phish nets while others may not. Over the years, phishing scams have grown from simply stealing accounts into much more dangerous criminal intention. Assuming the user is a prey of the phish net, let us understand the ways in which a phisher can harvest the data of the victim. There are various ways in which this can be done.

1) The attacker here uses services of websites that let you send HTML forms embedded in your email. On submit of this HTML form the phished page will redirect you to the legitimate website. This often tricks the user. They don’t realize what just happened. The details entered on the form are then emailed to the phisher’s inbox that is supposed to collect the details. The most common examples where you can see them are when advertising on the internet.

2) Second, the email is scripted in a way that a user is tempted or forced to visit the copied website. The attacker can also use the tactic mentioned above and use services like www.emailmeform.com. Attacker creates an account here and links his entire phished page to use their service to capture the details and then email it to them. This is the most common method used by phishers. Also the pages are scripted in server side programming languages like PHP, .NET, JSP etc. Doing so it does not expose the modus operandi or the attacker’s identity in any way or other details in any way.

3) The third type is where the phishers use nothing like above and instead writes all the output to a predefined file. In this way he needs no email address or anything mentioned above to capture the user details. This is what I am exactly going to write about.

Since I had some time off before I could start with the next takedown, I decided to dig further. Before we begin let me give you a brief about our service and the client. We offer take down services to a large public sector bank. We have a strict timeline defined of 24 hrs for every takedown. Every time a customer or their monitoring reports a phished page we have to takedown the site to protect the loss of financial and other details. While doing takedowns I also get a chance to research on understanding the modus operandi behind the operation. It is very interesting.

I have just started my day checking my email over a cup of coffee. I receive a new email on Tue 11/3/2009 10:22 AM about a phished link being up with the URL and we need to immediately start the takedown. He also sends me a sample email. We did the usual process and the link was down by noon. Have a look at a sample phishing email.

The email looks so real. It has the logo of the customer and perfect login URL. On hover I found it was actually pointing to some server in Russia. The page ‘retails.html’ simply redirects to the next URL where the phished page is hosted. Have a look at the closing lines of the email below. The phisher uses pressure tactic that will force the user to browse the URL.

Ok I now click and I am now redirected to the URL http://200.119.X.X/retail/login.php. The page looks like this

I then enter some fake details on this page and press the Enter key. I am now redirected to another page called ‘accounts.php’ on the same domain. I quickly check the html source code (view source) of the page to check for the

tag. This is where I would see where the page is going on hitting ‘submit’. I am now redirected to another page hosted on a hacked domain called hxxp://stirileprotv.fnhost.org/bi/ib.php

I go a level up in the URL hxxp://200.119.X.X/retail/login.php and now I see the directory listing. I see 2 files under the retail folder namely ‘login.php’ and ‘accounts.php’. Directory Listing has been common in all my takedowns. They don’t really care for the directory listings. What I also observed, at the bottom of the ‘account.php’ page is more interesting. The page is has an IFRAME with src pointing to http://statanalyze.cn/lib/index.php. This is some malware getting downloaded on victim system.

My anti virus immediately pops up an alert that a malware is getting downloaded. And it immediately blocks it. Coming back to ‘accounts.php’ it asks for my Name, email address, credit card number, ATM pin and expiration date. On entering some fake details I am now redirected to a third domain hxxp://stirileprotv.fnhost.org/bi/ib.php. And from ‘ib.php’ it redirects me to the legitimate page of my client website. I have changed that to hxxp://www.google.com in the code snippet. Aren’t these guys sick of so many re directions? Not really they have a smart modus operandi. They don’t use one domain to complete their operation.

I again go a level up on the http://stirileprotv.fnhost.org/bi/ib.php. What I happen to find is something even more interesting. It had a page ‘ib.php’ under the ib folder and a .txt file. When I tried accessing the file what I find is the actual account details of the people who have fallen prey to the trick with their usernames, credit card numbers, internet banking IDs and passwords. Check file snippet below

I then contact the client to freeze the accounts and get in touch with the hosting providers. I make sure I ask the hosting providers to provide me with the pages as they aid to my research in understanding various modus operandi out on pr0wl. Most of the time they don’t give the pages but this time I was lucky. The tech support guys actually emailed me the contents of the ib folder. Have a look at the php code

Let me explain the code in brief. It opens a stream to a file called x-account-all.txt and then captures the post variables from the URL http://200.119.X.X/retail/accounts.php. The following table explains what each variable means

I thought that was it. I was done with my research. I relaxed a bit and stretched my arms. But hold on readers I recollect that the website was also vulnerable to IFRAME injection. No more research on this malware guys I have colleagues who enjoys this. I will send this to him. Till he comes up with his analysis there are some who have already done it. Check the link below

http://wepawet.iseclab.org/view.php?hash=363c95666cf1e80072656c7b562c4dbb&type=js

http://anubis.iseclab.org/?action=result&task_id=1c109b3e2cc07d1f49168943cc884e1d2

http://www.virustotal.com/analisis/837508d65acc78ec684c0d7a907bea7f49ce223052a18a076240018fc61a0d7f-1257141946

I was still way too itchy to pull down a full stop. I picked some arbitrary entries from the file and picked the ‘ea’ and ‘bb’ field. Why only them? (I got this particular combination after trying out a few) I was able to login to the Yahoo accounts of the victim since the password used was the same for both the accounts. I then checked the spam box and found the email that the victim had received. There were similar emails and to my surprise I found another URL hosting the phished page. Ok guys that’s it, I need to get back to my next takedown immediately  Oh! By the way, this time it is some Windows 2003 server behind some ADSL router running the phished page on a XAMP server. I did RDP to the box, 3389 was found open. I will come back if I find something more interesting.

All the details in this post have being changed or rename to protect real identity of our client.

Adios!
Taufiq Ali

Deobfuscating Javascript Malware

Wasim Halani — Thu, 01 Oct 2009 11:20:32 +0000

Some days back I was greeted by a Google Safe browsing warning when I tried visiting a ‘known’ site. As I was sure it was supposed to be clean and harmless site, I thought it would be good to dig further into this problem. The trail led to interesting amounts of codes, concepts and techniques.

Malware writers are very smart nowadays (haven’t they always been ?). They know that once their code is understood it most likely to be detected by anti-malware applications. To delay detection by such applications, they resort to a wide range of techniques. In this blog post I’ll be discussing the most potent and easily created malware.

Javascript has become the boon and bane of the Internet. It provides greater interactivity with the user but can also be used by malware writers to infect innocent users. Javascript is a client-side scripting technology which means the processing of the script is handled by the user’s browser.

Obfuscation is the concealment of intended meaning in communication, making communication confusing, intentionally ambiguous, and more difficult to interpret.

JavaScript is sometimes obfuscated to prevent users from easily understanding their functionality. ( Legitimate uses are to prevent stealing of code)

There may be many ways to obfuscate a code and similarly there may be multiple ways to de-obfuscate a code. What I’ve presented below is very raw and cannot be used to analyze many malicious JS. But since this is the beginning for me, I thought it may help others too.

Disclaimer: Links presented below are live at the time of writing this blog post. Please do not visit them if you do not know what you are getting into.

First thing first, we need to get the HTML source the malicious page. We can either use wget/curl or Malzilla, which is what I used. It was observed that this page is dependent on the HTTP referrer. So if the domain receives a request for the page without a ‘valid’ HTTP referrer page, the page is not returned.
We get the ‘bad’ HTML at http://mybetorwager.cn:8080/index.php with a valid HTTP referrer.

The complete HTML source can be viewed here

The code starts off with the following in the SCRIPT tag.

Vhotzdq(function(p,a,c,k,e,d)

This section of the code shows that the javascript has been packed by the popular Dean Edword JS Packer. This packer is available online as well as in download-able formats. We use a GreaseMonkey script “Decode It!” to enable the online ‘ Decoder‘ on the webpage.

We paste the code from Vhotzdq(function(p,a,c,k,e,d) onwards till the end and rename the function name Vhotzdq to eval. This will help us decode and evaluate the result. The output of which can be found here

—————————————————-

Update
Seems like Dean Edwards had coded an UNPACKER as well. It can be accessed at http://dean.edwards.name/unpacker/. If using this tool, simply replace the Vhotzdq to eval and run the script. No additional GreaseMonkey scripts are necessary

—————————————————-

Fig: Unpacked Javascript using Dean Edwards Packer

As can be seen above, we need to unescape the code to get the decoded output. This can be done in multiple ways:

Replace Vhotzdq as eval, and execute the script
Use the Malzilla decoder feature “Decode UCS2 (%u)”
Use an online encoder/decoder like PHP Charset Encoder/PHP String Encrypter

Fig: Using the 'unescape' feature provided by PHP Charset Encoder

The decoded output of the above step can be found here

Now the code is in a more human readable format. To further complicate analysis, the malware authors have implemented small amounts of string manipulations on the code. Also, the variables used have been obfuscated or mangled. This will not pose a problem to us as the variables can be given any names.

Note that there exists a certain amount of code-block which is still encoded. Another malware analysis shows this section as the Shellcode. I will update this as I get more information on how to decode it.

—————————————————-

Update
OK, it turns out that the segment was indeed the shellcode. Using the Malzilla tool we concatenate the variable “var unf57UBnT”
This presents us with an encoding which seems to be UCS2. Next, we can either use Malzilla to convert UCS2 to Hex (which does not provide reliable results) or use a shellcode to EXE converter available at http://sandsprite.com/shellcode_2_exe.php.

Fig: ShellCode 2 EXE

Once we obtain the EXE from the shellcode, we can analyze this executable in a tool called FileInsight developed by Mcafee Labs. Below is a snapshot of FileInsight analysis output which shows the malicious URL.

Fig: FileInsight - Shellcode.exe analysis

URLMON.DLL is a system DLL generally used by malwares to download files from online locations

—————————————————-
The next step is to execute the ‘replace’ functions which involve Regular Expressions to clean out the manipulated code.
As an example below is the line of code that we currently have in our decoded output.

rqeqG6Spq.setAttribute(‘i#)@d!’.replace(/$|\!|&|\$|@|\^|$|#/ig, ”),rqeqG6Spq);

Let’s take this code in detail:

rqeqG6Spq	–>	declared variable
setAttribute	–>	the property of the variable rqeqG6Spq
/$\|\!\|&\|\$\|@\|\^\|$\|#/ig	–>	Regular Expression
(In JavaScript, to define a regex pattern, we define it between /…../ . ‘g‘ indicates Global Match and ‘i‘ is for Case-Insensitive search)
.replace()	–>	is a JavaScript string manipulation function, which runs the regex on the ‘object’ i#)@d!

After executing the replace() function, the output would look like this

rqeqG6Spq.setAttribute(‘id’,rqeqG6Spq);

Similar replace operations are performed at all other places, till we get the final output as shown here

NOTE: Your Anti-Malware may issue an alert when you try to visit the above link. I have modified the malicious URL a bit so the script won’t move ahead.

We are now at a stage where we can make a few observations on what the JavaScript does and how it works.
The original malicious domain is found to be http://3c8.ru:8080/welcome.php .This domain serves the malware payload.
The script tries to exploit a vulnerability in ActiveX which allows it to download and execute a malicious binary.
I haven’t had the chance to go deeper into the execution of the malware But once I get the time, I’ll look into analyzing the binary as well.

Before I end this long post, just a quick note that to automate this entire process, we can use an online tool called wepawet, which is a service for detecting and analyzing web-based malware. It currently handles Flash and JavaScript files.
You can find the result of the analysis of our malicious page at http://wepawet.iseclab.org/view.php?hash=07fc283602731721a97f196c3ab19092&type=js
It provides for a comprehensive analysis.

Also, do check out the VirusTotal scan results for the obfuscated and deobfuscated Javascript
Obfuscated Detection rate is 2/41
De-obfuscated Detection rate is 14/41

I guess that’s it. Hope you liked this basic tutorial. Do leave your feedback in the comments section below

First conviction under IT Act

admin — Thu, 07 Feb 2008 17:52:31 +0000

Finally, we have our first conviction under the IT Act 2000 in India. After more than a 100 cases being lodged, and about half of them actually reaching the courts, we have our first conviction of an orthopaedic surgeon in Chennai being convicted of recording and uploading pornographic images. He and his brother in the US were found running a profitable pornographic website selling the videos and images.
Other notable cases nowhere near conviction include the hacking of the Mumbai cybercrime cell, the financial defrauding of Citibank customers by its BPO Mphasis, the creation of an Orkut group criticising Shivaji which got an IT engineer in Bangalore wrongly incarcerated due to a serious goof-up by Bharti (the ISP), and others.
Coming back to the original case, though, I wonder why the actions of the doc, warranted a life sentence? What is intriguing is the presence of machine gun bullets at his farmhouse – wonder where the machine gun correlating to the bullets might be? Maybe the doc was also a gun-runner in addition to being a pervert.

Indian IT Act 2000 – An Insight

admin — Tue, 21 Aug 2007 11:39:30 +0000

from NII Consulting

The IT Act 2000 is a large repository of fine print fraught with judicial jargon and varying legal implications.

To quote from the preamble of the Act,

“An Act to provide legal recognition for the transactions carried our by means of electronic data interchange and other means of electronic communication, commonly referred to as “Electronic Commerce”, which involve the use of alternatives to paper based methods of communication and storage of information , to facilitate electronic filings of documents with the Government agencies and further to amend the Indian Penal Code, Indian Evidence Act, 1872,, The Bankers’ Books Evidence Act, 1891, and the Reserve Bank of India Act, 1934 and for matters connected therewith or incidental thereto.”

The full Act is available online in a neatly organized HTML format at http://www.naavi.org/importantlaws/itbill2000/index.htm

To make it more comprehensible, our principal consultant, K. K. Mookhey, recently drew up a presentation to provide an overview and quick understanding of all the chapters of the IT Act.

This presentation is available for download at http://www.niiconsulting.com/services/IT_Act_2000_NIIConsulting.ppt

Bad Superblock, corrupt inode tables and loads of bad luck!

Chetan Gupta — Thu, 07 Dec 2006 15:58:06 +0000

by Chetan Gupta, NII Consulting

Well, last week was abuzz with activity when we had to recover data from a corrupt Linux hard disk. Thought it would be pretty easy but as soon as I loaded the hard disk, I knew something was amiss. I was in for a shock as the disk had severe damage in the beginning sectors. Still, encase was able to load the disk but could not show the file structure! Atleast it was showing the three partitions!
What do we do?
Well, the first step was to image the hard disk so that If I do mess up the hard disk, I can restore it to what was there originally. So, loaded FTK imager and used it to image it the hard disk into split raw files (since raw files are easier to use with Sleuthkit and other open source tools..)
I had in my mind that encase will allow me to load raw files and anlayze so I thought I was on safe grounds! Well, the raw files filled up most of my forensic disk since they amounted to about 120 Gb of space! Neways, the idea was to run disk repairing tools on the conked hard disk and side-by-side run data recovery tools on the image. Well, not all plans execute to perfection…. this one sure didn’t! As soon as I loaded the split raw image into Encase, it crashed! Sure, it has problems with large split files. Then, I said to myself, “No problem, There’s sleuth kit for me”. What was not expected was that sleuthkit did not recognise the file system on the three partitions.

A simple strings on the first split image showed up interesting results – most of the files were quite intact although their beginning and end hardly recognizable from the big junk of words…and I saw the last fsck log which clearly stated that both primary and secondary superblocks were corrupt! WoW!

Anyways I tried rebuilding the superblock and inode table but to no avail. However, after the repair operation, I could run fsstat on the third partition but again it showed up 99% of the inodes to be free! I tried using fsck and using one of the secondary superblocks but it did not help. I guess the secondary superblock structures had got corrupted too!
Then I said to myself,” May be data carving is the best option in this situaton”. I concatenated the split files, and created a huge raw file so as to feed my open source data carving monsters (read foremost and scalpel)! Foremost did carve out some data but largely false hits and scalpel never got going. It would stop midway during the all-important second pass! Next step was to use all available file carving tools (from winhex to encase to FTK) and collating valid files obtained from them. It was tedious but nevertheless, I could recover a lot of files (read gif, bmp, jpeg html, and mail files).

Data carving could be quite frustrating if the filesystem is hugely fragmented. I would discuss data carving in some more detail in my forthcoming article.

Hope you enjoyed reading this one though!

Game One

admin — Sat, 21 Jan 2006 04:07:38 +0000

by K. K. Mookhey, NII Consulting

e4
It’s late at night, and the phone rings. This had better be a world-changing revolution. But it’s something weirder. A client in East Asia informs us that his systems are behaving most abnormally. Before one can gather one’s senses, the information begins to flow:

“The primary trading systems, which offer web-based trading are down”

The panic in his voice is unmistakable. But this statement could mean many things, so we probe further.

Opening
Have the web servers or database servers crashed? No.

Are they simply not accessible over the network? Yes.

Are they not accessible from the Internet, or from the internal network or both? Inaccessible both ways.

Now, this client is one of the country’s largest Internet share trading portals. The stock markets have been going crazy, and transaction volumes are testing the very limits of infrastructure capacity.

So maybe it’s simply too many investors going for the same trades at the same time, or any other such market anomaly, which would go away on its own? No. There are no IPO’s being listed today, there is no special buzz on the bourses, and the other online trading systems are doing just fine. It’s just our systems.

Hmm… looks like a Denial of Service attack or a worm out there or something absolutely weird (other than the fact that it’s 3:30 AM). Time to call in the help of some friends.

Middlegame
We’ve just done a project for the primary Internet Service Provider in the country, and know the manager of their SOC (Security Operations Centre) well.

We call him up, and ask:
Any worm traffic you’ve been seeing lately hitting ports 80 and 443? Or anything specifically targeting IIS? There was a remotely exploitable vulnerability released recently in IIS, right? He doesn’t recollect seeing any seriously anomalous traffic for these ports, or any spikes in earlier worms targeting IIS. But he hints at something more sinister being at play: cyber-extortion.

We call back the client, and now are surer of the information we need to know:
Are the source IP’s local or largely overseas? The assumption is that if it were just a spike in trading, then it would be largely the local populace accessing the systems. We’re informed that the source IP’s are largely from Eastern Europe. Plus, they’re a very wide range of source IP addresses – the IDS is dropping packets at an alarming rate, and the firewalls are at 100% CPU utilization.

The panic levels are continuing to rise, as senior management is concerned about the loss in revenues due to the complete absence of trades being placed, not to mention the reputation loss that is likely to occur once the news hits the media.

We ask them to immediately inform their upstream ISP and block all source IP addresses, except those IP blocks allocated to the country. Our friend whom we called in earlier has also been informed to co-ordinate the activity on a war-footing.

Within 15 minutes the client calls back. The flood of packets has been blocked successfully at the upstream ISP, and trading is more or less back to normal. Obviously, people traveling outside the country are still not able to trade, but the DDoS attack is no longer the nightmare it could have been.

Endgame
So what really happened out here? The next day we looked around for more information about the symptoms we’d seen – Distributed Denial of Service attacks targeting web servers, specifically of systems where transaction volumes are so huge, that even a few minutes of downtime results in significant losses. The most likely answer, we learnt, is cyber-extortion. We checked with the client if they had received a fax or voice communication asking them to pay up or be subjected to huge losses, or were there any serious disputes with trading partners or any other indications that someone had a grudge. So far, we’d been dealing with the IT team, but now we’re told they’re off the case, and Internal Audit has taken it up.

Post-mortem
We were never really able to confirm one way or the other whether it was a case of cyber-extortion or not. It was most decidedly a Distributed Denial of Service attack targeted at the client. The fact that DdoS-based extortion threats are on the rise is becoming evident[1],[2]. We ruled out worm traffic, since that should normally have affected a larger number of web-based systems in that country, and none of the malware monitors showed any spikes in worm traffic in the region. Their servers were functioning perfectly all right, and normal trading resumed almost as soon as the upstream ISP filtered the traffic. The Internal Audit department handled the matter internally, and didn’t inform the IT team whether there really was an extortion threat, or we were simply being paranoid.

The key lesson here was that a well-planned incident response strategy can help prevent knee-jerk reactions when security emergencies arise. It can save millions of dollars of financial losses and control the loss to reputation that can occur even if the systems are only unavailable, not compromised. Also, the client eventually went in for TopLayer IPS.

References

1. http://www.networkworld.com/news/2005/051605-ddos-extortion.html

2. http://www.csoonline.com/read/050105/extortion.html