해킹기법 [인터넷에 떠도는 해킹 코드의 불편한 진실]

[출처] http://www.tamonten.com/how-not-to-exploit-a-box

This week I had the opportunity to sit with a pentester as he conducted a test on one of our clients. I wasn't really sure why he needed someone with him, but management wanted someone there and I wasn't going to miss an opportunity to watch. I didn't want to interfere so I just sat a few feet away, ready to supply any info he needed.

Now, I'm familiar enough with tools used so I was actually able to keep track of what was being done with cursory shoulder surfing ("that looks like nmap out", "breaking out Metasploit I see", "that Saint report looks OK") and after a bit it's obvious there's no foot hold for him to get purchase on. He browses to exploitdb, he does a bit of googling and finally he find a single exploit for the version of ssh that's being run. He grabs the code compiles it, then stops, obviously concerned about something. Turning to me he asks "can we restart ssh if we need to?". When I answered in the affirmative he fires off the code.

The exploit fails.

Hurrah.

He lets me know that there's one or two things that could be done to tighten things up (most of which I agree with and had come to the same conclusions while watching the test progress) and this is what he'll be reporting and that there's exploits available for the vulnerable version of ssh being run *points to his screen to show me the code*

Now what's wrong with the above picture? Three things.

1: The version of ssh (openssh 5.3p1), to the best of my knowledge, has no remote vulns.

2: The site the code was retrieved from was pastebin.

3: Other than the quick glance he didn't do any kind of code audit, then ran it against a clients box (despite obviously having some second thoughts about it) and this is a stupid idea.

"Why is that wrong?" you say.
This is what was in the console window after he ran it:
[-] Exploit failed.
unable to delete directory /

See now?

Here's the code that was executed

Now my C skills are not what you'd call advanced, not having written any since uni many moons ago, but I've got enough general programming under my belt to do basic analysis.

So basic analysis is what you're going to get. (If you spot any errors or something obvious I've missed please drop me a line)

If you've ever looked at exploit code you'll see this looks textbook. The warning not to share it with anyone, the l33t speak, the chunk of shell code in the middle. So on a simple glance it looks legit.

Quick run though of what this appears to be doing

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

checks to see if running as root
checks to see if hostname can be resolved
tries to make socket connection
builds payload
sends payload
if successful spawns shell (but a shell on YOUR box. *alarmbells*)

Problems:
hostname (h) is never actually set within the code, just declared, therefore code beyond line 73 NEVER executes, which leaves it doing two things: checking it's being run as root, erroring out.

If you look at all the erroring out you'll see they're all an fprintf() statement followed by an exit(), with the exception of the one that's run, it contains

(*(void(*)())decoder)();

At the time I first read this I had no idea what this did, but I did know that anything that has that many parenthesis can't be good, and why only call it with the decoder shellcode and not the rootshell?

I've since had my suspicions confirmed, that this line in fact executes the decoder shellcode localy.

The shell code is the bit I'm always weary of in any exploit code. Unless you're some sort of ASM monster it's never obvious what's going on within it. One thing you can look for is strings within the shellcode. Now there's two sections of shell, one called "rootshell" the other "decoder". On the surface that looks like the rootshell code is packed or obfuscated in some way, so we'll see what, if anything, stands out.

converting the shellcode to ascii:

docoder
j?X?Rj/??Rfh-f???Rfh-r??Rh//rmh/bin??RWVQS????

rootshell
1????ou!?Q?ck yQf?fufQ1???1???1?????1?1?@??

The only real strings I can pull out of that are in the decoder section. Namely "/","-f","-r","/rm","/bin"

Or to put it another way "/bin","/rm","-r","-f","/"

Those are not strings I want to see in code I'm running on my box

Luckily the pentester in question was saved by the fact that "rm -rf /" doesn't work on modern distros, but he was only a "--no-preserve-root" away from a dead box.

And he wouldn't have got a jot of sympathy from me.

(thanks to Jon for taking a look at the code and confirming what I thought)