- *ZZ Penetration Report v3.0 -

[Aquina]

What's that you might ask!? Well... as you probably know I'm a bit in all that web server/portal/languages security stuff right now. Actually I'm a C and D programmer especially addicted to OS security. Previous depends on my orders as well as held study projects.

Back to the topic... It all began a few weeks ago when someone asked me to do a well crafted penetration test for a portals' webmaster. It's a business portal designed for C2B interaction. Other personal stuff doesn't matter right now. We get into details later...

My report started introducing with a promise everything I created was indeed my art/work and a notice on my organizations security and quality assurance guidelines. The article wasn't multilingual just because I had only 24 hours time to commence that task. Deadline will be 72 hours ahead I was told...


Unit 1 - WHOIS?

Straight forward I began with the first unit to figure out what kind of site I was asked to check up (shared host, domain with space, etc.), where it was hosted/located (ISP, domain owner, locations, contact persons, name servers) and everything about the ISP's networks structure as well as other specific details and things I possibly might require further for social engineering and stuff.

It wasn't hard to receive all that kind of information. With the help of the lovely "whois" UNIX command and the German domain name registration authority (DENIC) I was able to do it in no time! Besides I suggest everyone who's not yet familiar with these domain registration authorities to have a look at them first. This will help you getting a basic knowledge about how all this is organized. The main problem with all that whois stuff is that most people can't get enough out of it. ;-)


Unit 2 - Port Scan

First I have to admit that I was indeed using nmap for scanning because it's probably the most widespread scanner around there. Nmap provides all the basic functionality I expect to have with a scanner. Nevertheless there are some problems with -0 for example when it comes to guessing exotic operating systems. A good scanner also requires a basic knowledge abut protocols, networks and operating systems to avoid track-downs or other problems.

Today simply everyone can perform a port scan without even knowing much about the ISO/OSI model, lots of RFC's and other academic stuff. Nevertheless there are some rules to obey when it comes to advanced portscanning.

1. As I already mentioned - avoid track-downs! It's generally a bad idea to scan from your local host (maybe your Windoze machine at home). There s a slight chance your combination of IP and time stamp will be in the servers logs even though you know everything about NULL/XMAS/connect scan, evasive scanning tactics (-T1) and other stuff. By the way I also have to tell you that Socks (4/5) Proxies might give you a false feeling of security. Always be careful with them!

2. Only a scan that wasn't noticed is a successful scan and the basic requirement for ANY further investigation or attack. If you can't provide at least a basic level of self security I'll suggest you to FURTHER stay away from that target. You will loose on one or another way. Especially larger companies (where it's all about money) will take trouble to track you down and submit the chase to a court.

3. Finally it came to analyzing the results that were given to me. When I did my scan I saw a (rather) secure GNU/Linux operating system [Linux 2.4.20 - 2.4.22 w/grsecurity.org patch] with lot's of unnecessary services [OpenSSH 4.7 (protocol 2.0), Postfix smtpd, OpenSSL] running on it. Let me remember you that this server was only supposed to be a stand alone web server! :-/

At last I suggest everyone to try methods like "play dead" and further familiarize yourself with all the protocols and services. Even nmap is sometimes wrong and thus you're required to have some common sense, a good security mindset and maybe Mixter's knowledge too.


Unit 3 - WebHack / Injections & Scan

The scans I did here were quite interesting because they showed me whether the system already had some well known security flaws or not. I was testing against about 200 vulnerabilities, but let me first introduce the system to you. :-)

Server Version : Apache/2.2.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.8g PHP/5.2.5-pl1-gentoo
Total accesses : 1831413 - Total Traffic: 19.1 GB
CPU Usage : u2882.03 s3215.62 cu74.9 cs0 - .852% CPU load

Great! That already gave me some information. First of all I know what kinda exploits may work here. Then I realized it's a shared hosters server consisting out of multiple units. All this gave me a good point to start at and I wanted to know who else is located within that subnet. Truly I finally found a lot of servers, dozens of sites hosted there and got a good feeling about how the infrastructure was set up.

Besides... I don't want to deny you that I found a severe flaw within the servers hardware monitoring and control facility. Yeah, don't think your system is secure just because it only runs two or three services on it visible form the outside.


