cyberwart

I really try not to rant, but since this is my blog I’ll vent a little. A poster on a forum is asking for help getting pass-the-hash functionality into CANVAS. Besides for the fact that he could simply upload and run the tool, he’s still missing a few key points.

First, you don’t need to crack the hash. It’s often useful to do so — having a list of passwords is one of the best ways to maintain access to a network. But it’s a “nice to have” thing and completely unnecessary.

Second, the example he’s using is a remote system is compromised and a domain admin logs in via RDP or maybe uses domain credentials on a SQL server. If you’re SYSTEM on the local box, you can inject into that user’s process. When you do that, you are the domain user/admin. This is nicer than pass-the-hash style attacks because you can maintain the process. Active Directory uses kerberos so passing the hash should only work for so long.

To do this simply open CANVAS and browse to Commands->PROCESSINJECT and inject into the user process (RDP, Explorer, iexplorer, firefox, Word, whatever). At this point Canvas will execute commands as the owner of the process; with the same domain privileges as that user.  Note you need the seDebugPrivilege to do this which is SYSTEM, Administrators, and maybe (?) power users.

I’ve been eagerly awaiting the release of “Grey Hat Python” by Justin Seitz of Immunity. I think Python is a great language and it’s used extensively in the security industry so I’ve been quite curious about the book. Overall, I’m happy with it. The book gives insight into some of the tips and tricks one of the best exploit development companies uses to quickly find and exploit bugs. I think most security professionals will find the book a useful addition to their shelves.

If the book has a fault, it’s Justin’s concise focus on using python as a tool to rapidly find and exploit bugs. As such the book is in a niche category. It doesn’t really fulfill the subtitle “Python Programming for Hackers…” A more accurate subtitle might be “Python programming for expedited bug finding and exploitation”. As such it lacks some things I would have expected from a more general book such as:

1. Using scapy or impacket for network tricks
2. Using python for phishing (this is a potential hot topic — the Metasploit guys are working on a phishing addition for the framework so seeing something similar in python would be a plus).
3. Using python for generic security applications: web scraping, social network enumeration, gluing security tools, etc

All the above would have been nice additions to make the book more complete. As-is the book is very good, but you need to understand that it’s not a general purpose python for hacking book. It is a great resource for debugging and automating dynamic analysis of executables.

Now for the super-hardcore exploit guys out there I would have liked to see more depth. I understand why the book didn’t go into too much more detail — the number of interested parties likely decreases exponentially. But I’d have liked to see a few things:

1. Some code that Nico uses to manipulate the heap for use in heap overflows. I do a lot of trial and error with little automated analysis. I assume Immunity does something better and I’d like to see it. In fairness, they do review the !hippie function that’s in ID.
2. I’d like to see an easier intro to fuzzing RPC with python. RPC has always been a barrier for me and the Immunity folks have a lot of tools to do this. I’d like to see some more approachable examples than having the source and digging into spike.py
3. MOSDEF is one of things that makes CANVAS special. I’d have loved to see the book build a simpler win32MosdefShellServer

I’m a hardcore security geek and there are probably only a handful of people that would want to see the three items immediately above. So I’m not surprised they’re not in the book, and can’t fault anyone for that.

Overall, I recommend the book. Look at is a first iteration. It’s a good book to help security engineers use python to begin analyzing software vulnerabilities. Primarily it’s a book about using python to debug and to a lesser degree fuzz. It’s a good insight into how Immunity does things and will help you look at CANVAS code a little easier. For that alone it’s definitely worth buying.

DailyDave had a thread recently about defending against 0day. Carnal0wnage had a follow up on it. I meant to follow up more on the thought but I’m slow.

I’ve used generic 0days on pen tests before. By “generic” I mean 0day for popular software with high reliability. Generally speaking if that ends up in a report I hear “you cheated” or “Only someone with xyz background could do that”. Both are true. I’ll get to the “you cheated” in a moment, but you either need a highly specialized background or good security friends to get good 0days. Most organizations aren’t targeted by that sort of advesary. The exception is any organization in Fortune 100, Energy, Defense, or Finance. So when testing with 0day I think it’s important to understand your business and your threat. It simply doesn’t make sense to protect $100 of assets with $1000 of security.

