How to get Crash or Hang dump?

I have various methods/tools to collect crash/ hang dump. This article is aimed to consolidate and provide all the related information in a single nutshell.

Target Users : The Reader is familiar with Windows OS (XP & Vista)

Wondering what crash is & how to get crash dump! Here U go!!

A crash in computing is a condition where a program (either an application or part of the operating system) stops performing its expected function and also stops responding to other parts of the system. Often the offending program may simply appear to freeze.

A crash can either be a software fault or system crash. A software fault occurs whenever an exception is left unhandled. Upon software fault the OS stops the application from proceeding further.

System Crash or Blue screens on NT-based Windows systems are usually caused by poorly-written device drivers or malfunctioning hardware. Blue screens can also be caused by physical faults such as faulty memory, power supplies, overheating of computer components, or hardware running beyond its specification limits.

Various Methods for collecting crash dump

Below are the few methods to collect crash information.

• Using Windbg
• Using Adplus
• Using ‘Create Dump option in Vista
• Using ‘Problem Reports & Solutions’ in Vista
• Getting dump on BSOD
• From Keystroke
• Dump on Heap corruption

Generate crash dump using Windbg as default post-mortem debugger

• Install Windbg before installing the product.
• Set Windbg as the default post-mortem debugger
• Launch command prompt (as admin in Vista)
• Go to the windbg installed path (C:\Program Files\Debugging Tools for Windows\)
• Type “windbg.exe –I” and hit ‘Enter’
• You will see the message “Windbg is set as default post mortem debugger”

Now install the product and continue with your testing. Whenever crash occurs, windbg opens automatically. The below command is used to collect the crash.

.dump /ma <path>\<filename>.dmp

Where, <path> is the path where you want to save the crash dump and <filename> is the name of the file.

Generate crash dump using Windbg after crash occurs (not set any post-mortem debugger)

• Install Windbg
• From the crash window, see which process is crashed
• From the task manager, identify the process Id
• Make sure you have not closed the crash window
• Launch windbg from “Start > Programs > Debugging Tools for Windows > WinDbg”
• Select File > Attach to a Process
• Select the Process for which you want to collect the crash dump and click OK
• Type the command .dump /ma <path>\<filename>.dmp in the launched window

Generate Crash/hang dump using Adplus (not set any post-mortem debugger)

• Install Windbg
• Identify the process for which you want to generate the dump
• Make a note of the process id from task manager
• From command prompt (run as ‘admin’ for Vista), go to C:\Program Files\Debugging Tools for Windows\
• Type “adplus.vbs” and hit ‘Enter’
• In the launched dialogs click ‘Ok’
• In the newly launched command window, you can use any of the below commands
  1. ‘adplus –crash –p <pid>’
  2. ‘adplus –crash –pn <pname>’
  3. ‘adplus –hang –p <pid>’
  4. ‘adplus –hang –pn <pname>’
• Click ‘Ok’ in the launched dialogs
• cdb.exe will be running
• Now perform the test steps you want to do (you want to make a crash/hang)

Once the process crashed the dump will be automatically generated as a dated folder in “C:\Program Files\Debugging Tools for Windows\”

If the cdb.exe doesn’t end, you can use Ctl+C to quit the cdb.exe window and can get the dump

Generate dump using ‘Create Dump’ option in Vista

• Identify the process for which you want to collect the dump
• Go to Task Manager > Right click the process > click ‘Create Dump’
• The dump will be created in %temp% folder

Generate dump using ‘Problem Reports & Solutions’ in Vista

Windows Vista introduced the “Problem Reports and Solutions” control panel application. This dialog will show all detected application errors on the user’s machine. When a crash is encountered, we can leverage this built-in utility to get more information about what went wrong, and how to get more information to help resolve the issue.

When this event is recorded, there are three possible scenarios

• The crash or hang was recorded and submitted
• The crash or hang was recorded, but not yet submitted
• The crash or hang was recorded, but no information was captured.

The first two can provide us with valuable information to troubleshoot the issue. The third can give us a general idea, but no specific information about the exact issue the user reported.

Windows Error Reporting configuration is stored in the following registry key in Vista

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting

User based settings such as Block list are stored at:

HKEY_CURRENT_USER\Software\Microsoft\ Windows\Windows Error Reporting

Problem Reports and Solutions

This dialog is available via Start / Control Panel / Problem Reports and Solutions, or under Start / Control Panel / System and Maintenance / Problem Reports and Solutions (depending on whether the user has “classic view” configured or not). From there, click on “View Problem History”, and look for instances of applications. Double click an entry of interest, and select the “Copy to Clipboard” link, and provide the info. The data will tell us how much information is available, without any other files.

Case 1: WER data Submitted

In this case, the error report has already been submitted. The “Copy to Clipboard” data will include the bucket ID. Usually, in this case, the event files are removed from the local computer, as they have already been submitted. We must look up the crash using the bucket ID provided.

Case 2: WER data Available Locally

In other cases, the report has not yet been sent to WinQual. In this case, we can generally collect the files locally. The files that are available will also be included with the “Copy to clipboard” link at the bottom of the screen is used.

Once the “View Copy” of files link is clicked, an explorer window in the temp directory will be opened. The files present in the temp directory will definitely give more information on crash and hence this can be given to the developer for analysis.

Case 3: WER data not available or Submitted

Unfortunately, in some cases there’s no data available but the exception code, modules names and versions, and offset of the crash. In this case, the best we can do is dig through the data on winqual in an attempt to find it, but it’s not guaranteed the correct crash will be found. The screen shot below is of a managed application.

Blue Screens

In many cases, reports of bug checks (BSODs) will also appear on this screen, allowing this approach to be used when a user experiences a system crash and suspects it may be related to specific software. The approach may be used to collect information about this type of crash as for the application hangs or crashes described above.

Common Issues

In some cases, multiple crashes can appear at the same module & offset. Having a WinQual bucket ID or simply a module offset is sometimes not sufficient to describe the exact crash the user encountered.

Note:

1. When a process is added to the Block list of ‘Problem Reports and Solutions’ you will not get the WER Report for that process.

This can be checked by looking at the Block List at,

Control Panel > Classic View > ‘Problem Reports and Solutions’ > Change Settings > Advanced Settings > Block List

2. Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crash.

For more information on this refer http://msdn.microsoft.com/en-us/library/bb787181.aspx

Generate Dump on BSOD

Whenever BSOD occurs the memory dump will be collected automatically at

%SystemRoot%MEMORY.DMP

But the default dump is a small memory dump. In order to get the complete memory dump or kernel memory dump

• Go to System Properties > Advanced > Startup and Recovery > Settings
• From Write debugging information, choose the one which you want
• Click Ok.
• Proceed with your testing.

Generate Memory Dump using keyboard

Following are the steps to generate the dump using keyboard:

1.    To enable keyboard crash dumping, we need to enable a regkey in regedit. This setting varies w.r.t the keyboard type we use in our machine.