Unit 4 - HTTP Brute Force Attack

Oh yes, I admit that this kind of testing is a bit uncommon. However I wanted to figure out how fast the system actually was, if the personnel made use of secure passwords which is relevant for later FTP, Confixx, and mail account probing. I gave it a try with alphanumeric characters for about 100.000 times. I kept the session and cookies so they didn't get invalid after the first try and (sure) set the brute range to max. 5 characters. My scanner is a bit advanced from those ones you might have already seen before just because it's a scanner written on my own ;-) Effectively I omitted lot's of stupid combinations (it was brute force though - I was not using word lists!) by some mathematical evolved patterns.

It worked quite well but unfortunately I wasn't able to crack the account. The initiator told me later it was excessively secured. Even If I had cracked it I wouldn't have had even an exiguous chance to move around within the system and for example send goods to my home address.


Unit 5 - FTP Brute Force Attack / SE

Why not merge that chapter with the previous one you might ask now. Well it's just because the FTP brute force attack was a bit different from the one before. It virtually had nothing to do with the underlying protocols or such but rather with the manner I carried out this one.

Honestly I'd like to show you the password list I generated to get into that account, but it's fairly too large to display it right here. It's largely crafted out of personal information (names, friends, interests, important things in the peoples lives, other meta data, etc.) gathered about the account holder and some people from the staff.

Some of you may now understand why I introduced a 5th unit. It's all about social engineering, an alternative tactic used whenever you fell like the problem you face is just to complex to solve it either way. For the next step I did a web search to figure out in which way FTP account names were created by that provider. I came to the conclusion that the accounts user name must have been in the form "KOxxxxx" where x was an integer in the range of 0...9. The last thing I did was to make a "special" phone call to get the information I needed. Thus I held the user name in my hands and performed a nice attack on the FTP account.

The reason why I wasn't granted access again was just because the password was way to long (I was informed about that later too. *sigh*). Even with advanced tools, social engineering and common sense it's quite impossible to get into a 20 character passworded user account. The only possible way is to exploit a flaw within the operating systems FTP service then. Unfortunately I did not have the time to do that.

Now you hopefully understand why it's so important to train your personnel, use strong passwords and run secure services. ;-)

NOTE: I left distributed hacking attempts behind as well as a comment on how long passwords should be. Make your own thoughts about it!


Unit 6 - Goolag Scanner

As you might have already noticed the Goolag Scanner is the second application in my report I called by it's real name. I wanted to give it a try because it's name resounded throughout the land when it came up first in 2007. In fact the Goolag Scaner is a pretty versatile tool to get out some information from a web portal. The only thing you have to take into account is that the portal/website must be well known on Google and that it's often up to the webmasters inability to provide you with helpful information on the target system or not.

I initialized the scanner with a long interruption time between scans to ensure Google wouldn't block further attempts (which often happend). See, the basic idea behind the concept is to "ask Google" for known insecurities about your site of flavor.

