September 18, 2014

SSL Termination Proxy for Windows

There are many open source products developed mainly for Linux, but work on Windows, e.g. Rabbit MQ, OpenSSL and other enterprise solutions.
When developing enterprise software based on Windows, the importance of storing encryption keys in Windows Certificate Store becomes an issue.
The vulnerability of not working with the Windows Certificate Store is storage of encryption keys on the file system and not in a secure location as defined by Microsoft. The risk is not that high since both NTFS file system and Windows Certificate Store can be protected by an ACL, however, this is a standard for the customers I work with.

Assumptions

  1. Each framework implements the SSL handshake distinctly, e.g. The implementation of the .NET framework is not the same as OpenSSL or Erlang. 
  2. The solution should not be coupled with a specific protocol, e.g. HTML, AMQP or any proprietary protocol.

Requirements

  1. The enterprise software should not be recompiled to overcome the challenge.
  2. Performance should be minimally affected (it's very hard).
  3. The solution should support both SSL and client-side authentication.
  4. Private keys must be stored in the Windows Certificate Store and marked as not exportable. In fact, preferably to store the private key on HSM, but it's just a matter of changing the Windows CSP (Crypto Service Provider).

Challenges

Since the solution should support both access to the Windows Certificate Store and transparent protocols, the OpenSSL solution is not good enough due to inability to work with the Windows Certificate Store. In addition, reverse proxies with the ability to terminate SSL channels, e.g. NGINX and HAProxy, are also unable to comply with the requirements. 
There is also an option to use WCF transportation, which works pretty fast, secure and it complies with certificate storage requirements etc. However, the main problem with this solution is that code changes required to replace the tunnel of the system, especially if the transport based on 3rd party solutions.

A walk-through the solution

The solution is pretty simple and even scalable. The main idea is to develop SSL termination socket proxy, which means that it is transparent for any application. 
The architecture diagram illustrated below for Rabbit MQ, but it can work for any software:

Since Socket is lower than the application layer in the OSI model, it is much easier to control the flow in this level. Hence, the client should not be changed, except the port on the target server. On the server side, I would protect the Rabbit MQ server to refuse any connections from non-localhost address by configuration. As for the SSL termination socket proxy - it is responsible for all security requirements, e.g. Certificate revocation verification, mutual authentication, using the Windows Certificate Store to bind to the TCP listener etc.
As for the performance... If you develop in lower languages, it may be fast enough. On the other hand, if your'e and expert in non-blocking and fully asynchronous code writing, it can work fast enough even in .NET and Java.

Credits

I worked with two of my colleagues - Guy Baron and Nir Rotshtein - both are very experienced in software architecture and development. Folks - it's my pleasure working with you!

August 28, 2014

A new memory scraping tool

A Raising Trend

I've been looking for the term "POS Malware" on Google trends and I found the following result:
From my humble opinion, it looks like that many people getting interested in POS malware because they understand that POS can bring them a lot of $$$. On the other hand, these are only the results on Google, in the Darkent forums you'd find more aggressive results.

The Result

Few students from the "College of Management Academic Studies" decided to develop an open source memory scraping tool that allows organizations to find their vulnerability of scraping their process memory to get specific pattern from it, e.g. credit card numbers, URL or any regular expression.
This is an open source tool and I highly recommend you to download it, compile and run on systems that you need to analyze. 

April 12, 2014

Heartbleeding credit cards

Heartbleed Vulnerability
The Heartbleed vulnerability and exploit published few days ago in the wild. I suppose that most of you already understand the implications of communicating with servers that run a vulnerable version of OpenSSL, e.g. session hijacking, credentials stealing etc.

Known Threat Vectors
  1. Although OpenSSL in an open source software that can run on all standard operating systems, it runs mostly on Linux/Unix-based operating systems.
  2. Most (maybe all) appliances that protect organisations' gateways based on Linux/Unix-based operating systems. Thus, remote access such as SSL/VPN is highly attractive for hackers. From the other hand, organisations' IT operations are responsible to communicate the risks and even stop the SSL/VPN service if needed (depends on risk management).
What About Windows?
According to Microsoft's publication, Windows is not vulnerable to this attack due to the usage of SChannel security package for SSL communications.
However, most of the large-scale websites that rely on Windows have a front-end network load balancers (NLB) that perform the SSL termination. These NLBs mostly based on Linux/Unix operating systems that vulnerable to this attack.
Since the sessions stored in the RAM of the NLB (even for a minimal time), the exploitability of the systems that based on Microsoft's technology remains applicable. However, the exploit is still not affecting the memory space of the processes on Windows OS.   

Ecommerce Scenario
As explained in many sources, the Heartbleed can access to the memory of the operating systems and steal sensitive data that stored in the memory.
Specifically, since credit cards stealing became a frequent attack, regular expressions of credit cards can be seek in the memory. This scenario is similar to regular memory scraping, but this time, no malware should be installed on the vulnerable OpenSSL implementation.

October 8, 2013

Tamper the "Host" header

If you read this post, I suppose that you did some web pentests or have knowledge in web development.

The "Host" header
The HTTP RFC explains what is the "Host" header:
The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL). The Host field value MUST represent the naming authority of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.
This header can be used in the following scenarios:

  1. Reverse proxy server that replaces uses the header for back-end requests.
  2. Sometimes websites use this value to build new URLs from it, e.g. activation email, links in HTML pages (including error pages).


