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.

April 14, 2013

Are systems protected from memory scraping?

Lately I see a raise of memory scraping malwares that search sensitive data patterns, e.g. passwords, connection strings, SSNs and other secrets. As result, I have been looking for mitigation against this threat in .NET environment but didn't find anything. The main solutions that come along with threats are described below:

First solution: Encrypt configurations using DPAPI.
Result:  Bad solution.
Threat: Work only on configuration files, and still, the data stored in cleartext in the memory.

Second solution: Encrypt object using CryptoServiceProvider, e.g. AESCryptoServiceProvider
Result: Bad solution.
Threat: The sensitive cleartext data (prior encryption) can be inspected in the heap.

Third solution: Use .NET SecureString Class.
Result: Intermediate solution.
Threat: SecureString cannot be inspected in heap, however, it is possible to inject DLL into the process or replace another DLL of the application (easier). As result, the SecureString can be decrypted to cleartext.
For example, the following application should do something (we don't care what) with SecureString:

    class Program
    {
        static void Main(string[] args)
        {
            var secureString = new SecureString();
            AppendChars(secureString);
            MyApplicationHandler.DoSomething(secureString);
        }
        private static void AppendChars(SecureString secureString)
        {
            secureString.AppendChar('I');
            secureString.AppendChar('N');
            secureString.AppendChar('S');
            secureString.AppendChar('E');
            secureString.AppendChar('C');
            secureString.AppendChar('U');
            secureString.AppendChar('R');
            secureString.AppendChar('E');
        }
    }
The replaced DLL should look as follows:

    class MyApplicationHandler
    {      
        public static void DoSomething(SecureString value)
        {
            var bitStr = Marshal.SecureStringToBSTR(value);
            try
            {
                var stringInHeap = Marshal.PtrToStringBSTR(bitStr);
            }
            finally
            {
                Marshal.FreeBSTR(bitStr);
            }
        }
    }
The result of heap inspection can be seen below:

Forth solution: Use .NET SecureString Class AND sign application files.
Result: Intermediate solution.
Threat: Again, In normal state, SecureString cannot be inspected in the the memory. Moreover, DLLs cannot be replaced if application's files has been signed by trusted certificate (that not installed on the target machine). Bummer... another program still might be able to read the whole memory of the operating system.

Fifth solution: Use .NET SecureString AND sign application files AND harden operating system.
Result: Pretty secure.
Threats: Since no one can prohibit from hacker to inject DLL into process or even run side-channel attack by scraping all operating system's memory, it is required to combine software solution with infrastructure.  Therefore, by hardening the operating system, the hacker/malware might not have sufficient permissions to scrape the whole memory.

Sixth solution: Use point-2-point-encryption (P2PE), using hardware encryption.
Result: Great protection against memory scraping of credit cards. What about other sensitive data?
Threats: Mmmm... not in public :-)

In conclusion, there is no bulletproof countermeasure for memory scraping, but we can implement pretty good security solution by combining both software and infrastructure actions.


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.

January 30, 2013

Facebook Application Can Shame You

It is well known that Facebook applications required user's permissions to do specific actions. In some cases, people are not aware of the consequences.

I would like to demonstrate it on the "MakoConnect" Facebook application... This application required the following permissions:

Looks innocent? Not exactly.... See the result below:


For those of you who don't understand Hebrew, this Facebook application shares the article that someone read, which its title has something with exposing hooters. 

January 20, 2013

Nigerian 419 scam

Yesterday I received SMS from unknown number with very tempting message:
I decided to ask Google about this message.. I found that someone tried to collect information about me, or even worse, to do a big scam. This scam called "Nigerian 419", which is a group of upfront payment or money transfer scam. See more details in scamwatch.

January 8, 2013

Application whitelist - the good, bad and evil


We know that...

The common way to protect operating systems from malicious attacks is by installing endpoint protection system to prevent malwares, zero-day attacks and all the cool stuff we know.
However, there is additional concept of white listing all operating system's files and not allowing any other applications to run, e.g. Bit9 Parity product. 

The good

It can prevent from unauthorized applications to execute.

The bad

If the operating system is already infected, the malicious activity will continue to operate.


The evil

- If the protection is based on MD5 hash, it can be bypassed using MD5 collision attack.
- Sometimes runtime environments might be used for malicious software execution, e.g. if Java Runtime Environment (JRE) is installed on the operating system, then malicious java code can run (currently still work on Bit9 Parity).