Now is 0day “cheating”? Sometimes. I think it really depends. Ron Gula, head of Tenable (maker of Nessus) stated that simplicity is key. Indeed, complexity inevitably introduces security flaws. However, defense in depth is certainly more complicated than a flat network and is generally considered more secure. Yet even that can introduce new attacks. There have previously been exploits against Snort that an attacker could blindy attack to bypass the network perimeter. Snort is adding a best practice and defense in depth (by detecting attacks that made it into the network) but because of complexity (adding something) the network was made vulnerable. You can add more complexity to mitigate the attack such as cutting the Tx wires on the ethernet, ensure the promiscuous card has no IP address, that the management interface is on a private well monitored and hardened network, certs aren’t stored on the device, good egress rules, and standard hardening guidelines are followed. That’s pushing fairly paranoid though.

I haven’t answered is this cheating. The answer is, in this case, yes. The administrator followed best practice, the attacker basically sent the attack blind. The attacker leveraged a nasty exploit and won in a manner that most organizations couldn’t defend. The counter example is a friend who had an OWA 0day. He could pop through an OWA login and gain access to an account. I’d argue this isn’t cheating! Why the difference? In this case, there’s a clear high value target (corporate email) that an attacker is motivated to invest signifigant time to building an exploit. This matters, in my opinion, because it has a reasonable mitigation that the defender should have in place (restricting email to IPs, VPN, or using multi-stage authentication).

This is a complicated issue that’s in an extreme grey area. Balancing complexity with defense-in-depth to protect ungainst an unknown threat (0day) has no simple solution and the above case is only my particular view on this one case. But it goes to my overall solution, to protecting against 0day. Pen test continually and implement the recommendations. There’s always the one off case where there’s nothing reasonable (cost/business effective) you can do to mitigate a risk. In those cases you’ll simply have to choose to accept the risk. If you get burned in a pen test or by a hacker, that’s unfortunate but if you did your analysis and mitigation correctly you’re still ahead. There’s no way to protect against all unknown threats. Use pen testers (not just vuln scanners) to get into your network and figure out how a real-world attacker will compromise your network. In almost all cases buying or writing a 0day isn’t necessary so you have plenty to worry about before you worry about the unknown. Additionally, if the pen tester simply can’t get in otherwise they’ll probably go look for a 0day – if you want put that in the Statement of Work. Otherwise don’t worry too much about the unknown. The major exception to this is in-house and niche software that you suspect might be a problem but no one wants to touch.

So to recap:

1. Don’t overly worry about the unknown
2. Complexity is bad. Reduce it whenever possible
3. Reduce your attack surface with defense-in-depth (this has to be balanced with 2)
4. Pen test whenever possible. Make sure you understand what enabled the attacks and mitigate those factors.
5. Accept (and document) risk that doesn’t make sense to mitigate

I believe there is something fundamentally wrong about needing to write to disk to launch a process. Unfortunately, in Windows the de facto way to launch a process is LoadLibrary or CreateProcess both take a filename as an argument. Previously, I wrote that the Assembly::Load() method will perform that function nicely for you. Unfortunately, it requires your code to be .NET  (or that you manage to get access to the .NET code). I knew that CANVAS didn’t touch disk to launch a process but several layers of abstraction to get to the meat.

Immunity and Dave advertise MOSDEF occasionally and post the source code on their website. Despite this it eluded my as to why they’d want a Python based C compiler. The reason is that their C is special, it’s position independent code that you can point EIP to and start executing. This means you can take a C program and have working shellcode. This is lovely because you can reasonably convert your C code to compile with MOSDEF and execute it as shellcode.

As you can see above, the program is almost ANSI C. The difference is that you have to manually import every system/library that you want to use. While this can be slightly troublesome, overall it’s a fairly easy compared to other options.

