Hacking Guest Wifi Networks

(Cross-posting from my organization’s blog – http://niiconsulting.com/checkmate/2014/03/insecure-implementation-guest-wireless-networks/)

Most large organizations provide wireless facilities for their guest, which may include vendors, consultants, business associates, employees from other regions etc.

Certain points should be considered while implementing a guest wireless network.

  1. Encryption in use
  2. Captive Portals or Guest Authentication
  3. Network Segregation

Finding the SSID of a Hidden wireless network

To simplify the connectivity for guest devices some organizations configure their networks without encryption i.e. ‘OPEN’. To prevent un-authorized entities from connecting to their networks most of these networks are configured as HIDDEN. As is well known, this configuration does not really provide any security. It is simply a method of obfuscation (Non-Broadcast Wireless SSIDs Why hidden wireless networks are a bad idea).

To identify the SSID of a hidden network you would need:

  1. Wireless adapter which supports packet injection (http://www.aircrack-ng.org/doku.php?id=compatible_cards)
  2. Aircrack-ng wireless suite (http://www.aircrack-ng.org/)

I will be using an Alfa AWUS036H adapter. This card is well supported by Aircrack-ng.

Continue reading

How-to: Modify Apache-Coyote/1.1 Banner

If you’ve ever done a penetration test or got one done, you may have come across the following scenario:

HTTP Service running on port 8080, revealing the version information of the product in it banner.
The banner  revealed is Apache-Coyote/1.1.
This is the banner of the Apache Tomcat Web Server which runs on port 8080 by default.

Apache-Coyote/1.1 Version Disclosure

Now, as per good security practice, the banner should be removed or modified, so that it no longer reveals the version number.
This can be achieved by editing your server.xml configuration file found at the below location:


Original server.xml reveals version information

Modified server.xml

You may need to restart your server for the changes to reflect.
Once the Tomcat server is up, test the server to see if it shows the custom header.


> telnet localhost 8080

Web Server with Custom HTTP Banner


Hope this helps others who are looking for a solution to the banner version disclosure

Check out OWASP’s article on Securing Tomcat for more details.


Vulnerable Web Applications for learning

Update: 08/08/2010: Created a tabled output of the listing. Platforms for most applications added. More applications added to list thanks to comments.

Just a quick post. Someone on the ‘NULL’ mailing asked for WebGoat alternatives to learning Web Application penetration testing. The reponse was amazing, with many applications being listed as vulnerable web applications designed for learning web-app pentest. I have collected  all vulnerable web applications and listed them below for reference:

Continue reading

Windows (Trusted) Authentication Vs SQL (Mixed-Mode) Authentication

Just a quick post for my future reference on the differences between Trusted authentication and Mixed-mode Authentication used by SQL Server

Windows Authentication

  • When a user connects through a Windows user account, SQL Server validates the account name and password using the Windows principal token in the operating system. This means that the user identity is confirmed by Windows.
  • SQL Server does not ask for the password, and does not perform the identity validation.
  • Windows Authentication is the default authentication mode, and is much more secure than SQL Server Authentication.
  • Windows Authentication
    • uses Kerberos security protocol,
    • provides password policy enforcement with regard to complexity validation for strong passwords,
    • provides support for account lockout,
    • and supports password expiration.
  • A connection made using Windows Authentication is sometimes called a trusted connection, because SQL Server trusts the credentials provided by Windows.

SQL Authentication

  • When using SQL Server Authentication, logins are created in SQL Server that are not based on Windows user accounts.
  • Both the user name and the password are created by using SQL Server and stored in SQL Server.
  • Users connecting using SQL Server Authentication must provide their credentials (login and password) every time that they connect.
  • When using SQL Server Authentication, you must set strong passwords for all SQL Server accounts.
  • Three optional password policies are available for SQL Server logins.
    • User must change password at next login
    • Enforce password expiration
    • Enforce password policy
  • SQL Server Authentication cannot use Kerberos security protocol.
  • Supports environments with mixed operating systems, where all users are not authenticated by a Windows domain.

Source: http://msdn.microsoft.com/en-us/library/ms144284.aspx

SQL Injection in Stored Procedures

My colleague Dhiraj Ranka wrote about a very interesting topic of SQL Injections.
Though Stored Procedures provide certain protection from SQL injections, an improper implementation voids all such protections.

Dhiraj has demonstrated an SQL injection in a Stored Procedure which has not been constructed properly.

The crux of the issue lies in using the system Stored Procedure sp_executesql which takes a string as parameter and executes it. The string is generally a SQL query. So the entire premise of using stored procedures to prevent query injections fails as the input is directly inserted into the SQL query.

Read the detailed example at http://dhirajranka.wordpress.com/2009/08/25/sql-injection-stored-procedure/

Another interesting account of improper usage of Stored Procedure is demonstrated at


Astalavista 0wned !! – The Story

Update 1: 15th July, 2009 – Anti-Sec has struck again. It seems they’ve launched a campaign against Full-Disclosure ! Imageshack.us was the latest victim. This time too they have kept the logs, which shows a vulnerability in lighthttpd

Astalavista.com, the ‘Hacking Security Community’ was recently 0wned, literally, by an underground hacker group Anti-Sec. The interesting thing about this attack was that the hackers posted their entire ‘attack log’ online. Leaving out some crucial details (like the 0day which they used to initiate the attack) they demonstrated the inherent weakness of the human mind. Though the attack was personally motivated, it serves as a good learning ground for beginners in the security field…what and where mistakes may occur.

For reference purposes, I’ve added the entire attack log of the Astalavista.com attack here.

So what are the lessons learned from this real-world example

1) You’re never safe from 0-day exploits. Even though it seems that the guys had patched their systems, the anti-sec people were able to launch a script and exploit their ‘LightSpeed’ web server to obtain a shell.
The contents of the script have not been disclosed and it’s speculated that the issue was certainly with LightSpeed which is based on the Apache software.
Interestingly, the shell returned had the ‘apache’ user privileges which allowed the attackers to read almost any file on the system. Note that the user ‘apache’ is not given a default ‘shell’ (check /bin/false), but I believe the ‘g0tshell’ had a shell payload.

2) The owners at Astalavista ‘did’ have some sort of password complexity for much of the users. But the issue lies elsewhere. The attackers were able to obtain plain-text passwords to FTP servers and DBs via configuration files and backup scripts

3) Encrypt your passwords before storing it in the databases. As can be seen in the logs, the users of the database did not encrypt their passwords before storing their passwords there. This requires proper configuration at the database application end.

4) DON’T type passwords onto the command line. The attackers were able to obtain a password to a MySQL database by listing the .bash_history . This file contains all commands typed into the bash prompt after every session (the current session is stored in the RAM). So it becomes necessary to avoid typing passwords into the command prompt. Rather, the server should throw back a password request where the user should type his password. Else expect yourself to be owned by any Tom, Dick and Harry who can view the .bash_history file.

5) Following to the previous point, it is prudent to regularly ( maybe after each session) clear your .bash_history file. Check here for pointers.

6) Anything else ??….right now I’m just able to recollect these points from memory. I might update this later I anything new comes up.

Update 2: 22nd November, 2010: Remaining section of post removed

I hope it is understood that I do not condone such hacking activities. This post was just for educational purposes. As can be seen, we did learn a lot !!

Safe browsing 😉