linux security wargame testing. interested?

Soda, do me a favor? Paste the command you used when scanning my server with Nmap, but omit the IP. That way people can see what you did to gather that information.

Closed a few unneeded services that you found via nmap, by editing a few lines in /etc/inetd.conf. Now, correct me if I'm wrong, but the inetd is considered the "super daemon" in that it handles the loading and controls towards the majority of all system daemons running on the system? Regardless, it's configuration on which services to load (or which services are loaded by inetd at least) is the /etc/inetd.conf

Changed:

Quote:

---

# chargen dgram udp wait root internal
time stream tcp nowait root internal
time dgram udp wait root internal
#

---

To comment-out the time service from loading. Ended up like this.

Quote:

---

# chargen dgram udp wait root internal
#time stream tcp nowait root internal
#time dgram udp wait root internal
#

---

To the uninitiated, a # in a configuration file usually means that it is a 'comment line'.

Example:
# The code below preforms a binary cmd5 checksum
code code code
blah blah

So basically we just commented out the time service from loading, both on tcp and udp. Also disabled the 'comsat' service, which seems to report the logged in user of incoming mail. Looks like it means incoming system mail versus IMAP or pop, per say. Also, reports are that it is very insecure, so I've disabled it from /etc/inetd.conf by commenting out it's UDP line, like I did with the time service. AFAIK, the 'time' service itself is not exploitable due to it's limited nature. Can anyone confirm this or find documentation (couldn't find it on a brief google) of the time service being a security hazard? Granted, even if it isn't I don't want to run services I won't need.

Also can't find much about the comsat service being insecure, besides people just saying that it is insecure. Any past history you guys have of it's insecurities?

A question for everyone though, I left the auth service enabled in inetd.conf because I can't seem to find a straight answer on what it does. It is based on TCP, and the config file says it is a n ident service used for net authentication. Authentication for what though? SMTP? Htto? SSHd? Anyone know what it's for, and if it is something I should disable or not? I won't be disabling it until I know for sure what it does, and what danger it poses to me. I've read a few places that servers like an IRC server would require it for user authentication. Possible that ftp and ssh would require it as well?

Also rebooted the server to reflect inetd configuration changes. Not sure how to restart the inetd daemon safely without just rebooting.

edit: found out how to restart inetd without a complete machine reboot:

1. Find the process number: ps -e | grep inetd

Quote:

---

root@tutorial:/etc# ps -e | grep inetd
873 ? 00:00:00 inetd

---

2. Kill the process number with a HUD signal: kill -HUP 873

Definition: -HUP signal The HUP syntax for the kill command will tell the process you identified (in this case, process 873) to murder all of it's children processes (the processes and services that it created/started). This means it will terminate time, comsat, and everything else it started, but the process you identified will remain intact. After it's killed all the children processes, it re-reads its configuration files and re-opens any log files. Then it spawns a new set of children and continues serving merrily on it's way.

nmap targetIP -O -P0

auth is to provide a degree of authentication through mapping local usernames to TCP network ports in use. Example is when a user logs into IRC, a request is sent to auth to retrieve the users current login name. Got that from an O'Reilly.

Nmap used to be able to enumerate services better with auth by showing you the owner of a service from a port scan. However it doesn't support -I anymore, like my other post.

So why were / are there 2 ports with sendmail?

results again

Quote:

