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.

May 3, 2013

Execute WEBINT to prevent cyber attacks

Common practice
Many organizations understand the need to perform hardening on servers and network equipment, write secure code, perform penetration test, implement DLP systems etc.

In similar, we protect our personal interests as well, e.g. we keep our passwords secret, don't put our credit card details on web sites that we don't trust etc.

What do you miss?
The first and the simplest question is: "Did you Google yourself at least once?"
If your answer is yes, then you in half of the way to understand what should be done.

Second question: "Did you looked in people specific search sites? e.g.  https://pipl.com/ and http://www.peekyou.com/.
people search engine can collaborate any filer specific information on specific person. For instance, by searching my name, I can find the following interesting facts about myself (not all true, but it's pretty good):
By searching people, we actually do HUMINT (Human Intelligence). This method can assist cyber criminals to manipulate us, steal sensitive information or to spoof our identity.

What do your organization miss?
In similar to performing HUMINT on people, cyber criminals collect information about organizations using OSINT (Open Source Intelligence). The most common way to collect information is the web, which called WEBINT (Web Intelligence).

WEBINT is NOT less important than the common way to protect the organization. Actually, by execution of WEBINT on the organization, the information security manager can get a picture of what does the cyber criminal see while collecting information before the attack. Henceforth, the information security manager can take proactive steps to minimize the residual risk on assets.

How to execute WEBINT on your organization?
The most important question that should be answered prior execution is "what do you know about your organization?". Organize the answer somewhere and begin the WEBINT.

There are many great tools to do that, I want to demonstrate a the common ways:
1. Use Google hacks to find URLs, email addresses, sub-domains and other entry points. For example, in order to find Facebook's sub-domains, the following query can be googled: "site:*.facebook.com -www", which means to look in any prefix and then the domain 'facebook.com", except if the prefix is "www". See the result below:

2.  Use SHODAN search engine to find if organization's IP addresses are published and what are the banners that people see. See search results below:

3. Find job openings in your organization. Sometimes the requirements in the job description can expose the technologies in the company, e.g. Java developer with experience in Hibernate framework, System admin with experience in Windows 2003 and above, WebSCADA expert.

4. Underground work.. Go to the Onion network (Darknet), look into private blogs or follow people/hactivists on Twitter to find information about your organization and even planned attacks.

Important to mention that these are only examples - each organization may need to look in many more sources.
Note: Maltego is a pretty good tool that can combine few of the methods above and even more.


Combine HUMINT and WEBINT
In many cases cyber criminals can use the collected HUMINT information to do social engineering on your organization. By knowing facts from WEBINT, it makes the criminals stronger since they have not only business information, but also personal information, which leads to higher level of trust in case of social engineering.


Mitigation
There is no finger solution since any exposure can lead to other types of risks. Moreover, this process shouldn't occur one time only, but as ongoing process like performing penetration tests.

February 25, 2013

Proxy is transparent for malware

In this post I would like to break a myth for the people that know how to protect, but don't know how to attack. Proxy can be a good solution for performance, but not necessarily for security.

Proxy is good
  1. If a malicious user connects a computer to the network, then he might be limited in case the proxy requires authentication and protects against replay authentication attacks. 
  2. It is good for basic content filtering. 

Proxy is not enough
I would like to split the explanation to two scenarios - The first uses the framework's commands, while the second have direct access to windows API using non-frameworked language, e.g. C++.
First scenario:
Explanation
  1. In this scenario, the malware is based on Java/.NET. Therefore, It can access the methods of the frameworks in order to gain the proxy settings of Internet Explorer. e.g. in .NET, a malicious user is able to create WebClient that sends a request. Anyway, proxy settings are reflected from WebRequest.GetSystemProxy() method.
  2. The framework runs the code and calls the WinAPI in order to the the proxy settings. Note: this is invisible for the malware developer (black box).
  3. WinAPI returns the proxy settings.
  4. The framework returns the settings to the malware.
  5. The malware access to the proxy server as authorized user with the information that should be sent to the C&C. Since the malware have the IE settings, it uses the credentials to authenticate to the server exactly as IE does. Note: in order to reduce blocking by content filtering, the communication should be established over SSL.
  6. The C&C gets the information from the proxy server and responses. The Malware will be able to receive the response
Second scenario:


Explanation
  1. The malware creates WinAPI calls in order to get proxy configurations, e.g. WinHttpGetIEProxyConfigForCurrentUser (with few adjustments).
  2. The WinAPI updates the pointer that includes the proxy configurations.
  3. Exactly as step 5 in scenario 1 above.
  4. As step 6  in scenario 1 above.

Assumptions
  1. Antivirus does not recognize the Malware, e.g. by using thread timeouts, packers and all other cool stuff.
  2. Windows 8 does not allow to open network connections, unless it accepted in the UAC. Hence, an exploit or other way to gain higher privileges is required. 
  3. New JREs require re-authentication when accessing the internet.  

Acceptable solution
I don't think that the solution is unique, however, I would recommend to take into account the following actions:
  1. Install a sandbox solution that restricts access to proxy settings.
  2. Educate users to not allow unknown connections - java re-authentication request or windows UAC. (Sure... security awareness is only part of the solution...)
  3. All other action items to prevent malware infection.