To enable the feature on a computer that uses a PS/2 keyboard, follow these steps:

• Start Registry Editor.
• Locate the following registry subkey:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\i8042prt\Parameters
• On the Edit menu, click Add Value, and then add the following registry entry:
• Name: CrashOnCtrlScroll
  Data Type: REG_DWORD
  Value: 1
• Exit Registry Editor and then restart the computer.

Note: Restart the computer after this regkey setting is must for PS/2 Keyboard.

To enable the feature on a computer that uses a USB keyboard, install the hotfix that is mentioned in the "Windows Server 2003 resolution" subsection of the article at http://support.microsoft.com/kb/244139

To make sure that the feature is enabled on a computer that uses a USB keyboard, follow these steps:

• Start Registry Editor.
• Locate the following registry subkey:

         HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\kbdhid\Parameters

• Make sure that the following registry entry is enabled:

  Name: CrashOnCtrlScroll
  Data Type: REG_DWORD
  Value: 1

• Exit Registry Editor.

Note: For USB keyboard, Restart is not required. Instead unplug the keyboard and plug it again after this regkey setting.

2.  After setting this regkey, select the appropriate memory dump file option using the below steps:

• Right-click My Computer and then click Properties.
• Click the Advanced tab, and then click the Startup and Recovery button.
• Click Write Debugging Information and then click to select Complete Memory Dump, Kernel Memory Dump, or Small Memory Dump.

3.  When you get the hang, just hold down the CTRL key and pressing the SCROLL LOCK key two times. You must use the CTRL key on the right side of the spacebar.

You can see a Blue screen (as you see during BSOD) wherein it shows the progress of collecting the crash dumps.

Machine will be restarted after this process and you can get the memory dump in "C:\Windows\MEMORY.DMP"

For detailed info, visit this page http://support.microsoft.com/kb/244139

Getting heap information in case of Heap Corruption

• Enable WinDbg as Post-Mortem debugger using the command  - Windbg -I
• Enable Full Page Heap Verification for the process (In case of Heap Corruption). Use the below command gflags.exe -p /enable <Image File> /full           
• When the crash occurs, type the following in the Windows Debugger Command Window   .dump /ma <Dump_Path\File_Name.dmp>
• As the Page Heap is enabled, we will get complete details of Stack+Heap in the Dump. (Check the Size of the Dump .... It should be approx. 200 MB +).
• When the dump is created, disable the heap for the particular application. gflags.exe -p /disable <Image File>

Note: Make sure the gflags is enabled before the corresponding process (for which you are trying to generate the dump) starts. In other words, kill the process for which you want to get the heap information, enable gflags for that process, start the process, reproduce the crash and get the dump.

For more information on crash dump you can refer http://msdn.microsoft.com/en-us/library/cc265901.aspx

Set Symbols for Debugging

• Private symbols files have all information in them for the debugger to resolve data (local variables, structure type information, functions, source file name/line info...).
• Public symbols files are essentially stripped versions of private symbols that usually just contain the function information so that stack traces work. Sometimes limited type information is included so that debugger extensions can work.
• Export symbols are the symbols contained inside the binary, so you have these without a .pdb. They contain the public/exported function names.

1) Download the XP/Vista symbols from http://www.microsoft.com/whdc/DevTools/Debugging/symbolpkg.mspx

2) Install the symbols

3) Set the symbol path in windbg via,

Start > Programs > Debugging Tools for Windows > Windbg > File > Symbol File Path

Windbg commands to get the first level info

• Get Stack Trace using !analyze -v
• Task Tree using tlist.exe -t
• Services active in each process using tlist.exe -s
• Command Line Information using tlist.exe -c
• Complete Verbose Information using tlist.exe –v

Remote Kernel Debugging

Sometimes if you want to set a breakpoint in the windows kernel and the kernel hit the breakpoint, then the whole system would freeze, because kernel controls (among other stuff) process management, thread switching, etc. In such situations use of two computers to do a remote kernel debugging would be a better option. Below are the steps to perform Remote Kernel debugging using a serial cable or USB cable or Firewire (IEEE 1394).

• Consider “Machine 1”, which is the computer that you want to debug and ‘Machine 2”, which is the computer running Windbg. First, connect these two computers using Serial cable or USB cable or Firewire
• Now from Machine 2, start Windbg > File > Kernel Debug & select COM or USB or 1394 according to the connection you have made.
• Specify the values in the corresponding tab as below and click OK to the Kernel Debugging window
  • COM
    • Baud rate – 115200 (mostly)
    • Port – COM1 or COM2
    • You can check the ‘Pipe’ option if you want to debug a Vmware running in Machine 2
  • USB
    • Specify the target name (any name, but the same should be used in Machine 1)
  • 1394
    • Specify the Channel (a numeric value, but the same should be used in Machine 1)
• Now windbg in Machine 2 will wait until you configure Machine 1 to go into debug mode
• From Machine 2, enter into safe mode with networking.
  • XP
    • From command prompt go to C:\Windows\System32 folder
    • Type, bootcfg.exe /debug ON /baud 115200 /PORT COM1 /id 1
    • Use corresponding commands for USB or 1394
  • Vista
    • From command prompt go to C:\Windows\System32 folder
    • Type, bcdedit /dbgsettings DebugType [debugport:Port] [baudrate:Baud]
    • Ex, for serial debugging (using COM1 at 115200bps) it is: bcdedit /dbgsettings serial debugport:1 baudrate:115200
    • After that, enable debugging by using the below command. bcedit /debug on
    • Restart the Machine 1, if everything was configured correctly, you will see Machine 1 stop during boot, and Machine 2's windbg will print a message saying that the connection was established.
• Now reproduce the crash
• From Machine 1 , use the below command to get the crash dump. .dump /ma <path\filename>.dmp

References

• http://support.microsoft.com/kb/244139
• http://blogs.msdn.com/iliast/archive/2006/12/10/windbg-tutorials.aspx

Read More

How to get Crash or Hang dump?

I have various methods/tools to collect crash/ hang dump. This article is aimed to consolidate and provide all the related information in a single nutshell.

Target Users : The Reader is familiar with Windows OS (XP & Vista)

Wondering what crash is & how to get crash dump! Here U go!!

A crash in computing is a condition where a program (either an application or part of the operating system) stops performing its expected function and also stops responding to other parts of the system. Often the offending program may simply appear to freeze.

A crash can either be a software fault or system crash. A software fault occurs whenever an exception is left unhandled. Upon software fault the OS stops the application from proceeding further.

System Crash or Blue screens on NT-based Windows systems are usually caused by poorly-written device drivers or malfunctioning hardware. Blue screens can also be caused by physical faults such as faulty memory, power supplies, overheating of computer components, or hardware running beyond its specification limits.

Various Methods for collecting crash dump

Below are the few methods to collect crash information.

