Monday, November 28, 2011

Welcome to Safe Bank’s net banking. Please enter your net banking userid and password.
Userid: 15236523 
Password: ************* 
Action = submit.jsp
and you have logged into net-banking application. Wow!!! You can now view your account balance, do third party funds transfer and much more.
File contents: 
08-Aug-08: 08:00: Window title: Welcome to Safe Bank net banking
Userid: 15236523 [tab] Password: Welcome123!
Behind the Scenes: 
When you browsed to your net banking page and typed in your username and password to login into the online bank, there was a malicious program you were unaware of, named keylogger running in the background logging all the keystrokes into a config.dll file located in C:\WINDOWS\system32 folder. This file contains all the keystrokes typed in. It contains the window title and all those things typed into that window along with few other details. This file will then be uploaded to the attacker’s website which he can use to his benefit.
These keyloggers are easily and freely available on internet and also integrated with other programs like rookits making its detection very difficult. So your chance of being infected by such a malicious code even if you have an updated antivirus/anti-Spyware program is about 70%. See the brighter side, you still are 30% safe. Sounds scary..huh!!! So lets keep our focus to internet banking websites and see how we (BANK + USERS) can try to avoid compromising login credentials.

Round 1: Fight!

This is when password stealers were simple keyloggers. Whatever keys were typed in, they were captured by the malicious code and logged into some file in simple or encrypted form. This file was later uploaded to attacker’s site or simply the logs were mailed. This attack can be mitigated by virtual keyboards.
Figure 1.shows the basic virtual keyboard screenshot. It works simply by clicking the keyboard layout by a mouse. So the basic keyloggers cannot capture the mouse clicks and hence the passwords cannot be logged.
HDFC Virtual Keyboard
Fig 1. Virtual Keyboard (HDFC Net banking VKB)
You can achieve the same by Windows built-in virtual keyboard. Go to Start -> All Programs -> Accessories -> Accessibility -> on-screen keyboard.
Windows Virtual Keyboard
Fig 2. Virtual Keyboard (Windows in-built)

Round 2: Fight!

Now the malware coders were challenged as to how to defeat the virtual keyboards.
Mouse clicks cannot be logged. However their x-y positions can be logged which can then be used to get the keys clicked using their x-y position on the web page.
This technique is much simpler to mitigate by simply randomizing the keyboard layout. However total randomizing can make end users unhappy. So a good tip can be randomizing only selected 2 or 3 rows of alphabets instead of all of them.

Round 3: Fight!

Now what? We have the x-y positions but how do we know that what keys were present in that x-y co-ordinate for that period as they have been randomized. Simple!!! Why not take a snap of the keys pressed. Screen snap-shot of say 1 by 1 cm can be taken when a mouse click occurs. The letter present in snapshot is the password of the victim. This code along with basic keylogger can get log username typed from keyboard and snapshots of keys pressed by mouse-clicks from the other code.
Captured Password
Fig 3: Screen shots of password typed as captured by the malicious code.
One well known worm using this technique was W32/Dumaru. How can this be mitigated? How about changing the characters on the keys pressed to something other, on a mouse click? Or simply put change all keys (instead of a single key) to a # sign or a * sign. So if I click on letter “p” then it changes to “#” and then to original letter.
Replaced Keys 1
Fig 4: p changes to # on a mouse click
So the key captured on the screen shot will be captured-keys-2.png instead of correct characters.

Round 4: Fight!

Again our frustrated malicious minded person, let us call them “Malman” (We can’t call them either a hacker or a script kiddie so in short Malman :) ) thinks of a way to fight their way to capture passwords. What if they capture screen shot of the keys clicked just a second after (or rather say few milliseconds after) the mouse is clicked. So when I click on “P” it becomes “#” on mouse click and back to “P” when click is released. Boom! Take a screen-shot of the key now. This works fine.
This can be defeated by changing the keys after the mouse click. So if I press “p”, it changes to “#” and then to “r”. Character “r” is captured in the screen shot.
Replaced Keys 3
Fig 5: p changes to # on a mouse click and then to r
This can however make the end-user uncomfortable because each time the keys location will change and he will have to search for his password which will greatly help shoulder surfing. Hovering is a technique in which the keys will automatically be selected and entered into the password field when a mouse cursor is held over it for a few milliseconds. Again the time delay has to be such that it should cause neither user in-convenience nor aid shoulder surfing.

