Mobile Application Testing

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 Security

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

My Website is infected with Malware - What's next?

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

Web Services Security - The Basics

Wiki defines Web services as “Application programming interfaces (API) or web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services”. So putting this down in simpler words, it is a function of the application that can be made available for use for other developers to integrate it into their applications.

Say I have a piece of code which precisely calculates the age of any girl based on 5 questions and their answers. Believe me this is really a difficult piece of code and everyone will wish to have it on their website. Now if I publish this code as a service, you as a developer can simply use this service and integrate into your application instead of itching your gray cells and trying to write one of your own. Since web services can be used to connect to data sources from even outside the enterprise, they are prone to hacker attacks.

Before moving towards basic security concepts lets first understand the four technologies that form the basis of web services:

1. Extensible Markup Language (XML):
1. XML is plain text.
2. XML was designed to carry data, not to display data
3. XML tags are not predefined. You must define your own tags
4. XML is designed to be self-descriptive
5. XML is the standard of web services standards.
2. Simple Object Access Protocol (SOAP):
   
   1. SOAP is a communication protocol
   2. SOAP is a format for sending messages
   3. SOAP is designed to communicate via Internet
   4. SOAP is platform independent
   5. SOAP is language independent
   6. SOAP is based on XML
   7. SOAP is simple and extensible
   8. SOAP allows you to get around firewalls
   SOAP consists of 2 parts, the header which contains information about SOAP messages like management and securing the message etc and the other part is the body which contains the message payload.
3. Web Services Description Language (WSDL):
1. WSDL is used to describe Web services
2. WSDL is used to locate Web services
3. WSDL describes the set of operations the web service provides.
4. WSDL is a set of rules to describe your web service & how you can communicate with my web services, how & what messages will be sent in SOAP envelope.
4. Universal Description, Discovery & Integration (UDDI):
1. UDDI is a directory for storing information about web services
2. UDDI is a directory of web service interfaces described by WSDL
3. UDDI defines the set of services supporting the description & discovery of other web services providers, the web services they make available & the interfaces which may be used to access this services.

Web Services thus aim to deliver interoperability and reusability thus helping different business applications to talk/transact across multiple platforms. And like any other technology, even Web Services do not have security incorporated or enabled by default. Web Services Security can broadly be divided into two categories: interface and implementation security and message security.

Interface and implementation security includes controls such as Secure Socket Layer (SSL), Access Control Lists (ACL) etc. These are the basic web based security implementations.

For message security, XML mechanisms such as WS-Security, the Security Assertion Markup Language (SAML), XML Signature and XML Encryption can sign, encrypt, and authenticate message data. Thus the trust in confidentiality and authenticity in the transit of data increases giving a greater sense of security. Let us have their quick overview.

XML Signature

Defines XML syntax for digital signatures. Also referred as XML DSig, it is more flexible than PGP and other form of digital signatures as the fact that it operates on XML infoset rather than binary data. (XML infoset in simpler words is describing XML document as a data model in terms of information items). It is core to WS-Security, XKMS, and other Web services security standards. It provides integrity and non-repudiation, and can play a vital role in the process of key sharing that is needed by XML Encryption.

Another important concept is canonicalization. Verifying data integrity in XML is particularly challenging since the differences in platforms and XML parsers can result in logically equivalent documents being physically different. So canonicalization signs only the necessary element, eliminating meaningless differences like white space and line endings.

XML Encryption

XML Encryption provides end-to-end security for applications that require secure exchange of structured data. XML-based encryption is the best suited way to handle complex XML requirements for security in data interchange applications. TLS/SSL is originally used to encrypt the data. However XML encryption provides a mechanism for security requirements that are not covered by SSL. The following are the two important areas not addressed by SSL:

• Encrypting part of the data being exchanged
• Secure sessions between more than two parties

XML encryption are divided into two main parts:

• Symmetric encryption for data transfer
• Asymmetric encryption to exchange the eyes which can be used for data transfer later.

XML Encryption applies standard algorithms to data and then stores that encrypted result in XML.

SAML

Security Assertion Markup Language is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). Assertion applies to an individual or entity which is attached to the message. Thus in short SAML provides a set of rules that can be used to obtain these assertions from trusted third party services that make authorization and authentication decisions about individuals and entities. After the authority makes its assertion, SAML also provides a way to exchange the information.

Also the other single most important problem that SAML is trying to solve is the Web Browser Single Sign-On (SSO) problem

WS-Security

WS-Security deals more with SOAP security and is the member of WS-* family of web service specifications which were published by OASIS. The protocol specifies how integrity and confidentiality can be enforced on messages and it abstracts different security technologies into claims and tokens. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.

WS-Security describes three main mechanisms:

• How to sign SOAP messages (using XML signatures) to assure integrity and non-repudiation.
• How to encrypt SOAP messages (using XML encryption) to assure confidentiality.
• How to apply for security token, hoe to link them to identity & how they are attached to web services.

Auditing

Other than above mentioned basic controls, auditing should also be enabled. This can help detect any “broken into” kind of requests. They can also reveal larger weaknesses that might affect regulatory compliance and even corporate governance. Auditing can basically include the following categories:

• Authentication, Authorization & Access
• Data Changes & Application Changes
• Threats such as invalid inputs
• Resource management
• Startups & Shutdown events
• Faults & Errors

Other Concerns

Other issues which needs to be considered while securing web services include:

1. Brute force attack: Proper measures should be in place to avoid brute force attacks to gain privilege access. Recently improper controls against brute force attack on Yahoo web services was in the news. The attacker was able to gain login credentials for hundreds of users (with weak passwords). The account must be locked out after specified number of incorrect login attempts.
2. Spoofing attack: An attack can spoof user information to gain unauthorized access. If the compromised credentials belong to an administrator account, the outcome can be worse. Proper authentication mechanism can help tackle spoofing attacks.
3. Security bugs: Bugs in the application can be used by attacker to launch attacks like XPATH/SQL injection, Input variable manipulation etc. The user input should be proper validated.
4. XML Denial of Service attack: The vulnerability mainly exists in the XML parser. Specially crafted payloads can bring the XML parser down to its knees. Some known attacks are XML Bombs, External Entity attacks. There are various ways to defend against DoS attacks like disabling unwanted services like inline DTD schemas in our XML parsing object, securely configuring the behavior of XmlReader etc.

Thus we have done a brief walk-through of security concepts and controls that can be implemented in Web Services. Controls for encryption, authentication, authorization, non-repudiation and availability when implemented correctly can help protect your web services against preying eyes of hackers.