Polymorphic Exploitation

The emerging attacks by attackers which is dynamically changing each time a potential victim visits the malicious page is defying the traditional regular-expression and heuristic-based protection that identifies Web exploits at the network or host.

The attacker are very effective in creating a unique exploit with each request and making it impossible for signature-based protection engines to uniquely detect each attack instance.

The major driving factor for the attacker still remains Financial gain. Stealing personal data, hijacking Web transactions, executing phishing scams and perpetrating corporate espionage
are all motivators.

Traditional security techniques focus on stopping file execution and viruses at the client’s operating system (OS) layer. Unfortunately, it is far more difficult to protect users at the browser level. While some signature-based protection is able to detect one layer of Web exploit obfuscation, polymorphic exploitation will pose a new problem.

Proposed countermeasures for Web 2.0 and client side attacks include:
• Educating Web developers on the need for secure coding throughout the development lifecycle, with emphasis on input validation.
• Transitioning from finger-print or pattern matching protection to heuristics or behavior-based protection.
• Enabling protection engines to understand JavaScript just as the browser does.
• Utilizing feedback networks to analyze malicious Web sites, encourage remediation and improve content filtering at the browser level.

SQL Injection in Stored Procedure

Let us examine SQL Injection in Stored Procedure. This would be 1 of the vulnerable cases.

The Server Side Code would be something like:
oCmd.CommandText = "sp_login";
oCmd.CommandType = CommandType.StoredProcedure;
oCmd.Parameters.Add( "@loginId", strUserName);
oCmd.Paramerters.Add( “@password”, strPassword);
oCon.Open();
string result = (string)oCmd.ExecuteScalar();
oCon.Close();
====================================================================
The Stored Procedure would be:
CREATE PROC sp_login (@loginid nvarchar(25),@password)
AS
DECLARE @SQLString NVARCHAR(500)
DECLARE @loginid VARCHAR(64)
DECLARE @password VARCHAR(64)

/* Build the SQL string once.*/

SET @SQLString = 'SELECT * from cust_users WHERE login_id = '+ ''''+@loginid+'''' + 'AND password = '+ ''''+@password+''''

EXECUTE sp_executesql @SQLString

====================================================================

If the user input is as follows:
loginId = ' OR 1=1 --
password = junk

The above stored procedure will have an injection attack. The procedure executing will return all the rows because of the injected SQL.

Cheers.

HTTP Pipelines in ASP.NET

1. ASP.Net uses a pipeline model to process incoming requests and provide responses.
2. The steps in the pipeline are:

• HTTP Runtime
• HTTP Application Factory
• HTTP Application
• HTTP Handler Factory
• HTTP Handler

3. When IIS receives a request, it checks the extension of the requested page.
4. If the extension is .aspx, then it invokes aspnet_isapi.dll and passes the request to it
5. The aspnet_isapi.dll calls the HTTP Runtime object in the ASP .Net worker process
6. The pipeline is implemented inside this worker process (Aspnet_wp.exe)
7. The HTTP Runtime passes the request to the HTTP Application Factory
8. The Application Factory creates an application object for the request (or reuses an existing one) by looking at which application should be invoked
9. Every virtual folder is a different “application” to IIS
10. The HTTP Application objects contains modules or filters
a. The filters can be used inspect and modify HTTP requests and responses
b. For eg, to cloak the banner of the response, or filter out HTML or script tags in the request
c. Web application firewalls will be implemented as filters
d. The filters that are active for each app can be configured in web.config
11. The HTTP Application Object uses the Handler Factory to create the appropriate Handler to pass on the request
12. The HTTP Handler is the endpoint in the pipeline. It calls the .aspx page/assembly
13. The Handler has a method called “processRequest” that is called by the Application object
14. Custom handlers can be configured in web.config
15. An IIS web server will have only one asp.net worker process at a time
16. Each worker process contains multiple app domains
17. App domains are light weight processes running inside the worker process
18. App domains are .net “processes”, different from the Windows processes
19. Each application runs on different app domains.
20. These app domains enforce isolation.
21. When multiple requests are made to the IIS server, all of them are serviced by the same HTTP runtime and the same Application Factory.
22. The Application Factory creates new app domains to service concurrent requests