The fight continues

The fight will go on and on. New attack vectors target Win32 API calls made to access HTML document where virtual keyboard fails to protect your passwords. However this can be mitigated in combination with products from different vendors like Trusteer’s Rapport, Juniper’s “Secure Virtual Workspace” or by secured remote terminal sessions using citrix. But then this again adds to increased cost and security overheads. Not many banks will happily implement such solutions.
So should we as end users let the “Malman” get all our passwords. No. We can fight back by taking few precautions from our side in combination with few other trusted tools which can help us protect our passwords.
  • Regularly update your Operating System for any patches released.
  • Use latest anti-virus and anti-spywares engines. Regularly update with detection signatures and periodically scan your system
  • Also do scan for any rootkit present on your system with tools like Rootkit Revealer
  • Always use updated version of internet browsers with latest patches. Do not forget to regularly update the patches
  • Simple freeware tools like KeyScrambler Personal firefox add-on can add to the increased security
  • Keep yourself educated with different techniques used by Malman to steal passwords

At last

This is what-in-short you can do to secure your Bank accounts. I mainly focused on Virtual Keyboards and how their fight against keyloggers evolved. But there are many attack vectors like Phishing etc. on internet used to compromise Bank accounts. Both Bank and the end customers should fight side by side to defeat the Malman. Individually it is impossible to fight them back

Technology is evolving faster by the day. Today, we see mobiles are no longer mobiles, they are small computers. The smartphones run powerful applications, providing everything to users at their fingertips. Users can use their mobiles for:
  • Logging in to banks in order to transfer funds
  • Purchasing or selling shares via trading portals
  • Booking travel or movie tickets
  • Tweeting or social networking
  • Donating to charity
As money transactions move to mobiles, hackers also move their attention to it. Hence, as a precautionary measure, securing mobile applications becomes important. This article introduces you to the three key aspects of securing mobile applications.
Mobile applications may be a -
  • web application accessed via a WAP browser.
  • thick client application sending out an HTTP requests or SMSes.
Security testers should broadly focus on the following categories while analyzing their test cases -
  • Local Storage of Data
  • Hard-coded Sensitive Data in the Source Code
  • Data in Transition
Let us further discuss these categories in detail from a security tester’s perspective.

Local Storage of Data

The local storage of data can also be referred to as a “Handset Memory Analysis” for mobiles.
Mobile applications store data in the local memory of a handset. This data is stored by developers in files locally and is used by the application.
  • The Android OS stores data in files at runtime, but due to its native sand-boxing mechanism, obtaining access to this data is difficult. It also stores some data in the SQLite database.
  • The Apple iOS stores sensitive information like keystrokes, snapshots and other cached information in the iPhone local memory in the form of client-side SQLite databases or .plist files.
  • The Java application in Nokia phones stores it in the form of RMS files. These RMS (Record Management System) files get stored permanently and are easily accessible. Sometimes, they are easily readable when connected to a PC via a data cable. These files have a history of containing sensitive information like bank account numbers, beneficiary details or registered biller(s) auto-pay details.
A security tester needs to conduct a Handset Memory Analysis to detect sensitive information stored in the device.
A mobile application should not store sensitive data in user handsets. If at all it is necessary to store some data, it should be stored in a secure manner using strong encryption algorithms. It can further be stored at non-reachable locations with strict permissions.

Hard-coded Sensitive Data in the Source Code

Applications are also known to comprise hard-coded data in the source code. We may come across various types of sensitive data like –
  • payment gateways hard-coding the credentials
  • applications hard-coding the server and application-specific details
  • developer names & comments explaining the code pieces
Reverse-engineer the source code to obtain readable code files. This would ultimately help discover hard-coded data. It would also help reveal the application logic.
  • Android packages the application in .apk files, which have to be reverse-engineered to .dex files and then to readable class files.
  • Other .jar files can be simply renamed to .rar and extracted by WinRAR software. This results in decompiled class files that can be read using text editors.
A security tester has to decompile the application code in order to detect sensitive data or hard-coded information.
A mobile application should not hard-code sensitive data in the client-side code.

Data in Transition

Another aspect of mobile usage is the communication channel. Data in transit may be vulnerable to sniffing or manipulation. The data in transit can be tampered or stolen to –
  • obtain access to other user accounts.
  • transfer funds from other accounts.
  • sell shares of other users in order to create a nuisance.
  • conduct social engineering.
