os detection

i read the don's post about the tcp forsenic challange , i couldnt help notice that , presumabley the attacker tried a portscan to find out the OS of the system.

what is intresting is that how a simple port scan can tell the os ( and if poss its build), as all the services and ports are usually dependent upon the applications and not exactly on the server, and os normally do not run services unique to them. ex a ftp deamon running on every os will ahve same port (by default).....

could u pls explain how can an attacker find out the type of OS by using pscan etc. , and how deep the info could be, (ex. is it pos to find out the kernel version, build etc) ,

the answer ought to be intresting.

It isn't so much the port scan that gave away the OS. Every OS, and even different revs of the same OS, respond in their own unique way to various exceptions, or even normal, TCP/IP traffic. Something that does OS detection well, doesn't really look at the banners returned by services because they can frankly lie (I had my RedHat Box come back with SunOS 4.1 :) ).

There are standards for TCP/IP; however, the vendors/coders were left to implement the standards in their own ways. The differences in the implementations is what is used by a scanner to determine the OS. Differences in sequence numbers, window sizes, option flags, etc can all be used by a 'good' scanner to determine the underlying OS. The scanner can also choose to inject erroneous traffic to measure the response, for example, sending a Fin-Rst-Ack-Syn flag to the port and then wait to see how the OS responds (this was kind of a grey area, and different vendors respond differently).

Fyodor, the creator of nmap, wrote an excellent article on this:

http://www.insecure.org/nmap/nmap-fi...g-article.html

/nebulus

im not sure thats exactly what that scan was doing. it kept scanning the same 10 ports while an os detection requires at least 2 ports the chances of finding 2 of those 10 open reduces the chances of detecting the OS and it wouldn't keep repeating it.


if youd like to see one method used for os detection run NetCat like this:

echo quit |nc -vv somedomain.com 1-1024

this isn't very fast or effecient but will give you an idea. this is one of the methods satan employs (the program not the devil)

This is interesting stuff.... i loved that article....thx guys ;)

before posting this stuff i thought of googling first but then i had no clear key words to google but guess what, i googled the subject line and the first page i got was the page given by nebulus.... some time u just miss the obvious :)

thanx guys this stuff did give me some insight.. now let me google more for some depth... and ill come back if there is any problem...sure

ran this nmap on few servers (security games are usually on in our coll) as a newbie to these games (actually the first timer) i m sure i wont be getting some support......

now this is something crazy i scanned only first 500 ports ....... the reply is intresting and ido get some head and tail of it......