References:
a. Security and HTTP Pipelines in ASP.NET:
http://msdn.microsoft.com/msdnmag/issues/02/09/HTTPPipelines/default.aspx

Thick Client Application Security

This article discusses the top vulnerabilities in a two tier thick client application.

Thick client is defined as an applicationclient that processes data in addition to rendering. An example of thick client application would be a VB.NET or Java Swing application that communicates with a database.

I have generally observed in these types of applications have weak access controls, weak authentication management, information disclosure, improper error handling or application crash.

It is interesting to note that most of the Open Web Application Security Project (OWASP) Top 10 vulnerabilities are as applicable to Thick Client applications as they are to web applications.

Let us map them for simplicity.

Sr	OWASP Top 10 (Web Apps)	Thick Client
1	Unvalidated Input	Unvalidated Input
2	Broken Access Control	Broken Access Control
3	Broken Authentication & Session Management	Weak Authentication & Session Management
4	Cross-Site Scripting Flaws	Not Applicable
5	Buffer Overflows	Buffer Overflows
6	Injection Flaws	Injection Flaws
7	Improper Error Handling	Improper Error Handling
8	Insecure Storage	Insecure Storage
9	Denial of Service	Denial of Service
10	Insecure Configuration Management	Insecure Configuration Management

PCI Compliance bothering???

Hi,

When I was reading thru PCI DSS standards, something that was bothering me was the following requirement:

Ensure that all web-facing applications are protected against known attacks by applying either of the following methods:

* Having all custom application code reviewed for common vulnerabilities by an organization that specializes in application security
* Installing an application layer firewall in front of web-facing applications.

This method is to be considered a best practice until June 30, 2008, after which it becomes a
requirement.

My confusion was whether I had to hire someone to go a code review or penetration testing or would other means work ?? Finally I could clear this by posting it to PCI and getting the answer.

What they mentioned was :
-----------------------------------------------

Using specialized 3rd-party tools that perform thorough analysis of applications to detect vulnerabilities and defects may well meet the intention and objectives of the source code review requirement in PCI Data Security Standard requirement 6.6, if the company using the 3rd-party tool also has the internal expertise to understand the findings and make appropriate changes.

The PCI Security Standards Council will look to clarify this section of the standard during the next revision, to include that testing of web-facing applications can be done via source code review or products that test the application thoroughly for defects and vulnerabilities (when internal staff have the skills to use the tool and fix defects). The PCI Security Standards Council will also consider including prescriptive requirements as to what both the application firewall and application analysis tool or process should test for.

-----------------------------------------------

Finally, I could settle for the confusion. I need not go for a 3rd party review to go through several lines of code or do it myself. I can very well use tools like WebInspect and AMP to complete this requirement.

Cheers,
Dharmesh.

App Security Testing Cheat Sheet

Hi,

I thought to prepare a brief cheat sheet for Application Security Testing.

Please have a look and drop in your views. In case you wish to use it for your testing, please drop me a mail at dharmeshmm at gmail dot com to notify me about it.

Authentication Checks

1. Login and Change Password pages on SSL?
2. All sensitive pages (accepting SSN, Credit Card) over SSL?
3. Strong Password Policy? (Joe Accounts/Blank Passwords/Max Password Age/Min Password Age, etc)
4. Is Forgot Password page secure?
5. Password Change forced on 1st login?
6. Re-authenticate before moving to sensitive pages (Edit Account Info?)
7. Prompts old password before changing password?
8. Has "Remember Me" feature? If so, how's password stored?
9. Warns before allowing "Remember Me"?
10. Has CAPTCHA to prevent password guessing?
11. Does show error msgs like "Invalid User/Invalid Password"?
12. Can auth. be by-passed for priviledged URL's?
13. Is AutoComplete set to OFF?
14. Is password re-submitted on 'Back/Refresh' of browser?
15. SQL Injection in login?

Session Management

1. Is session id random enough?
2. Session Timeout present?
3. Stored in what form? (persistent cookie/in-memory cookie)?
4. Session Id expires on request tampering?
5. Sensitive data in cookie?
6. Can you see X user's data with Y's session id?
7. Session expires at server-side on logout?
8. Can logged out user's session be re-used?
9. Is new session id generated on login?
10. Is cookie over-written on logout?

SQL Injection Checks

