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
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
HEAD / HTTP/1.0
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.
A member of the ‘NULL’ mailing-list today announced a ‘Persistent XSS’ vulnerability in the ‘subject’ parameter of RediffMail’s email application.
This Vulnerability was discovered and reported by w4rl0ck.d0wn and Rockey Killer of h4ck3r crew
Check out their PoC video at:
I know this is ‘old’ news, but I was a bit busy so could not post it here.
ZF05 has been released to stands where the ‘hackers hack the hackers‘ …hehe
Pretty interesting stuff. Make sure to read the hackers comments embedded in between the text – which by the way is pretty huge !!
Check it out at http://r00tsecurity.org/files/zf05.txt
Here’s a snippet of what to expect :-)
- Kevin Mitnick
- Dan Kaminsky
- Hacking in gitmo
- Binary Revolution
-….and many more
A new vulnerability has been discovered in Microsoft IIS 6.0 which allows an attacker to access protected(password) content in a website. The vulnerability arises because of the way IIS handles Unicode.
Microsoft has released a security advisory 971492 and it’s follow-up
According to the advisory the scale of vulnerable systems is reduced due to multiple factors
* An IIS server not running WebDAV is safe.
The Windows Server 2003 IIS (version 6) shipped with WebDAV disabled by default.
* An IIS server not using IIS permissions to restrict content to authenticated users is safe.
* An IIS server that does not grant filesystem access to the IUSR_[MachineName] account is safe.
* An IIS server that hosts web applications using only forms-based authentication is probably safe.
If your web server meets all of the following criteria, you will want to read on:
* IF an IIS 5, 5.1, or 6.0 webserver is running with WebDAV enabled;
* AND the IIS server is using IIS permissions to restrict a subfolder of content to authenticated users;
* AND file system access is granted for the restricted content to the IUSR_[MachineName] account;
* AND a parent folder of the private subfolder allows anonymous access;
THEN an anonymous remote user may be able to leverage this vulnerability to access files that normally would only be served to authenticated webserver users.
This vulnerability is primarily an information disclosure threat.
Thierry Zoller has made an excellent post explaining the vulnerability with graphical representation. It’s a must-read.
He made a reference to the SANS article on the original Unicode vulnerability in IIS 4.0 and 5.0 which explains the Unicode issues in depth.
There are a few tools that can be used to search for WebDav enabled servers on the network (referenced from Zoller’s blog
* Specifically for this vulnerability: Metasploit added test script to the trunk (use svn update to get the latest exploits)
* Webdav network scanner here
* Nmap webdav scanner
Till Microsoft releases a patch to fix this vulnerability, it’s best to disable WebDAV on IIS servers (Sharepoint user beware)