Wednesday, November 30, 2011

Now that the Windows 8 Developer Preview has been available for a while, it is easier to take a step back and evaluate it without the powerful emotions that strike most people the first time they deal with it. Looking at it from a long-distance perspective, there’s a lot to like about Windows 8, especially if you are ready to cut the cord from an installed desktop application base and transition to Web applications and Windows 8 native applications. Here are 10 things I think are great about Windows 8.


1: It’s designed for tablets and touch

Microsoft is working hard to make Windows 8 work well with tablets and the touch UI paradigm, to the point of alienating traditional desktop users. It remains to be seen how Microsoft will respond to criticism over the Metro UI. But I can tell you that after using a phone with the Metro UI for well over half a year now, I think it is extremely effective for touch, and I would love to have a tablet running Windows 8.

2: Apps “share” data

One of the big changes in the application development model is that native Windows 8 apps (those using the new Metro UI and WinRT API) really do not directly communicate with each other, even through the file system, except via carefully defined interfaces. While this handcuffs developers a bit, it means that when applications do share data, Windows is aware of how they do it and makes it easy. For example, you could have an application that handles images and use it to share the pictures with, say, an application to upload them to Facebook. That unleashes a lot more power for developers because it means that applications from different vendors will work together seamlessly, and the developers do not even have to write anything specific for the application theirs works with.

3: The apps can be integrated into the OS

Just as the applications can “share” with each other, they can do the same thing with Windows itself. Again, this allows some really neat integrations to be done without much work by application makers. You can see things like a new social networking application come out and within weeks, Windows will be able to use your friends who are on it in its contact list, or the pictures can go into your picture gallery. The possibilities are endless.

4: It offers ARM support

While the ARM CPUs may not be for everyone or every purpose, lots of mobile vendors have a deep commitment to that platform and understand it well. The ARM devices will not be able to run legacy Windows applications, but they will run the Windows 8 native apps without a hitch. That’s great news for hardware makers, software developers, and users.

5: It beefs up security

The new programming model for Windows 8 native applications is extraordinarily secure. While I am sure that exploits will be found, it will be difficult for the native applications to break free of their chains. Microsoft has really flipped it around. Instead of allowing everything and slowly adding restrictions over the years (and breaking applications in the process, like XP SP2 and Vista did), it’s starting from an “allow nothing” stance.

6: App markets will benefit developers and users

Application markets are nothing new. Even Vista had one (although no one seems to remember it). With Windows 8 native applications, Microsoft is making the application market the primary way of getting apps onto the computer, much like Windows Phone 7. That’s great news for developers who need to get some more visibility for their applications and who do not want to deal with payments processing and such, especially for low-priced apps. And the application market is great for users, too. As we’ve seen, app markets encourage lower prices, and Microsoft will surely apply the same strict quality control that it has to the Windows Phone 7 app market.

7: System restore is easier

Microsoft has built new utilities into Windows 8 that makes it much easier than ever to send the system back to “out of the box,” while preserving your data. Providing a more appliance-like experience is critical for the typical user, and the help desk will appreciate it too.

8: Cloud sync is everywhere

While not everyone is in love with the cloud as an idea, Windows 8 has great facilities for allowing applications and users to automatically sync data between devices using the cloud. That’s great for users who can seamlessly transition between their tablet and desktop PC (and perhaps their phone), as well as for tech support, who can just replace a broken device instead of worrying about data loss.

9: It offers simplified administration and configuration

The Control Panel has been stripped down to the bare essentials, and you can’t even think about tasks like registry editing, defragging, etc., from the Metro UI. (You can do these tasks through the legacy desktop, if needed, but that won’t work for ARM devices.) Throughout Windows 8, a primary theme has been giving the user a more appliance-like “It just works” experience. Power users might howl about it, but the truth is, the Windows experience is still far more complex than the average user wants to deal with. Windows 8 is a great move in the right direction for those users.

10: System stability is improved

Windows 7 has really set the standard for system reliability. Short of hardware or driver problems, the old blue screen of death is almost never seen anymore. Windows 8 takes this to the next level. The same changes to the application development model also improve system stability. Applications can’t run over each other’s data easily, and the new WinRT API just does not allow the kinds of shenanigans that have caused unstable systems over the years. If you stick with native Windows 8 applications, reboots (other than for patching) and crashes should be extraordinarily rare.

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.
Location: 
C:\WINDOWS\system32\config.dll
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.

Conclusion

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,http://it.toolbox.com/blogs/oracle-guide/database-links-a-definition-in-plain-english-7023
  2. Database Links, Pete Finnigan’s Oracle Security Forum,http://www.petefinnigan.com/forum/yabb/YaBB.cgi?board=ora_sec;action=display;num=1181549741
  3. A Simple Oracle Host Based Scanner, Pete Finnigan,http://www.securityfocus.com/infocus/1522
  4. Public DBLinks or Not?, AskTom, http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:5991749853476
  5. Guidelines for Securing the Network, Keeping your Database Securehttp://download.oracle.com/docs/cd/B28359_01/network.111/b28531/guidelines.htm#i1009371
  6. Oracle Database Listener Security Guide,http://www.integrigy.com/security-resources/whitepapers/Integrigy_Oracle_Listener_TNS_Security.pdf
  7. Database Links, Ask Tom, http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:456820211101

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”.