• Using Windbg
• Using Adplus
• Using ‘Create Dump option in Vista
• Using ‘Problem Reports & Solutions’ in Vista
• Getting dump on BSOD
• From Keystroke
• Dump on Heap corruption

Generate crash dump using Windbg as default post-mortem debugger

• Install Windbg before installing the product.
• Set Windbg as the default post-mortem debugger
• Launch command prompt (as admin in Vista)
• Go to the windbg installed path (C:\Program Files\Debugging Tools for Windows\)
• Type “windbg.exe –I” and hit ‘Enter’
• You will see the message “Windbg is set as default post mortem debugger”

Now install the product and continue with your testing. Whenever crash occurs, windbg opens automatically. The below command is used to collect the crash.

.dump /ma <path>\<filename>.dmp

Where, <path> is the path where you want to save the crash dump and <filename> is the name of the file.

Generate crash dump using Windbg after crash occurs (not set any post-mortem debugger)

• Install Windbg
• From the crash window, see which process is crashed
• From the task manager, identify the process Id
• Make sure you have not closed the crash window
• Launch windbg from “Start > Programs > Debugging Tools for Windows > WinDbg”
• Select File > Attach to a Process
• Select the Process for which you want to collect the crash dump and click OK
• Type the command .dump /ma <path>\<filename>.dmp in the launched window

Generate Crash/hang dump using Adplus (not set any post-mortem debugger)

• Install Windbg
• Identify the process for which you want to generate the dump
• Make a note of the process id from task manager
• From command prompt (run as ‘admin’ for Vista), go to C:\Program Files\Debugging Tools for Windows\
• Type “adplus.vbs” and hit ‘Enter’
• In the launched dialogs click ‘Ok’
• In the newly launched command window, you can use any of the below commands
  1. ‘adplus –crash –p <pid>’
  2. ‘adplus –crash –pn <pname>’
  3. ‘adplus –hang –p <pid>’
  4. ‘adplus –hang –pn <pname>’
• Click ‘Ok’ in the launched dialogs
• cdb.exe will be running
• Now perform the test steps you want to do (you want to make a crash/hang)

Once the process crashed the dump will be automatically generated as a dated folder in “C:\Program Files\Debugging Tools for Windows\”

If the cdb.exe doesn’t end, you can use Ctl+C to quit the cdb.exe window and can get the dump

Generate dump using ‘Create Dump’ option in Vista

• Identify the process for which you want to collect the dump
• Go to Task Manager > Right click the process > click ‘Create Dump’
• The dump will be created in %temp% folder

Generate dump using ‘Problem Reports & Solutions’ in Vista

Windows Vista introduced the “Problem Reports and Solutions” control panel application. This dialog will show all detected application errors on the user’s machine. When a crash is encountered, we can leverage this built-in utility to get more information about what went wrong, and how to get more information to help resolve the issue.

When this event is recorded, there are three possible scenarios

• The crash or hang was recorded and submitted
• The crash or hang was recorded, but not yet submitted
• The crash or hang was recorded, but no information was captured.

The first two can provide us with valuable information to troubleshoot the issue. The third can give us a general idea, but no specific information about the exact issue the user reported.

Windows Error Reporting configuration is stored in the following registry key in Vista

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting

User based settings such as Block list are stored at:

HKEY_CURRENT_USER\Software\Microsoft\ Windows\Windows Error Reporting

Problem Reports and Solutions

This dialog is available via Start / Control Panel / Problem Reports and Solutions, or under Start / Control Panel / System and Maintenance / Problem Reports and Solutions (depending on whether the user has “classic view” configured or not). From there, click on “View Problem History”, and look for instances of applications. Double click an entry of interest, and select the “Copy to Clipboard” link, and provide the info. The data will tell us how much information is available, without any other files.

Case 1: WER data Submitted

In this case, the error report has already been submitted. The “Copy to Clipboard” data will include the bucket ID. Usually, in this case, the event files are removed from the local computer, as they have already been submitted. We must look up the crash using the bucket ID provided.

Case 2: WER data Available Locally

In other cases, the report has not yet been sent to WinQual. In this case, we can generally collect the files locally. The files that are available will also be included with the “Copy to clipboard” link at the bottom of the screen is used.

Once the “View Copy” of files link is clicked, an explorer window in the temp directory will be opened. The files present in the temp directory will definitely give more information on crash and hence this can be given to the developer for analysis.

Case 3: WER data not available or Submitted

Unfortunately, in some cases there’s no data available but the exception code, modules names and versions, and offset of the crash. In this case, the best we can do is dig through the data on winqual in an attempt to find it, but it’s not guaranteed the correct crash will be found. The screen shot below is of a managed application.

Blue Screens

In many cases, reports of bug checks (BSODs) will also appear on this screen, allowing this approach to be used when a user experiences a system crash and suspects it may be related to specific software. The approach may be used to collect information about this type of crash as for the application hangs or crashes described above.

Common Issues

In some cases, multiple crashes can appear at the same module & offset. Having a WinQual bucket ID or simply a module offset is sometimes not sufficient to describe the exact crash the user encountered.

Note:

1. When a process is added to the Block list of ‘Problem Reports and Solutions’ you will not get the WER Report for that process.

This can be checked by looking at the Block List at,

Control Panel > Classic View > ‘Problem Reports and Solutions’ > Change Settings > Advanced Settings > Block List

2. Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crash.

For more information on this refer http://msdn.microsoft.com/en-us/library/bb787181.aspx

Generate Dump on BSOD

Whenever BSOD occurs the memory dump will be collected automatically at

%SystemRoot%MEMORY.DMP

But the default dump is a small memory dump. In order to get the complete memory dump or kernel memory dump

• Go to System Properties > Advanced > Startup and Recovery > Settings
• From Write debugging information, choose the one which you want
• Click Ok.
• Proceed with your testing.

Generate Memory Dump using keyboard

Following are the steps to generate the dump using keyboard:

1.    To enable keyboard crash dumping, we need to enable a regkey in regedit. This setting varies w.r.t the keyboard type we use in our machine.

To enable the feature on a computer that uses a PS/2 keyboard, follow these steps:

• Start Registry Editor.
• Locate the following registry subkey:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\i8042prt\Parameters
• On the Edit menu, click Add Value, and then add the following registry entry:
• Name: CrashOnCtrlScroll
  Data Type: REG_DWORD
  Value: 1
• Exit Registry Editor and then restart the computer.

Note: Restart the computer after this regkey setting is must for PS/2 Keyboard.

To enable the feature on a computer that uses a USB keyboard, install the hotfix that is mentioned in the "Windows Server 2003 resolution" subsection of the article at http://support.microsoft.com/kb/244139

To make sure that the feature is enabled on a computer that uses a USB keyboard, follow these steps:

• Start Registry Editor.
• Locate the following registry subkey:

         HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\ Services\kbdhid\Parameters

• Make sure that the following registry entry is enabled:

  Name: CrashOnCtrlScroll
  Data Type: REG_DWORD
  Value: 1