During a security test, the tester should analyze the data in transition. The HTTP traffic in mobile networks can be intercepted via a proxy editor tool. Here, the security tester can execute targeted manipulation attacks in order to test the application’s resilience against such attacks.
Mobile applications should thus implement server-side validation to prevent data manipulation in transit. Strong SSL encryption should also be implemented to protect data in transit.


There may be various dimensions to mobile application attacks. This article attempts to focus on three key aspects of the mobile security testing domain. Most of the tests revolve around these three aspects. OWASP and other known security forums periodically release guidelines for securing mobile applications. All these guidelines should be diligently followed by developers and included in the detection armory by a security tester.

Database links (DBLinks in Oracle) are a technique for one database to connect to a remote database and execute queries. The originating database uses an account in the remote destination database to connect. This connection thus uses a username and password of an account in the destination database. The connection has the privileges of the account that’s used in the destination database.

Insecurities with Database Links

Database links introduce several insecurities for the destination database:
  • If the originating database is insecure and compromised, the database link could be used by an unauthorized user
  • If the originating database is compromised, the user name and password of the database link connection could be compromised
  • An adversary who gains access to a database link can execute queries with the privileges of the DBLink account

Best Practices for Database Links

Database links can be made secure through a combination of technical and process controls:

Technical Controls

  1. Use Private Database links, instead of Public links. This restricts access to the DBLink to the owner of the DBLink.
  2. Use accounts with minimal privileges to access the database link.
  3. If the DBLink requires read access to some tables, and update access to some other tables, split this into two DBLinks with different accounts – one with Read, and the other with Update privileges
  4. Ensure that the DBLink password is stored encrypted in the originating database
  5. Ensure that the DBLink connection is encrypted in transit, by using, say SSL.
  6. Restrict the IP addresses from which the DB Link connection may originate.

Process Controls

  1. Evaluate the need for database links and authorize them only when they are essential
  2. Verify the level of privileges required for the database link - give the minimal set of privileges required to function
  3. Assign different accounts for database links from different sources - this allows better auditing and tracking
  4. Insist that the originating database server adhere to security best practices - remember security is only as strong as the weakest link, and the originating database should be secure
  5. Perform periodic audits of the originating database to ensure that it complies with the best practices for database security, and that the database links adhere to the technical controls specified above

Recommended Reading

  1. Database Links: A Definition in Plain English, Lewis Cunningham,
  2. Database Links, Pete Finnigan’s Oracle Security Forum,;action=display;num=1181549741
  3. A Simple Oracle Host Based Scanner, Pete Finnigan,
  4. Public DBLinks or Not?, AskTom,
  5. Guidelines for Securing the Network, Keeping your Database Secure
  6. Oracle Database Listener Security Guide,
  7. Database Links, Ask Tom,

Legitimate websites are being targeted for malware infections. Reason, large number of users visit their websites and hence these websites can be misused to easily spread or distribute malware to large number of users. If a website is infected with malware it may belong to one of the following scenarios
  • Scenario-1: Website infected with Malware - but not blacklisted by search engines or not blocked by browsers
  • Scenario-2: Website infected with Malware - blacklisted by search engines and blocked by browsers
Irrespective of the scenarios mentioned above you need to take the following necessary activities:
Corrective Action -> Cause Analysis 

                       -> Preventive Action -> Continuous Assessment
For Scenario-2, in addition to the above mentioned activities, some additional steps need to be taken to salvage the lost pride. Read “Request Malware Review - Why” section for more details.

Corrective Action

The objective of corrective action is to clear the malware and any malware related links from the infected website. Follow the below mentioned most common corrective steps to clean the infected website and system.
  1. Bring down the website
  2. Know the details of the malware infection
    • Infected Pages
    • Pages linked to the infected pages
  3. Restore the infected pages with respective clean pages from the backup. It is always recommended to restore entire website (all pages), all files referred in the web pages and its database from a clean back-up set. 
  4. Follow the necessary steps to clean the infection in your web server with respect to registry, configuration, settings, etc. to ensure there is no single back-door program left in the system. This step would vary with the infection.
Through the above mentioned steps, you can just fix or clean the infection in your web server. However, you cannot prevent the malware infection from happening again as hackers continue to attack and compromise the security weakness again.

Cause Analysis (Possible Causes)