1. SQL Injection : '
2. SQL Injection : ' OR 1=1 --
3. SQL Injection : '; waitfor delay'00:00:05'--

XSS Checks

1. XSS Javascript
2. XSS Encoded
3. XSS Cookie
4. Is CSRF possible?

Input Validation Checks

1. Use proxy to by-pass client side validation?
2. Generate errors for information disclosure?
3. Web Page source reveals sensitive application information
4. HTTP Headers manipulation
5. Viewstate manipulation
6. GET and POST parameter manipulation

Secure Storage Checks

1. Are passwords stored in clear text?
2. Is sensitive information like Credit Card encrypted?
3. What encryption algo used? Standard or Proprietary?
4. Is connection string in clear text?
5. Any passwords hard-coded in application?

Browser Checks
1. Check browser history? Are sensitive pages cached?
2. Is data cached by search engines or desktop search engine?
3. Any hard-coded secrets in javascripts?
4. Web Page code reveals sensitive comments?

File Checks

1. Is file upload /download allowed?
2. Can files be downloaded directly from URL?
3. Can malicious files be uploaded?


Environment Checks

1. Are default apps installed?
2. Are default accounts enabled? Do they have strong passwords?
3. Is firewall deployed?
4. Is code obfuscated?
5. Can detect server details using banner grabbing?
6. Are forms bot resistant?

In case you have your views, please feel free to write here or mail me at dharmeshmm at gmail dot com

Cheers,
Dharmesh.

Things to ponder for securing your UI

#1. Clearly describe how to set security

· Ensures that UI reduces the level of complexity in configuring and managing security
· Are there features to test roles?
· Will users understand how the test features work?
· What are Default Security Roles for New Objects
· When objects are created, what are the default security settings?
· Are users informed what the security settings are?
· Default Security Roles for Updated Objects
· What is the default security mode for updated (sub-) objects?
· Are users aware of the default security permissions?
· Is the security mode appropriate?
· When updating the object, will users think/be prompted to change the security?
· Are there Multiple Methods of Setting Security:
· Are there are multiple methods of setting security for an object?
· How are the methods different?
· Do users understand the key differences between the methods? (Will they be able to choose the appropriate method?)
· If a parent object rolls-up security state from its children, is the state accurately rolled up?
· Can I Bulk Edit Security Roles?
· Do users require bulk editing of security roles?
· Are bulk editing facilities provided?

#2. Does UI provide a means to quickly reset to a secure mode in case of a security lockdown?

• Provide a single place for users to turn off features in security lockdown.
• If clusters or a group of servers are used, provide a facility to bulk reset

#3. Does the UI imply security when system may not be secure

• Don’t give users a false sense of security: Users feel secure when they have set a password. Counter intuitively, if this password is weak, a blank password is in fact a stronger defense, since the system will restrict certain access if there is no password, but will not do this if there is a password is present.
• Giving partial or incomplete information can falsely imply security.

#4. Ensure that UI provide admins an overview of privilege granted to users

• Ensure that admins have a means to have a system overview of which user has what privileges.
• Excessive privileges granted are a major vulnerability. Ensure that UI allows admins to easily revoke granted privileges, and clearly see consequences.

#5. Does the UI actively promote security

• Ensure that your UI does everything it can to actively help the user secure their system.
• If a user must compromise their system’s security to perform a task, provide some way to automatically restore the system’s security later, or prompt the user to restore the setting when the user has completed the task.
• Make it clear to the user where they need to go to reestablish a secure configuration. Provide direct links wherever possible.
• Enable your feature to be updated easily if security issues appear after it ships using an automatic mechanism such as Windows Update.
• Make sure that the most secure option is the default. Explain to users the security issue that makes this is the recommended option.
• When the default option is not the most secure option (for reasons of product compatibility or some other intention), indicate visually which setting is the most secure.
• Provide an option to automatically secure system, such as to lock unattended machines
• Provide a simple means in the UI for users to determine if preventive measures such as virus signatures are up-to date

#6. Are security messages effective?