• Exit Registry Editor.

Note: For USB keyboard, Restart is not required. Instead unplug the keyboard and plug it again after this regkey setting.

2.  After setting this regkey, select the appropriate memory dump file option using the below steps:

• Right-click My Computer and then click Properties.
• Click the Advanced tab, and then click the Startup and Recovery button.
• Click Write Debugging Information and then click to select Complete Memory Dump, Kernel Memory Dump, or Small Memory Dump.

3.  When you get the hang, just hold down the CTRL key and pressing the SCROLL LOCK key two times. You must use the CTRL key on the right side of the spacebar.

You can see a Blue screen (as you see during BSOD) wherein it shows the progress of collecting the crash dumps.

Machine will be restarted after this process and you can get the memory dump in "C:\Windows\MEMORY.DMP"

For detailed info, visit this page http://support.microsoft.com/kb/244139

Getting heap information in case of Heap Corruption

• Enable WinDbg as Post-Mortem debugger using the command  - Windbg -I
• Enable Full Page Heap Verification for the process (In case of Heap Corruption). Use the below command gflags.exe -p /enable <Image File> /full           
• When the crash occurs, type the following in the Windows Debugger Command Window   .dump /ma <Dump_Path\File_Name.dmp>
• As the Page Heap is enabled, we will get complete details of Stack+Heap in the Dump. (Check the Size of the Dump .... It should be approx. 200 MB +).
• When the dump is created, disable the heap for the particular application. gflags.exe -p /disable <Image File>

Note: Make sure the gflags is enabled before the corresponding process (for which you are trying to generate the dump) starts. In other words, kill the process for which you want to get the heap information, enable gflags for that process, start the process, reproduce the crash and get the dump.

For more information on crash dump you can refer http://msdn.microsoft.com/en-us/library/cc265901.aspx

Set Symbols for Debugging

• Private symbols files have all information in them for the debugger to resolve data (local variables, structure type information, functions, source file name/line info...).
• Public symbols files are essentially stripped versions of private symbols that usually just contain the function information so that stack traces work. Sometimes limited type information is included so that debugger extensions can work.
• Export symbols are the symbols contained inside the binary, so you have these without a .pdb. They contain the public/exported function names.

1) Download the XP/Vista symbols from http://www.microsoft.com/whdc/DevTools/Debugging/symbolpkg.mspx

2) Install the symbols

3) Set the symbol path in windbg via,

Start > Programs > Debugging Tools for Windows > Windbg > File > Symbol File Path

Windbg commands to get the first level info

• Get Stack Trace using !analyze -v
• Task Tree using tlist.exe -t
• Services active in each process using tlist.exe -s
• Command Line Information using tlist.exe -c
• Complete Verbose Information using tlist.exe –v

Remote Kernel Debugging

Sometimes if you want to set a breakpoint in the windows kernel and the kernel hit the breakpoint, then the whole system would freeze, because kernel controls (among other stuff) process management, thread switching, etc. In such situations use of two computers to do a remote kernel debugging would be a better option. Below are the steps to perform Remote Kernel debugging using a serial cable or USB cable or Firewire (IEEE 1394).

• Consider “Machine 1”, which is the computer that you want to debug and ‘Machine 2”, which is the computer running Windbg. First, connect these two computers using Serial cable or USB cable or Firewire
• Now from Machine 2, start Windbg > File > Kernel Debug & select COM or USB or 1394 according to the connection you have made.
• Specify the values in the corresponding tab as below and click OK to the Kernel Debugging window
  • COM
    • Baud rate – 115200 (mostly)
    • Port – COM1 or COM2
    • You can check the ‘Pipe’ option if you want to debug a Vmware running in Machine 2
  • USB
    • Specify the target name (any name, but the same should be used in Machine 1)
  • 1394
    • Specify the Channel (a numeric value, but the same should be used in Machine 1)
• Now windbg in Machine 2 will wait until you configure Machine 1 to go into debug mode
• From Machine 2, enter into safe mode with networking.
  • XP
    • From command prompt go to C:\Windows\System32 folder
    • Type, bootcfg.exe /debug ON /baud 115200 /PORT COM1 /id 1
    • Use corresponding commands for USB or 1394
  • Vista
    • From command prompt go to C:\Windows\System32 folder
    • Type, bcdedit /dbgsettings DebugType [debugport:Port] [baudrate:Baud]
    • Ex, for serial debugging (using COM1 at 115200bps) it is: bcdedit /dbgsettings serial debugport:1 baudrate:115200
    • After that, enable debugging by using the below command. bcedit /debug on
    • Restart the Machine 1, if everything was configured correctly, you will see Machine 1 stop during boot, and Machine 2's windbg will print a message saying that the connection was established.
• Now reproduce the crash
• From Machine 1 , use the below command to get the crash dump. .dump /ma <path\filename>.dmp

References

• http://support.microsoft.com/kb/244139
• http://blogs.msdn.com/iliast/archive/2006/12/10/windbg-tutorials.aspx

Read More

Validating the Security of Web Based Applications

Introduction

The emergence of Web applications has brought in lot of evolutions in the field of business. An increase in the usage of web applications is directly related to an increase in the number of security attacks invited by them.

To list a few attacks that grabbed the attention are:

• In 2006, K2 Networks Inc, an operator of Asian games for US market claims to have lost over USD 1 million in a single year due to account compromises. The attacks that were sited were SQL Injection attacks.
• “PetCo plugs credit card leak” – Around 5 lakh credit card numbers were open to hackers with the help of SQL injection attack

Thus most of the web applications that were developed to make life easier by offering online trading become prone to network attacks or security threats and hence turn out to be “The Necessary Evils”.

This article focuses on some of the Command Execution attacks that invade a web application. It also describes about the ways to detect these attacks and methodologies to validate the security of those web applications. It also touches upon some of the free-wares that are available to detect these threats.

Command Execution Attacks

The Command Execution section covers attacks designed to execute remote commands on the web site. All web sites utilize user-supplied input to fulfill requests. Often these user-supplied data are used to create construct commands resulting in dynamic web page content. If this process is done insecurely, an attacker could alter command execution.

Some of the attacks are as follows:-

1. Buffer Overflow Attack - Buffer Overflow exploits are attacks that alter the flow of an application by overwriting parts of memory.
2. Format String Attack Format String Attacks alter the flow of an application by using formatting library features to access other memory space.
3. LDAP Injection - LDAP Injection is an attack technique used to exploit web sites that construct LDAP statements from user-supplied input.
4. OS Commanding - OS Commanding is an attack technique used to exploit web sites by executing Operating System commands through manipulation of application input.
5. SQL Injection - SQL Injection is an attack technique used to exploit web sites that construct SQL statements from user-supplied input.
6. SSI Injection - SSI Injection (Server-side Include) is a server-side exploit technique that allows an attacker to send code into a web application, which will later be executed locally by the web server.
7. XPATH Injection - XPATH Injection is an attack technique used to exploit web sites that construct XPATH queries from user-supplied input.