---

Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-27 03:10 Central
Standard Time
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
Interesting ports on
(The 1650 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
80/tcp open http
113/tcp open auth
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
587/tcp open submission
1080/tcp filtered socks
1400/tcp filtered cadkey-tablet
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20

---

Thanks for the rescan and information on auth. Sounds like it might be required for sshd and ftpd after all.

Sendmail? Sendmail is running yes but I only see SMTP running. What is the second one you are speaking of? And to answer your question, sendmail was running because I did not turn it off during the default installation. I'll worry about turning off sendmail and SMTP tomorrow though. Things to get done today.

Anything you feel is exploitable so far? Comsat and time are the only two things I've changed from the default installation.

C:\>nc target 25
220 tutorial.localhost.org ESMTP Sendmail 8.13.3/8.13.3; Sat, 2 Jan 1999 07:47:2
8 -0700
^C
C:\>nc target 587
220 tutorial.localhost.org ESMTP Sendmail 8.13.3/8.13.3; Sat, 2 Jan 1999 07:47:4
2 -0700
^C

As far as being exploited, jidentd and cidentd have a reputation of vulnerability. I put a huge string into it, and it didn't throw any errors. However, when I put a small string into it, it throws an error:

C:\>nc target 113
asdf
0 , 0 : ERROR : UNKNOWN-ERROR

C:\>nc target 113
really long string
C:\>

########EDIT

Hello again

I found a vuln test for identd, and it's saying you're vulnerable! It's nothing major except private info though.

Quote:

---

Plugin ID: 152
Plugin name: identd detection
Plugin protocol: tcp
Plugin port: 113
Bug severity: Low
Bug affected: identd service
Bug not affected: Other services
Bug vulnerability class: Configuration

Bug description: The remote host is running an ident (also known as 'auth') daemon. The 'ident' service provides sensitive information to potential attackers. It mainly says which accounts are running which services. This helps attackers to focus on valuable services (thoseowned by root).

Bug response:

0 , 0 : ERROR : INVALID-PORT



Bug solution: The server should be deactivated or de-installed if not necessary. Under Unix systems, comment out the 'echo' line in /etc/inetd.conf and restart the inetd process. Try to prevent unwanted connection attempts by filtering traffic with firewalling.

Source CVE: CAN-1999-0629
Source Nessus ID: 10021


I doubt it was a buffer overflow but it could be if the service is old.

---

Tool I used was called attack tool kit.

Before you do anything about it, let me try to work with auth a little bit. I can't get what's outlined in the RFC's to work.
http://www.faqs.org/rfcs/rfc1413.html

Soda, very very interesting. Keep pecking away at auth and tell me what you get. Also, I need you to actuall try and exploit that identd bug. Because if it's a false positive then that isn't going to help us.

Looks like you're running a silc server now...

And why are you running mail on 2 ports!?!? Or am I missing something really stupid.

As for the identd testing... if I had time and a good lead on where to start, I'd go for it. There are nix tools for scanning it, identfp is one, but I don't have the means of running it right now. I'll see if it runs on cygwin later.

Is this OpenBSD Mr. Guardian? :)
Don't quote me on that, your identd service appears to be from OpenBSD?

nmap target -sV -sR -P0 -vv -O

Quote:

---

Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-27 14:47 Central
Standard Time
Initiating SYN Stealth Scan against target () [1663 ports] at 14:47
Discovered open port 113/tcp on target
Discovered open port 25/tcp on target
Discovered open port 22/tcp on target
Discovered open port 80/tcp on target
Discovered open port 706/tcp on target
Discovered open port 587/tcp on target
The SYN Stealth Scan took 11.63s to scan 1663 total ports.
Initiating service scan against 6 services on target
(target) at 14:47
The service scan took 101.16s to scan 6 services on 1 host.
For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
Host target (target) appears to be up ... goo
d.
Interesting ports on target (target):
(The 1649 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.3/8.13.3
80/tcp open http Apache httpd 1.3.33 ((Unix))
113/tcp open ident OpenBSD identd
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
587/tcp open smtp Sendmail 8.13.3/8.13.3
706/tcp open silc
1080/tcp filtered socks
1400/tcp filtered cadkey-tablet
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux 2.4.0 - 2.5.20
OS Fingerprint:
TSeq(Class=RI%gcd=1%SI=29F236%IPID=Z%TS=100HZ)
T1(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16A0%ACK=S++%Flags=AS%Ops=MNNTNW)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RIPCK=E%UCK=F%ULEN=134%DAT=E)

Uptime 0.442 days (since Sun Feb 27 04:12:52 2005)
TCP Sequence Prediction: Class=random positive increments
Difficulty=2748982 (Good luck!)
TCP ISN Seq. Numbers: 7CE2B3FE 7C594659 7D09673B 7CBB987A 7CFD07AE 7C6CD364
IPID Sequence Generation: All zeros

Nmap finished: 1 IP address (1 host up) scanned in 114.984 seconds
Raw packets sent: 1738 (69.8KB) | Rcvd: 1682 (77.8KB)

C:\nmap>

---

A couple of questions for everyone. How does nmap get uptime, and how did it determine that identd was from OpenBSD? The RFC's don't talk about getting a banner of any kind.

Quote:

---

Looks like you're running a silc server now...

---

Correct, wanted to learn how to operate a SILC server and am loving it :)

Quote:

---

And why are you running mail on 2 ports!?!? Or am I missing something really stupid.

---

I don't think it's actually running on two ports. I think you have normal SMTP and them a subsystem of sendmail for some reason. I'll look more into it.

Quote:

---

Is this OpenBSD Mr. Guardian? :)
Don't quote me on that, your identd service appears to be from OpenBSD?

---

Nope, it is not OBSD.

Quote:

---

A couple of questions for everyone. How does nmap get uptime, and how did it determine that identd was from OpenBSD? The RFC's don't talk about getting a banner of any kind.

---

There is a option field in the tcp header. There are lots of different options you can choose between, (these you can read about in for example RFC 1323). One of these options are Timestamp. There is no what I know of "must" how to implement the timestamp option, but to citate Richard Stevens:

