OWASP 2010

Since 2003, OWASP (Open Web Application Security Project) has been making an effort to inform web decision makers of the 10 most critical web application security flaws are through their Top 10 Project (link to: http://www.owasp.org/index.php/OWASP_Top_10_Project). 2010 marks the third update to this list after a final draft to the original released in 2004 and an update to the list in 2007.

OWASP is “an open community dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted.” Their work is derived from a collaboration of security professionals who serve as volunteers to bring information to the community in an open and unbiased manner. While the organization is not affiliated with any technology or security companies, they do support the use of commercial security products.

The Top 10
The Top 10 project is described by OWASP as:

The OWASP Top 10 provides a powerful awareness document for web application security. The OWASP Top 10 represents a broad consensus about what the most critical web application security flaws are.

One of the most noticeable changes to the Top 10 list is the focus being shifted from a list of the top 10 vulnerabilities to the top 10 risks. The reason for the shift is quite practical, “Actually, it moved from prevalence (which is one factor of likelihood) to risk, which takes into likelihood and prevalence to estimate risk. Organizations care about risk, not just likelihood, and the Top 10 was always about risk (really), but we weren’t as clear as we should be, so this update works to make that much more clear.” Dave Wichers, Project Leader for the Top 10 List.

Additionally, two risks were dropped from this update: Malicious File Execution due to tighter PHP security lowering the prevalence of this problem, and Information Leakage and Improper Error Handling because of a minimal zed impact of disclosing stack trace and error message information.

Injection

• Examples of injection flaws are SQL, LDAP, HTTP header injection (cookies, requests), and OS command injections
• Attacks occur when untrusted data, such as a query, command or argument, is sent to an interpreter
• Vulnerable applications can be tricked into executing unintended commands or allowing the attacker to access, and modify, data

Cross Site Scripting

• There are three types of XSS attacks: stored, reflected, and Dom based
• XSS attacks occur when an application allows data that is not validated or escaped properly to be sent to a web browser
• Malicious scripts are executed in the victim’s browser allowing the attacker to hijack the user’s session, steal cookies, deface web sites, redirect users to malicious web sites, and remote browser control

Broken Authentication and Session Management

• Users are impersonated due to leaks or flaws in the authentication process
• Attacks occur when a session ID is visible to others, timeouts are not properly set, SSL/TLS is not used, or any other flaw in the authentication scheme is detected
• Flaws used against one account may be replicated against an account with higher privileges

Insecure Direct Object References

• Attack occurs when an authorized user can change a parameter value that refers to a system object that they are not authorized for
• Almost any reference that can be reached by URL to include: references to files, paths, database keys, reflection by class name (e.g. JDBC connector class)
• Remote referencing includes: Web Services, CORBA, RMI, RPC

Cross Site Request Forgery (CSRF)

• Attacker creates malicious code to generate a forged request that the attacker tricks the victim into submitting
• Forged requests can be hidden in image tags, XSS attacks and a number of other techniques
• CSRF attacks can complete any transactions that the victim is permitted to perform such as access data, transfer funds or make purchases

Security Misconfiguration

• New to the 2010 update
• Attacker exploits unsecured pages, default accounts, unpatched flaws or any other vulnerability that could have be addressed by proper configuration
• These attacks can result in a complete system compromise

Failure to Restrict URL Access

• This attack takes place when an authorized user can simply change a URL to access a privileged page
• Attackers generally look for administrative functions to employ this attack on
• Links can be obtained from: hidden fields, client-side code, robots.txt, configuration files, static XML files, directory access

Unvalidated Redirects and Forwards

• New to the 2010 update
• Unvalidated parameter allows an attacker to choose a destination page where they wish to send a victim to trick them into disclosing private information
• Victims trust these links because the link is to a valid site

Insecure Cryptographic Storage

• The most common reason for this attack is that data that should be encrypted is stored in cleartext
• Can result from the poor use of encryption algorithms such as using home grown algorithms, insecure use of strong algorithms or the continued use of proven weak algorithms
• The use of weak or unsalted hashes to protect passwords is another common flaw that leads to this risk

Insufficient Transport Layer Protection

• Most commonly, this attack occurs when a site does not use SSL/TLS for pages that require authentication where an attacker can monitor network traffic to steal an authenticated user’s session cookie
• Poorly configured SSL certificates can lull a user into accepting warnings for legitimate sites only to be tricked into accepting a phishing site’s certificate
• Attacks can lead to account theft, phishing attacks and admin accounts being compromised

Ostinato

ostinato - a new packet/traffic generator and analyzer.

You need admin privilege to run it. It has a client-server architecture. Download it today and give it a try. There is a portable Win32 edition. :-)

IDS Evasion with Syncookies