1. Buffer Overflow

The term Buffer Overflow means “generating/providing excess of data than what a buffer or variable can hold”. Since the variable size is defined and hence cannot hold more than the defined size, the excess data will be written in the next data storage area. This will in turn corrupt this storage area also.

Hackers make use of this and inject their code in the form of extra data which gets stored in the storage area. This extra data can get executed and may cause adverse effects. Some of these are Denial of Service, disclosure of confidential information and change to any personal data.

The Buffer Overflow attacks are the common ones in the web based applications. Testing for these attacks is very tricky unless the code is gone through by the tester line by line and looking for data overflow in the code. There are some free-wares available that can be used for testing buffer overflow.

One such tool is called “NTOMax”. This tool will take a text file as input and will try to catch the places where Buffer Overflow could occur. The input file should contain the host name, port, minimum buffer size and maximum limit.

Since Web applications read all types of inputs, there is a high possibility that Buffer Overflow can occur at any point when the web based applications interact and use services and dlls from other non-safe languages like C/C++.

Mitigation methods include using safe string libraries and container abstractions. The safe string functions take the size of the destination buffer as an input parameter, to ensure that the function does not write past the end of the buffer. These functions also null-terminate all output strings, to avoid problems caused by a missing null terminator.

The best way to prevent buffer overflow problems is to validate the input data before using it in the application.

There are two types of Buffer overflow: Stack based and heap based.

2. SQL Injection

This type of hacking uses SQL commands and injects these commands to retrieve the data from application. Other effects of SQL injection attacks include Add/Modify and Delete records/tables from the application.

Hackers use input that would generate invalid SQL query to hack data from the web application. There are two types of SQL injection: (1) Normal SQL injection and (2) Blind SQL Injection.

In Normal SQL Injection attacks, the hacker tries to write an invalid SQL query. On executing this invalid query, the database returns some error messages. Using these error messages, the hacker will be able to understand and determine the database structure and the fields in the tables. By repeating this method, the hacker will get more familiarized with the entire structure of the database.

In Blind SQL Injection attacks, the error messages that get generated due to invalid SQL queries are suppressed by the developers. Hence, the hackers use trial and error methods to construct a valid SQL query in order to retrieve information about the database.

Checking for SQL Injection in the web based applications can be done in the following ways:

• Analyzing the present state of security present by performing a thorough audit of your website and web applications for SQL Injection and other hacking vulnerabilities.
• Making sure that you use coding best practice sanitizing your web applications and all other components of your IT infrastructure.
• Regularly performing a web security audit after each change and addition to your web components.

Manual vulnerability auditing is complex and very time-consuming. This requires a high level of expertise and the ability to handle large volumes of code. Hence, web applications can be tested using automated scanners available.

An automated web vulnerability scanner scans the entire web site and checks the areas that are prone to attacks. By scanning, it will find the URLs that can be attacked by SQL Injection. One such scanner that is available as a free-ware for limited trial period is Acunetix Web Vulnerability Scanner. Provides you with an immediate and comprehensive website security audit

• Ensures your website is secure against web attacks
• Checks for SQL injection, Cross site scripting and other vulnerabilities
• Audits shopping carts, forms, and dynamic content
• Scans all your website and web applications including JavaScript / AJAX applications for security vulnerabilities.

Acunetix Site Audit grants you immediate access to the latest technologies and best practices in web vulnerability scanning, eliminating your total cost of ownership.

3. XPATH Injection

Any web application that uses XML to store and retrieve data are prone to attacks by XPATH Injection .Data is stored in XML in a node tree structure. XPATH language is used for retrieving information from the nodes of an XML document. When an application has to retrieve data from the XML document based on user input, it sends an XPATH query which gets executed on the server. Some sample XPATH queries are as follows