If you you don’t want to recompile your code, you could always use Metasploit’s technique. Rather than recompiling code, they hook LoadLibrary and replace it with a custom loader. This work is done in Meterpreter. This method could cause some problems with complicated libraries, but overall makes it easier to generic code.

The above is the main code that loads your library. It’s buried in  ./framework/external/source/meterpreter/source/server/

I think for a quick solution Meterpreter is probably the easier option, but if you’re looking for more flexibility and/or you’re trying to load your code anywhere Mosdef is probably the way to go. Either way, both methods provide good options for getting custom code onto a remote system without touching the disk.

Buried inside an Immunity Inc slideset somewhere is a line “Generic heap exploitation approaches are obsolete….Application specific techniques are needed”. As usual the Immunity guys are right. They were specifically discussing that there are no more easy write4 heap overflows due to safe unlinking and other similar technologies (DEP, ASLR, SafeSEH, DEP, etc). They go on to write about some of the interesting things they’re doing to effectively exploit heap vulnerabilities. For those facing a touch heap exploit, I recommend reading their papers.

Unfortunately, they estimate that it can take 3 to 6 man-months to craft a reliable heap overflow exploit. For most assessment organizations that’s unrealistic. Most penetration test or security assessments last between 1-2 weeks. A common problem to see is that an organization recently patched all their systems right before you arrived. In fact, I’ve been asked to delay tests while they finished patching.

I’d generalize Nico’s statement to “General exploitation is obsolete” and state that “Exploitation is now specialized”. By that I mean, for most organizations creating generic exploits is too expensive or the return on investment isn’t there. The solution is to specialize multiple chained attacks into a larger attack vector particular to the target organization. I come from a Red Team background. One of the first concepts I was taught about breaking into systems is to identify two key factors:

1. An adversarial model. Determine who the organization fears. Mimic their skill set and goals.
2. The mission or business critical assets. Managers don’t understand technical vulnerabilities. They only know their mission/business.

My goal is to exploit that asset as their adversary would. I find this is an extremely effective approach. Foremost, you’re likely to keep your client happy if you understand both their business and their threats. But it also keeps you from going down interesting technical challenges that don’t mean all that much to them. Explaining business impact derived from a realistic methodology means far more.

Digging into the dirt what does this mean? It means there is no clear one size service. The client needs to put realistic vectors on the table and experienced testers will use the ones that make the most sense. In all but the worst organizations, there are no easy remote exploits from the Internet. Then even if you do get in, you have AV and are usually in a DMZ. The key is to chain your attacks.

A common pattern that I’ve used is a bit of customized code and targeted phishing. I’ll spend a few hours data mining the company and employees. I’ll target them with a couple options such as a signed, safe for scripting, safe for initialization ActiveX control that almost everyone clicks or a recent Office/PDF/IE exploit. The initial callback gets you into unprivileged user land. Unless their is a specific need for it, you usually don’t even need SYSTEM at this point. If you do, more than likely MS08-067 will still work somewhere. Next, I’ll look around the intranet for internal web applications or in-house software. I often find weak in-house or niche software that has no public vulnerabilities but is very obviously not security hardened. Grab a copy of the software (usually available on the local machine, a share on the target server with user credits — handily available from your logged in phishing victim, or other source). Take the software home and begin fuzzing it. The software has probably never seen a fuzzer and will break very quickly. Once you have an exploit working (probably a stack overflow without GS, DEP, SafeSEH) you can exploit the remote server — which is usually running the app as SYSTEM. At this point you have SYSTEM on a server. A domain admin will likely have some process running, inject into that and the game is over.

How is this specialized? Rather than spending 6 months developing an exploit I got what I needed in the time of my assessment by targeting users, the internal infrastructure, common vulnerabilities, and the in-house software that is unimportant outside the organization.

This approach definitely is not an attack on research exploit development. In fact, I think it’s more a testament to how well guys at places like Immunity and Core have pushed exploit development — thereby pushing Microsoft and others toward strong generic security measures. So while they do the hard work of finding new vulnerability classes and faster techniques to exploit the strong security measures, I think penetration testers and the bad guys will have to step up their game from point-click-scan-exploit to focus building customized approaches for their particular target and exploiting the low hanging fruit. This is double true since tools like Immunity Debugger are available to tackle the easy bugs. It reminds me of doing differential calculus with a TI-89.