There are multiple ways (exploitation of security weakness) by which a website can be compromised. You need to take appropriate steps (read as control measures) to fix those security weakness to prevent the incident from happening again. Some of the most common ways of malware or malware links being introduced into a website are as follows:
  • Exploit “SQL Injection” related vulnerabilities
  • Exploit Cross-Site Script(XSS) Injection related vulnerabilities
  • Exploit default passwords or weak passwords to compromise the web server
  • Exploit known software vulnerabilities at Operating System, Web Server (IIS, Apache, etc.), other sub-systems, 3rd party software being used in the website, and so on to compromise the web server.
A cause analysis of the incident could reveal the security vulnerabilities that could have been used to infect your website.

Preventive Action

Follow the preventive action associated with most common vulnerabilities listed below to reduce the risk of getting infected again.

SQL Injection

To prevent “SQL Injection” attacks, follow the most common preventive control measures mentioned below:
  • Strict input validation for all user entered data (Never trust user input)
  • Use parameterized SQL or Stored Procedures (Avoid dynamic SQL construction)
  • Use limited access account to connect website application to the database (Avoid using accounts with admin privileges)
  • Encrypt connection strings and database passwords (Avoid storing sensitive data in plain text)
  • Use custom error pages (Limit the information revealed through error and unhandled exceptions)

Cross Site Script Injection

To prevent “injection” attacks, follow the most common preventive control measures mentioned below:
  • Strict input validation for all user entered data based on white-list of allowed regular expressions. Especially, for the user data that would be displayed in web pages as responses, comments, blog, etc.
    • Reject all known bad inputs
    • In case certain HTML tags are allowed in input fields for formatting, sanitize all other sensitive HTML tags and make them potentially safe.

Default and Weak Passwords

To prevent attacks exploiting “default and weak password”, follow the most common preventive control measures mentioned below:
  • Change the default password of built-in or default accounts of FTP Server, OS, and so on to compromise the website hosted server
  • Use strong passwords. Passwords
    • should be at least 8 characters in length
    • should contain a mix of alpha, numeric and special characters
  • Change passwords frequently 

Software Vulnerabilities

To prevent attacks exploiting “Software Vulnerabilities”, follow the most common preventive control measures mentioned below:
  • Test and implement the latest service pack and security fixes for the respective Operating System, Web Server, Database Server, etc as and when released by Software Vendors
  • Upgrade older, discontinued or unsupported software versions to newer versions

Continuous Assessment (Monitoring)

As threat scenarios evolve, a continuous vigil and check on the intact of preventive and corrective action is inevitable. The following activities should help to assess the security status of the website:
  • Vulnerability Assessment - To assess the impact of vulnerabilities related to security settings of OS, Web Server, and Patch Update and so on.
    • Recommended Frequency: Quarterly or Half-Yearly based on business dependency on the website
  • Penetration Testing - To assess the impact of vulnerabilities related to SQL Injection, XSS, and password strength and so on.
    • Recommended Frequency: Quarterly or Half-Yearly based on business dependency on the website
  • Website Monitoring & Malware Detection - To assess the up-to-date status of the website with respect to malware infections, malware links, unauthorized changes and so on.
    • Recommended Frequency: Daily or Weekly based on business dependency on the website.

Request Malware Review - Why?

If your website has been already blacklisted for containing Malware or links to Malware, the search engines may flag them accordingly in search results containing your website URL with a warning message. The warning message would vary with different search engines. For example,
  • Google Search Listing -> “This site may harm your computer.”
  • Yahoo Search Listing -> “Warning: Dangerous Downloads”
  • Bing -> A Note pops up with “Careful! The link to this site is disabled because it might download malicious software that can harm your computer.”
All popular browsers may also detect malware content in the website being accessed and also to check against blacklisted websites and accordingly block access to the website. The warning message by the browsers also vary as follows:
  • Internet Explorer -> “This website has been reported as unsafe”
  • Firefox -> “Reported Attack Site!”
  • Safari -> “Warning: Visiting this site may harm your computer”
  • Chrome -> “Warning: Visiting this site may harm your computer!”
  • Opera -> “Fraud Warning”
If your infected website belongs to scenario-2, subsequent to cleaning your website for any Malware and Malware links, you need to submit “Request for Malware Review” with different search engines through different processes. This review process is a must to remove the warning messages for your website URL related search results in respective search engines.
This would be covered in detail in our next article “Request Malware Review - Process and Steps”.