/	Selects the root node of the tree
/users	Selects all "users" child elements of the root node
/users/user[@admin= ‘true’	Selects all user child elements whose “admin” attribute has the value “true”
/*	Selects all elements of the root

As we have seen earlier how SQL injection is done by injecting the attackers query into the application to retrieve hidden information, XPATH injection also uses a similar technique. The attacker injects his own XPATH query and makes the Web Server execute it instead of the one defined in the application. Some of the ways of performing XPATH Injection are Blind and Single Query Attacks

The key to executing a Blind XPATH Injection attack is the ability to “ask” the server a series of true or false “questions” to know the about the data structure and query according to our requirements.

AJAX applications are especially vulnerable because XML fragments are sent to the client for processing. When XPATH query result fragments are processed directly on the client, attacks can be perpetrated with a script-kiddie level of simplicity. The XPATH Single Query Attack method allows an attacker to extract the backend document with a single request to the server. Single Query Attack can run quickly and are much harder to detect as an attack. And unlike blind forms of injection attacks, they are not tedious to perform. There are three properties of XPATH that make attacks against AJAX applications extremely effective: simple joins, error resilience, and easy top level document access.

The best method for preventing XPATH injection vulnerability is by properly validating user input for both type and format. All client-supplied data needs to be cleansed of any characters or strings that could possibly be used maliciously. The best method of doing this is via “white listing”. This is defined as only accepting specific data for specific fields, such as limiting user input to account numbers or account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. Stripping quotes or putting backslashes in front of them is not enough, and is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.

A good method of filtering data is by using a default-deny regular expression.
Make it so that you include only the type of characters that you want. For instance, the following regular expression will return only letters and numbers: s/ [^0-9a-zA-Z]//\

Make your filter narrow and specific. Whenever possible, use only numbers. After that, numbers and letters only. If you need to include symbols or punctuation of any kind, make absolutely sure to convert them to HTML substitutes, such as &quote; or & gt. For instance, if the user is submitting an e-mail address, allow only the “at” sign, underscore, period, and hyphen in addition to numbers and letters, and allow them only after those characters have been converted to their HTML substitutes.

Some of the freeware tools available to detect XPATH injection are as follows

Paras from SourceForge and WS Digger from Foundstone (McAfee).

Paras

Paras is a Java based HTTP/HTTPS proxy for assessing web application vulnerability. It supports editing/viewing HTTP messages on-the-fly. Other features include spiders, client certificate, and proxy-chaining, intelligent scanning for XSS and SQL injections etc. It is platform independent only requires JRE 1.4. The following are the functions of Paras tool.

Spider

Spider is used to crawl the websites and gather as many URL links as possible. This allows you to have a better understanding of the web site hierarchy tree in a short time before manual navigation. It supports cookie and proxy chaining, which is set at the
field in Option tab. Automatically add URL links to the web site hierarchy tree for later scanning.

Scanner

The scanner function is to scan the server based on the website hierarchy. It can check if there is any server mis configuration. Automatic web scanner may not be able to find out the paths and check if there exist any backup files (.bak) which could expose server information. In order to use this function, you need to navigate the website first. After you logon a website and navigate it, a website hierarchy tree will be built by Paros automatically. Then you can do the following things:

a) If you want to scan all websites on the tree, you can then click on the menu item "Tree" =>"Scan All" to trigger the scanning.
b) If you just want to scan one website on the tree, you can click on that site in the tree panel and click menu item "Tree" => "Scan selected Node" (You can also right click on the tree view and choose the options).

Paras include the following checks:

• HTTP PUT allowed − check if the PUT option is enabled at server directories
• Directory index table − check if the server directories can be browsed.
• Obsolete files existed − check if there exist obsolete files at
• Cross−site scripting − check if Cross−site scripting (XSS) is allowed on the query parameters

Default files on web sphere server – check if default files existed on web sphere server
Note that all the above checks are based on the URLs in the website hierarchy. That means the scanner will check each URL for each vulnerability. Compared with other web scanners which just do a blink scan without website hierarchy, our scanning result is more accurate.

Filter

The use of filters is to detect and alert you the occurrence of certain predefined patterns in HTTP message. If you use filters you do not need to trap every HTTP message and seek for the pattern. You can also use filters to log information in which you are interested. Paros has the following filters:

a) LogCookie
b) LogGetQuery,
c) LogPostQuery,
d) CookieDetectFilter,
e) IfModifiedSinceFilter•

WS Digger Tool

The WS Digger tool from McAfee is more helpful in testing as it has very good features as follows:

• Built in sample attack plug-ins: SQL injection, cross site scripting, XPATH injection.
• Automated web services discovery: The tool analyzes public and or private UDDI to discover web services related to search strings.
• Automated attack vector discovery: It analyzes the web service to determine potential points of attack.
• Automated and manual exploit testing: It can be used to manually inject malicious data and generate test cases which can be automatically executed through the attack plug-ins.
• HTML reporting: It also reports of the results and test case history for further analysis.

4. Format String Vulnerability

Format String Vulnerability got familiarized only early 90’s. Format string Injection vulnerability could take advantage of the format string function to hack the system.

Format string Vulnerability occurs when a user supplied data are used directly as formatting string input for functions. Format string attacks alter the flow of an application by using string formatting library features to access memory space.

Consider a programmer who wants to print out a string or copy it to some buffer. What he means to write is something like:
Printf ("%s", str); but instead he decides that he can save time, effort and 6 bytes of source code by typing: printf (str);
The first argument to printf is a string to be printed. Instead, the string is interpreted by the printf function as a format string. It is scanned for special format characters such as "%d". As formats are encountered, a variable number of argument values are retrieved from the stack. At the least, it should be obvious that an attacker can peek into the memory of the program by printing out these values stored on the stack.

The possible use of Format string attacks are Read data from the stack, Read character strings from the Process’s memory, Write an integer to locations in the process’s memory.

Format string attacks falls in to three categories,

• Denial of Service
• Reading
• Writing

Denial of Service: - Format String Vulnerability attacks are characterized by continuously reading from the instance of stack data by using %s until the program attempts to read data from an illegal address, which will cause program to crash.

Reading : - Format String Vulnerability reading attacks attempts to read from memory that we do not normally have access to. This technique uses %x format specifies to print sections of memory.

Writing : - Format string Vulnerability writing attacks utilize the %d %u or %x format specifies to overwrite the instruction pointer and force the execution of user supplied shell code. By using %n conversion character, an attacker may write an integer value to any location in memory.

The key to testing format string vulnerabilities is supplying format type specifiers in application input.

For example: - Consider an application that processes a URL string or accepts inputs from form, http://abcd.com/html/en/index.htm, if format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.
Format string vulnerabilities is more common in web servers, application servers or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases an error reporting or logging function like syslog ( ) has been called insecurely.
When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like http://hostname/cgi-bin/query.cgi?name=allen&code=45000 can be altered
http://hostname/cgi-bin/query.cgi?name=allen%x.%x.%x&code=45000%x.%x, if a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.
There are several tools available to validate Format String Vulnerability in source code. In the case of manual testing, reviews should include more priority to several formatting functions that are specific to the development platform and those functions should be validated for absence of format strings.
ITS4 a tool for statically scanning security critical c and c++ source code for vulnerabilities. ITS4 tool along with source code is available from

http://www.rstcorp.com/its4/.

Conclusion

Apart from the Command Execution attacks discussed, Client Side Attacks also challenge the security of web based applications.
The Client-side Attacks focuses on the abuse or exploitation of a web site’s users. When a user visits a web site, trust is established between the two parties both technologically and psychologically. A user expects web sites they visit to deliver valid content. A user also expects the web site not to attack them during their stay. By leveraging these trust relationship expectations, an attacker may employ several techniques to exploit the user.
In Content Spoofing, technique used is to trick a user into believing that certain content appearing on a web site is legitimate and not from an external source.
In Cross-site Scripting (XSS), the web site is forced to echo attacker-supplied executable code, which loads in a user’s browser.
Web applications are used for variety of functions like booking tickets, shopping, banking which involves lot of money, so they should be made more robust and free from vulnerable attacks. The usage of web applications will be more if they are well secured. The approach of validating the web application should not only focus on the functionality & load testing but should also focus on validating the security of the web applications against vulnerabilities.

References

• http://www.foundstone.com
• http://www.owasp.org
• http://www.securitydocs.com
• http://www.rstcorp.com/its4/
• http://www.securityfocus.com/infocus/1704
• http://sectools.org/web-scanners.html
• http://searchsecurity.techtarget.com/

Read More

Validating the Security of Web Based Applications

Introduction

The emergence of Web applications has brought in lot of evolutions in the field of business. An increase in the usage of web applications is directly related to an increase in the number of security attacks invited by them.

To list a few attacks that grabbed the attention are:

• In 2006, K2 Networks Inc, an operator of Asian games for US market claims to have lost over USD 1 million in a single year due to account compromises. The attacks that were sited were SQL Injection attacks.
• “PetCo plugs credit card leak” – Around 5 lakh credit card numbers were open to hackers with the help of SQL injection attack

Thus most of the web applications that were developed to make life easier by offering online trading become prone to network attacks or security threats and hence turn out to be “The Necessary Evils”.

This article focuses on some of the Command Execution attacks that invade a web application. It also describes about the ways to detect these attacks and methodologies to validate the security of those web applications. It also touches upon some of the free-wares that are available to detect these threats.

Command Execution Attacks

The Command Execution section covers attacks designed to execute remote commands on the web site. All web sites utilize user-supplied input to fulfill requests. Often these user-supplied data are used to create construct commands resulting in dynamic web page content. If this process is done insecurely, an attacker could alter command execution.

Some of the attacks are as follows:-

1. Buffer Overflow Attack - Buffer Overflow exploits are attacks that alter the flow of an application by overwriting parts of memory.
2. Format String Attack Format String Attacks alter the flow of an application by using formatting library features to access other memory space.
3. LDAP Injection - LDAP Injection is an attack technique used to exploit web sites that construct LDAP statements from user-supplied input.
4. OS Commanding - OS Commanding is an attack technique used to exploit web sites by executing Operating System commands through manipulation of application input.
5. SQL Injection - SQL Injection is an attack technique used to exploit web sites that construct SQL statements from user-supplied input.
6. SSI Injection - SSI Injection (Server-side Include) is a server-side exploit technique that allows an attacker to send code into a web application, which will later be executed locally by the web server.
7. XPATH Injection - XPATH Injection is an attack technique used to exploit web sites that construct XPATH queries from user-supplied input.

1. Buffer Overflow

The term Buffer Overflow means “generating/providing excess of data than what a buffer or variable can hold”. Since the variable size is defined and hence cannot hold more than the defined size, the excess data will be written in the next data storage area. This will in turn corrupt this storage area also.

Hackers make use of this and inject their code in the form of extra data which gets stored in the storage area. This extra data can get executed and may cause adverse effects. Some of these are Denial of Service, disclosure of confidential information and change to any personal data.

The Buffer Overflow attacks are the common ones in the web based applications. Testing for these attacks is very tricky unless the code is gone through by the tester line by line and looking for data overflow in the code. There are some free-wares available that can be used for testing buffer overflow.

One such tool is called “NTOMax”. This tool will take a text file as input and will try to catch the places where Buffer Overflow could occur. The input file should contain the host name, port, minimum buffer size and maximum limit.

Since Web applications read all types of inputs, there is a high possibility that Buffer Overflow can occur at any point when the web based applications interact and use services and dlls from other non-safe languages like C/C++.

Mitigation methods include using safe string libraries and container abstractions. The safe string functions take the size of the destination buffer as an input parameter, to ensure that the function does not write past the end of the buffer. These functions also null-terminate all output strings, to avoid problems caused by a missing null terminator.

The best way to prevent buffer overflow problems is to validate the input data before using it in the application.

There are two types of Buffer overflow: Stack based and heap based.

2. SQL Injection

This type of hacking uses SQL commands and injects these commands to retrieve the data from application. Other effects of SQL injection attacks include Add/Modify and Delete records/tables from the application.

Hackers use input that would generate invalid SQL query to hack data from the web application. There are two types of SQL injection: (1) Normal SQL injection and (2) Blind SQL Injection.

In Normal SQL Injection attacks, the hacker tries to write an invalid SQL query. On executing this invalid query, the database returns some error messages. Using these error messages, the hacker will be able to understand and determine the database structure and the fields in the tables. By repeating this method, the hacker will get more familiarized with the entire structure of the database.

In Blind SQL Injection attacks, the error messages that get generated due to invalid SQL queries are suppressed by the developers. Hence, the hackers use trial and error methods to construct a valid SQL query in order to retrieve information about the database.

Checking for SQL Injection in the web based applications can be done in the following ways:

• Analyzing the present state of security present by performing a thorough audit of your website and web applications for SQL Injection and other hacking vulnerabilities.
• Making sure that you use coding best practice sanitizing your web applications and all other components of your IT infrastructure.
• Regularly performing a web security audit after each change and addition to your web components.

Manual vulnerability auditing is complex and very time-consuming. This requires a high level of expertise and the ability to handle large volumes of code. Hence, web applications can be tested using automated scanners available.

An automated web vulnerability scanner scans the entire web site and checks the areas that are prone to attacks. By scanning, it will find the URLs that can be attacked by SQL Injection. One such scanner that is available as a free-ware for limited trial period is Acunetix Web Vulnerability Scanner. Provides you with an immediate and comprehensive website security audit

• Ensures your website is secure against web attacks
• Checks for SQL injection, Cross site scripting and other vulnerabilities
• Audits shopping carts, forms, and dynamic content
• Scans all your website and web applications including JavaScript / AJAX applications for security vulnerabilities.

Acunetix Site Audit grants you immediate access to the latest technologies and best practices in web vulnerability scanning, eliminating your total cost of ownership.

3. XPATH Injection

Any web application that uses XML to store and retrieve data are prone to attacks by XPATH Injection .Data is stored in XML in a node tree structure. XPATH language is used for retrieving information from the nodes of an XML document. When an application has to retrieve data from the XML document based on user input, it sends an XPATH query which gets executed on the server. Some sample XPATH queries are as follows

/	Selects the root node of the tree
/users	Selects all "users" child elements of the root node
/users/user[@admin= ‘true’	Selects all user child elements whose “admin” attribute has the value “true”
/*	Selects all elements of the root

As we have seen earlier how SQL injection is done by injecting the attackers query into the application to retrieve hidden information, XPATH injection also uses a similar technique. The attacker injects his own XPATH query and makes the Web Server execute it instead of the one defined in the application. Some of the ways of performing XPATH Injection are Blind and Single Query Attacks

The key to executing a Blind XPATH Injection attack is the ability to “ask” the server a series of true or false “questions” to know the about the data structure and query according to our requirements.

AJAX applications are especially vulnerable because XML fragments are sent to the client for processing. When XPATH query result fragments are processed directly on the client, attacks can be perpetrated with a script-kiddie level of simplicity. The XPATH Single Query Attack method allows an attacker to extract the backend document with a single request to the server. Single Query Attack can run quickly and are much harder to detect as an attack. And unlike blind forms of injection attacks, they are not tedious to perform. There are three properties of XPATH that make attacks against AJAX applications extremely effective: simple joins, error resilience, and easy top level document access.

The best method for preventing XPATH injection vulnerability is by properly validating user input for both type and format. All client-supplied data needs to be cleansed of any characters or strings that could possibly be used maliciously. The best method of doing this is via “white listing”. This is defined as only accepting specific data for specific fields, such as limiting user input to account numbers or account types for those relevant fields, or only accepting integers or letters of the English alphabet for others. Many developers will try to validate input by “black listing” characters, or “escaping” them. Basically, this entails rejecting known bad data, such as a single quotation mark, by placing an “escape” character in front of it so that the item that follows will be treated as a literal value. Stripping quotes or putting backslashes in front of them is not enough, and is not as effective as white listing because it is impossible to know all forms of bad data ahead of time.

A good method of filtering data is by using a default-deny regular expression.
Make it so that you include only the type of characters that you want. For instance, the following regular expression will return only letters and numbers: s/ [^0-9a-zA-Z]//\

Make your filter narrow and specific. Whenever possible, use only numbers. After that, numbers and letters only. If you need to include symbols or punctuation of any kind, make absolutely sure to convert them to HTML substitutes, such as &quote; or & gt. For instance, if the user is submitting an e-mail address, allow only the “at” sign, underscore, period, and hyphen in addition to numbers and letters, and allow them only after those characters have been converted to their HTML substitutes.

Some of the freeware tools available to detect XPATH injection are as follows

Paras from SourceForge and WS Digger from Foundstone (McAfee).

Paras

Paras is a Java based HTTP/HTTPS proxy for assessing web application vulnerability. It supports editing/viewing HTTP messages on-the-fly. Other features include spiders, client certificate, and proxy-chaining, intelligent scanning for XSS and SQL injections etc. It is platform independent only requires JRE 1.4. The following are the functions of Paras tool.

Spider

Spider is used to crawl the websites and gather as many URL links as possible. This allows you to have a better understanding of the web site hierarchy tree in a short time before manual navigation. It supports cookie and proxy chaining, which is set at the
field in Option tab. Automatically add URL links to the web site hierarchy tree for later scanning.

Scanner

The scanner function is to scan the server based on the website hierarchy. It can check if there is any server mis configuration. Automatic web scanner may not be able to find out the paths and check if there exist any backup files (.bak) which could expose server information. In order to use this function, you need to navigate the website first. After you logon a website and navigate it, a website hierarchy tree will be built by Paros automatically. Then you can do the following things:

a) If you want to scan all websites on the tree, you can then click on the menu item "Tree" =>"Scan All" to trigger the scanning.
b) If you just want to scan one website on the tree, you can click on that site in the tree panel and click menu item "Tree" => "Scan selected Node" (You can also right click on the tree view and choose the options).

Paras include the following checks:

• HTTP PUT allowed − check if the PUT option is enabled at server directories
• Directory index table − check if the server directories can be browsed.
• Obsolete files existed − check if there exist obsolete files at
• Cross−site scripting − check if Cross−site scripting (XSS) is allowed on the query parameters

Default files on web sphere server – check if default files existed on web sphere server
Note that all the above checks are based on the URLs in the website hierarchy. That means the scanner will check each URL for each vulnerability. Compared with other web scanners which just do a blink scan without website hierarchy, our scanning result is more accurate.

Filter

The use of filters is to detect and alert you the occurrence of certain predefined patterns in HTTP message. If you use filters you do not need to trap every HTTP message and seek for the pattern. You can also use filters to log information in which you are interested. Paros has the following filters:

a) LogCookie
b) LogGetQuery,
c) LogPostQuery,
d) CookieDetectFilter,
e) IfModifiedSinceFilter•

WS Digger Tool

The WS Digger tool from McAfee is more helpful in testing as it has very good features as follows:

• Built in sample attack plug-ins: SQL injection, cross site scripting, XPATH injection.
• Automated web services discovery: The tool analyzes public and or private UDDI to discover web services related to search strings.
• Automated attack vector discovery: It analyzes the web service to determine potential points of attack.
• Automated and manual exploit testing: It can be used to manually inject malicious data and generate test cases which can be automatically executed through the attack plug-ins.
• HTML reporting: It also reports of the results and test case history for further analysis.

4. Format String Vulnerability

Format String Vulnerability got familiarized only early 90’s. Format string Injection vulnerability could take advantage of the format string function to hack the system.

Format string Vulnerability occurs when a user supplied data are used directly as formatting string input for functions. Format string attacks alter the flow of an application by using string formatting library features to access memory space.

Consider a programmer who wants to print out a string or copy it to some buffer. What he means to write is something like:
Printf ("%s", str); but instead he decides that he can save time, effort and 6 bytes of source code by typing: printf (str);
The first argument to printf is a string to be printed. Instead, the string is interpreted by the printf function as a format string. It is scanned for special format characters such as "%d". As formats are encountered, a variable number of argument values are retrieved from the stack. At the least, it should be obvious that an attacker can peek into the memory of the program by printing out these values stored on the stack.

The possible use of Format string attacks are Read data from the stack, Read character strings from the Process’s memory, Write an integer to locations in the process’s memory.

Format string attacks falls in to three categories,

• Denial of Service
• Reading
• Writing

Denial of Service: - Format String Vulnerability attacks are characterized by continuously reading from the instance of stack data by using %s until the program attempts to read data from an illegal address, which will cause program to crash.

Reading : - Format String Vulnerability reading attacks attempts to read from memory that we do not normally have access to. This technique uses %x format specifies to print sections of memory.

Writing : - Format string Vulnerability writing attacks utilize the %d %u or %x format specifies to overwrite the instruction pointer and force the execution of user supplied shell code. By using %n conversion character, an attacker may write an integer value to any location in memory.

The key to testing format string vulnerabilities is supplying format type specifiers in application input.

For example: - Consider an application that processes a URL string or accepts inputs from form, http://abcd.com/html/en/index.htm, if format string vulnerability exists in one of the routines processing this information, supplying a URL like http://xyzhost.com/html/en/index.htm%n%n%n or passing %n in one of the form fields might crash the application creating a core dump in the hosting folder.
Format string vulnerabilities is more common in web servers, application servers or web applications utilizing C/C++ based code or CGI scripts written in C. In most of these cases an error reporting or logging function like syslog ( ) has been called insecurely.
When testing CGI scripts for format string vulnerabilities, the input parameters can be manipulated to include %x or %n type specifiers. For example a legitimate request like http://hostname/cgi-bin/query.cgi?name=allen&code=45000 can be altered
http://hostname/cgi-bin/query.cgi?name=allen%x.%x.%x&code=45000%x.%x, if a format string vulnerability exists in the routine processing this request, the tester will be able to see stack data being printed out to browser.
There are several tools available to validate Format String Vulnerability in source code. In the case of manual testing, reviews should include more priority to several formatting functions that are specific to the development platform and those functions should be validated for absence of format strings.
ITS4 a tool for statically scanning security critical c and c++ source code for vulnerabilities. ITS4 tool along with source code is available from

http://www.rstcorp.com/its4/.

Conclusion

Apart from the Command Execution attacks discussed, Client Side Attacks also challenge the security of web based applications.
The Client-side Attacks focuses on the abuse or exploitation of a web site’s users. When a user visits a web site, trust is established between the two parties both technologically and psychologically. A user expects web sites they visit to deliver valid content. A user also expects the web site not to attack them during their stay. By leveraging these trust relationship expectations, an attacker may employ several techniques to exploit the user.
In Content Spoofing, technique used is to trick a user into believing that certain content appearing on a web site is legitimate and not from an external source.
In Cross-site Scripting (XSS), the web site is forced to echo attacker-supplied executable code, which loads in a user’s browser.
Web applications are used for variety of functions like booking tickets, shopping, banking which involves lot of money, so they should be made more robust and free from vulnerable attacks. The usage of web applications will be more if they are well secured. The approach of validating the web application should not only focus on the functionality & load testing but should also focus on validating the security of the web applications against vulnerabilities.

References

• http://www.foundstone.com
• http://www.owasp.org
• http://www.securitydocs.com
• http://www.rstcorp.com/its4/
• http://www.securityfocus.com/infocus/1704
• http://sectools.org/web-scanners.html
• http://searchsecurity.techtarget.com/

Read More