Threat Level: green Handler on Duty: Russell Eubanks

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Blind Elephant: A New Web Application Fingerprinting Tool

Published: 2010-08-16
Last Updated: 2010-08-16 21:59:25 UTC
by Raul Siles (Version: 1)
0 comment(s)

During Black Hat USA 2010, Patrick Thomas presented a new web application fingerprinting tool called Blind Elephant (http://blindelephant.sourceforge.net). The tool uses the same techniques I've been using for a few years now, manually or through custom scripts, during web-app penetration tests to identify the available resources on the web application, and based on them, categorize its type and fingerprint its version. This methods apply particularly well to open-source web application and blogging frameworks, and CMS's, such as Drupal, Joomla, Wordpress, phpBB, phpMyAdmin, etc, as you can check the resources available on the source code for a specific version, and compare them with the resources of the target web-app.

Patrick took this idea seriously and created a Python-based tool. He has precomputed the hashes of the known files and automated the process. You can get more details from the original Black Hat presentation, or the updated version (v2). The tool is very useful from two perspectives: defensive and offensive.

On the one hand (offensive), to incorporate the tool to your pen-tests activities in order to fingerprint more accurately the target environment. On average it takes less than 6.5 seconds to fingerprint the web-app, with an average precision of three candidate versions (and the bandwidth compsumption is also very low).

On the other hand (defensive), to collect global details about the current state of the web portion of the Internet. The presentation provides results about the web application versions available out there, as well as the version distribution and real update status for the major players. The goal was to answer the following question: "What % of (active) sites on the net are running a well-known webapp?". I would personally add "...a well-known VULNERABLE webapp?". The results of this global analysis are pretty scary but match what I commonly see on pen-tests. Just to provide you the insights of the phpMyAdmin vulnerability mentioned on a recent ISC diary (from the tool author):

Scanned on June 18, the % of net-visible phpMyAdmin installations unpatched against PMASA-2009-3/CVE-2009-1151: 60.75%
(52.2% are running a vulnerable version in the 2.x branch, 8.6% are running a vulnerable version in the 3.x branch)

Please, use this tool and its results to create awareness and force people to patch web infrastructures and applications, and help them to improve the update process! I know this is easier said than done, but if you are still running a vulnerable web application more than one year after the vulnerability was announced, you are asking for trouble.

The project is looking for contributors, so its an opportunity to make a difference and help to make the Internet a more secure place.

----
Raul Siles
Founder and Senior Security Analyst with Taddong
www.taddong.com

0 comment(s)
We have reports of AVG reporting a trojan downloader on our main page and RSS feed: It is due to the code snippet we are showing in one of our diaries.

DDOS: State of the Art

Published: 2010-08-16
Last Updated: 2010-08-16 06:32:16 UTC
by Raul Siles (Version: 1)
0 comment(s)

During this year we wrote only a few times about DDOS (Distributed Denial of Service) attacks, referencing a report from 2009, and a couple of attacks in January and August.

On March 2010, Team Cymru released a 4-part series of videos (Episodes 42-45) and a related paper covering the basics of DDoS, a good resource to point novice people to.

However, although DDOS is still a prevalent threat, the research, improvements and information sharing in this area seem to have decrease during this year, even with all the new and growing botnets out there, most of them implementing DOS or DDOS capabilities. Obviously, some attack reports become public, while some other DDOS incidents never see the light.

We would be interested on hearing you, and know about your experiences: what are the latest improvements on both the offensive and defensive sides, what are the solutions security vendors and service providers are offering you worldwide, what are the latest attack techniques, what are the most effective tools to detect and mitigate the attacks, what is the current underground offering (DaaS, DDOS-as-a-Service)? (...the list could go on and on)

You can share the details with us through the contact page (include "DDOS" in the subject) or the comments section below.

----
Raul Siles
Founder and Senior Security Analyst with Taddong
www.taddong.com

0 comment(s)

The Seven Deadly Sins of Security Vulnerability Reporting

Published: 2010-08-16
Last Updated: 2010-08-16 05:48:35 UTC
by Raul Siles (Version: 1)
0 comment(s)

The Seven Deadly Sins of Security Vulnerability Reporting pretends to become an easy to follow list, not very technical but security relevant (so that anyone can point people to it), for any organization, commercial company, and open-source project in order to improve the resources and procedures they put in place to be notified (by external security researchers or third parties) and act on security vulnerabilities on their official web site(s), services, or any of their products

This is a scenario we (Internet Storm Center handlers) frequently find ourselves at, when notifying findings during our daily activities, or acting as a vulnerability reporting proxy for other researchers.

Below you can find the summarized list, while the additional reasoning and comments for every item are available on the original post I made on Taddong's Security Blog.

  1. Communication channels: Do you have clear and simple communication channels to be notified about security vulnerabilities in your environment and products?
  2. Confidentiality: Do you have secure communication channels to receive sensitive and/or confidential notifications?
  3. Availability: Are the notifications channels available 24x7, specially, when they are required ;)?
  4. ACK (Acknowledgment): How can the researcher know you have received the notification?
  5. Verification: How do you know if the notification is related with a new vulnerability (0-day) or is a well known issue?
  6. Interactivity: Once you confirm it is a new vulnerability, design a plan to fix it, and keep all parties involved informed about how the plan progresses.
  7. "Researchability": All the previous sins provided guidance to the organization that has the responsibility to fix the vulnerability, but... what about the security researcher that found it?

    Bonus: Once a fix for the vulnerability is available and it is finally announced, provide credit where appropriate.

I strongly recommend you to go through the list during this Summer, identify what sins you can redeem in your environment, and implement the changes on September. Let's get ready for the new season!

Please, share with us any finding or remarkable situation you might have found when reporting vulnerabilities (or when someone reported vulnerabilities to you), through the contact page or the comments section below.

----
Raul Siles
Founder and Senior Security Analyst with Taddong
www.taddong.com

0 comment(s)
Diary Archives