linux security wargame testing. interested? - Page 3
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 34

Thread: linux security wargame testing. interested?

  1. #21
    Senior Member
    Join Date
    Feb 2005
    Posts
    153
    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:
    # 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.

    # 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
    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.
    \"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.\"
    - Charles Darwin

  2. #22
    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
    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

  3. #23
    Senior Member
    Join Date
    Feb 2005
    Posts
    153
    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.
    \"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.\"
    - Charles Darwin

  4. #24
    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.
    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

  5. #25
    Senior Member
    Join Date
    Feb 2005
    Posts
    153
    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.
    \"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.\"
    - Charles Darwin

  6. #26
    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

    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.

  7. #27
    Senior Member
    Join Date
    Feb 2005
    Posts
    153
    Looks like you're running a silc server now...
    Correct, wanted to learn how to operate a SILC server and am loving it

    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.

    Is this OpenBSD Mr. Guardian?
    Don't quote me on that, your identd service appears to be from OpenBSD?
    Nope, it is not OBSD.

    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

  8. #28
    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>

  9. #29
    Senior Member
    Join Date
    Feb 2005
    Posts
    153
    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.
    \"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.\"
    - Charles Darwin

  10. #30
    Just a Virtualized Geek MrLinus's Avatar
    Join Date
    Sep 2001
    Location
    Redondo Beach, CA
    Posts
    7,324
    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.
    Goodbye, Mittens (1992-2008). My pillow will be cold without your purring beside my head
    Extra! Extra! Get your FREE copy of Insight Newsletter||MsMittens' HomePage

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

 Security News

     Patches

       Security Trends

         How-To

           Buying Guides