"4.4BSD increments (and linux similar) the timestamp clock once every 500 ms and this timestamp clock is reset to 0 on a reboot"

"The timestamp is a monotonically increasing value. Since the receiver echoes what it receives, the receiver doesn't care what the timestamp units are. This option does not require any form of clock synchronization between the two hosts. RFC 1323 recommends that the timestamp value increment by one between 1 ms and 1 second."


I have completely disabled my server from reporting uptime by running the command:

Code:

---

echo 0 >> /proc/sys/net/ipv4/tcp_timestamps

---

This will set the variable in tcp_timestamps to 0, effectively turning off the RFC 1323 TCP uptime reporting. Scan me again and see if uptime is still reported.

edit: I also added that echo command to /etc/rc.d/rc.local so that it will automagically tell the kernel to not report it if/when the server needs to reboot, since the setting isn't saved upon reboot. Granted, this feels like a horrible hack, but I bet the true setting is within the kernel configuration. I'll look into that later

Quote:

---

C:\nmap>nmap target -sV -sR -P0 -vv -O

Starting nmap 3.81 ( http://www.insecure.org/nmap ) at 2005-02-27 15:28 Central
Standard Time
Initiating SYN Stealth Scan against target [1663 ports] at 15:28
Discovered open port 22/tcp on target
Discovered open port 80/tcp on target
Discovered open port 25/tcp on target
Discovered open port 113/tcp on target
Discovered open port 587/tcp on target
The SYN Stealth Scan took 15.64s to scan 1663 total ports.
Initiating service scan against 5 services on target) at 15:28
The service scan took 5.22s to scan 5 services on 1 host.
For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
Insufficient responses for TCP sequencing (0), OS detection may be less accurate

For OSScan assuming port 22 is open, 1 is closed, and neither are firewalled
Insufficient responses for TCP sequencing (3), OS detection may be less accurate

Host target appears to be up ... good.
Interesting ports on target:
(The 1650 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.9p1 (protocol 1.99)
25/tcp open smtp Sendmail 8.13.3/8.13.3
80/tcp open http Apache httpd 1.3.33 ((Unix))
113/tcp open ident OpenBSD identd
135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
587/tcp open smtp Sendmail 8.13.3/8.13.3
1080/tcp filtered socks
1400/tcp filtered cadkey-tablet
No exact OS matches for host (If you know what OS is running on it, see http://w
ww.insecure.org/cgi-bin/nmap-submit.cgi).
TCP/IP fingerprint:
SInfo(V=3.81%P=i686-pc-windows-windows%D=2/27%Tm=42223B8B%O=22%C=1)
TSeq(Class=RI%gcd=1%SI=2649B3%IPID=Z%TS=U)
T1(Resp=Y%DF=Y%W=16D0%ACK=O%Flags=A%Ops=)
T1(Resp=Y%DF=Y%W=16D0%ACK=S++%Flags=AS%Ops=MNW)
T2(Resp=N)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=16D0%ACK=O%Flags=A%Ops=)
T3(Resp=Y%DF=Y%W=16D0%ACK=S++%Flags=AS%Ops=MNW)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RIPCK=E%UCK=F%ULEN=134%DAT=E)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RIPCK=E%UCK=F%ULEN=134%DAT=E)


IPID Sequence Generation: All zeros

Nmap finished: 1 IP address (1 host up) scanned in 34.625 seconds
Raw packets sent: 1766 (71.5KB) | Rcvd: 1738 (83.6KB)

C:\nmap>

---

Good! No more uptime reporting :)

Now, I'm disabling the sendmail daemon since I will not be hosting a mail server. Went into /etc/rc.d/rc.M and checked to see how it loaded up sendmail.

Code:

---

# Start the sendmail daemon:
if [ -x /etc/rc.d/rc.sendmail ]; then
  . /etc/rc.d/rc.sendmail start
fi

---

What this means, is if rc.sendmail is set with permissions to be executable, then run the rc.sendmail daemon script. So, all I had to do was turn off executable permissions on the rc.sendmail script. But before that, let's turn off the sendmail daemon.

I also shut off the sendmail service manually, so I wouldn't need to reboot.

Code:

---

/etc/rc.d/rc.sendmail stop

---

Now with that done, let's make sure sendmail doesn't autoload on next reboot.

Code:

---

chmod 644 /etc/rc.d/rc.sendmail

---

Doing that will turn off executable capability for root, the root group, and everyone else. And will only allow read access to root group and everyone else, but read AND write to root. This will stop the service from autoloading.

GA, based on an experience I did on a linux "abuse" box, you might want to remove sendmail completely. Eventhough they weren't running a SMTP server (it wasn't a running service) it could still be locally vulnerable (not sure to what point your security level/desire is) as it's often used for mail between users locally.