MS09-013 is set of 3 bugs in the Windows HTTP library. This affects any application using the winhttp.dll client library. It’s important to note that several services use this library, including UnP and Java Update. Of most interest is an integer underun. This is located in the ChunkFilter::Decode() method. Incorrect usage of the size field gets passed down to RtlMoveMemory() which shifts the source address down 0xA bytes. An error occurs when a malicious web server uses chunk encoding and passes an overly large (negative) value.

This bug is not readily exploitable for remote code execution unless you can corrupt memory in such a way to affect a thread stack and/or a function pointer.

I’ve been reversing some of the recent Patch Tuesday updates. One of interest to me is MS09-013 which affects the WinHTTP library. I wanted to see which processes were already using the library on my box. I didn’t have a tool to quickly dump all loaded modules, but a quick google found the following code on MSDN:

// enum_modules.cpp : Defines the entry point for the console application.
//

#include “stdafx.h”
#include <windows.h>
#include <tchar.h>
#include <stdio.h>
#include <psapi.h>

void PrintModules( DWORD processID )
{
HMODULE hMods[1024];
HANDLE hProcess;
DWORD cbNeeded;
unsigned int i;

// Print the process identifier.

printf( “\nProcess ID: %u\n”, processID );

// Get a list of all the modules in this process.

hProcess = OpenProcess( PROCESS_QUERY_INFORMATION |
PROCESS_VM_READ,
FALSE, processID );
if (NULL == hProcess)
return;

if( EnumProcessModules(hProcess, hMods, sizeof(hMods), &cbNeeded))
{
for ( i = 0; i < (cbNeeded / sizeof(HMODULE)); i++ )
{
TCHAR szModName[MAX_PATH];

// Get the full path to the module’s file.

if ( GetModuleFileNameEx( hProcess, hMods[i], szModName,
sizeof(szModName) / sizeof(TCHAR)))
{
// Print the module name and handle value.

_tprintf( TEXT(“\t%s (0x%08X)\n”), szModName, hMods[i] );
}
}
}

CloseHandle( hProcess );
}

int main(int argc, char * argv[] )
{
// Get the list of process identifiers.

DWORD aProcesses[1024], cbNeeded, cProcesses;
unsigned int i;

if ( !EnumProcesses( aProcesses, sizeof(aProcesses), &cbNeeded ) )
return -1;

// Calculate how many process identifiers were returned.

cProcesses = cbNeeded / sizeof(DWORD);

// Print the name of the modules for each process.

for ( i = 0; i < cProcesses; i++ )
PrintModules( aProcesses[i] );

return 0;
}

It works perfect. Just makes sure to link with psapi.lib

While I was an employee at G2, I maintained a modified version of “Insider”. Which is an older remote access server/trojan that was on the Internet. Around 2003 it was great, it connected outbound to an HTTP server for command and control. Fixes and improvements kept it going. Unfortunately, as time went along it became obvious that there were implementation issues that would only allow it to scale so much. That fact combined with the fact that some of the code was on the clock, I decided to start re-writing insider.

Now named Wintermute, I’m writing the code from scratch. It’s again a windows based implant/rootkit. I’ve moved it to a DLL and focusing on modularity and designing it to not be a standalone app. As such I learned a few interesting things about DLLs that I didn’t know before:

• Visual Studio 2008 pushes you toward a MFC Dll. This probably isn’t what most people (C programmers) want to do. Create a generic Win32 project and select the DLL option.

