Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Security > Rogue DHCP Lease... hacker?

Reply
Thread Tools

Rogue DHCP Lease... hacker?

 
 
dougga
Guest
Posts: n/a
 
      11-10-2004
donnie wrote:

> On Mon, 08 Nov 2004 23:42:42 -0800, dougga <(E-Mail Removed)>
> 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
 
Reply With Quote
 
 
 
 
dougga
Guest
Posts: n/a
 
      11-10-2004
>
> --------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
 
Reply With Quote
 
 
 
 
Moe Trin
Guest
Posts: n/a
 
      11-10-2004
In article <(E-Mail Removed)>, 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

 
Reply With Quote
 
Micheal Robert Zium
Guest
Posts: n/a
 
      11-11-2004
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.

 
Reply With Quote
 
dougga
Guest
Posts: n/a
 
      11-11-2004
Much thanks.

Moe Trin wrote:

> In article <(E-Mail Removed)>, 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


 
Reply With Quote
 
dougga
Guest
Posts: n/a
 
      11-11-2004
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


 
Reply With Quote
 
Bill Unruh
Guest
Posts: n/a
 
      11-12-2004
dougga <(E-Mail Removed)> writes:

]Much thanks.

]Moe Trin wrote:

]> In article <(E-Mail Removed)>, 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.



 
Reply With Quote
 
Micheal Robert Zium
Guest
Posts: n/a
 
      11-12-2004
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.

 
Reply With Quote
 
Moe Trin
Guest
Posts: n/a
 
      11-12-2004
In article <cn0vel$rkv$(E-Mail Removed)>, 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

 
Reply With Quote
 
dougga
Guest
Posts: n/a
 
      11-13-2004
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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
detect rogue DHCP server Chris Henderson Ruby 4 03-17-2009 09:10 PM
Wireless DHCP clients cannot obtain an IP address from the DHCP se =?Utf-8?B?SGVpbkQ=?= Wireless Networking 0 01-08-2006 03:41 PM
Prevent Rogue DHCP using CISCO 4500??? mostro Cisco 0 09-16-2005 01:39 AM
Switch Recommendation to prevent "rogue" DHCP? Steve Ames Cisco 2 05-15-2005 01:15 PM



Advertisments