Sunday, March 20, 2016

Static Source Code Analysis with OWASP LAPSE for Java

Code analysis is the process of analyzing the source code of software to verify the quality and identify weaknesses that can be exploited. This is achieved in two ways; static and dynamic. In Static code analysis, the code is inspected without executing the code. This can be done through a peer to peer code review or else using automated tools. The benefit of performing static code analysis is that the vulnerabilities can be detected early and addressed before deploying the software. In Software Development Life Cycle, it is important that the developers perform code analysis for every piece of code they write.

Static code analysis functionality is integrated into the development environments as well (IDEs) where the developers can simply analyze their code while writing code and see how much secure their code is. However when using such tools for analyzing source code, there is a high chance that they produce false positives where the developer has handled the security of code but still these tools would complain.

OWASP [1] has defined top 10 vulnerabilities [2] related to Web Application security where the developers have to pay attention to write secure code that are not open to such vulnerabilities. For analyzing code statically to identify such issues, we can use OWASP’s LAPSE [3] tool which comes as a plugin for Eclipse IDE.

Installation of LAPSE on Eclipse

You can download the tool from [4] and by the time of this writing, the latest version is LapsePlus 2.8.1.

Once you download the jar file (LapsePlus_2.8.1.jar), copy it to the plugins directory of eclipse installation.

After that run eclipse.

Go to Window -> Show View -> Other



In the Show View window, type ‘Vulnerability’ and you can see the Lapse’s Vulnerability Sinks and Vulnerability Sources options.


LAPSE+ is based on the static analysis of code to detect the source and the sink of a vulnerability. The source of a vulnerability refers to the injection of untrusted data, e.g. in the parameters of an HTTP request or a Cookie. The sink of a vulnerability refers to the process of data modification to manipulate the behaviour of the application, such as a servlet response or a HTML page. The vulnerability sources can lead to sinks by simple assignments, method calls or parameters passing. When it is possible to reach a vulnerability sink from a vulnerability source then we have a vulnerability in our application [1].

Vulnerability Sources

From the Show View window, you can select Vulnerability Sources and you will see a panel in Eclipse as shown below.

You can import your project to Eclipse for analyzing the source code. Here I am using the Webgoat [5] sample application for static code analysis.

Once you have imported the project, right click on the Vulnerability Sources panel and click on Find sources.



This will scan the source code and display all possible vulnerabilities of the code.

You can double click on a specific vulnerability in the panel and it will open and highlight the source code related to that issue.

Vulnerability Sinks

Similar to Vulnerability Sources, you can select Vulnerability Sinks from the Show View window.

Then from the Vulnerability Sinks panel, right click and select Find sinks option.


It will list down all the vulnerability sinks if found.
You can double click on a specific vulnerability and view the code that is responsible for the issue.

Although this tool complains vulnerabilities, there can be false positives where we have handled the security from code even though the tool complains that there is a problem. In such cases we can ignore those warnings. However there can be possible actual vulnerabilities as well and therefore it is always better to check the code you write to verify the quality of it in terms of security.

References


Tharindu Edirisinghe
Platform Security Team
WSO2

Wednesday, March 16, 2016

Tenant Domains Dropdown Feature in WSO2 Identity Server 5.1.0

In WSO2 Identity Server, when you have a Service Provider where you allow users from different tenants to get authenticated (SAAS enabled Service Provider), The users have to enter their fully qualified username in the login page so that Identity Server can recognize from which tenant this user should get authenticated. For example, if there is a user in wso2.com tenant with the username tharindu, in the login page, that user should enter the username as tharindu@wso2.com. However Identity Server has a feature where it can display all active tenants in a dropdown in the login page where the user can select the tenant he/she belongs and just enter the username without the @tenant-domain in the username textbox in the login page. For Identity Server 5.0.0, I have previously written the blog post [1] that provides step by step guide for setting up this feature. If  you are new to this feature, you can follow it and get the basic idea about the feature.