• During DLL initialization (functions called from Dllmain, the Constructor, or the Initialize function if MFC, cannot create new threads. To be more precise, new threads are created but do not begin execution. This is actually documented on MSDN here near the bottom of the article.

• MSDN Recommends exporting DLL functions with keyword __declspec(dllexport) in the function’s definition. Unfortunately this mangles the function name. MS calls the name “decorated”, but it makes it difficult to be sure the mangling will be predictable across builds to create a uniform entry point.

• The other option is to create a .def file. It has this format:

LIBRARY    “wintermute”
EXPORTS
execute @1

In this case “execute” is the function name that is exported and the name that you can use when calling GetProcAddress()

Dave Aitel to dailydave

show details Apr 4 (2 days ago)

If you have a CEU subscription, access it here:
http://www.immunityinc.com/ceu-index.shtml

For a quick movie:
http://www.immunityinc.com/documentation/cloudburst-vista.html

Kostya Kortchinsky’s CLOUDBURST exploit is now available to CANVAS
Early Update subscribers. It is patched in the latest versions of
VMWare workstation and VMWare Player, etc.

Thanks,
Dave Aitel
Immunity, Inc.
__________

Rules for Private Networks Also Proposed

By Joby Warrick and Walter Pincus
Washington Post Staff Writers
Wednesday, April 1, 2009; A04

Key lawmakers are pushing to dramatically escalate U.S. defenses against cyberattacks, crafting proposals that would empower the government to set and enforce security standards for private industry for the first time.

The proposals, in Senate legislation that could be introduced as early as today, would broaden the focus of the government’s cybersecurity efforts to include not only military networks but also private systems that control essentials such as electricity and water distribution. At the same time, the bill would add regulatory teeth to ensure industry compliance with the rules, congressional officials familiar with the plan said yesterday.

Addressing what intelligence officials describe as a gaping vulnerability, the legislation also calls for the appointment of a White House cybersecurity “czar” with unprecedented authority to shut down computer networks, including private ones, if a cyberattack is underway, the officials said.

How industry groups will respond is unclear. Jim Dempsey, vice president for public policy at the Center for Democracy and Technology, which represents private companies and civil liberties advocates, said that mandatory standards have long been the “third rail of cybersecurity policy.” Dempsey said regulation could also stifle creativity by forcing companies to adopt a uniform approach.

The legislation, co-sponsored by Senate Commerce Committee Chairman John D. Rockefeller IV (D-W.Va.) and Sen. Olympia J. Snowe (R-Maine), was drafted with White House input. Although the White House indicated it supported some key concepts of the bill, there has been no official endorsement.

Many of the proposals were based on recommendations of a landmark study last year by the Center for Strategic and International Studies.

Currently, government responsibility for cybersecurity is split: The Pentagon and the National Security Agency safeguard military networks, while the Department of Homeland Security provides assistance to private networks. Previous cybersecurity initiatives have largely concentrated on reducing the vulnerability of government and military computers to hackers.

A 60-day federal review of the nation’s defenses against computer-based attacks is underway, and the administration has signaled its intention to incorporate private industry into those defenses in an unprecedented way.

“People say this is a military or intelligence concern, but it’s a lot more than that,” Rockefeller, a former intelligence committee chairman, said in an interview. “It suddenly gets into the realm of traffic lights and rail networks and water and electricity.”

U.S. intelligence officials have warned that a sustained attack on private computer networks could cause widespread social and economic havoc, possibly shutting down or compromising systems used by banks, utilities, transportation companies and others.

The Rockefeller-Snowe measure would create the Office of the National Cybersecurity Adviser, whose leader would report directly to the president and would coordinate defense efforts across government agencies. It would require the National Institute of Standards and Technology to establish “measurable and auditable cybersecurity standards” that would apply to private companies as well as the government. It also would require licensing and certification of cybersecurity professionals.

The proposal would also mandate an ongoing, quadrennial review of the nation’s cyberdefenses. “It’s not a problem that will ever be completely solved,” Rockefeller said. “You have to keep making higher walls.”

Last week, Director of National Intelligence Dennis C. Blair told reporters that one agency should oversee cybersecurity for government and for the private sector. He added that the NSA should be central to the effort.

“The taxpayers of this country have spent enormous sums developing a world-class capability at the National Security Agency on cyber,” he said.

Blair acknowledged there will be privacy concerns about centralizing cybersecurity, and he said the program should be designed in a way that gives Americans confidence that it is “not being used to gather private information.”