Anatomy of a Hack

Tiberius_Fel writes "Informit.com is running an extensive article about the anatomy of a hack against a sample network. It's an excerpt from a book titled Protect Your Windows Network: From Perimeter to Data. Even though it makes references to Windows, the techniques can be applied to other operating systems fairly easily." From the article: "Although attacking networks can be fun and informative--not to mention illegal if you do not have all the proper permissions--the fact remains that the vast majority of us do not need to know how to do so. Frankly, becoming a good penetration tester (pen tester) takes more than a week-long class. It takes commitment, dedication, intuition, and technical savvy, not to mention a blatant disregard for the rules and the right way to do things."

Comments

Article has a good page on cleaning systems

[billstewart]

About page 10 of the article, the author gets to a discussion of what you can do to clean up a compromised system, and uses the analogy of cleaning a swimming pool with undesirable liquids in it - you can't just clean the water, you've got to drain the whole thing and start over. He lists a large number of things you can no longer trust on a compromised system, and explains how each of a number of successively more difficult approaches won't work.

• You can't just patch the hole the attacker used - he installed a bunch more new holes one he got in.
• You can't just reinstall from backup, because you don't know if your backup files are compromised too.
• You can't look in your log files to figure out when you got compromised, because any good cracker knows to wipe his traces out of the log file.
• You can't just reinstall the operating system over the existing one - too many dangerous files may still be there, including things left in the data and application directories.
• 3... 4... 5. DON'T PROFIT! 6...
• You're stuck reinstalling the OS and applications from known-good media onto a clean disk, and hoping you can salvage some of the data, depending on whether your applications make this possible.

What he doesn't really go into his how to build your production systems in a way that *ASSUMES* you're going to get attacked, maintains a clean environment for developing them in, and gives you the tools to rebuild rapidly from trustable versions. On the other hand, he does show how his example's victim's system was thoroughly broken into, getting from the production system to the development system, because it really *is* hard to do a good job of separating them adequately in a real environment, so even if you think you have a clean-room, you might not.

strange definitions of warez, xss, etc.

[lonedroid]

I just read the whole FA (yup, I'm new here as my user ID can tell ;) and I'm not sure what to think about it.

The metodology used is not extraordinary: setting up a purposedly insecure network then hacking (sic) it themselves using the known holes is kind of cheesy. It helps to show how it works, but I prefer the honeynet approach: setting up boxes with known (or not) security holes, then analysing how a real intruder creates havoc.

Then there's some strange (re)definition of words.

For example, straight from TFA:

There are several techniques for getting our tools (often called "warez") onto the database server.

Then, as a side note:

Warez is a hacker/attacker colloquialism. It comes from the term "software," but is now used varyingly to mean either "attack tools" or "bootlegged software." In this chapter, we use it in the former context.

I think it's the first time I see the term "warez" used to describe "attack tools" (sic). I used to live in ancient times where "warez" weren't yet called "warez", then "warez" became "warez". Now what? "warez" aren't "warez" anymore? As it changed? (then a great many online dictionaries definition should be updated btw.).

The definition of XSS is also interesting:

In Figure 2-5, we see that not only do we get logged on, but the application also displayed the fake username we sent it on the home page. This latter artifact is actually a separate type of vulnerability known as a cross-site scripting (XSS) vulnerability, where the user input is echoed directly to the screen without sanitizing it first. We will not use it in the following attack, but it is interesting to note that it is there.

This definition of XSS is wrong: it's not because we see what was typed that the input weren't sanitized (sic). And it's certainly not because we see what was entered that this could lead to code being executed on another user's computer. Moreover I find the last sentence of this paragraph misleading: We will not use it in the following attack, but it is interesting to note that is is there. Of course they're not using it: they're "hacking" the server(s), not joe random visitor's box.

Then there are quite a lot half-truth, that can also be misleading:

A fully compromised system cannot be trusted to tell you the truth. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it.

If by "fully compromised" it means that the BIOS has been flashed and now lies about the files it reports, I then more or less agree. However such a tool is improbable (not enough room in the BIOS memory and not all BIOS can be flashed at will). So by "fully compromised" that's probably not what they meant. How would then an attacker lie when booting from a CD and running the scan from the CD? Or when hooking the compromised HD as a second HD on a clean system? It's not like everybody run their virus/trojans/rootkits scanners from the suspicious host.

Then at the end of TFLA (the 'L' stands for "Long") they explain, in a very windowish style, how to recover from a "hack": reinstall everything, because there's nothing you can trust (besides Windows's installation medium?)

So is it about the anatomy of a "hack" or how to recover from a "hack"? Both? Then why not a single word about how to configure an IDS?

Speaking of IDS, from TFA: Once we took over an entire network through an intrusion detection system.

WTF? I'm not sure if by their definition Snort qualifies as an IDS, but I run Snort in a passive way: no IP, not a single packet emitting from the box, etc. If an IDS becomes an entry point for intruders, then it's not an IDS but an IAS: Intrusion Automation System ;)

The article could be summarized like this (like others already pointed out i

Re:For Some, it just isn't worth it.

[_Sharp'r_]

From the summary "becoming a good penetration tester (pen tester) takes more than a week-long class"

Using the few thousand business and government networks I've seen over many years, about 99% of them could be cracked very quickly by anyone with half a clue. What's more, in the majority of cases, the technical people involved (either in-house or consultants) pretty much all knew that.

It may take more than a week to become a good pen tester because that involves a more comprehensive look at finding ALL the vulnerabilities and providing priorities and instructions on fixing them, but it sure doesn't take that long to learn enough to crack most network security.

The most common network used to be completely un-hardened hosts running multiple insecure applications on unsegmented networks with multiple unmonitored internet connections.

About the only improvement in the "average" network nowadays is that a firewall or at least NAT device is generally found on the internet facing edges of that insecure network and not much more.

Sure, I've worked for large ecommerce companies where we had better security than most banks (at least according to our regular third-party security auditors), but the vast majority of networks out there are either small to medium businesses run by managers with no clue and less inclination to spend money on security, or large companies and government agencies where no one knows what's going on enough to close all the gaps.

Especially government agencies. A friend worked as a security consultant for a cabinet level agency that ran for years with all the firewalls in simple routing mode because one of the high level bureacrats decided it simplified things (you know, no pesky security in the way) and their IDS would be good enough security by itself. If you've seen most government contracted IDS, you know how much of a joke that is.

It's routine at some of the agencies I did consulting work for to have all the employees in the office using the same username and password. Of course, the password being "password" made it easy for them all to remember and happy to give it out to any outside who they thought might need it.

Just this last saturday I listened to someone in the park on their mobile phone tell their customer that their company email password was "password" so that the customer could check their email for a document they wanted.

Now with widespread unsecured wireless network use showing up all over the place..... ahhhh... the lack of security is too much to contemplate! At least you used to have to be able to somewhat guess an IP range if you wanted to target a specific office. Now people can generally just park nearby and watch all the packets go past.