Tamper it!
Let's do simple tampering and see what kinds of responds do we get. Before doing that, I created a php page that contains the following content in order to illustrate the inputs and outputs. The following php code runs on the server:
If we send a not-tampered request to this page, we should get the following result:

We can see that she server prints the host header. The REAL question is what happens when this header is tampered? See the result below:
In this example I used the well-known XSS locator in the "Host" header. As you can see, the request is sent to the server that defined in the "Target" in the top right corner.

Conclusion
We learned that if the server uses the "Host" header, it can affect on many variables in the message that sent back to the browser/email. I suggest to log for it in customized error pages as well...
In addition, the demo above contains very simple code in php, but it is not limited to specific technology, thus it can be done on most of the web servers. 

August 27, 2013

How to secure password reset? The SALT approach!

Password reset has always been a challenge for organizations since incorrect implementation can cause to many additional expenses, e.g. more human resources, security breaches and other maintenance issues.
In this post, I would like to explain what should be done and even dive to details about the reason for each one of them.

Identification Channels

It doesn't matter if you allow password reset using SMS, mobile application, email or IVR systems. As long as you know how to identify the user, any of these details can be relevant.

Pre-reset actions

Many websites allow users to enter their identification channel and submit it to the server. In most cases, this request can be replied. As result, malicious user is able to reply the same request and cause to flooding attack on specific user, e.g. by sending too many emails of password reset.
In order to mitigate it, the website should use anti-bot and anti-reply mechanisms before the submission of the details, e.g. CAPTCHA.

Password management

This post does not focus on password management, but it is important to mention that all passwords in the system should be salted. That means that the system should store in the repository a random salt (I use UUID/GUID) and the hashed value, which created from the real password and the salt. The main reason for that will be clearer by the end of this post.

Reset password link

Following user's request to reset password, the system should generate encrypted string that contains at least the following values:
- Username - this is required to identify the user when he clicks the link.
- Timestamp - the time when the link created. This is important since it allows the system to control the time frame that this link should be active, e.g. if user entered the link two days following the link generation, it should not allow password reset.
- Password salt - This is important since it allows the system to create one-time link instead allowing to use the link many times within the timestamp above.

What should be done with the password salt that included in the link?

When user clicks the link, the system should identify the user against the repository and get his password salt from it. This salt should be equal to the salt that included in the link.
Following the verification of the password link, the user should choose his new password. When the system gets this password, the following steps should be done:
1. Change the password salt of the user to other random string.
2. Set the password hash using the value of the new password and the new salt.
In this case, if the user clicks the same link from above, the salt from the link should not be equal to the salt from the repository.

Reset password in other channels

If reset password link does not fit the specific channel (e.g. IVR), the common approach should be used. In this case, the system should manage other identification mechanisms, such as dummy questions, voice recognition etc.

June 2, 2013

Compliant is NOT secure!

The issue
Many sources explain about specific or minimum security requirements, e.g. PCI. Many organizations that must follow regulations think that the difficult job already done since the regulator already defined the security requirements for any system in the organization.
In this post I would like to refute this approach using examples.

Example #1 - Symmetric encryption standards
How does exactly PCI allow applications to use 3DES? The requirement for using this algorithm is double length key (2 x 156bit = 312bit). Ok, but it's still vulnerable to cryptoanalysis attacks.
BTW - Let's ignore the fact that 3DES is eight times slower than AES :-)

Moreover, I don't think that even requirement for AES with 256bit key is enough because:
1. By default, the cipher mode is weak (.NET use CBC) - NIST took it one step further and explained about the secure block ciphers. A weak cipher can still comply with most regulative requirements, but still be vulnerable to cryptoanalysis attacks as well.
2. Do you really think that with today's cloud computing resources, it won't be deciphered? It has been demonstrated in BlackHat DC 2011.
Note: PCI include AES configuration with at lease 128bit key length.

To conclude this example, I think that the newest algorithm and the longest encryption key must be used for most applications, i.e. AES with 512bit key length.
In addition, I think that also new mobile devices can handle this encryption. The exceptions in this case are old mobile devices and embedded ones, which have less computing resources.

Example #2 - Passwords management
Many systems store the password in an hash format, e.g MD5, SHA1, SHA256. In this case, there is requirement in PCI to store sensitive information using SHA1 and above.
The old news - there are also SHA-1 rainbow tables!!!

Can the organization comply to regulations that require SHA1? Yes.
Is the organization secure (not  vulnerable to password guessing via SHA1 rainbow tables)? No.
The solution: use "salt" and implement SHA512 algorithm. I think that the maximum should be implemented because:
1. Even in Big-Data systems, the execution of SHA512 is not that expensive.
2. User authenticates once in a session - the rest is based on a session id. Hence, the hash function is performed only once per successful login.
Disclaimer: In this case I write about server-side. If hashing is performed on the client side, then it should be considered according to the hardware.

Secure = future ready
Everything is about risk management? Not really... Everything is about risk management and future readiness!
I think that organizations should not run after their tail and try to comply to the updated version of a specific regulation/standard. If organizations think about future readiness, they can be compliant and secure for at least the next following years.