In this blog post, I will provide the steps needed for setting up this feature in Identity Server 5.1.0 version.  Here I am providing the steps comparing how it was done in 5.0.0 version so that if you have already configured this previously in 5.0.0, you can see what has been changed when comes to 5.1.0.

Configuration Steps

This feature uses Mutual SSL (Certificate Based Authentication) and for that, we need to set the clientAuth property to want in <IS_5.1.0_HOME>/repository/conf/tomcat/catalina-server.xml file.  In IS 5.1.0, this is by default set (clientAuth="want") so you do not need to make any change when you use a fresh 5.1.0 pack.  


In order to use Mutual SSL, in IS 5.0.0, we had to copy the org.wso2.carbon.identity.authenticator.mutualssl jar file to the dropins directory of IS. However with IS 5.1.0, org.wso2.carbon.identity.authenticator.mutualssl_5.0.7.jar file is by default shipped in <IS_5.1.0_HOME>/repository/components/plugins so you do not need to manually copy this.

Next step is to enable the Mutual SSL Authenticator. For that you need to add following configuration in <IS_5.1.0_HOME>/repository/conf/security/authenticators.xml file. This configuration is there by default in 5.1.0, but you have to enable this by adding disabled=”false” attribute.

        <!-- Authenticator Configurations for MutualSSLAuthenticator -->
    <Authenticator name="MutualSSLAuthenticator" disabled=”false”>
     <Priority>5</Priority>
     <Config>
         <Parameter name="UsernameHeader">UserName</Parameter>
         <Parameter name="WhiteListEnabled">false</Parameter>
         <Parameter name="WhiteList"/>
     </Config>
    </Authenticator>

Next step is to add following configuration to the application-authentication.xml file. In IS 5.0.0, this file was in <IS_5.0.0_HOME>/repository/conf/security/ but in 5.1.0, it is in <IS_5.1.0_HOME>/repository/conf/identity/ .

<TenantDomainDropDownEnabled>true</TenantDomainDropDownEnabled>
<TenantDataListenerURLs>     <TenantDataListenerURL>/authenticationendpoint/tenantlistrefresher.do</TenantDataListenerURL>
</TenantDataListenerURLs>


If you are hosting the authenticationendpoint.war webapp outside Identity Server (i.e in a different tomcat or in WSO2 application server), then you can add the full URL to TenantDataListenerURL value. If you have a cluster of IS nodes, then for each node you can repeat the TenantDataListenerURL tag and provide the full URL to other nodes.

In 5.0.0 pack, the properties file related to this feature was TenantConfig.properties, but in 5.1.0 pack it is EndpointConfig.properties which is by default there in <IS_5.1.0_HOME>/repository/conf/identity/EndpointConfig.properties location.


tenantListEnabled=true
This property controls whether this feature is enabled or not. Set this to true for enabling the feature.
mutual.ssl.username=admin
When mutual ssl authentication happens, Identity Server needs to know whether this request (retrieving tenants from TenantMgtAdminService) is authorized. For that we need to put a name of a user who has the permission Super Admin Permissions > Manage > Monitor > Tenants > List
identity.server.serviceURL=/services/
This property is there for building the URL for TenantMgtAdminService. You can keep the value as /services/ and let Identity Server build the URL.
client.keyStore=./repository/resources/security/wso2carbon.jks
This is the keystore used in this feature. If you host authenticationendpoint.war within IS itself, you can provide the relative path to the keystore of IS itself.
Carbon.Security.KeyStore.Password=wso2carbon
This is the password for the keystore.
client.trustStore=./repository/resources/security/client-truststore.jks
This is the path of the truststore used for this feature.
Carbon.Security.TrustStore.Password=wso2carbon
This is the password of the truststore.

If your authenticationendpoint webapp is hosted within Identity Server (IS_HOME/repository/deployment/server/webapps), then you can enable secure vault to secure the keystore and truststore passwords in this property file so it does not store the plain text password in this file. It needs some additional steps and I will cover them in a separate post.

