Contact us for your penetration testing needs 1-866-PLYNT-24    |   Contact Us   Plynt UK Website  
Click to get Security Testing Quote

I'm an administrator

  1. Are these attacks for real? Does anyone get affected really?
  2. What about Web Servers? Can they also have vulnerabilities? Is nothing safe, folks?
  3. I bought a shiny new application firewall. Now don't tell me that isn’t enough!
  4. All my web pages have SSL enabled. You still think I might be vulnerable to these attacks?
  5. Tell me again: what exactly are the benefits of SSL?
  6. I am checking my web server logs to track an adversary. Any useful tips?
Are these attacks for real? Does anyone get affected really?

People often wonder if all these attack techniques and exploits are indeed for real. Is anyone really hit by these attacks? Is this all just theory?

While it's unlikely that any company will want to publicize that it's been the victim of an attack, some incidents do get reported in the media. The Webappsec site maintains an incident database of those reported in the media.

What about Web Servers? Can they also have vulnerabilities? Is nothing safe, folks?

The Web Server is the most visible and easy to exploit part of a web application infrastructure. Even if the application hosted is highly secure, it can still be breached if the underlying Web Server is insecure.

NIST has a great set of guides to securing web servers (and a lot of other servers too). This is a good page to bookmark if you are an administrator.

I bought a shiny new application firewall. Now don't tell me that isn’t enough!

An application firewall stands between the web server and the user’s browser. It intercepts all traffic to and from the web server. The traffic is checked against various rules to determine if it's "good" or "bad".

Rules are developed in two ways:

  • From a database of known attacks either through signatures of actual attack data, behavioral patterns, or hybrid of both.
  • By observing the application's functions and generating a set of policies that define acceptable input from the user.

    But application firewalls can be thwarted. Many attacks use legal characters to probe Web applications and get access to sensitive or restricted pages. Here're some examples where application firewalls fail to protect your app:

    • Session Hijacking, when session tokens are assigned weakly. The firewall would have no clue as everything in the session hijacking attack appears to it as a valid normal session.
    • Privilege escalation attack, when an adversary manipulates an input to that of a higher privileged user. Since the firewall is unable to verify the authorization level of the user, it lets the attack go through.
    • Stolen passwords, when the application stores passwords on the client. There is no way an application firewall can prevent it from getting stolen.
    • Insider attacks

    An application firewall can provide an additional layer of security for the application. As such, it is possible that some novel attacks may be thwarted before they can reach the application. However, they cannot be a substitute for sound, secure programming practices. Relying on an application firewall to protect bad software is destined for an eventual failure of the application. Thus, the best solution would be to combine some form of external protection via an application firewall with securely coded applications.

All my web pages have SSL enabled. You still think I might be vulnerable to these attacks?

A common misconception is that SSL is the answer to most attacks.

SSL ensures that the server is who he claims to be, and that the traffic cannot be eavesdropped by anybody else. It achieves this by using a digital certificate to prove the authenticty of the server, and encryption to secure the traffic.

However, SSL cannot prevent an adversary intercepting his own communication with server using freely available web proxy editor tools (e.g. Webscarab, Burpproxy etc.). These tools intercept SSL communication within the adversary’s machine and present editable data to him in plaintext, which can be used to launch several popular attacks.

Tell me again: what exactly are the benefits of SSL?

Secure Sockets Layer or SSL for short provides the following benefits:

Authentication of the server

Whenever an end user connects to an SSL enabled site, the Server sends its unique Digital certificate which is approved and signed from a universally trusted source (E.g. Verisign). This guarantees an end user that he is communicating with the right server.

Communication privacy

SSL uses public key as well as private key encryption technologies to provide an encrypted channel. This channel ensures an end user that all communication between the user’s browser and the Webserver remains encrypted. Thus, any one intercepting or sniffing the communication will only see garbled text which would make no sense.

I am checking my web server logs to track an adversary. Any useful tips?

Logs are like the "black box" in an aircraft, they are the primary sources of clues in the event of an incident. A typical web server log is as shown below.

192.168.0.1 - - [02/Jun/2006:06:56:12 +0530]
"GET /Demo/page2.htm HTTP/1.0" 200 5593

Each time a page is downloaded or a CGI script is run from a web browser, the web server records the following information into its log file:

- Site-either an IP address or the symbolic name of the site making the HTTP request. In the example, remote host is 192.168.0.1

- LogName-login name of the user who owns the account that is making the HTTP request. Most remote sites don't give out this information for security reasons. If this field is disabled by the host, we will see a dash (-) instead of the login name

- FullName-full name of the user who owns the account that is making the HTTP request. Most remote sites don't give out this information for security reasons. If this field is disabled by the host, we will see a dash (-) instead of the full name. If the server requires a user id in order to fulfill an HTTP request, the user id will be placed in this field

- Date-date of the HTTP request. In the example, the date is 02/Jun/2006

- Time-time of the HTTP request. The time will be presented in 24-hour format. In the example, the time is 06:56:12

- GMToffset-signed offset from Greenwich Mean Time. In the example, the offset is +0530, Five and a half hours after GMT

- Request-HTTP command. For WWW page requests, this field will always start with the GET command. In the example, the request is GET

- File-path and filename of the requested file. In the example line the file is /Demo/page2.htm

- Proto-type of protocol used for the request. In the example, HTTP 1.0 is used.

- Status-status code generated by the request. In the example, the status is 200

- Length-length of requested document. In the example, the length is 5593 bytes

While tracking down an attacker, the fields we should be looking at are:
- The Site field for the source IP address or the source hostname
- The Date field for the date of attack
- The Time field for the time of attack
- The GMT offset field for the origin of the attack

This information can be combined with other log files such as login/ logout information from the Internet service providers, or logs from mail servers to discover the actual identity of the attacker. In most of the cases, ISPs dynamically assign IP addresses to computers each time they dial in. From the Webservers logs, we will know that the attacker accessed the server from a dynamically assigned IP from a particular ISP. Then we will have to approach that ISP to check their log files to find out who was assigned that IP then.

Another situation is when the attacker accesses the web server through his company’s proxy. Here the Webserver records the proxy’s address and not the actual attacker’s machine address. In this case, we will have to approach the company to run a check on their proxy server’s logs to find the actual attacker. Thus, while conducting forensic analysis to track down an attacker, prompt assistance and co-ordination from ISP’s and other organizations is required.


Request a proposal

Our quote contains the best price, the time estimate, and our methodology; and we'll mail you the quote in 24 hrs.


                                                
 
Movable Type Appliance - Powered by TurnKey Linux