Penetration Testing: Re: A Quality Penetration Test

["Adriel T. Desautels" <ad_lists () netragard com>]

Lee,
	The tests were basic in nature, nothing complicated at all. If you'd  
been following the blog then you would understand why we choose that  
example.  When I wrote about vulnerability scanners and vendors that  
rely on them for penetration testing someone asked me to comment on  
how a real penetration test was better.  In this particular case the  
customer underwent a "penetration test" by a different vendor. That  
vendor missed all of the vulnerabilities that we found during the  
follow up engagement.  So, this post was probably a good read for  
people who payed attention and asked for it.
	Also, if you are telling me that Social Engineering is a standard  
component of "your" penetration tests then you are either a liar or  
are speaking from little experience.  Just this past year we serviced  
a few hundred customers and of those customers only about 10% would  
allow us to use our Social Engineering module.  Even less allowed us  
to use Infected media, distributed metastasis, physical entry, etc.   
Those types of services are non-standard because they are intrusive  
and aggressive and most customers just don't want them.
	So, yes what we did during the test was actually significantly  
different than what most consultancies do. What consultancies would  
you suggest deliver the same caliber services? Can you give me some  
names so that I can look into them?
	Anyway, you made the mistake of thinking that advanced services  
always means technically advanced when in fact it only means above the  
norm.  The fact of the matter is that sometimes technically advanced  
attacks are required, sometimes they are not. We're more than capable  
of doing both, but what about you? What would you consider to be an  
advanced attack lee?
Next time you decide to compliment someone, don't attack them first.


On Jan 21, 2009, at 4:22 AM, Lee Lawson wrote:

