Spamhaus's web servers came under a DDoS attack starting yesterday at
just after 21:00 GMT. The attack is being carried out by the same people
responsible for the BlueSecurity DDoS last year, using the
Storm malware.
The attack method was sufficiently different to previous DDoS attacks on
us that some of it got through our normal anti-DDoS defenses and halted
our web servers.
At 02:00 GMT we got the attack under control and our web servers are now
back up, www.spamhaus.org is running again as normal.
The attack is ongoing, but it's being absorbed by anti-DDoS defenses.
Also under attack by the same gang are SURBL and URIBL.
Storm is the 'nightmare' botnet, capable of taking out government
facilities and causing much mayhem on the internet. It has 3 functions;
sending spam, fast-flux web and dns hosting mainly for stock scams, and
DDoS. There is a hefty international effort underway by cyber-forensics
teams in a joint effort by law enforcement and private sector botnet and
malware analysts to trace the perpetrators.
--
Steve Linford
The Spamhaus Project
http://www.spamhaus.org
Labels: Attack Tools, Botnet, DoS, Spam
Web Application Auditing Over LunchMarch 22nd, 2007
By Dr. Johannes B. Ullrich
Version 1.0
Web applications are frequently the Achilles heel of a network. A Web application has to be accessible to all of your customers. Ports 80 and 443 have to be open to the world to provide ubiquitous access to the Web application. On the other hand, a full-featured Web application is connected to a corporation′s database storing customer, order, and pricing information. In short: A Web application is the shortest path for an attacker to take to reach the organization′s crown jewels. Securing Web applications is critical and not easy. This paper outlines some simple steps to audit the security of a Web application. Sadly, while this audit is simple and incomplete, a lot of applications will fail the test. A more comprehensive audit will include source code reviews and more advanced techniques to circumvent security measures.
NOTE: You will need WRITTEN permission from your company to perform this audit. Failure to obtain such permission may get you fired, prosecuted, or worse: your GIAC certifications may be revoked.
First StepsDon't forget the obvious. A quick portscan with nmap may reveal an unprotected VNC server or a database server with no password. Any penetration test should start with a quick portscan, likely followed by a vulnerability scan with a tool like Nessus. The use of a more Web-specific scanner (like Nikto) will save you a lot of tedious work. Nikto, in particular, is good at scanning for common problems like default installations of vulnerable tools, outdated versions, and left-over backup and configuration files.
ToolsBefore we get started, let's talk about some tools. In order to perform your audit, you need appropriate tools to attack the application under test. You already have the most important tool for auditing Web applications: a browser. If you use Firefox, you will be able to use a number of free toolbars that will make it much easier to launch the attacks outlined below. We recommend the following plugins:
Web Developer toolbar (https://addons.mozilla.org/firefox/60/) A Swiss Army knife-like extension every Web developer should have installed. For our purposes, the important feature is the ability to modify forms on the fly to remove some of the restrictions imposed by forms. For example, you are able to enter strings beyond the designed length, or you are able to edit locked fields.
Hackbar (https://addons.mozilla.org/firefox/3899/) Nice tool to decode Base64 and URL Encoding. It is also helpful in obfuscating SQL injection attacks.
SwitchProxy Tool (https://addons.mozilla.org/firefox/125/) If you decide to use a proxy server like WebScarab, Switch Proxy allows you to quickly switch proxies.
Add N Edit Cookies (https://addons.mozilla.org/firefox/573/) The Add N Edit Cookies cookie editor will allow you to edit cookies on the fly. This tool gives you one less reason to require a full proxy server to intercept requests.
Tamper Data (https://addons.mozilla.org/firefox/966/) This extension, much like a proxy server, will allow you to intercept requests and responses. Either may be manipulated at will.
These toolbars allow you to do most of what is required to quickly test a Web application. However, for some of the more advanced techniques, a proxy server can be helpful. Probably the most full-featured free proxy server for auditing purposes is
WebScarab (http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project). The Open Web Application Security Project (OWASP) Web site is also a good resource to learn more about Web application security.
PreparationBefore you start, configure your browser to show hidden fields and comments and to ignore form limits. This will make some of the tests discussed later a bit easier to complete. Here is how to adjust the Web Developer toolbar:
In the Options menu, select Persist Features. This will make your selections stick, so you don't need to adjust them for each new page.
Now move to the Miscellaneous menu and select Show Hidden Elements as well as Show Comments.
In Forms, select Make Form Fields Writeable and Remove Maximum Length. Later, you may want to use the Convert POST to GET function to make it easier to manipulate form content.
As a quick test, start browsing the site you are testing and become familiar with it. You will see yellow exclamation marks within the web page displayed by Firefox whenever there is a comment. The current version of the Web Developer toolbar appears to have a bug in that the hidden fields are not shown all the time. It may be easier to use WebScarab if you find a lot of hidden fields, because WebScarab will make them editable.
In a worst case scenario, you will find things like passwords or account names in comments listed in the Web Developer toolbar. At this point, your quick audit would likely be complete. There is no need to go any further if the goal is just to show that a side is vulnerable.
The AuditWith browser and toolbars ready and armed, we are all set to dive into the actual audit. The steps below are listed in the order in which they are most likely to deliver results, staying with our theme to find problems quickly.
robots.txt: A vulnerability roadmap. The robots.txt file is often misunderstood by Web developers. The file will not protect or hide content. It is only used by well-behaved search engines to avoid indexing content that should not be indexed. A good robots.txt file includes content like image directories or locations that are generated dynamically and do not work if a search engine accesses the page. A bad robots.txt file, on the other hand, will list admin pages, Web logs, and similar locations. Access all the locations listed in robots.txt and see what you find. If, as part of this experiment, you hit a page with Web logs, browse the Web logs for any administrative pages. If they are not obviously named /admin, look for pages hit by only very few hosts. Your quest to prove that the web application is vulnerable may already be over if you find a non-password-protected admin page. For each password-protected admin page, try a few obvious username/password combinations. But don′t spend too much time on it. After all, we only have 1 hour to break the site.
XSS: trial and error. Cross site scripting (XSS) is probably the most common vulnerability. Not all XSS issues are easily exploitable. However, the presence of these errors demonstrates lack of attention to input validation and output sanitation. The most likely place to find XSS is in the search function. Enter a "e;>"e; as a search string and see what you get. In particular, watch for pieces of HTML code that may all of the sudden be visible or for skewed formatting in forms. As a next step, enter ">. Even if you don't see the popup message, try to find the string in the result. See how the application dealt with the quote. As a note, many applications will escape single quotes (′) but not double quotes ("). If you try to inject JavaScript, you may need to use double quotes only. Again, for this 1 hour exercise, we are only trying to find XSS problems. Exploiting them may take a bit more time. More dangerous XSS issues arise if content is stored in a database and not escaped properly if returned. The most likely location for this XSS vulnerability is any mailing or shipping address. Try to set up an account with the Web site, and use > or similar strings as street or city name. These issues are almost always exploitable to retrieve administrator cookies because they retrieve addresses for order fulfillment or customer service.
SQL Injection: trial and error. The procedure to find SQL injection is similar to what we did for XSS. Start by entering a single quote in various form fields. As an indication of SQL injection is going to be possible, you may see a database error returned. Once you have the database error, it should tell you more about the nature of the problem. Some Web sites do a decent job of hiding the error messages. In this case, SQL injection is a bit more tricky. Try to guess a valid, but bad, SQL query. For example if you get an error for page.html?id=1′ , try page.html?id=1%20or%201 and page.html?id=1′%20or′1′=′1 or page.html?id=1-- to see if you still get the error page. This can easily be the most time-consuming part of the audit. If you suspect SQL injection issues, try to use a tool like Paros, which can assist you in finding SQL injection problems. In addition to the obvious quotes, try to use characters like double-dash (--), semi-colon (;) or comma (,). Blind SQL injection, which is frequently necessary if no error messages are displayed, is a more advanced topic and is beyond the scope of this paper.
Cookies and Hidden Fields. Cookies and hidden form fields are just another form of user-provided input. However, a lot of Web developers don't see it that way and treat cookies and hidden fields as trusted data. So, if you are still looking for vulnerabilities, try to inject some single quotes and XSS characters and see what you get. The Add N Edit Cookies toolbar is all you need for this. The Web Developer toolbar will allow you to edit hidden fields that you find.
Sessions. With sessions, you will find developers who are using a standard toolkit, in which case the sessions are likely reasonably secure, or you will find developers using homemade toolkits that are frequently flawed. Take a look at the session ID. Does it look like a long random string? Start playing with it. Remove and add characters. Again, try to add a single quote or XSS. Is the text cleaned up? If your session ID is numeric: Try to replace the session ID with the next number. Also, try and increment the last two numbers by 1 each (in case the last digit is a checksum). Are you able to get someone else's session? At the very least, your session ID should change after you log in. In the best case scenario, the session ID should change on each page view. Webscarab can help with session ID analysis if you need to dive in deeper. Webscarab is a proxy server. It can be configured to intercept all data passed to the server or to the browser. Before it passes the data to the server or browser, the user can edit the data at will. Webscarab offers a large number of additional features to analyze the content passing between browser and server. The session ID analysis is one of these features. Session ID analysis will graph session Ids collected from the website to make it easy to spot patterns.
Google Hacking. Take a look at Google and check what it knows about the site. You can limit Google's focus by adding a?site:example.comato the search. Strings to search for include: "sql", "error", "password", "cvv2".
Spidering.Run wget -m http://www.example.com to retrieve a mirror of the site. This will cause wget to create a directory called www.example.com. Use grep to find any errors or other odd contents like error messages or comments. This is essentially the same thing the Google search will do, but grep is more complete. Note that Google as well as wget obey robots.txt. At this point, you are likely a bit more familiar with the application you are testing. Google can help to find default locations for configuration files (e.g. global.asa) or administrative consoles for the particular Web application.
ConclusionThese tests will only find obvious problems and are less likely to find more complex issues. We totally neglect some common problems like response-splitting or secondary SQL injection issues, and we spent little time on actually exploiting these problems. See this 1 hour audit as a due diligence test that should be done periodically. It is also a great learning tool for Web developers. By involving them in such an audit, they will find out more about how easy it can be to exploit some of the problems the audit identifies. Have them actually perform the test or perform the test with them. If they are part of the audit team it will be much easier to explain what is going on and they won't see the test in a confrontational manner.
In order to do a more exhaustive test, it is highly advisable to use the source code for the Web application. Again, this is easy if you have cooperating Web developers. With source code, it is much easier to validate a problem and estimate its impact.
We did not say much about how to defend against each of these tests. However, the overall approach should not be to fix vulnerabilities one at a time as they are found, but to develop strategies and procedures that will prevent these vulnerabilities in the first place. It is imperative for a Web application to create a library of authentication, access control, session handling, and validation functions that are used consistently throughout the application.
Referenceshttp://www.owasp.org: Open Web Application Security Project.
http://www.cgisecurity.com/articles/xss-faq.shtml: The Cros Site Scriptin (XSS) FAQ
http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf": SQL Injection White Paper
http://www.robotstxt.org: The Web Robots Page
http://johnny.ihackstuff.com: The Google Hacking Database
Many thanks to the ISC handlers, in particular Jason Lam, for the discussions that led to this paper.
Labels: Attack Tools, http, News Article
ElcomSoft released an Enterprise version of its award-winning Advanced PDF Password Recovery software. This program makes it easy to remove both password encryption and usage restrictions from Adobe Acrobat PDF files. APDFPR Enterprise now comes with support of all Adobe Acrobat versions (up to 8.0), including those that use AES encryption, and super-fast guaranteed recovery of PDF files with 40-bit encryption using state-of-the-art "time-memory trade-off" technology.
With the increasing popularity of PDF formatted file, comes an increasing number of problems which occur when authors forget the passwords to their source documents. ElcomSoft has revised version 3.0 of all three editions of its Advanced PDF Password Recovery software (Enterprise, Professional, and Standard) to allow the seemingly impossible recovery of passwords for these documents. This software package handles both owner and user passwords used to protect PDF documents. The latest addition to ElcomSoft's family of password recovery software allows business managers to recover lost and destroyed passwords. It also helps in dealing with employees who, intentionally or unintentionally, are unable to edit and print password-protected PDF files.
APDFPR is also a state-of-the-art computer forensics tool that could be used by law enforcement, military and intelligence agencies to open secure documents. PDF documents protected with access restriction passwords can be decrypted instantly, allowing full access to the document. For documents with "user" passwords (that could not be opened without that password), the program blazes through brute-force password attempts at a rate of a few hundred thousand passwords per second!
The code has been effectively optimized for most CPUs such as Pentium II/III, Pentium 4, Intel Core/Core 2 (Duo) and Athlon. More sophisticated methods are available, such as applying all words from a dictionary. ElcomSoft's website has dictionaries for more than 20 different languages, from English to Swahili.
Even if the above methods fail because the password is too long and complex, the program runs a special key search attack which gives a 100% success rate on files with 40-bit encryption (used in all Adobe Acrobat 4 files, and most files from more recent versions). This may take some time to run, but is well worth the time if your document is very important. If you have a dual processor system, APDFPR takes advantage of it to double the performance of this software.
On modern systems with Intel Core Duo CPUs, the document can be recovered in maximum 3-4 days, regardless of the password length and complexity. And in APDFPR Enterprise, ElcomSoft has introduced a new "rainbow attack" subsystem -- it is shipped with a DVD that contains special pre-computed hash tables that will allow you to decrypt most (an estimated 99.6 percent) PDF files in just minutes instead of days, even on slow computers.
Advanced PDF Password Recovery Enterprise costs $999(US) for a single-user license and includes express delivery worldwide. Professional and Standard versions, with reduced feature sets, are available at affordable prices. The program runs under Windows 95/98/Me/NT4/2000/XP/2003/Vista.
Labels: Attack Tools, News Article