The whole thing began to make fun when I realized that (though the portal wasn't yet fully indexed at that time) one of the two vulnerabilities I found was indeed the hardware monitoring flaw I described in Unit 3. What a wreck! Anyway... I tested for ~1400 known flaws within the system and finally came to the conclusion this cannot help me at the moment but will provide more useful information in the future.


Unit 7 - NTO Scan / Webscan

That kind of scan is a Windoze OS specific one. I ran it using WINE and it gave more information on the websites structure and possible attack vectors. I cannot/am not allowed get much into detail with code here but I figured out that a file called "secure.php" controlled user authentication.

Further a cookie was set and the PHPSESSID was used in combination with some weird but well working encoding mechanism as well as IP checking and an internal user account locking table to only grant users access who really deserved it. The techniques used were quite well implemented into that core script. The only thing I complained about later was that the site owners didn't make use of SSL encryption in combination with a Level 2 certificate at that time. I know some of you might complain about me now because SSL isn't secure at all. Sure it isn't but it provides some basic immunity against remote session hijacking. The biggest problem in every client-server web session is a well carried out man-in-the-middle attack OR (sometimes even better) an attack in which the victim performs the necessary action on it's own (e.g. phishing).

But unit 7 isn't yet finished. I still missed some things like an extended script analysis, a HTML header (request/response) analysis, the style and correctness as well as conformance of all received HTML documents, even SQL Injections and finally XSS (cross site scripting).

In short I can say that all scripts were crafted well. I seriously wasn't able to find any mistakes in 'em neither when looking through them nor when running (pseudo) debugging tools or pentests against them. Since I feel like these scripts are the most important thing the overall appearance of that portal was good. In the end there were only minor bugs or problems like malformed CSS and omitted document type definitions.

One of the good things (I mentioned before) was that request and response headers were correlating and the overall configuration of the server was good. For example compression was enabled by default and the system was pretty reliable.

Further the system was recently converted to use an XML/plainfile database instead of an SQL database (so much for SQL injections...). This was a step I didn't understand THOUGH in that field of science a lot of progress, for example with toendaCMS was made over the years and it actually has some advantages over an SQL database driven system. Nevertheless this is likely to change soon since an SQL database is simply able to handle more requests at the same time. Besides... XSS also wasn't possible which is founded in the absence of dozens of input forms like the ones you find in guest books or forums.


Conclusion

Wow. After so much prose it'll be difficult for me to outmatch this. Maybe I give it a try with a "short" statement in the end.

A highly efficient manner of attack I still let untouched is to rent a root server which is located within the same subnet as the target system. From that location scans in promiscous mode can be run with ease. This method is a bit more time and cost-intensive but provides you with unequally more prospects to perform attacks. Extended, time consuming, source code analysis for flaws would become superfluous with a host in the net recording every packet sent through it. Even different post methods and encryption via SSL would become obsolete then since it's easy to get all required data right on from the first packet being sent.

Further I have to emphasize the importance of social engineering once again. Taking the average system into account then security on it mainly depends on a secret combination of independent user names and passwords for every single account. Recent research studies by experts have shown that randomization of user names is at least important as choosing secure passwords with adequate length and keyspace. This especially applies when providing more than one service interface to log into on a system or when allowing a wide range of users to register with the system for example via some website front-end. Especially at that point a server-side mandatory encryption and password scheme is advised.

I also recommend securing the hosting environment and as a second step to avoid PHP whenever possible. PHP is a bad language and by no means comparable to Perl, Python or TCL. If you cannot do this I suggest you to run the PHP environment as strict as possible. Disable weak things like "register_globals" or "allow_url_fopen" right from the beginning. Run the system with minimum rights within a sandbox or chroot() environment. Get rid of all unnecessary services and programs. Why having "wget" laying around there? But this isn't enough... always update your system, enable security enhancement (SELinux) or use hardened libraries (*BSD). Last but not least use a system wide running IDS and a rootkit scanner, install anti-malware programs (even when not using Windoze / to stop the spread of malware) and (statefull) firewalls everywhere. Note that a firewall by nature NEVER runs on the system it protects. Stuff like ZoneAlarm is a so called "desktop filer" but NOT a fully qualified firewall. This also applies to GNU/Linux or Unix firewall software as long as the system does anything else except firewalling. Take this serious!

From the project related standpoint of view I suggest thinking about teams/companies that write websites for you and run your servers. The thing is highly complicated but there are some "guidelines" you can still follow. First thing is to choose a hosting provider you fully trust. Make sure you're a customer they listen to. Ensure the company has the will to fix problems ASAP and has an eye an security BY DEFAULT. Whenever you ask someone to write you a website (or do it on your own) learn something about QoS (Quality of Service). Makes sure you understand how to run a project and what it means for you and all of your teammates to regard quality and security as an integral part of the project - not something which is set on top loveless or just applied later (at the end when it's too late and costly to fix). Excessive penetration testing at the end never helped to write better code right on from the beginning. Even more... security and audits are (the same way as this report you read now) never finished. It's an highly iterative process. Once again. It never ever ends...

[d@v|d]

This blog is a must read. great work! Love the reference to Mixter

[Kernel Hash]

Real nice work. Alot of information in a small space. Cool blog. Later.

[jeasoft]

hey, it's very interesting this article, thanks and congratz!

[Happy-Dude]

Wow, nice work.

A quick and brief post, yet well versed and informative. Thanks for the heads up in the conclusion :) .

[dev0id]

Great work!

[:: justy ::]

interesting blog. loved the post.