Is it possible that after a destination host (server) sends you a RST packet, you still can continue to send the server some data and continue the connections?

Yes, it is possible, on a Linux server with SynCookies enabled.

sysctl -a | grep net.ipv4.tcp_syncookies

net.ipv4.tcp_syncookies = 1

Steps (howto):

• During the 3-way handshake, the client sends a ACK packet (3rd packet) to the server with a value one more than the expected value.
• The Linux server will response with a RST at the 4th packet. - > fool the IDS that the TCP connection is terminated.
• Then, the client can continue to send EVIL stuff to the server.

Summary:

• TCP SynCookies is used to combat Syn flood (DoS) attack.
• By right, should see a re-transmit of SYN+ACK instead of RST, by the server.
• The faked ACK packet (4th) is just a stray packet (in SynCookies).
• The subsequent GET /EVIL packet (5th), is considered as valid final ACK of three-way handshake since the syn-cookie will match.
• With Snort IDS, the default stream5 policy of "windows" will not be fooled by this because of what it considers an invalid reset sequence number.

Source articles:

• IDS/IPS Evasion - Step 1. Awareness
• IDS/IPS Evasion with SynCookies

Source codes:

• FakeRST (by famousjs)
• Scapy Code for Bad ACK Reset

How TCP SynCookies Work?

So far, TCP Syn-Cookies is only available in Linux (some are turned on by default). Below is an interesting quirk of TCP Syncookies of how it works.

>>> From IDS/IPS Evasion with SynCookies

I will start off by covering the relevant parts of syncookies. There are many types of Denial of service attack, but the most powerful are low rate DoS attacks; attacks that need very little of the attackers resources, but cause major disruption to the attacked host or network. 

One such attack was the SYN flood attack. The attacker would spoof thousands of packets from fake hosts. Since the destination would half-open a connection for each of these, its resources would soon be overwhelmed with these faked connections, and it would then stop acting as it should (either by rejecting new connections, or dropping old ones, or even crashing outright). 

Some clever folks devised TCP Syncookies to combat this problem. Whenever a SYN was received, the connection was not opened by the destination. Instead, it SYN-ACK’d using a ‘magic’ sequence number that it calculated. The calculation involved the IP Source, Destination, TCP Source port and Destination port, along with an unknown random bit of data that only the server would know. No entry was added to the servers table, so its resources would stay free. When the client would ACK, it would increase the sequence number by one. The server would see this ack, and would do the same math it did before to create its magic sequence number, and subtract one from the received number. 

Since the number is only based on the IP, Port, and random number, the numbers should be identical, even though it would not remember the original connection. If the two matched, it would open the connection. Since the magic number was effectively unguessable to the client, this would make it impossible for an attacker to flood the server with a low rate SYN flood attack.

Spot Crafted Packet in PCAP

An excellent article about detecting crafted packets: Fitting in:

If you ever see a packet flying by on your network that has a SYN flag set and does not have a TCP options Maximum Segment Size (MSS) – you can be fairly certain that it was crafted. And, if it was crafted – it probably is for some nefarious purposes. There are other TCP options too that can be included, but most current well-known TCP/IP stacks list the MSS as the first of the TCP options in the TCP header. However, Solaris stacks do not follow this convention and may present some false positives if you include this check.

Another unusual condition that may be a reflection of a crafted packet or a poorly written TCP/IP stack is where a client SYN packet has a non-zero acknowledgement value. After all, the client has received nothing to acknowledge.

To filter (SYN and !MSS) with tcpdump:

tcp[13] & 2 != 0 and ((tcp[12]/16 == 5) or (tcp[12]/16 > 5 and tcp[20] != 02))

• 'tcp[13] & 2 !=0' looks for the SYN flag set
• 'tcp[12]/16 ==5' looks for a TCP header length of 5. This is fairly convoluted because the value for the TCP header length is found in the high-order nibble so we must first divide by 16 to make it more logical (at least for me). Now, a TCP header length of 5 (32-bit words) means a conventional 20-byte TCP header with no options.
• There can still be TCP options, yet no MSS. The rest of the "and" clause examines that by finding TCP options where the TCP header length is greater than 5, and assumes that the MSS value appears first in the 20th byte offset of the TCP header with a value of 02.

To filter (SYN and !MSS) with Wireshark (display filter) :

!(tcp.options.mss) && (tcp.flags.syn == 1)

To find bogus packet with Wireshark (display filter):

tcp.flags.syn == 0 && (tcp.options.mss || tcp.options.wscale || tcp.options.sack)

To filter (SYN and non-zero ACK ) with tcpdump:

tcp[13] = 2 and tcp[8:4] > 0

To filter (SYN and non-zero ACK ) with tcpdump:

tcp.flags.syn == 1 && tcp.flags.ack == 0 && tcp[8:4] > 0