# nmap (V. 3.00) scan initiated Thu Feb 22 00:17:40 2001 as: nmap -p 1-500 -O -sF -oN log 202.141.64.50
Insufficient responses for TCP sequencing (0), OS detection may be less accurate
Insufficient responses for TCP sequencing (0), OS detection may be less accurate
Insufficient responses for TCP sequencing (0), OS detection may be less accurate
Interesting ports on (202.141.64.50):
(The 491 ports scanned but not shown below are in state: closed)
Port State Service
39/tcp open rlp
137/tcp open netbios-ns
138/tcp open netbios-dgm
139/tcp open netbios-ssn
262/tcp open arcisdms
339/tcp open unknown
412/tcp open synoptics-trap
445/tcp filtered microsoft-ds
450/tcp open tserver
No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.00%P=i68 6-pc-windows-windows%D=2/22%Time=3A940F68%O=39%C=1)
T1(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)
T2(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T2(Resp=N)
T3(Resp=N)
T3(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)
T4(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T5(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)
T6(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T6(Resp=N)
T6(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T7(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)
PU(Resp=N)

# Nmap run completed at Thu Feb 22 00:26:40 2001 -- 1 IP address (1 host up) scanned in 540 seconds

hehe

it basically tells that the server is well protected (seems so) and has a window box coz of netbios and win-ds ports .... but u still dont get any other info ...........probably win 2k, but it could be nt or even xp, 9x is less likely .......
the server did not respond on normal scan then i tried the stealth fin.. this is that output

- sN -sX also gave the same ports.......

since i m on a win2k box .. no *nix applications can be used.... all the ports above do not accept :
- telnet
-hyperterminal (tcp mode)

and thats it... not to mention no ping.

ill keep googling but any help will be appreciated.......

just to add .... i dont understand lot of stuff in here and googling for specific stuff like tserver etc. dosent give much info (first 50 pg all contain port list, and think of it a port list in this site got me intrested in the first phase).... so the point is that there could be some staright forward info in here that i m missing... i could look stupid for that.. but hey i was even stupider when i couldnt count till 10.

you will need nmap to do this, you can download it from www.insecure.org/nmap

nmap -sS -P0 -O <hostame>

done =)

Ok, first off, and this is my personal opinion, and one that alot of people might agree with: You should have permission to do those scans, some people might consider an nmap scan an attack. This is to cover your rear...

If you read Fyodor's article and stuff on his web site, there are several things that can change the results of a scan.

Two things about your scan stick out, you limited your ports, you chose a FIN scan. FIN scans are not as reliable (or so I have read) on non-unix systems...for best results there, try SYN and don't limit the ports. Man nmap, there is a very long page there that explains why what you did isn't very reliable...

Other things that can effect results: You pass through a proxy, Timing, Firewalls, Filtering...

Also, next time, remove the IP from your post ;)

Two more things: On your guess of OS, 137,138,445 are a good indication that it is Windows, but could still be something running a Samba server, so you can't jump to conclusions; however, chances are it is Win2k or XP, for the simple reason that windows95/98/me do not use 445 as netbios...

Even if you do the above, it is still possible that you won't get a match, and that is what makes OS detection more of an art than a science, but if you do what I mentioned with permission, your results should improve. If you look at the part that they want you to submit, you can see clearly what they are using to check for the OS:

Quote:

---

T1(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)
T2(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T2(Resp=N)
T3(Resp=N)
T3(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)
T4(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T5(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)
T6(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T6(Resp=N)
T6(Resp=Y%DF=N%W=800%ACK=S%Flags=AR%Ops=WNMETL)
T7(Resp=Y%DF=N%W=800%ACK=S++%Flags=AR%Ops=WNMETL)
PU(Resp=N)

---

You might want to brush up on TCP/IP, connection establishment, and options to help you understand the stuff going on under the hood with nmap.

Good luck, and be sure to have permission!

/nebulus

lets clear it.... i do have permission.... secondly i m feeling very sleepy... had given my last paper in the morning and its 2:am here a hectic day...... this was just a post examination party ......

i did an unlimited scan and after some time found an HA cluster running... so it ****s my win box theory they do have a ms sql server monitor though........they also have a fortan debugger ...sometimes the obvious is not the right answer.....

secondly there is afire wall that i detected at some 40000+ port (whew) some csca firewall.. i think thatz enough for the day.........i did read the man and some other stuff too. the man page said about identifying a win box using fin and a null scan .......now no use.....the prob seems to be unpenetrable at this moment coz there is no way that out of 100distro i would be able to recognize this one with exact build......

its an art that ill have to master ... i would brush my tcp a bit before i go.... one last chance..

thanx guys

if had been windows then i would have woke up all night coz then odds are one out of three.. now the odds are crazy......

:)

addition :
i have a udp scan running

Hmm...snip from man nmap:

Quote:

---

-sF -sX -sN
Stealth FIN, Xmas Tree, or Null scan modes: There are
...
Unfortunately Microsoft (like usual) decided to
completely ignore the standard and do things their own
way. Thus this scan type will not work against systems
running Windows95/NT. On the positive side, this is a
good way to distinguish between the two platforms. If
the scan finds open ports, you know the machine is not
a Windows box. If a -sF,-sX,or -sN scan shows all
ports closed, yet a SYN (-sS) scan shows ports being
opened, you are probably looking at a Windows box.
This is less useful now that nmap has proper OS detec-
tion built in. There are also a few other systems that
are broken in the same way Windows is. They include
Cisco, BSDI, HP/UX, MVS, and IRIX. All of the above
send resets from the open ports when they should just
drop the packet.

---

/nebulus

PS. I also looked in Hacking Exposed, 3rd Ed. for a brief synopsis of the scans (I highly recommend this book):

Quote:

---

TCP connect scan: scan connects to the target port and complete full three-way handshake ... easily detected by target system.

TCP SYN scan: This technique is also called half-open scanning because a full TCP connection is not made. Instead, a SYN is sent to the target port. If a SYN/ACK is received from the target port, we can deduce that it is in the LISTENING state. If an RST/ACK is received, it usually indicates that the port is not listening. ... This technique has the advantage of being stealthier than a full TCP connect, and it may not be logged by the target system.

TCP FIN scan: This technique sends a FIN packet to the target port. Based on RFC 793, the target system should send back a RST for all closed ports. This technique usually only works on UNIX based TCP/IP stacks.

TCP Xmas Tree Scan: This technique sends a FIN, URG, PSH packet to the target port. Based on RFC 793, the target system should send back a RST for all closed ports.

TCP Null Scan: This technique turns off all flags. Based on RFC 793, the target system should send back a RST for all closed ports.

TCP Ack Scan: This technique is used to map out firewall rulesets. It can help determine if the firewall is a simple packet filter allowing only established connections (connections with the ACK bit set) or a stateful firewall performing advanced packet filtering. (my note: stateful)

TCP Windows Scan: This technique may detect open as well as filtered/nonfiltered ports on some systems (For example, AIX and FreeBSD) due to an anomaly in the way the TCP window size is reported.

TCP RPC Scan: This technique is specific to UNIX systems and is used to detect and identify Remote Procedure Call (RPC) ports and their associated program and version number.

UDP scan: This technique sends a UDP packet to the target port. If the target port responds with an "ICMP port unreachable" message, the port is closed. Concversely, if we don't receive an "ICMP port unreachable" message, we can deduce the port is open. Since UDP is known as a connectionless protocol, the accuracy of this technique is highly dependent on many factors related to the utilization of the network and system resources. In addition, UDP scanning is a very slow process if you are trying to scan a device that employs heavy packet filtering. If you plan on doing UDP scans over the Internet, be prepared for unreliable results.

---

nebulus

I have nmap and xprobe installed on my *nix box.
-To detect OS using nmap I used this command :
# nmap -vv -sS -0 www.example.org
-For xprobe :
# xprobe -v test.org
X probe ver 0.0.0.2
_________________
Interface : eth0/216.xx.yy.zz
LOG: Target: 10.xx.yy.zz.tt
LOG: Netmask:255.255.255
LOG: probing: 10.xx.yy.zz
LOG: (send)>>UDP to 10.xx.yy.zz:32132
LOG: [98 bytes] sent, waiting for response.
TREE: Sun Solaris 2.3-2.8! HP-UX 11.x!MAcOS 7.x-9.x
LOG: [send] >>ICMP time stamp request to 10.xx.yy.zz
LOG: [68 bytes] sent, waiting for response
FINAL: [Sun Solaris 2.3-2.8 ]

You can get this xprobe from http://www.sys-security.com

Cheerss

if only i had a *nix box ;)... ill definetly try this piece of code, the documentation seems pomising

thx

One question that I am concerned with nmap is that whenever i try to run OS detection (with permission of course) It says that I need Raw support.Any Suggestions on how to fix this would help , thanx.

ya it happens in win98 (read it on a site) they offered to update the win98 protocol stack from Ms site, i think searching would help, it also happens if u try to raw scan a host on win, on my 2k box it gave a warning that a raw scan may not work and it didnt ;).. i read something about it in detail while searching the insecure.com site..... ill post it if i remember.