Rogue DHCP Lease... hacker?

Discussion in 'Computer Security' started by dougga, Nov 4, 2004.

  1. dougga

    dougga Guest

    I've been investigating a strange lease on one of my DHCP servers that as
    far as I can tell should not be there for any legitimate reason.

    Here are the logs from the server:
    2004:11:01-12:46:32 (none) dhcpd: DHCPDISCOVER from 4d:c8:43:bb:8b:a6 via
    eth0
    2004:11:01-12:46:33 (none) dhcpd: DHCPOFFER on 10.1.255.254 to
    4d:c8:43:bb:8b:a6 (detective)

    In my investigation I've run into several people who have seen this exact
    MAC address and many reports of this same host name, "detective".

    I'm beginning to suspect a hacker or a worm of some kind.

    Here are links to some of the folks who have reported similar findings:

    http://archives.neohapsis.com/archives/openbsd/2004-06/1581.html
    http://www.ixus.net/resume_messages.php?topic=13792 [in French]
    http://www.experts-exchange.com/Networking/Q_21070857.html

    Can anyone help shed some light on this?
    If you have access to your company's dhcp server, you might take a quick
    look at the logs. Perhaps I'm missing something in an RFC somewhere.

    Much thanks for any help

    D
    dougga, Nov 4, 2004
    #1
    1. Advertising

  2. dougga

    donnie Guest

    On Wed, 03 Nov 2004 23:47:05 -0800, dougga <>
    wrote:

    >I've been investigating a strange lease on one of my DHCP servers that as
    >far as I can tell should not be there for any legitimate reason.
    >
    >Here are the logs from the server:
    >2004:11:01-12:46:32 (none) dhcpd: DHCPDISCOVER from 4d:c8:43:bb:8b:a6 via
    >eth0
    >2004:11:01-12:46:33 (none) dhcpd: DHCPOFFER on 10.1.255.254 to
    >4d:c8:43:bb:8b:a6 (detective)
    >
    >In my investigation I've run into several people who have seen this exact
    >MAC address and many reports of this same host name, "detective".
    >
    >I'm beginning to suspect a hacker or a worm of some kind.
    >
    >Here are links to some of the folks who have reported similar findings:
    >
    >http://archives.neohapsis.com/archives/openbsd/2004-06/1581.html
    >http://www.ixus.net/resume_messages.php?topic=13792 [in French]
    >http://www.experts-exchange.com/Networking/Q_21070857.html
    >
    >Can anyone help shed some light on this?
    >If you have access to your company's dhcp server, you might take a quick
    >look at the logs. Perhaps I'm missing something in an RFC somewhere.
    >
    >Much thanks for any help
    >
    >D

    ##############################
    I assume all that is happening on a wireless network. Look at the
    following URL,
    http://216.239.41.104/search?q=cach...spoof.pdf mac address spoofing&hl=en&ie=UTF-8

    See if that helps.
    donnie
    donnie, Nov 4, 2004
    #2
    1. Advertising

  3. dougga

    dougga Guest

    donnie wrote:

    > On Wed, 03 Nov 2004 23:47:05 -0800, dougga <>
    > wrote:
    >
    >>I've been investigating a strange lease on one of my DHCP servers that as
    >>far as I can tell should not be there for any legitimate reason.
    >>
    >>Here are the logs from the server:
    >>2004:11:01-12:46:32 (none) dhcpd: DHCPDISCOVER from 4d:c8:43:bb:8b:a6 via
    >>eth0
    >>2004:11:01-12:46:33 (none) dhcpd: DHCPOFFER on 10.1.255.254 to
    >>4d:c8:43:bb:8b:a6 (detective)
    >>
    >>In my investigation I've run into several people who have seen this exact
    >>MAC address and many reports of this same host name, "detective".
    >>
    >>I'm beginning to suspect a hacker or a worm of some kind.
    >>
    >>Here are links to some of the folks who have reported similar findings:
    >>
    >>http://archives.neohapsis.com/archives/openbsd/2004-06/1581.html
    >>http://www.ixus.net/resume_messages.php?topic=13792 [in French]
    >>http://www.experts-exchange.com/Networking/Q_21070857.html
    >>
    >>Can anyone help shed some light on this?
    >>If you have access to your company's dhcp server, you might take a quick
    >>look at the logs. Perhaps I'm missing something in an RFC somewhere.
    >>
    >>Much thanks for any help
    >>
    >>D

    > ##############################
    > I assume all that is happening on a wireless network. Look at the
    > following URL,
    >

    http://216.239.41.104/search?q=cach...spoof.pdf mac address spoofing&hl=en&ie=UTF-8
    >
    > See if that helps.
    > donnie


    donnie wrote:

    > I assume all that is happening on a wireless network.   Look at the
    > following URL,
    >

    http://216.239.41.104/search?q=cach...spoof.pdf mac address spoofing&hl=en&ie=UTF-8
    >
    > See if that helps.
    > donnie


    Donnie,

    Thanks for the response. The article you've fond is a good overview of
    wireless vulnerabilities but I don't see a relationship to my post.
    Neither the mac address nor the word 'detective' shows up in the article.

    As for my topology, no, I do not have a wireless network on this network.
    I have a robust hardware firewall with reasonably sophisticated intrusion
    detection mechanism in place.

    This is why I'm puzzled as to this machine showing up on my internal
    interface/network to gain a DHCP lease.

    If you have information pertaining to what this might mean with specific
    reference to the others around the world who have seen BOTH this mac
    address and machine name, I would very much appreciate any help.

    Much thanks,

    ~Doug
    dougga, Nov 5, 2004
    #3
  4. dougga

    dougga Guest

    Hacker on internal net: DHCP

    I've been investigating a strange lease on one of my DHCP servers that as
    far as I can tell should not be there for any legitimate reason.

    Here are the logs from the server:
    2004:11:01-12:46:32 (none) dhcpd: DHCPDISCOVER from 4d:c8:43:bb:8b:a6 via
    eth0

    2004:11:01-12:46:33 (none) dhcpd: DHCPOFFER on 10.1.255.254 to
    4d:c8:43:bb:8b:a6 (detective)

    In my investigation I've run into several people who have seen this exact
    MAC address and many reports of this same host name, "detective".  
    I'm beginning to suspect a hacker or a worm of some kind.

    Here are links to some of the folks who have reported similar findings:
    http://archives.neohapsis.com/archives/openbsd/2004-06/1581.html
    http://www.ixus.net/resume_messages.php?topic=13792 [in French]
    http://www.experts-exchange.com/Networking/Q_21070857.html

    Can anyone help shed some light on this?
    If you have access to your company's dhcp server, you might take a quick
    look at the logs.  Perhaps I'm missing something in an RFC somewhere.

    Much thanks for any help

    D
    dougga, Nov 6, 2004
    #4
  5. dougga

    donnie Guest

    On Fri, 05 Nov 2004 13:41:55 -0800, dougga <>
    wrote:

    >Donnie,
    >
    >Thanks for the response. The article you've fond is a good overview of
    >wireless vulnerabilities but I don't see a relationship to my post.
    >Neither the mac address nor the word 'detective' shows up in the article.
    >
    >As for my topology, no, I do not have a wireless network on this network.
    >I have a robust hardware firewall with reasonably sophisticated intrusion
    >detection mechanism in place.
    >
    >This is why I'm puzzled as to this machine showing up on my internal
    >interface/network to gain a DHCP lease.
    >
    >If you have information pertaining to what this might mean with specific
    >reference to the others around the world who have seen BOTH this mac
    >address and machine name, I would very much appreciate any help.
    >
    >Much thanks,

    #########################
    As far as I know, MAC address spoofing can be done on a wired network
    too. It was some years ago before wireless became popular that I heard
    about it. I searched the MAC address that you posted and one in one
    of the other URLs in one of the MAC address vendor locator sites and
    neither one showed up. I don't think the idea is to find an exact MAC
    address or machine name match because it can be made to say anything.
    If your network is totally wired, I would start looking for a tojan.
    Also, what OSes, IDS, firewall are you ruuning, server, clients,
    services, etc....?
    If it's a windows based network, do the event logs say anything?
    donnie
    donnie, Nov 6, 2004
    #5
  6. dougga

    Moe Trin Guest

    Re: Hacker on internal net: DHCP

    In article <>, dougga wrote:

    >I've been investigating a strange lease on one of my DHCP servers that as
    >far as I can tell should not be there for any legitimate reason.


    Is the host still there? Use a network sniffer to confirm/deny. How
    big is your net? Are you using coax, or twisted pair? If twisted pair,
    are you using a hub, or switch? If a switch, which port does the
    switch say this MAC address is on? You posted using KNode, which is
    part of KDE - try using nmap to look for that hardware.

    >2004:11:01-12:46:32 (none) dhcpd: DHCPDISCOVER from 4d:c8:43:bb:8b:a6 via
    >eth0


    [compton ~]$ etherwhois 4d:c8:43
    Non-existent address as of Oct 31 09:26:22 MST 2004 OUI file
    [compton ~]$

    The address has not been assigned by IEEE, so it's a forgery by
    someone. http://standards.ieee.org/regauth/oui/oui.txt

    Old guy
    Moe Trin, Nov 7, 2004
    #6
  7. dougga

    dougga Guest

    Re: Hacker on internal net: DHCP

    Moe Trin wrote:

    > In article <>, dougga wrote:
    >
    >>I've been investigating a strange lease on one of my DHCP servers that as
    >>far as I can tell should not be there for any legitimate reason.

    >
    > Is the host still there? Use a network sniffer to confirm/deny. How
    > big is your net? Are you using coax, or twisted pair? If twisted pair,
    > are you using a hub, or switch? If a switch, which port does the
    > switch say this MAC address is on? You posted using KNode, which is
    > part of KDE - try using nmap to look for that hardware.
    >
    >>2004:11:01-12:46:32 (none) dhcpd: DHCPDISCOVER from 4d:c8:43:bb:8b:a6 via
    >>eth0

    >
    > [compton ~]$ etherwhois 4d:c8:43
    > Non-existent address as of Oct 31 09:26:22 MST 2004 OUI file
    > [compton ~]$
    >
    > The address has not been assigned by IEEE, so it's a forgery by
    > someone. http://standards.ieee.org/regauth/oui/oui.txt
    >
    > Old guy


    That's good information, it adds further clout to the conspiracy theories.

    The interesting thing is that others around the world have seen the exact
    match between this MAC and dhcp station name.

    Much thanks
    dougga, Nov 9, 2004
    #7
  8. dougga

    dougga Guest

    donnie wrote:

    > On Fri, 05 Nov 2004 13:41:55 -0800, dougga <>
    > wrote:
    >
    >>Donnie,
    >>
    >>Thanks for the response. The article you've fond is a good overview of
    >>wireless vulnerabilities but I don't see a relationship to my post.
    >>Neither the mac address nor the word 'detective' shows up in the article.
    >>
    >>As for my topology, no, I do not have a wireless network on this network.
    >>I have a robust hardware firewall with reasonably sophisticated intrusion
    >>detection mechanism in place.
    >>
    >>This is why I'm puzzled as to this machine showing up on my internal
    >>interface/network to gain a DHCP lease.
    >>
    >>If you have information pertaining to what this might mean with specific
    >>reference to the others around the world who have seen BOTH this mac
    >>address and machine name, I would very much appreciate any help.
    >>
    >>Much thanks,

    > #########################
    > As far as I know, MAC address spoofing can be done on a wired network
    > too. It was some years ago before wireless became popular that I heard
    > about it. I searched the MAC address that you posted and one in one
    > of the other URLs in one of the MAC address vendor locator sites and
    > neither one showed up. I don't think the idea is to find an exact MAC
    > address or machine name match because it can be made to say anything.
    > If your network is totally wired, I would start looking for a tojan.
    > Also, what OSes, IDS, firewall are you ruuning, server, clients,
    > services, etc....?
    > If it's a windows based network, do the event logs say anything?
    > donnie


    OSes on my internal net:

    Windows Server 2003 - new install for testing only
    SMB - Named - kitchen sink that comes standard
    SuSE 9.1pro - server
    SMB - NFS - VNC - NTPd - Rsync
    SuSE 9.1pro/WinXP pro - Workstation nearly always Linux

    SuSE 9.1pro/WinXP pro - rarely used
    SuSE 9.1pro - server - rarely used

    Firewall: Astaro Security Linux - v5
    DHCPD -
    Proxies: HTTP DNS SMTP POP
    Firewall event logs just show the lease being established. That's it.

    THanks for any info.
    dougga, Nov 9, 2004
    #8
  9. dougga

    Moe Trin Guest

    In article <>, dougga wrote:

    >OSes on my internal net:


    >Windows Server 2003 - new install for testing only


    >SuSE 9.1pro - server


    >SuSE 9.1pro/WinXP pro - Workstation nearly always Linux


    >SuSE 9.1pro/WinXP pro - rarely used
    >SuSE 9.1pro - server - rarely used


    OK - for those four Linux installations - SuSE is 'rpm' based, so you
    can use that to look over the systems. You can also dig up a copy of
    'chkrootkit' but take the information with a ten kilogram block of salt,
    especially on SuSE, which does some things differently. The cut below is
    a 'canned' response to a suspected Linux system compromise. Read it all
    the way through before trying it. Also look at the man page for rpm for
    further details.

    >Firewall: Astaro Security Linux - v5
    > DHCPD -
    > Proxies: HTTP DNS SMTP POP


    Just curious - with five systems on the net, why are you using DHCP? I'm
    not familiar with Astaro, other than knowing it's a German development.
    If it's rpm based, you can try the stuff below. You may also be able to
    run chkrootkit on it. If Astaro is Debian based (using the Debian package
    manager apt), see if there is a 'debsums' program (debsums -s can be used
    in the same way as rpm -V).

    In the future, look at the 'tripwire' program - that won't help now, because
    you don't have a virgin system snapshot to compare against.

    --------rpm -V trick--------------
    OK, bring the box up single user. Move (repeat, MOVE, not copy) /bin/ps to
    some safe place, and copy any other file to /bin/ps

    /bin/mv /bin/ps /bin/ps.original
    /bin/cp /etc/services /bin/ps

    OK, do you see what I've just done? Note: if you are not permitted to move
    /bin/ps, use the '/usr/bin/lsattr /bin/ps' command to see if the -i flag is
    set. If it is, the game is over, You can use 'usr/sbin/chattr -i /bin/ps'
    command to reset the immutable bit, but this was a SURE sign that your box
    is 0wn3d.

    Now use the rpm command to see what happens.

    /bin/rpm -V procps

    and watch that rpm freaks out when it discovers that /bin/ps is not what
    /bin/ps should be. See the rpm man page for an explanation of the flags.

    SM5....T /bin/ps

    Now, before you do _anything_ else, move /bin/ps.original back to /bin/ps.
    When I did this originally, I was so happy that it worked the way it did,
    that I forgot to do the move. Two hours later, I discovered that I could
    not su, strace, etc. And I wasn't root any more. Oops! (I was able to go to
    another virtual terminal and log in there as root). Remember to use the
    MOVE ( /bin/mv ), not copy, command, to avoid messing with the file date
    stamps.

    NOTE: I illustrate this test using /bin/ps, but you can use _ANY_ program
    that a script kiddie is likely to replace. These include /bin/login,
    /bin/ls, /usr/bin/top, /usr/bin/find, /usr/bin/diff, and so on, or even
    /bin/bash itself. You _do_ need to know what rpm package the file you
    changed came in. Use 'rpm -qf /name/of/file' to get that information.

    If rpm doesn't report problems, your box is toast. Wipe it and reload from
    scratch. You may be able to salvage /home/, but after reinstalling, I would
    do a find for root owned files or directories and unknown groups and users
    in /home before bringing it back online.

    find /home/ \( -user 0 -o -group 0 \) -exec ls -lad {} \;
    find /home/ \( -nouser -o -nogroup \) -exec ls -lad {} \;

    If rpm does indeed freak out, then do a global test.

    /bin/rpm -Va > files_2_check

    NOTE: This rpm -Va does not ensure that your box is not otherwise subverted.
    What it _does_ do is to tell you if find, ls, lsmod, fuser, ps, and so on
    are probably not bogus. This test does not check files installed by means
    other than rpm, which is why you need find, and so on. Obviously, you should
    also install _all_ applicable updates, too. Remember, this check does NOT
    check /etc/passwd, /etc/shadow, /etc/inetd.conf (xinetd in RH7.0+), so you
    have to inspect those files manually to see if there is something "new".
    Look specifically at the last lines of these files.

    One significant point to CAUTION you about is FALSE ALARMS. Even a brand new
    box just installed is going to have something pop into files_2_check. On
    this work-station, that file lists 92 items, about 40 of which are /dev/
    with permission/ownership changes. About 20 more are normal configuration
    files like /etc/hosts.allow (you _did_ set that, didn't you???)

    If you are properly paranoid, you will keep copies of rpm and the rpm
    database (in /var/lib/rpm/) off line, or on a different computer. Also, just
    to feel good, I run this check (as root) weekly.
    --------end rpm -V trick -------------

    Old guy
    Moe Trin, Nov 9, 2004
    #9
  10. dougga

    donnie Guest

    On Mon, 08 Nov 2004 23:42:42 -0800, dougga <>
    wrote:

    >OSes on my internal net:
    >
    >Windows Server 2003 - new install for testing only
    > SMB - Named - kitchen sink that comes standard
    >SuSE 9.1pro - server
    > SMB - NFS - VNC - NTPd - Rsync
    >SuSE 9.1pro/WinXP pro - Workstation nearly always Linux
    >
    >SuSE 9.1pro/WinXP pro - rarely used
    >SuSE 9.1pro - server - rarely used
    >
    >Firewall: Astaro Security Linux - v5
    > DHCPD -
    > Proxies: HTTP DNS SMTP POP
    > Firewall event logs just show the lease being established. That's it.
    >
    >THanks for any info.

    #######################
    The first thing that stands out in my mind is SMB. Go to
    http://web.textfiles.com/hacking/
    and d/l The MH Desk Reference (MH = Modern Hackers)
    There is a lot on SMB and it's vulnerabilities.
    donnie.
    donnie, Nov 10, 2004
    #10
  11. dougga

    dougga Guest

    donnie wrote:

    > On Mon, 08 Nov 2004 23:42:42 -0800, dougga <>
    > wrote:
    >
    >>OSes on my internal net:
    >>
    >>Windows Server 2003 - new install for testing only
    >> SMB - Named - kitchen sink that comes standard
    >>SuSE 9.1pro - server
    >> SMB - NFS - VNC - NTPd - Rsync
    >>SuSE 9.1pro/WinXP pro - Workstation nearly always Linux
    >>
    >>SuSE 9.1pro/WinXP pro - rarely used
    >>SuSE 9.1pro - server - rarely used
    >>
    >>Firewall: Astaro Security Linux - v5
    >> DHCPD -
    >> Proxies: HTTP DNS SMTP POP
    >> Firewall event logs just show the lease being established. That's
    >> it.
    >>
    >>THanks for any info.

    > #######################
    > The first thing that stands out in my mind is SMB. Go to
    > http://web.textfiles.com/hacking/
    > and d/l The MH Desk Reference (MH = Modern Hackers)
    > There is a lot on SMB and it's vulnerabilities.
    > donnie.



    Thanks Donnie,

    The issue here is that someone is on the net not specifically whether they
    have compromised one of my machines. The area I'd like to focus on for
    protection is the network barrier not the machine barrier. Thus I have
    been comfortable using SMB, NFS and other easily exploitable protocols on
    my own network.

    Now that I find that someone HAS been on my net, I have to look at scenarios
    of machine compromising. I have reinstalled my two most critical machines
    completely de novo just to be sure.

    Cheers

    ~D
    dougga, Nov 10, 2004
    #11
  12. dougga

    dougga Guest

    >
    > --------rpm -V trick--------------
    > OK, bring the box up single user. Move (repeat, MOVE, not copy) /bin/ps to
    > some safe place, and copy any other file to /bin/ps
    >
    > /bin/mv /bin/ps /bin/ps.original
    > /bin/cp /etc/services /bin/ps
    >
    > OK, do you see what I've just done? Note: if you are not permitted to move
    > /bin/ps, use the '/usr/bin/lsattr /bin/ps' command to see if the -i flag
    > is set. If it is, the game is over, You can use 'usr/sbin/chattr -i
    > /bin/ps' command to reset the immutable bit, but this was a SURE sign that
    > your box is 0wn3d.
    >
    > Now use the rpm command to see what happens.
    >
    > /bin/rpm -V procps
    >
    > and watch that rpm freaks out when it discovers that /bin/ps is not what
    > /bin/ps should be. See the rpm man page for an explanation of the flags.
    >
    > SM5....T /bin/ps
    >
    > Now, before you do _anything_ else, move /bin/ps.original back to /bin/ps.
    > When I did this originally, I was so happy that it worked the way it did,
    > that I forgot to do the move. Two hours later, I discovered that I could
    > not su, strace, etc. And I wasn't root any more. Oops! (I was able to go
    > to
    > another virtual terminal and log in there as root). Remember to use the
    > MOVE ( /bin/mv ), not copy, command, to avoid messing with the file date
    > stamps.
    >
    > NOTE: I illustrate this test using /bin/ps, but you can use _ANY_ program
    > that a script kiddie is likely to replace. These include /bin/login,
    > /bin/ls, /usr/bin/top, /usr/bin/find, /usr/bin/diff, and so on, or even
    > /bin/bash itself. You _do_ need to know what rpm package the file you
    > changed came in. Use 'rpm -qf /name/of/file' to get that information.
    >
    > If rpm doesn't report problems, your box is toast. Wipe it and reload from
    > scratch. You may be able to salvage /home/, but after reinstalling, I
    > would do a find for root owned files or directories and unknown groups and
    > users in /home before bringing it back online.
    >
    > find /home/ \( -user 0 -o -group 0 \) -exec ls -lad {} \;
    > find /home/ \( -nouser -o -nogroup \) -exec ls -lad {} \;
    >
    > If rpm does indeed freak out, then do a global test.
    >
    > /bin/rpm -Va > files_2_check
    >
    > NOTE: This rpm -Va does not ensure that your box is not otherwise
    > subverted. What it _does_ do is to tell you if find, ls, lsmod, fuser, ps,
    > and so on are probably not bogus. This test does not check files installed
    > by means other than rpm, which is why you need find, and so on. Obviously,
    > you should
    > also install _all_ applicable updates, too. Remember, this check does NOT
    > check /etc/passwd, /etc/shadow, /etc/inetd.conf (xinetd in RH7.0+), so you
    > have to inspect those files manually to see if there is something "new".
    > Look specifically at the last lines of these files.
    >
    > One significant point to CAUTION you about is FALSE ALARMS. Even a brand
    > new box just installed is going to have something pop into files_2_check.
    > On this work-station, that file lists 92 items, about 40 of which are
    > /dev/ with permission/ownership changes. About 20 more are normal
    > configuration files like /etc/hosts.allow (you _did_ set that, didn't
    > you???)
    >
    > If you are properly paranoid, you will keep copies of rpm and the rpm
    > database (in /var/lib/rpm/) off line, or on a different computer. Also,
    > just to feel good, I run this check (as root) weekly.
    > --------end rpm -V trick -------------
    >
    > Old guy


    Greetings Old Guy,

    I'm interested and somewhat confused by what this does and doesn't tell me
    about my machines.

    How thorough do you think this is given what hackers are doing out there?
    I really am not a forensics expert, but would like to figure this out.

    This seems to be pretty good for looking for changes to system-installed
    packages. That at least sounds pretty thorough. In practice, though, I'd
    venture to guess that this can easily be gotten around by pointing existing
    system apps to alternative (compromised) files not otherwise examined by
    this method. What do you think?

    Much thanks.

    ~D
    dougga, Nov 10, 2004
    #12
  13. dougga

    Moe Trin Guest

    In article <>, dougga wrote:

    >I'm interested and somewhat confused by what this does and doesn't tell me
    >about my machines.


    The 'rpm -V' mechanism was originally meant to uncover user blunders. By
    itself, it is not foolproof, but you can use it to gain confidence.

    >How thorough do you think this is given what hackers are doing out there?
    >I really am not a forensics expert, but would like to figure this out.


    That's why you first test rpm by "altering" a critical file, and seeing
    if rpm detects the switch. And yes, once the system passes a 'rpm -Va'
    test, you then need to use the tools that you now have some confidence
    in, to rigorously test the rest of the stuff - for example, using find
    to locate new or newly altered files/directories, files with owners you
    never heard of, executables located in unusual places.

    >This seems to be pretty good for looking for changes to system-installed
    >packages. That at least sounds pretty thorough.


    It's relatively crude - looking at relatively obvious tests. The main
    advantage is that the baseline information already exists without any
    action of the user or admin. There are MUCH superior tools available,
    but they require action _before_ a problem exists. Carrying the idea
    to an extreme, think about making an exact copy of your hard disk (to
    an identical disk that is normally not installed). You can now run a
    bit-by-bit comparison of your current disk with the archive. VERY
    tedious, and probably boring, but done right, it will detect all bad
    stuff. However, this requires that you made that clean copy _BEFORE_
    stuff happened. For a less rigorous test, look at the common Intrusion
    Detections Systems (IDS) like 'tripwire'.

    >In practice, though, I'd venture to guess that this can easily be gotten
    >around by pointing existing system apps to alternative (compromised)
    >files not otherwise examined by this method.


    Think about that. How would the system apps be redirected and not
    detected? First, look at your PATH environment. NOTE: I'm assuming a
    Bash or at least Bourne shell in the stuff that follows - a C shell
    like csh or tcsh will have some differences.

    [compton ~]$ echo $PATH
    /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/ibuprofin/bin
    [compton ~]$

    Here, the shell will first look for INTERNAL shell commands (at a shell
    prompt, type 'enable' and 'alias' to see what these might be), then
    look in /usr/local/bin to find any commands that the local administrator
    may have added. If the command isn't found, the system then checks (in
    order) the three standard system directories, before looking in the
    optionally defined bin directory of the individual. Root's PATH should
    _ALWAYS_ have the system directories before any local directories, and
    should NEVER have the 'current' directory (.) in the PATH.

    Now, it's _possible_ for someone who has gained root on your box to FOR
    EXAMPLE put compromised commands normally lower in the PATH (/usr/bin/foo)
    into directories higher in the path (/bin/foo or /usr/local/bin/foo in
    this example), and that would get around the 'rpm -V' check because the
    uncompromised binary is still there where it should be. The solution
    for that is trivial - long before I got a 'root' account, the instructors
    I had, and the mentors used to pound on my head to always use the full
    command name (/bin/ls, not just ls) when doing ANYTHING as root. That
    also avoids the 'alias' problem. Likewise, any scripts or programs that
    you may create should ALWAYS use full command names, or at least set the
    PATH in the script/program. That's actually a good idea anyway.

    >What do you think?


    The UNIX gods have been out there for a while, and there is decades of
    experience in their methods, and method in their madness.

    Old guy
    Moe Trin, Nov 10, 2004
    #13
  14. Re: Rogue DHCP Lease... hacker?

    dougga wrote:

    >Windows Server 2003


    There is your culprit. Had the same thing happen to me when I was
    (beta) testing it about a year or so ago.
    Micheal Robert Zium, Nov 11, 2004
    #14
  15. dougga

    dougga Guest

    Much thanks.

    Moe Trin wrote:

    > In article <>, dougga wrote:
    >
    >>I'm interested and somewhat confused by what this does and doesn't tell me
    >>about my machines.

    >
    > The 'rpm -V' mechanism was originally meant to uncover user blunders. By
    > itself, it is not foolproof, but you can use it to gain confidence.
    >
    >>How thorough do you think this is given what hackers are doing out there?
    >>I really am not a forensics expert, but would like to figure this out.

    >
    > That's why you first test rpm by "altering" a critical file, and seeing
    > if rpm detects the switch. And yes, once the system passes a 'rpm -Va'
    > test, you then need to use the tools that you now have some confidence
    > in, to rigorously test the rest of the stuff - for example, using find
    > to locate new or newly altered files/directories, files with owners you
    > never heard of, executables located in unusual places.
    >
    >>This seems to be pretty good for looking for changes to system-installed
    >>packages. That at least sounds pretty thorough.

    >
    > It's relatively crude - looking at relatively obvious tests. The main
    > advantage is that the baseline information already exists without any
    > action of the user or admin. There are MUCH superior tools available,
    > but they require action _before_ a problem exists. Carrying the idea
    > to an extreme, think about making an exact copy of your hard disk (to
    > an identical disk that is normally not installed). You can now run a
    > bit-by-bit comparison of your current disk with the archive. VERY
    > tedious, and probably boring, but done right, it will detect all bad
    > stuff. However, this requires that you made that clean copy _BEFORE_
    > stuff happened. For a less rigorous test, look at the common Intrusion
    > Detections Systems (IDS) like 'tripwire'.
    >
    >>In practice, though, I'd venture to guess that this can easily be gotten
    >>around by pointing existing system apps to alternative (compromised)
    >>files not otherwise examined by this method.

    >
    > Think about that. How would the system apps be redirected and not
    > detected? First, look at your PATH environment. NOTE: I'm assuming a
    > Bash or at least Bourne shell in the stuff that follows - a C shell
    > like csh or tcsh will have some differences.
    >
    > [compton ~]$ echo $PATH
    > /usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/home/ibuprofin/bin
    > [compton ~]$
    >
    > Here, the shell will first look for INTERNAL shell commands (at a shell
    > prompt, type 'enable' and 'alias' to see what these might be), then
    > look in /usr/local/bin to find any commands that the local administrator
    > may have added. If the command isn't found, the system then checks (in
    > order) the three standard system directories, before looking in the
    > optionally defined bin directory of the individual. Root's PATH should
    > _ALWAYS_ have the system directories before any local directories, and
    > should NEVER have the 'current' directory (.) in the PATH.
    >
    > Now, it's _possible_ for someone who has gained root on your box to FOR
    > EXAMPLE put compromised commands normally lower in the PATH (/usr/bin/foo)
    > into directories higher in the path (/bin/foo or /usr/local/bin/foo in
    > this example), and that would get around the 'rpm -V' check because the
    > uncompromised binary is still there where it should be. The solution
    > for that is trivial - long before I got a 'root' account, the instructors
    > I had, and the mentors used to pound on my head to always use the full
    > command name (/bin/ls, not just ls) when doing ANYTHING as root. That
    > also avoids the 'alias' problem. Likewise, any scripts or programs that
    > you may create should ALWAYS use full command names, or at least set the
    > PATH in the script/program. That's actually a good idea anyway.
    >
    >>What do you think?

    >
    > The UNIX gods have been out there for a while, and there is decades of
    > experience in their methods, and method in their madness.
    >
    > Old guy
    dougga, Nov 11, 2004
    #15
  16. dougga

    dougga Guest

    Re: Rogue DHCP Lease... hacker?

    Micheal Robert Zium wrote:

    > dougga wrote:
    >
    >>Windows Server 2003

    >
    > There is your culprit. Had the same thing happen to me when I was
    > (beta) testing it about a year or so ago.



    Michael,

    Do you know of any documentation that confirms this?
    This is mighty strange behavior for a production server.

    ~Doug
    dougga, Nov 11, 2004
    #16
  17. dougga

    Bill Unruh Guest

    Re: Rogue DHCP Lease... hacker?

    dougga <> writes:

    ]Much thanks.

    ]Moe Trin wrote:

    ]> In article <>, dougga wrote:
    ]>
    ]>>I'm interested and somewhat confused by what this does and doesn't tell me
    ]>>about my machines.
    ]>
    ]> The 'rpm -V' mechanism was originally meant to uncover user blunders. By
    ]> itself, it is not foolproof, but you can use it to gain confidence.

    Well, anyway. rpm -V compares teh md5 hash on the installed programs vs the
    hash when they were installed. Any changes mean the file has changed.
    It is possible for a very knowledgeable hacker to change the stored
    original value.

    ]>
    ]>>This seems to be pretty good for looking for changes to system-installed
    ]>>packages. That at least sounds pretty thorough.
    ]>
    ]> It's relatively crude - looking at relatively obvious tests. The main

    It is very uncrude. IF the md5 hash has changed, the file has changed.
    Period.

    ]> advantage is that the baseline information already exists without any
    ]> action of the user or admin. There are MUCH superior tools available,
    ]> but they require action _before_ a problem exists. Carrying the idea
    ]> to an extreme, think about making an exact copy of your hard disk (to
    ]> an identical disk that is normally not installed). You can now run a
    ]> bit-by-bit comparison of your current disk with the archive. VERY
    ]> tedious, and probably boring, but done right, it will detect all bad
    ]> stuff. However, this requires that you made that clean copy _BEFORE_
    ]> stuff happened. For a less rigorous test, look at the common Intrusion
    ]> Detections Systems (IDS) like 'tripwire'.

    Tripwire does nothing more than rpm -V does. The only disadvantage of rpm
    -V is keeping the rpm database secure. But that is the same problem as with
    tripwire.
    Bill Unruh, Nov 12, 2004
    #17
  18. Re: Rogue DHCP Lease... hacker?

    dougga wrote:

    >Micheal Robert Zium wrote:
    >
    >> dougga wrote:
    >>
    >>>Windows Server 2003

    >>
    >> There is your culprit. Had the same thing happen to me when I was
    >> (beta) testing it about a year or so ago.

    >
    >
    >Michael,
    >
    >Do you know of any documentation that confirms this?
    >This is mighty strange behavior for a production server.


    No. I remember seeing it show up in my DHCP leases file and I
    remember thinking it was really weird. I did find where I posted
    about it in May of 2003:

    >Has anyone seen this in their DHCP lease logs?
    >lease 192.168.1.112 {
    > starts 5 2003/05/02 11:55:08;
    > ends 5 2003/05/02 11:57:08;
    > hardware ethernet e9:eb:b3:a6:db:3c;
    > uid 01:e9:eb:b3:a6:db:3c;
    > client-hostname "detective";
    >I had been playing with RC2 and later noticed this after running
    >the network discovery wizard. Note the two-minute lease and the
    >bogus MAC address.


    No one knew anything about it then either. I just chalked it up to a
    temporary virtual device used by the Network Discovery Wizard.
    Micheal Robert Zium, Nov 12, 2004
    #18
  19. dougga

    Moe Trin Guest

    Re: Rogue DHCP Lease... hacker?

    In article <cn0vel$rkv$>, Bill Unruh wrote:

    >Well, anyway. rpm -V compares teh md5 hash on the installed programs vs the
    >hash when they were installed. Any changes mean the file has changed.


    True. It also compares size, permissions, ownership, and mtime.

    >It is possible for a very knowledgeable hacker to change the stored
    >original value.


    True - same for size. That's why I state it is crude.

    >It is very uncrude. IF the md5 hash has changed, the file has changed.
    >Period.


    If the md5 has has NOT changed, the file _MAY_ still have been changed,
    as you say above. That trick has been around for a while.

    >Tripwire does nothing more than rpm -V does.


    [compton ~]$ rpm -qf /etc/fstab
    file /etc/fstab is not owned by any package
    [compton ~]$ rpm -qlf /etc/passwd | wc -l
    15
    [compton ~]$ rpm -Vf /etc/passwd
    S.5....T c /etc/hosts.allow
    S.5....T c /etc/hosts.deny
    S.5....T c /etc/motd
    S.5....T c /etc/printcap
    S.5....T c /etc/profile
    ...?..... c /etc/securetty
    S.5....T c /etc/services
    [compton ~]$ id
    uid=214(ibuprofin) gid=100(users) groups=100(users)
    [compton ~]$

    That's just a couple of examples. Notice that /etc/passwd (and /etc/group)
    are NOT flagged, and you can bet your last penny that /etc/passwd and
    /etc/group have been changed from what the package creator set up, 'cause
    I really doubt the packager included that username/UID. And here, tripwire
    has most certainly been configured to monitor files that rpm has heard of
    but ignores, but ALSO files that were not installed by rpm, and therefore
    are unknown to it.

    >The only disadvantage of rpm -V is keeping the rpm database secure. But
    >that is the same problem as with tripwire.


    As for keeping the databases secure, that's relatively easy - you keep the
    secure versions (the ones you would use when the paranoia level has been
    increased for some reason) on some removable or remote (isolated) media.

    Old guy
    Moe Trin, Nov 12, 2004
    #19
  20. dougga

    dougga Guest

    Re: Rogue DHCP Lease... hacker?

    Micheal Robert Zium wrote:

    > dougga wrote:
    >
    >>Micheal Robert Zium wrote:
    >>
    >>> dougga wrote:
    >>>
    >>>>Windows Server 2003
    >>>
    >>> There is your culprit. Had the same thing happen to me when I was
    >>> (beta) testing it about a year or so ago.

    >>
    >>
    >>Michael,
    >>
    >>Do you know of any documentation that confirms this?
    >>This is mighty strange behavior for a production server.

    >
    > No. I remember seeing it show up in my DHCP leases file and I
    > remember thinking it was really weird. I did find where I posted
    > about it in May of 2003:
    >
    >>Has anyone seen this in their DHCP lease logs?
    >>lease 192.168.1.112 {
    >> starts 5 2003/05/02 11:55:08;
    >> ends 5 2003/05/02 11:57:08;
    >> hardware ethernet e9:eb:b3:a6:db:3c;
    >> uid 01:e9:eb:b3:a6:db:3c;
    >> client-hostname "detective";
    >>I had been playing with RC2 and later noticed this after running
    >>the network discovery wizard. Note the two-minute lease and the
    >>bogus MAC address.

    >
    > No one knew anything about it then either. I just chalked it up to a
    > temporary virtual device used by the Network Discovery Wizard.


    I think you're right.
    Rebooting the server caused all kinds of duplicate dhcp leases (on a machine
    with a fixed IP address)... then two leases by "Detective" as described
    above.

    Microsoft uses very crude tools to achieve their goals... so what's new.

    Thanks for the help.

    ~Doug

    PS: I think I'll block packets from a certain MAC address from traversing
    the firewall from here on out.
    dougga, Nov 13, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Luc D.B.

    DHCP lease on an interface ?

    Luc D.B., Feb 22, 2004, in forum: Cisco
    Replies:
    1
    Views:
    2,727
  2. Tom
    Replies:
    3
    Views:
    1,800
    No Spam Sorry
    Jun 11, 2004
  3. Tim Kettring

    DHCP Lease expiration ?

    Tim Kettring, Feb 2, 2004, in forum: MCSE
    Replies:
    5
    Views:
    16,400
    Tim Kettring
    Feb 3, 2004
  4. JohnH.
    Replies:
    4
    Views:
    25,548
    JohnH.
    Feb 8, 2006
  5. Replies:
    1
    Views:
    1,021
    Aaron Leonard
    Feb 8, 2006
Loading...

Share This Page