• Ensure that security messages are differentiated from other messages. Users are inundated with so many message boxes that they often breeze through these obstacles. Security messages look much like every other message, so users get a mixed message and tend to ignore them. In one usability study, 5 out of 8 clicked either Yes or No without reading the security dialog.
• Emphasize security by giving a visual clue that this is a different type of message. Even as users become familiar with the style and learn to click through without reading the text, we alert them to the fact that there is a security issue during the split second we have their attention. Used judiciously, users may even perceive them as infrequent enough and visually arresting enough to slow down and pay attention.
• Communicate the level of risk associated with any choice provided in security-related information. Users should be able to identify the severity of the problem, likelihood that it will affect them, and any necessary steps to correct the situation.
• A high risk warning would have more lasting impact if the frequency of other messages is low.
• Make information in the message box specific enough for the user to follow up after closing the box, such as searching for the terms in the message to find relevant Help content or links to security features.

#7. Are UI graphics appropriate to the severity of the message?

• Use graphics to reinforce, highlight or convey security information, but ensure that the graphics are appropriate and related to the content.
• Do not use the question mark message icon. This image does not clearly represent a specific type of message or could be misinterpreted as related to Help information.
• Avoid overusing the warning icon. Be sure that the content is truly a warning, and not simply an fyi or even more serious than a warning.
• Use graphics that look professional and consistent with the product’s look and feel so that the user feels they can trust the source of the message. Work with a designer to define the correct style for icons in your product.

#8. Does UI Help assist user to be secure?

• The Help topic should bridge the gap between the UI and real world usage. The Help topics can be the user’s last hope of understanding a concept or helping them make a decision. Often our Help topics are just as vague, technical and intimidating as the interface the user is trying to understand.
• Address common user scenarios.
• When the user experience is not great, explain how to understand the feature’s design and UI, not just the steps to use it. For example, if the settings for using a feature for a specific scenario are on a different tab or hidden behind a link to “advanced” features, explain that X users can find the settings they want there.
• Where a feature allows users to choose settings that affect the security of their system, explain the security consequences even if it makes it clear that they don’t get to have a perfect solution.

#9. Has the UI been designed to accommodate supplemental security?

• Design the product to anticipate security devices t such as smart cards, biometric product fingerprint, and retina scanners which are starting to be used to identify users to system.

How do you get Web Testing the right way?

With the eminence of Internet in business and culture which has expanded the applications to evolve in complexity and scale, it has become very crucial for organizations to build webs for scalability and rigor. The webs with capability to withstand expected (and unexpected) spikes and peaks in load are in the insight.
As web applications are becoming increasingly mission-critical, errors can mean disastrous strikes to a company’s business and reputation, as well as exposure to potential legal and financial liability.

With global access to systems, nonfunctional requirements such as security, performance, scalability, and availability suddenly become strategic. Many Internet systems are tested for performance and scalability only after the bulk of the functionality is built.

Since companies now realize that errors in web application performance and
functionality can be insidious, occurring as a result of multiple causes, and risky and
costly to fix, they are becoming more proactive in their web testing. The question
then becomes not whether a website is tested, but how well was it done?

To assure confidence in application deployment, in shorter project timeframes, testers must take a realistic and an integrated approach to testing.

Start by simulating concurrent users as realistically as possible. For
example, a online shopping site should mix many prospective shoppers with some purchasers and a few administrators. Each role will stress the application differently, giving you a
realistic view of how your users will experience your application.

Automation tools can help you simulate real-world variables at run time, such as different levels of SSL encryption, multiple client types, variable “think” times or the effect of slow line speeds.

The advantages of testing with an integrated, flexible solution cannot be denied. It is possibly the best way to identify problems sooner, reproduce them faster, and resolve issues earlier.

While designing this series of realistic tests, we need to determine what are the crucial factors to be evaluated for the tests. For eg. What is the number of users to simulate, what is the expected Page Load time, what type of hardware is required for these scenario, what is the CPU utilization on the servers, the Memory consumption at peak load and much more. . Bear in mind that your performance testing, while it may be focused on the end user’s experience, needs to uncover problems further back in the system. It does no good if the system performs well, but uses so much server memory that it crashes your servers after a few days in production.

Performance is the speed at which a system responds to user actions. Scalability is the relative ability of a system to maintain its performance when under load. Load is measured by the number of simultaneous requests that are dispatched to a system.

Scalability testing is to verify your application’s data integrity while verifying its performance. Both should be validated under load for every individual user. After all, what good is a speedy response from your web server if it is only delivering a “busy” message back to the user – or, worse yet, delivering subtle data errors?