Change Registered Owner Info On your Windows
Change Registered Owner Information
This is small and simple registry tweak you can perform so as to change the registered owner information of your computer/windows which you have entered wrong during the windows installation.
On run command, type regedit(regedit32 in some) and hit enter to start registry editor. First make a backup of your registry so that u can be safe if any mistake is done. I would say, make backup of registry before any tweak with it.
Now go to:
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion
Read More
Add your Comment
0
comments
Change Yahoo Messenger Title
Steps:
- Go to folder where you have installed yahoo messenger (ex: C:\Program Files\Yahoo!\Messenger)
- there u'll find one file named 'ymsgr' (Don't be confused with other file names. there's only one file named 'ymsgr')
- Open the file, go to the end and write following code:
[APP TITLE]
CAPTION=ADNAN
(In place of ADNAN you can write your own name or your own custom text)
- Save the file
Read More
Add your Comment
0
comments
Disable Right Click On your Desktop
This is small and simple registry tweak u can perform so as to disable right click on ur desktop.
On run command, type regedit(regedit32 in some) and hit enter to start registry editor. First make a backup of ur registry so that u can be safe if any mistake is done. I would say, make backup of registry before any tweak with it.
Now go to:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
Now add a DWORD value on the right side and name it as NoViewContextMenu.
Give it the value of 1.
Now exit registry and restart ur pc to see the effect. Isn't that cool?
If u want to enable right click again just delete the DWORD value or change its value to 0 and restart ur computer.
CHEERS!
Read More
Add your Comment
0
comments
Windows XP NASA Second Generation SP3 2010 (New Links)
WINDOWS XP
Now The Second Generation from Windows XP NASA SP3 2010 comes with New Exclusive Technology .. Used for the first time.. it "Automatic Recovery for Basic System Files in every Windows Boot" or "Self Maintenance" .. This means .. in every time windows reboot .. all basic system files will recover automatically as if windows installed for first time without affecting the programs and other files and without taking additional time!!
That's Amazing!! More use for the Windows increase the speedy and stability .. Windows XP NASA Second Generation SP3 2010 very fast, fully stable, NO system errors, High Internet speed . More developments and improvements for all features and functions of the previous edition "XP NASA SPACE v1.0 SP3 2010" VGA clarity, sound effects, Graphics and Multimedia, New 3D Themes Multi Color, Icons, 3D Wallpapers and Transparency.
Release Name: Windows XP NASA Second Generation SP3 2010
Read More
Add your Comment
1 comments
Finding IP From GMAIL Headers
When You send an email to any of your friends or others could be your Girl friends Never mind. But When you send the email through any email client like Gmail , Yahoo Mail , Hotmail, AOL, Outlook Express, etc it also sends the Email Header which contains Some important information for Us i.e.Hackers.
Basically it is a feature of Mailing protocol.
Now when the victim sends you a Email through any ,Gmail, Yahoo mail etc doesn't matter, then mail comes to your inbox in the form of Email Header but the your Email client changes it and shows only readable part of it.
Well This article is based on how to view Email headers in Gmail. We Will talk about others in Future too. Yeah its a kind of easy tutorial....
Finding IP address in Gmail
Login to your Gmail account with your username and password.
Open the mail.
Read More
Add your Comment
3
comments
Google Operating System 2010 (Android LiveCD - No Instalation)
LiveAndroid lets you download a disk image LiveCD operating system Google Android. Just record the image on the disc, placing it in the CD-ROM drive and restart your computer and you can test Android, without installing it and not touching any files on your computer.
Language: English
File: ISO
Size: 172.46 Mb
Checksums
MD5 E0C5C305F78CD958DBAEA3716C82296F
SHA-1 741B42748666AC085FC12692AC6AFB369B002A2E
CRC32 EEDBFF00
File: ISO
Size: 172.46 Mb
Checksums
MD5 E0C5C305F78CD958DBAEA3716C82296F
SHA-1 741B42748666AC085FC12692AC6AFB369B002A2E
CRC32 EEDBFF00
Read More
Add your Comment
1 comments
Change Google logo to your name
change google logo to your name
code
go to
http://www.google.com.pk
and now in adress bar type
http://www.shinysearch.com/randomlogo.php?ltext=ADNAN
replace ADNAN by your name
Read More
Add your Comment
0
comments
Megaupload and depositfiles premium hack
Get Megaupload and depositfiles premium speeds at no extra cost,
this script will be continuously updated to ensure maximum output.
ALL INTRUCTIONS ARE ENCLOSED ON THE INSIDE FILES,ENJOY!
Read More
Add your Comment
0
comments
Phone Unlock v7.1
Most phones will need a data cable to connect your Handset to the PC.
Most models catered for
- Ericsson: (virtually all models covered)
- LG: (virtually all models covered)
- Mitsibushi: (virtually all models covered)
- Motorola: (virtually all models covered)
=> also V3 - Black, Blue, Green, Pink & Silver
- NEC: (virtually all models covered)
- Nokia: (virtually all models covered)
- Panasonic: (virtually all models covered)
- Philips: (virtually all models covered)
- Sagem: (virtually all models covered)
- Samsung: (virtually all models covered)
- Sharp: (Inc. GX’s) (virtually all models covered)
- Siemens: (virtually all models covered)
- Sony: (virtually all models covered)
You can do the upgrade at home/work with a USB cable in 20 minutes
all you require is a 'USB to mini-USB' cable to connect your V3 Handset to the PC
this cable is normally provided with your phone.
Read More
Add your Comment
1 comments
400 Virus Source Codes - My Best Virus Code Collection
DOWNLOAD FROM HERE
400 Virus Source Codes
- Avispa.dr
- Dark Avenger
- AVA.550
- Univ/a
- Auspar.377
- Auspar.338
- OC/oops
- Middle
- Auspar.635
Read More
Add your Comment
0
comments
Password Guessing
Password guessing attacks can be carried out manually or via automated tools.
Password guessing can be performed against all types of Web Authentication
The common passwords used are:
root, administrator, admin, operator, demo, test, webmaster, backup, guest, trial, member, private, beta, [company_name] or [known_username]
Passwords are the principal means of authenticating users on the Web today. It is imperative that any Web site guard the passwords of its users carefully. This is especially important since users, when faced with many Web sites requiring passwords; tend to reuse passwords across sites. Compromise of a password completely compromises a user.
| Attack Methods | Often Web sites advise users to choose memorable passwords such as birthdays, names of friends or family, or social security numbers. This is extremely poor advice, as such passwords are easily guessed by an attacker who knows the user. The most common way an attacker will try to obtain a password is through the dictionary attack'. In a dictionary attack, the attacker takes a dictionary of words and names, and tries each one to see if it is the require password. This can be |
Read More
Add your Comment
1 comments
Web Based Password Cracking Techniques
Passport authentication messages are passed in the form of electronic "tickets" that are used to inform the site that the user has signed in successfully. A ticket is a small amount of data that indicates the time the sign in occurred, when the user last manually signed in, and other information that is useful to the authentication process. Within the Passport system, these tickets take the form of cookies.
To obtain a ticket, a user with a Passport account signs in to the site or tries to access a protected Web page within the merchant site (e.g., a page that requires user authentication before allowing access). This redirects the user to a special page on Passport.com. This page takes information that the merchant site has appended to the URL and processes it. This allows the Passport service to know which merchant site has referred the user, and which merchant site to return the user to.
Once the information has been processed, Passport redirects the user to a page on Passport.net.
Once the information has been processed, Passport redirects the user to a page on Passport.net.
Once the user enters their credentials, they are sent back to the Passport.com domain. Once there and verified, Passport writes a cookie on the user's browser that stores information about this sign in. This is called a "ticket-granting-cookie" and it is used in subsequent sign in attempts. Then Passport redirects them back to your site.
When the user arrives back at the merchant site, they bring two encrypted packets of information attached to the query string. Software called the Passport Manager which is installed on the merchant's authenticating servers reads those packets and writes them as encrypted cookies in the merchant site domain.
The first cookie contains the authentication ticket information. The second contains any profile information that the user has chosen to share, and any operational information and unique identifiers that need to be passed. These packets are encrypted with a unique secret key that is shared between Passport and the merchant site. This helps to ensure that only the merchant can decode these messages.
The merchant site then takes this information and uses it to issue his cookies. Since these cookies are issued from the merchant domain, the merchant will have access to them. The merchant can use the Passport User ID to look a user up in the merchant database and perform authorization tasks.
When the user navigates to another Passport participating site, the new site has several choices to make about how they will authenticate this user. When the user clicks the sign in button, they are directed to the Passport service exactly as they were at their first sign in. The difference is that this time there is a ticket-granting-cookie saved on the browser that Passport can read.
Since the ticket contains the time that it was issued, it allows the referring site to decide how "fresh" the cookie needs to be in order for the site to accept it. If the ticket meets the rules the referring site has chosen, the user is redirected back to the referring site along with the encrypted ticket and profile cookies. If the ticket is too old, the user is prompted to re-enter their credentials.
| Note | However, passport has been plagued with security issues - right from reuse of authentication cache to privacy flouting activities. Apart from this exploits that plague Microsoft based web systems such as Unicode exploits, cross site scripting and cookie stealing cast more than a shadow of doubt on this means of authentication. |
A few links exploring these issues are given below:
It is highly customizable authentication mechanism that uses a form composed of HTML with
After the data input via HTTP or SSL, it is evaluated by some server-side logic and if the credentials are valid, then a cookie is given to the client to be reused on subsequent visits.
Forms based authentication technique is the popular authentication technique on the internet.
Conventionally, web applications had users authenticate themselves through a Web form. The user's credentials as captured by this form are submitted to the business logic which determines the authorization level. If the user is authenticated, the application generates a cookie or session variable. This cookie contains anything from a valid session identification access token to customized personalization values. The time period for which the cookie is valid or the contents stored in it are subject to security risks.
Forms Authentication is a system in which unauthenticated requests are redirected to a web form where the unauthenticated users are required to provide their credentials. In the context of ASP.NET, it extends similar logic into its architecture as an authentication facility, Forms Authentication. Forms Authentication is one of three authentication providers. Windows Authentication and Passport Authentication make up the other two providers.
Reverting back to the web based authentication method, on being properly verified by the application, based on the credentials input by the user, an authorization ticket is issued by the Web application in the form of a cookie. In essence, Forms Authentication is a means for wrapping the web application around the login user interface and verification processes.
| Note | Forms Authentication Flow
|
-
-
WinSSLMiM is an HTTPS Man in the Middle attacking tool. It includes FakeCert, a tool to make fake certificates. -
It can be used to exploit the Certificate Chain vulnerability in Internet Explorer. The tool works under Windows 9x/2000. -
Usage:-
FakeCert: fc -h -
WinSSLMiM: wsm -h
-
We have seen how digital certificates are used for authentication purposes. Typically, the administrator of a web site opts to provide secure communication through the SSL. To enable this, the administrator generates a certificate and gets it signed by a Certification Authority. The generated certificate will list the URL of the secure web site in the Common Name (CN) field of the Distinguished Name section. The CA verifies that the administrator legitimately owns the URL in the CN field, signs the certificate, and gives it back.
[CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject: www.website.com]
| Note | When a web browser receives the certificate, it should verify that the CN field matches the domain it just connected to, and that it is signed by a known CA certificate. No man in the middle attack is possible because it should not be possible to substitute a certificate with a valid CN and a valid signature. However, it is possible that the signing authority has been delegated to more localized authorities. In this case, the administrator of www.website.com will get a chain of certificates from the localized authority: |
| Attack Methods | However, as far as IE is concerned, anyone with a valid CA-signed certificate for any domain can generate a valid CA-signed certificate for any other domain. If an attacker wants to, he can generate a valid certificate and request a signature from VeriSign: [CERT - Issuer: VeriSign / Subject: VeriSign] -> [CERT - Issuer: VeriSign / Subject: www.attacker.com] |
Then he can generate a certificate for any domain he wants to, and sign it using his CA-signed certificate: [CERT - Issuer: VeriSign / Subject: VeriSign]
-> [CERT - Issuer: VeriSign / Subject: www.attacker.com] -> [CERT - Issuer: www.attacker.com / Subject: www.amazon.com]
Since IE does not check the Basic Constraints on the www.attacker.com certificate, it accepts this certificate chain as valid for www.amazon.com. This means that anyone with any CA-signed certificate (and the corresponding private key) can spoof anyone else. Any of the standard connection hijacking techniques can be combined with this vulnerability to produce a successful man in the middle attack.
| Tools | WinSSLMiM is an HTTPS Man in the Middle attacking tool. It includes FakeCert, a tool to make fake certificates. It can be used to exploit the Certificate Chain vulnerability in Internet Explorer. The tool works under Windows 9x/2000. ........................................................................................................................... .................................................. ........................................................................................................................... .................................................. ........................................................................................................................... .................................................. |
Read More
Add your Comment
0
comments
What is cookie?
Persistent vs. Non-Persistent
Persistent cookies are stored in a text file (cookies.txt under Netscape and multiple *.txt files for Internet Explorer) on the client and are valid for as long as the expiry date is set for (see below). Non-Persistent cookies are stored in RAM on the client and are destroyed when the browser is closed or the cookie is explicitly killed by a log-off script.
Secure vs. Non-Secure
Secure cookies can only be sent over HTTPS (SSL). Non-Secure cookies can be sent over HTTPS or regular HTTP. The title of secure is somewhat misleading. It only provides transport security. Any data sent to the client should be considered under the total control of the end user, regardless of the transport mechanism in use.
Read More
Add your Comment
1 comments
Authentication And Session Management
Brute/Reverse Force
Session Hijacking
Session Replay
Session Forgoing
Page Sequencing
| Attack Methods | Brute Force Brute Forcing involves performing an exhaustive key search of a web application authentication token's key space in order to find a legitimate token that can be used to gain access. |
According to rfc2617, the Basic Access Authentication scheme of HTTP is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL), as the user name and password are passed over the network as cleartext. To receive authorization, the client sends the userid and password, separated by a single colon (":") character, within a base64 encoded string in the credentials.
user-pass | = | userid ":" password |
userid | = | * |
password | = | *TEXT |
For instance, if the user agent wishes to send the userid "Winnie" and password "the pooh", it would use the following header field:
Authorization: Basic bjplc2vcGZQQWxRpVuIHhZGNFt==
Therefore, it is relatively easy to brute force a protected page if an attacker uses decent dictionary lists. For the page http://www.victim.com/private/index.html, an attacker can generate base 64 encoded strings with commonly used usernames and a password, generate HTTP requests, and look for a non-404 response:
| Attack Methods | Session Replay If a user's authentication tokens are captured or intercepted by an attacker, the session can be replayed by the attacker, making the concerned web application vulnerable to a replay attack. In a replay attack, an attacker openly uses the captured or intercepted authentication tokens such as a cookie to create or obtain service from the victim's account; thereby bypassing normal user authentication methods. |
A simple example is sniffing a URL with a session ID string and pasting it back into the attacker's web browser. The legitimate user may not necessarily need to be logged into the application at the time of the replay attack. While it is generally that username/password pairs are indeed authentication data and therefore sensitive, it is not generally understood that these generated authentication tokens are also just as sensitive. Many users who may have extremely hard-to-guess passwords are careless with the protection of cookies and session information that can be just as easily used to access their accounts in a replay attack. This is often considered forging "entity authentication" since most applications check the tokens stored in the browser or HTTP stream, and do not require user authentication after each web request.
By simply sniffing the HTTP request of an active session or capturing a desktop user's cookie files, a replay attack can be very easily performed. Exploitation can take the following general forms:
-
Visiting a pre-existing dynamically created URL that is assigned to a specific user's account which has been sniffed or captured from a proxy server log -
Visiting a specific URL with a preloaded authentication token (cookie, HTTP header value, etc.) captured from a legitimate user -
A combination of 1 and 2.
Session tokens that do not expire on the HTTP server can allow an attacker unlimited time to guess or brute force a valid authenticated session token. An example is the "Remember Me" option on many retail websites. If a user's cookie file is captured or brute-forced, then an attacker can use these static-session tokens to gain access to that user's web accounts. Additionally, session tokens can be potentially logged and cached in proxy servers that, if broken into by an attacker, may contain similar sorts of information in logs that can be exploited if the particular session has not been expired on the HTTP server. To prevent Session Hijacking and Brute Force attacks from occurring to an active session, the HTTP server can seamlessly expire and regenerate tokens to give an attacker a smaller window of time for replay exploitation of each legitimate token. Token expiration can be performed based on number of requests or time.
| Attack Methods | Session Forging/Brute-Forcing Detection and/or Lockout Many websites have prohibitions against unrestrained password guessing (e.g., it can temporarily lock the account or stop listening to the IP address). With regard to session token brute-force attacks, an attacker can probably try hundreds or thousands of session tokens embedded in a legitimate URL or cookie for example without a single complaint from the HTTP server. Many intrusion-detection systems do look for this type of attack; penetration tests also often overlook this weakness in web e-commerce systems. Designers can use "booby trapped" session tokens that never actually get assigned but will detect if an attacker is trying to brute force a range of tokens. Anomaly/misuse detection hooks can also be built in to detect if an authenticated user tries to manipulate their token to gain elevated privileges. |
| Attack Methods | Session Re-Authentication Critical user actions such as money transfer or significant purchase decisions should require the user to re-authenticate or be reissued another session token immediately prior to significant actions. Developers can also somewhat segment data and user actions to the extent where reauthentication is required upon crossing certain "boundaries" to prevent some types of cross-site scripting attacks that exploit user accounts. |
| Attack Methods | Session Token Transmission If a session token is captured in transit through network interception, a web application account is then prone to a replay or hijacking attack. Typical web encryption technologies include but are not limited to Secure Sockets Layer (SSLv2/v3) and Transport Layer Security (TLS v1) protocols in order to safeguard the state mechanism token. |
| Attack Methods | Session Tokens on Logout With the popularity of Internet Kiosks and shared computing environments on the rise, session tokens take on a new risk. A browser only destroys session cookies when the browser thread is torn down. Most Internet kiosks maintain the same browser thread. It is recommended to overwrite session cookies when the user logs out of the application. |
| Attack Methods | Page Sequencing Page sequencing is the term given to the vulnerability that arises as a result of poor session management, thereby allowing the user to take an out of turn action and bypass the defined sequence of web pages. This can be something like moving ahead to a later stage of a financial transaction. This arises due to faulty session/application state management. |
-
User is logged on to a web application and the session is currently active. An attacker knows of a XSS hole that affects that application. -
The user receives a malicious XSS link via an e-mail or comes across it on a web page. In some cases an attacker can even insert it into web content (e.g. guest book, banner, etc,) and make it load automatically without requiring user intervention.
| Attack Methods | It is a fact that most web sites address security using SSL for authenticating their login sessions. Let us see how this process takes place. When the client connects to a web site two events take place to ensure security. |
-
The web site must prove that it is the web site it claims to be.
The web site authenticates itself by the SSL certificate issued to the domain in question by a trusted third party. Depending on the extent the user trusts the certificate issuer; s/he can be assured that the web site is what it claims to be.
Once the web site is authenticated by the user, he can choose to establish a secure data connection via the public key mechanism of SSL so that all the data that is transmitted between them is encrypted.
-
The user must authenticate self to the web site
The user provides his username/password into a form and this data is transmitted in an encrypted fashion to the web site for authentication. If the client is authenticated, a session cookie is generated with appropriate timeout and validation information. This is sent back to the user as a "secure cookie" - i.e. one that is only passed back and forth over SSL.
This can be considered as passing a shared secret back and forth, which is encrypted and is not the actual password and does timeout. If the website does not use cookies, it can opt for session codes that are embedded in the site URLs so that they are never stored in the hard disk of the client computer. Some web sites do require their users to obtain client SSL certificates so that the web site can authenticate the clients via these certificates and thus not need this whole username/password scheme.
Cookies were originally introduced by Netscape and are now specified in RFC 2965 (which supersedes RFC 2109), with RFC 2964 and BCP44 offering guidance on best practice. Cookies were never designed to store usernames and passwords or any sensitive information. There are two categories of cookies, secure or non-secure and persistent or non-persistent, giving four individual cookies types.
-
Persistent and Secure -
Persistent and Non-Secure -
Non-Persistent and Secure -
Non-Persistent and Non-Secure
..................................................................................................................................................................... ..................................................................................................................................................................................................... .................................................................................................................................................................................................. .............................
Read More
Add your Comment
0
comments
What is Cross Side Scripting (XSS)?
A Web application vulnerable to XSS allows a user to inadvertently send malicious data to self through that application.
Attackers often perform XSS exploitation by crafting malicious URLs and tricking users into clicking on them.
These links cause client side scripting languages )VBScript, JavaScript etc,) of the attacker s choice to execute on the victim's browser.
XSS vulnerabilities are caused by a failure in the web application to properly validate user input.
The simplest description of cross-site scripting can be put as the attack that occurs when a user enters malicious data in a Web site. It can be as simple as posting a message that contains malicious code to a newsgroup. When another person views this message, the browser will interpret the code and execute it, often giving the attacker control of the system. Malicious scripts can also be executed automatically based on certain events, such as when a picture loads. Unlike most security vulnerabilities, CSS doesn't apply to any single vendor's products - instead, it can affect any software that runs on a web server |
CSS takes place as a result of the failure of the web based application to validate user supplied input, before returning it to the client system. "Cross-Site" refers to the security restrictions that the client browser usually places on data (i.e. cookies, dynamic content attributes, etc.) associated with a web site. By causing the victim's browser to execute malicious code with the same permissions as the domain of the web application, an attacker can bypass the traditional document object model (DOM) security restrictions. The document object model is accessible application interface that allows client-side languages to dynamically access and modify the content, structure and style of a web page.
Cross-Site Scripting (CSS) attacks require the execution of Client-Side Languages (JavaScript, Java, VBScript, ActiveX, Flash, etc.) within a user's web environment. Cross Site Scripting can result in an attacker stealing cookies, hijacking sessions, changing of web application account settings etc. The most common web components that are vulnerable to CSS attacks include CGI scripts, search engines, interactive bulletin boards, and custom error pages with poorly written input validation routines. Moreover, a victim does not necessarily have to click on a link to make the attack possible.
-
As a web application user, there are a few ways to protect yourselves from XSS attacks. -
The first and the most effective solution is to disable all scripting language support in your browser and email reader. -
If this is not a feasible option for business reasons, another recommendation is to use reasonable caution while clicking links in anonymous e-mails and dubious web pages. -
Proxy servers can help filter out malicious scripting in HTML.Preventing cross-site scripting is a challenging task especially for large distributed web applications. If the application accepts only expected input, then the XSS can be significantly reduced.Web servers should set the character set, and then make sure that the data they insert is free from byte sequences that are special in the specified encoding. This can typically be done by settings in the application server or web server. The server should define the character set in each html page as below.Web pages with unspecified character-encoding work mostly because most character sets assign the same characters to byte values below 128. Some 16-bit character-encoding schemes have additional multi-byte representations for special characters such as "<. These should be checked.
Read More
Add your Comment
0
comments
Input Manipulation : Web Application Vulnerabilities
URL Manipulation CGI Parameter Tampering
HTTP Client-Header Injection
Filter/Intrusion Detection Evasion
Protocol/Method Manipulation
Overflows
In the context of a web based attack (or web server attack), the attacker will first try to probe and manipulate the input fields to gain access into the web server. They can be broadly categorized as given below. |
URL Manipulation CGI Parameter Tampering: This is perhaps the easiest of the lot. By inserting unacceptable or unexpected input in the url through the browser, the attacker tries to gauge whether the server is protected against common vulnerabilities.
HTTP Client-Header Injection: The next accessible point is the HTTP header. Using HTTP tags such as referrer, the attacker can manipulate the client side to suit his needs.
Filter/Intrusion Detection Evasion: The best part of attacking a web server is that the attacker can use the default port of entry - namely port 80 - to gain access into the network. As this is a standard port open for business needs, it is easy to evade intrusion detection systems or firewalls.
Protocol/Method Manipulation: Manipulating the particular protocol or the method used in the function, the attacker can hack into a web server.
Overflows: Some web server vulnerabilities take advantage of buffer overflows. The advantage is that by using buffer overflow techniques, the attacker can also make the server execute a code of his choice, making it easier for him to exploit the server further
Read More
Add your Comment
0
comments
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.
-
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.
-
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.
-
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.
-
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.
-
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.
Read More
Add your Comment
0
comments
Top20 Scan Method : Hacking Web Servers
This method will scan the web server for the top 20 vulnerabilities list published by SANS/FBI (www.sans.org)
-
WebInspect is an impressive Web server and application-level vulnerability scanner which scans over 1500 known attacks. -
It checks site contents and analyzes for rudimentary application-issues like smart guesswork checks, password guessing, parameter passing, and hidden parameter checks. -
It can analyze a basic Webserver in 4 minutes cataloging over 1500 HTML pages
WebInspect enables application and web services developers to automate the discovery of security vulnerabilities as they build applications, access detailed steps for remediation of those vulnerabilities and deliver secure code for final quality assurance testing.
With WebInspect, the developer can find and correct vulnerabilities at their source, before attackers can exploit them. WebInspect provides the technology necessary to identify vulnerabilities at the next level, the Web application.
-
Security scanner is designed to identify known and unknown vulnerabilities, suggest fixes to identified vulnerabilities, and report possible security holes within a network's internet, intranet and extranet environments. -
Shadow Security Scanner includes vulnerability auditing modules for many systems and services.These include NetBIOS, HTTP, CGI and WinCGI, FTP, DNS, DoS vulnerabilities, POP3, SMTP,LDAP,TCP/IP, UDP, Registry, Services, Users and accounts, Password vulnerabilities, publishing extensions, MSSQL,IBM DB2, Oracle, MySQL, PostgressSQL, Interbase, MiniSQL and
These include NetBIOS, HTTP, CGI and WinCGI, FTP, DNS, DoS vulnerabilities, POP3, SMTP, LDAP, TCP/IP, UDP, Registry, Services, Users and accounts, Password vulnerabilities, publishing extensions, MSSQL, IBM DB2, Oracle, MySQL, PostgressSQL, Interbase, MiniSQL and more.
Running on its native Windows platform, SSS also scans servers built practically on any platform, successfully revealing vulnerabilities in Unix, Linux, FreeBSD, OpenBSD, Net BSD, Solaris and, of course, Windows 95/98/ME/NT/2000/XP/.NET. Because of its unique architecture, SSS is the able to detect faults with CISCO, HP, and other network equipment. It is also capable of tracking more than 2,000 audits per system.
The Rules and Settings Editor will be essential for the users willing only to scan the desired ports and services without wasting time and resources on scanning other services. Flexible tuning lets system administrators manage scanning depth and other options to make benefit of speed - optimized network scanning without any loss in scanning quality.
-
IISLockdown:-
IISLockdown restricts anonymous access to system utilities as well as the ability to write to Web content directories. -
It disables Web Distributed Authoring and Versioning (WebDAV). -
It installs the URLScan ISAPI filter.
-
-
URLScan:-
URLScan is a security tool that screens all incoming requests to the server by filtering the requests based on rules that are set by the administrator.
-
UrlScan is a security tool that screens all incoming requests to the server by filtering the requests based on rules that are set by the administrator. Filtering requests helps secure the server by ensuring that only valid requests are processed. UrlScan helps protect Web servers because most malicious attacks share a common characteristic they involve the use of a request that is unusual in some way. For instance, the request might be extremely long, request an unusual action, be encoded using an alternate character set, or include character sequences that are rarely seen in legitimate requests. By filtering unusual requests, UrlScan helps prevent such requests from reaching the server and potentially causing damage.
-
Web servers assume critical importance in the realm of Internet security. -
Vulnerabilities exist in different releases of popular web servers and respective vendors patch these often. -
The inherent security risks owing to compromised web servers have impact on the local area networks that host these web sites, even the normal users of web browsers. -
Looking through the long list of vulnerabilities that had been discovered and patched over the past few years provide an attacker ample scope to plan attacks to unpatched servers. -
Different tools/exploit codes aids an attacker perpetrate web server hacking. -
Countermeasures include scanning, for existing vulnerabilities and patching them immediately, anonymous access restriction, incoming traffic request screening and filtering.
Read More
Add your Comment
0
comments
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.
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.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.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:
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.
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.
Read More
Add your Comment
0
comments