If you are hosting the autheticationendpoint.war webapp outside the Identity Server (i.e in a different tomcat or WSO2 Application Server), then you cannot use the <IS_5.1.0_HOME>/repository/conf/identity/EndpointConfig.properties file as the webapp does not have access to this file. In such case, the same property file is available inside the webapp (authenticationendpoint/WEB-INF/classes/EndpointConfig.properties) Where you can set the properties in that file. In that case you have to provide the full URL to Identity Server’s admin services endpoint in identity.server.serviceURL property (i.e identity.server.serviceURL=https://<ip>:<port>/services ).

However If you are hosting the authenticationendpoint.war webapp outside the Identity Server, then you need to copy the org.wso2.carbon.identity.application.authentication.endpoint.util-5.0.7.jar file into authenticationendpoint/WEB-INF/lib . You can find this jar file in <IS_5.1.0_HOME>/repository/components/plugins folder, or else can download from [2].

For Identity Server 5.1.0, the security patch WSO2-CARBON-PATCH-4.4.0-0073 is issued for this feature and if you are using IS 5.1.0, make sure you apply this patch to your environment. You can download this patch from [3]. 


Note :

If you are applying the WSO2-CARBON-PATCH-4.4.0-0073 security patch and hosting the authenticationendpont.war (war file is taken from the patch) outside Identity Server (i.e external tomcat or WSO2 Application Server), then the org.wso2.carbon.identity.application.authentication.endpoint.util-5.0.7.jar file should be taken from the patch0073 folder of the patch and copy to authenticationendpoint/WEB-INF/lib folder. The reason is authenticationendpont.war and org.wso2.carbon.identity.application.authentication.endpoint component are dependent on each other. Both should contain the latest fixes (after applying a patch).

Once you have followed above steps you should be able to get this feature working. Once your client application is trying to authenticate with Identity Server, you should see the active tenants in the dropdown.



References




Tharindu Edirisinghe
Platform Security Team
WSO2

Tuesday, March 15, 2016

Introduction to Hashing and Salted Hashing with a Sample Java Application

Hashing is a technique used to transform a variable length input into an irreversible and fixed-sized output which is known as a message digest or hash value. Storing passwords in software systems, ensuring the integrity of messages during communication and creating indexes in databases are some examples where hashing is used. In this blog post, I am discussing what hashing is and the usage of hashing in real world applications. In addition to that, I will be providing a sample java application for hashing, which you can use to learn the concept and also refer it for applying hashing techniques in software applications you develop.

Following diagram simply explains hashing. We have some input (text) value and using a hash function (i.e MD5, SHA-1, SHA-256) we can transform this input into a fixed length output which we call as the hash value. Using this hash value, it is not possible to obtain the original input. That is why we call hashing is irreversible.
If we need to preserve the data in original format for later use, we cannot use hashing. In such cases, we can encrypt the data and keep where we can later decrypt it and obtain the original value.  

Some of the examples discussed in this post are taken from the Official (ISC)2 Guide to the CSSLP [1] book.

Hashing for Integrity Verification

Let’s say John wants to send a message to Jessie. Once Jessie receives the message, how can she verify that it is the original message sent by John and not altered by some other party during the communication ?

Here, John can write the message and calculate the hash value of the message (H1) using a hash function (i.e SHA-1). Then he can send the message to Jessie along with the hash value (H1) which we call as the message digest [2]. When Jessie receives the message and the hash value (H1), she can calculate the hash value of the message again using the same hash function as John. Now if the calculated hash value (H2) matches with the hash value (H1) sent by John, it ensures that the original message sent by John is not altered. If it was altered, then the new hash value (H2) would not match with the previous hash value (H1).  

Hashing for Password Storage and Authentication

If you develop a software application in which you need to manage user accounts, how are you going to store the passwords of the users ? If you store the passwords in plain text, whoever who has access to the userstore (database, LDAP or Active Directory) where the users are stored, all the passwords would be visible and that person can even login to the system using the credentials of any user which should not be done at any cost. In this case, we can use hashing to overcome this risk.

Here what we can do is, instead of storing plain text password as it is, we can hash the password using a hashing function and store the hashed value. When a user tries to login to the system by providing his plain text password, the system has to hash the password using the same hashing function and compare the hashed value with the value stored in the userstore (i.e database). If they match, then the user is successfully authenticated.

In above diagram, both John and Jessie are having the same password ‘tiger123’. When we hash this password using a particular hashing algorithm, we get the same hashed value. Even with this, the security of the passwords cannot be fully guaranteed. Let’s say John uses a word in the Dictionary as his password. An attacker can prepare a list of hash values for all the words in the dictionary. Then if he has access to the userstore where the hashed passwords are stored, then he can compare the hashed dictionary words with the hashed user passwords and find if any matching record is found. That way, the attacker can get to know the password of John. In order to avoid dictionary attacks for hashed passwords, we can use the technique called Salting.

In Salting, the system can generate a random set of characters which we call as the salt. Then the user’s plaintext password is appended with this salt value. After that, this combined password is sent to the hashing function to obtain the hash value. This value is called as the salted hash. The system has to remember the salt value generated for each user. When a user tries to login to the system, the system can retrieve the salt value of the user, append it to the plaintext password, hash it and compare the salted hash value with the value stored in the system. If they match, then the user is successfully authenticated.

In following example, both John and Jessie have the same password ‘tiger123’. The system generates the salt ‘1234ABC’ for John and ‘9876XYZ’ for Jessie.

After adding the salt to John’s password, we get “tiger1231234ABC” and for Jessie, we get “tiger9876XYZ”. When these values are sent to the hashing function, John and Jessie get different hash values. So with this, we can avoid dictionary attacks.



Hashing for Indexing in Databases

When using hashing in database indexing, we can divide a set of records to different groups which we call as a bucket, based on a key. This key is a hash value. When we need to perform a search, the input is sent to a hashing function which returns a hash value that points to a particular bucket. Then we can get to know the particular records that are associated with the search. For more information, you can follow [3].


Hashing Functions

Some of the most common hash functions are the MD2, MD4, and MD5, which were all designed by Ronald Rivest; the Secure Hash Algorithms family (SHA-0, SHA-1, SHA-and SHA-2) designed by NSA and published by NIST to complement digital signatures, and HAVAL. The Ronald Rivest MD series of algorithms generate a fixed, 128-bit size output and has been proven to be not completely collision free. The SHA-0 and SHA-1 family of hash functions generated a fixed, 160-bit sized output. The SHA-2 family of hash functions includes SHA-224 and SHA-256, which generate a 256-bit sized output and SHA-384 and SHA-512 which generate a 512-bit sized output. HAVAL is distinct in being a hash function that can produce hashes in variable lengths (128 bits - 256 bits). HAVAL is also flexible to let users indicate the number of rounds (3-5) to be used to generate the hash for increased security. As a general rule of thumb, the greater the bit length of the hash value that is supported, the greater the protection that is provided, making cryptanalysis work factor significantly greater. So when designing the software, it is important to consider the bit length of the hash value that is supported [1].


When selecting a hashing function for your systems, it is important to check the strength of the function. For example, MD5 is proven to have collisions [4]. A collision is when two different input values result in getting the same hash value.

Sample Java Application with Hashing Implementation

For demonstrating hashing, I have developed a sample java swing GUI application. The source code of the application can be found at [5] as a maven project. If you do not want to build the application from source but want to try out, you can download the jar file from [6] and run it with “java -jar <jar file name>” command.


Here you can type a password in plain text and select a hashing algorithm and obtain the hash value of the password. For a particular password, the output will be same with a particular hashing algorithm as we do use salting.



In the application, you can use salting by checking the “Salted Password” checkbox. If you select “Auto Generate Salt” option, the application itself will generate a salt value for you. 


If not you can uncheck the “Auto Generate Salt” option and provide your own salt value for hashing the password.


You can verify the result obtained from this application using the online tool [7].

References


Tharindu Edirisinghe
Platform Security Team
WSO2