> whilst this may seem like a good read to non-penetration testers,  
> all of the attacks you carried out are part of a basic, no frills  
> penetration test.  Why you are calling it an Advanced Penetration  
> Test evades me.  If you are using this mailing list to advertise  
> your company and the way that you perform your services then you are  
> not using the list for the reason it was created.  If, however, you  
> are using this entry to explain the actions you took during a  
> penetration test (which would help the non-penetration testers that  
> read the list) then that is fine as it is educational (almost).
> By comparing your services to the previous company, and exposing  
> some pretty basic flaws in the web application platforms you are  
> 'bigging' yourself up without justifying it.  What you did during  
> this 'advanced' test is nothing different to what most decent  
> consultancies do, of course, we are all frustrated by the idiot  
> companies out there that simply run Nessus and call that a  
> penetration test, but comparing yourself to them and claiming 'leet'  
> skills is far from accurate.
> However,
>
> What you did was a quality penetration test, just not an advanced  
> one, and I commend you and your company for performing this trade  
> with professional and skilled personnel.
>
>
>
> On Tue, Jan 20, 2009 at 10:26 PM, Adriel T. Desautels <ad_lists () netragard com 
> > wrote:
> As requested, here is the latest entry...
>
> Someone on the pen-testing mailing list asked me to write an entry  
> about the difference between vulnerability scanning (and services  
> that rely on it) and Real Time Dynamic Testing™.  This entry is a  
> sanitized description of a real Advanced External Penetration Test  
> that our team delivered to a customer.  Many details were left out  
> and our customer's information was removed or augmented to protect  
> their identity.  Our customer did approve this entry.
> Our team (Netragard, LLC.) was hired to perform an Advanced External  
> Penetration Test as a follow-up engagement to a pen-test that was  
> delivered by a different vendor.  This might seem unusual, but we  
> get these types of engagements more and more frequently.  This test  
> was no different than most of them, and we found significant  
> exploitable vulnerabilities that the other vendor missed entirely,  
> which unfortunately seems all too common.
> When we deliver Advanced services we expose our customers to  
> specific type of threat. Our goal is to create a threat that is a  
> few levels higher than what they would likely face in the real  
> world.  Testing our customers at a threat level that is less than  
> that would do nothing to help them defend against the actual threat.  
> Our services are not the product of automated vulnerability scanners  
> and scripts; they are the product of human talent.
> During this particular engagement we were authorized to perform  
> Distributed Metastasis, Covert Testing, Social Engineering, Malware  
> Deployment, ARP Poisoning, etc.  All targets were also authorized  
> and included Web Servers that were hosted by third parties, Web  
> Servers that were hosted locally, VPN end points, FTP servers, IDS  
> systems, DNS servers, Secure Email Servers like tumbleweed and so  
> on. We were not given a list of IP addresses to target, we had to  
> identify them and request approval.
> We began the engagement by performing covert social and technical  
> reconnaissance.  Reconnaissance is the military term for the  
> collection of intelligence about an enemy prior to attacking the  
> enemy; in this case our customer was the "enemy". Our philosophy is  
> that we cannot produce an accurate threat level without first  
> understanding some details about our target's political structure,  
> social behavior, and technology infrastructure.  We might not use  
> all of the information that we collect while testing, but more times  
> than not it provides us with a good idea of what will be effective,  
> and what will not.
> During reconnaissance we focused on two separate target groups.  The  
> first target group was the social structure of the client's  
> employees that we felt was of interest. As such we collected  
> information about those employees that included office-location,  
> telephone extensions, email address, relationships to other  
> employees, friends outside of work, etc. Our secondary sets of  
> targets for reconnaissance were technical targets. Those targets  
> included the identification of servers used by the client, vendor  
> identification, partner identification, the identification of IP  
> addresses belonging to the client, the internal IP addressing  
> scheme, operating system information, patch frequency information,  
> etc.
>
> We were able to use the information collected during reconnaissance  
> to begin performing vulnerability identification through analysis.   
> Because this service was an advanced service and required covert  
> testing, vulnerability identification was mostly done with manual  
> testing (Real Time Dynamic Testing™) and during reconnaissance. As  
> testing progressed we increased our noise level until we received  
> notification from the customer that we'd been detected.  This  
> enabled us to identify what level of testing was considered "flying  
> below the radar" and what level was "tagged".  (Knowing this enables  
> us to help our customers retune their IDS technologies so that they  
> are more difficult to evade. In most cases IDS technologies are not  
> tuned properly, and yes this includes IPS and Correlation Systems  
> too.)
> Once we were finished with vulnerability identification we built a  
> target matrix that was organized by probability of penetration.   
> This matrix is used as a guide for the team and enables us to test  
> the most probable points of entry first, and the least probable  
> points of entry last.  In the case of this particular customer we  
> identified three probable points of entry along with a few other  
> basic vulnerabilities like Cross-site Scripting, etc.  (While Cross- 
> site Scripting is useful for performing Social Engineering based  
> attacks, we won't go into the details about how we used them here.)   
> The other vendor even with basic scanning services should have  
> detected most, if not all of these vulnerabilities, but they didn't.
> The first point of attack that we focused on was the customer's  
> corporate website.  This website was being hosted by a third party  
> and was using a Content Management System ("CMS") that was created  
> by vendor that we'll call the Noname Group.  This particular CMS was  
> written entirely in PHP, was closed source and had no security  
> functionality to speak of. There were multiple points were unchecked  
> variables were passed directly to SQL statements or other critical  
> internal application components.  We were able to use those  
> unchecked variables to penetrate into our Customer's Web Server and  
> take control of it.
> Upon accessing that web server we found customer data that was  
> stored in the database in clear text. This information contained  
> names, addresses, account numbers, social security numbers, etc.  In  
> some cases the information was from users requesting information, in  
> other cases it was users looking to sign up.  As a proof of concept  
> we wrote a ruby script that would automatically dump the contents of  
> the database when executed. That script was submitted to the  
> customer.  Because this server was not hosted within our Customer's  
> IT Infrastructure it did not provide us with a platform from which  
> we could perform Distributed Metastasis.
> The next target lined up for testing was another Web Application,  
> this time it was hosted from within our customer's infrastructure.   
> Again, the application suffered from a basic SQL Injection  
> vulnerability that could be triggered by a back-tick.  We used the  
> vulnerability to fingerprint the application's backend database and  
> learned that it was a MS-SQL database. We also learned that was  
> hosted on a separate server from the Web Server.  We then tested for  
> "xp_cmdshell" access and found that the "sa" user had no password  
> set and as a result we could execute arbitrary commands against the  
> database server with administrator privileges.
> Once we gained control over the database server we began to examine  
> other systems within proximity to our new point of control  
> (Distributed Metastasis). That was when we learned that we'd  
> compromised a key server that was deep within the customers IT  
> Infrastructure and had clear access to other critical systems.  We  
> also noticed that the server that we were controlling contained  
> multiple databases that contained a wide variety of highly sensitive  
> information including customer banking information, social security  
> numbers, etc.  In addition, while performing network probes we  
> identified a secondary database server. Ironically this second  
> database server was running on the web server with the SQL Injection  
> vulnerability that we'd just attacked.
> When we tried to connect to the second database server from the  
> internal server we were unable to access it because this time the  
> "sa" password was set and we didn't know what it was set to.  We did  
> however know which system accessed that database server as a result  
> of the Social Engineering efforts that were mixed into our Social  
> Reconnaissance.  The system with access was also the third system in  
> our targeting matrix and contained another vulnerable Web  
> Application.  This time, due to the configuration of the application  
> SQL Injection capabilities were limited.  We did however manage to  
> find an arbitrary file read vulnerability and were able to use it to  
> read the application's configuration file that contained the "sa"  
> password.
> This enabled us to go back to the previously inaccessible database  
> and access it using the sa password. This also gave us access to the  
> xp_cmdshell function that in turn allowed us to execute arbitrary  
> commands against the system.  At this point in the test we'd managed  
> to penetrate into both the DMZ and the corporate LAN which also  
> allowed us to connect to any other system within proximity without  
> issue. In other words, there was no internal segmentation in the  
> form of VLAN's or physical isolation.  The networks were flat.
> The server that we penetrated in the LAN contained a SAM file. We  
> were able to crack 90% of the passwords in that SAM file with  
> rainbow tables, including the Administrator password.  Once we had  
> that password we were able to use RDP to access the Active Directory  
> server and it was technically game over.  If we had not discovered  
> the SAM we were prepared to perform ARP Poisoning to collect data  
> and possibly in-transit credentials. Our penetration of the AD  
> server concluded the penetration test.
> It is important to note that this is not a complete description of  
> all of the testing that we did for the customer. As with any  
> engagement we produce a deliverable that outlines all discovered  
> points of risk with their respective methods for remediation. In  
> this particular case our report identified 47 risks and provided 47  
> methods for remediation.  Remember that this customer just completed  
> a penetration test from a different vendor, how is it that they  
> missed 47 risks? Their services certainly did not protect our  
> customer from hackers.
>        Adriel T. Desautels
>        ad_lists () netragard com
>        --------------------------------------
>
>        Subscribe to our blog
>        http://snosoft.blogspot.com
>
>
>
>
>
>
> --
> Lee J Lawson
> leejlawson () gmail com
>
> CISSP | EnCE | CPTS | CEH | MCSE+S
> http://www.linkedin.com/in/leejlawson


        Adriel T. Desautels
        ad_lists () netragard com
        --------------------------------------

        Subscribe to our blog
        http://snosoft.blogspot.com