[Wolves] help - think I've been hacked

[James Turner]

On Friday 18 Jul 2003 5:06 pm, bambam@pineapple.shacknet.nu wrote:
> I need more information: What hardware have you got
> attatched to the box?
>
> Here is my run down of what's going on in these logs:
>
> Jul 17 09:10:56 tabby kernel: uhci.c: e800: host controller
> halted. very bad <-- the uhci is the universal host
> controller interface, and one of the interface types that
> runs USB. Unless you have critical stuff attatched to your
> USB ports, (like a usb cable modem) then this is not
> important. If it is then it is most likely a hardware
> failure either in the uhc itself, or the attatched device.
> It is unlikely to be an attack-related problem (note the use
> of the word: "Unlikely"). What kernel version do you have?

I agree that it is likely to indicate a hardware fault, probably unconnected 
with hacking activity directed towards the machine. However, just to be sure, 
what equipment is connected via USB? If the machine's Internet connection is 
NOT via a USB device then such messages are very unlikely to be relevant.

[IMHO log entries should state facts rather than opinions, and I'm somewhat 
dubious of the merit in including statements like "very bad" at the end of 
the message as above!]

> Jul 17 09:29:54 tabby kernel: SuSE-FW-DROP-DEFAULT IN=ppp0
> OUT= MAC=
>
> > SRC=217.56.254.131 DST=217.158.156.143 LEN=48 TOS=0x00
>
> PREC=0x00 TTL=120
>
> > ID=29683 DF PROTO=TCP SPT=1205 DPT=445 WINDOW=16384
>
> RES=0x00 SYN URGP=0
>
> > OPT (020405B401010402) <-- this is your suse firewall
>
> ruleset giving out rediculously verbose information about a
> packet it dropped. This packet appears to be a valid tcp
> connection request coming in over your modem. It doesn't say
> what port the request was on, and this information is
> suspicious in it's absence (ie - it was probably this
> information that the packet was dropped upon).

Actually it does give the info: SPT=Source port, DPT=Destination port. The 
source port is chosen by the connecting machine, specific to the individual 
connection/connection attempt. In this case it could probably be considered 
arbitrary (though there are often identifiable patterns/trends in the port 
numbers a client machine uses). The destination port (DPT) is generally 
specific to a particular service which "listens" for connections to that port 
(called a "well known" port number).

The items in between RES=.... and URGP=.... indicate the TCP flags that are 
set/unset for the packet. In this case the SYN (synchronise) flag is set and 
the other flags are unset, which indicates that the packet is the first 
packet involved in opening a new TCP connection - a request from client to 
server.

A destination port of TCP/445 (or UDP port 445, incidentally) is used on the 
server ("listening") end of NetBIOS over TCP/IP (NBT) communication in 
Windows 2000 and later. It is not used by earlier Windows versions. For more 
information see the following web page:

http://ntsecurity.nu/papers/port445/

A quick bout with Google reveals that Samba (which implements a file server 
and related facilities using NBT) can be set up to listen on either port 139 
or 445. In practice I suspect that it is generally always shipped so that it 
listens on port 139. When listening on port 445 only, the server would be 
inaccessible to pre-Windows 2000 clients.

> Messages like
> this are usually classed as "attempted reconnaisance" as
> someone is trying to poke around to see what you are
> running.

...or someTHING (ie a worm), automatically looking for new machines to infect 
to. I get quite a few packets to port 445 (which I drop) and I suspect that 
most of them come from worms that have infected Windows machines. I'd 
consider such packets as a hostile action, though not particularly worthy of 
concern unless in conjunction with other activity (as the packets are 
dropped).

> (probably this packet *should* have been routed
> over one of your interfaces to another, but was stopped by
> the kernel firewalling - hence the rediculously (and
> unnecessarily) cryptic suse name "SuSE-FW-DROP-DEFAULT" -
> the default rule of your forwarding table (or chain, or
> rule) is to drop the packet.

The packet is most likely intended to illicit a response from a Windows 
(2000/XP) machine which has been inadvertently set up such that NetBIOS 
communication is open to the Internet. (I wouldn't be suprised if this is the 
default, knowing Microsoft!).

You may be relieved that your log entry shows that the packet HAS been dropped 
(discarded/ignored by the kernel rather than being passed on to any process 
listening on port 445, or a "reset" packet being sent in reply if no process 
is listening). That is not to say that no other packets got through or that 
the dropping of this one doesn't allow the sender to draw certain 
conclusions. Whether or not this is likely would depend on your firewall 
configuration.

I am not familiar with the specifics of SuSE's firewall setup, but recommend 
checking the exact meaning of SuSE-FW-DROP-DEFAULT and 
SuSE-FW-UNAUTHORIZED-TARGET. The latter is non-obvious to me as someone not 
particularly used to the SuSE way of thinking.

> Jul 17 10:47:29 tabby kernel: SuSE-FW-UNAUTHORIZED-TARGET
> IN=ppp0 OUT=
>
> > MAC= SRC=195.8.69.184 DST=217.158.156.151 LEN=60 TOS=0x00
>
> PREC=0x00
>
> > TTL=62 ID=29479 PROTO=TCP SPT=110 DPT=1900 WINDOW=57344
>
> RES=0x00 ACK SYN
>
> > URGP=0 OPT (020405B4010303000101080A7E035B7A016367E8) <--

Port 1900 isn't listed in /etc/services and is probably the arbitrarily chosen 
client end of the connection (see above). A POP3 (Post Office Protocol 
version 3) server generally listens for connections to port 110. (POP3 is 
typically used for transfering e-mail messages from a mail server to a user's 
e-mail client software.)

The source address of the packet described above resolves to pop.clara.net and 
the destination address to du-069-0660.access.clara.net - your ISP's own POP3 
mail server and your own machine respectively. Looks like you were 
downloading your e-mail, which for some reason caused the packet to trigger a 
logging rule in the firewall. Not knowing the detail of the firewall setup I 
wouldn't know why the packet was logged or whether or not it was dropped, but 
it seems harmless enough to me - a false alarm.

Detailed description: Your machine probably sent an outgoing packet to the 
mail server immediately prior to this. The packet would be from 
du-069-0660.access.clara.net, TCP port 1900 to pop.clara.net port 110. The 
SYN flag would have been be set to indicate that a new connection is being 
requested. The mail server then responded by sending a packet back to port 
1900 on your machine, which is the packet logged above. The flags on this 
packet are are ACK and SYN (acknowledge/synchronise), a response to your 
previous outgoing packet confirming that the connection has now been 
established. In the normal sequence of events a "virtual circuit" between the 
machines would have been created, and both ends would continue by passing 
packets of data between your port 1900 and the server's port 110 in 
accordance with the POP3 protocol.

> this is roughly the same kind of thing. Again, stupid suse
> does not give a clear reason and we must all guess what
> "SuSE-FW-UNAUTHORIZED-TARGET" means. Presumably the
> destination address was not allowed to be reached, but it's
> difficult to tell without knowing more about your interfaces
> what this message is telling us.
>
> You did disconnect and reconnect between the two times of
> the firewalling messages, gaining a different IP from the
> dhcp pool of your isp. As such these two things are unlikely
> to be related (notice use of the word: "unlikely").

Agreed. Depends on the size of the DHCP address pool of course.


For the first packet quoted above (port 445) there's a good chance that the 
attacker was simply looking around for potentially weak machines in order to 
exploit and that Jayne's IP address was chosen arbitrarily. As the packet got 
dropped, they probably just moved on to look for a softer target.

> Having seen the firewall rules go off, presumably you got
> worried and re-installed your firewalling rules from script.
> (Jul 17 10:47:30 tabby SuSEfirewall2: Firewall rules
> successfully set from /etc/sysconfig/SuSEfirewall2) however,
> the timestamps are telling me something different - that
> happened one second after the second warning. Now - either
> the second warning was a false alert caused by running a
> firewalling script on a transceiving interface (when the
> firewall is "half-up" (half way through executing the
> script) there can be strange false-positives).
>
> So, a firewall rule triggered during a USB host controller
> device failure, and a false positive from a half-up firewall
> caused by executing a firewall script on a device that was
> up at the time? Probably. That's what I would interpret
> these logs as.
>
> *However* you need to be more sensitive to things going
> wrong now. Don't panic (even if you terminals start printing
> "all your dialup accounts are belong to us" repeatedly), but
> do try to keep up the good basic awareness that you have
> kept up till now.
>
> Please give me:

(...)

These two might be useful too:

iptables -L -v
iptables -L -v -t nat

> And give me your IP when you are next online (in the case of
> a modem) and I'll have an ethical (and authorized) poke
> around if you think you can trust me. After a short "poke
> around" I am in a better position to talk about the
> interface you present to the rest of the world (obviously).
>
> Hope this more verbose response helps
>
> bambam
>
> --
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
>
> On Thu, 17 Jul 2003, Jayne Heger wrote:
> > >    what makes you think you have been hacked ?
> > >This would give a good place to start looking.
> >
> > well, last night when I was looking at my logs, i.e. I press f10 I got
> > all this
> > I have copied and pasted the bits I think are relevant
> > Recently I had been having problems with my Smoothwall box (hardware
> > issue) so temporarily disconnected that and instead have been runninng
> > an iptables based SuSE's own firewall on my workstation. I do intend to
> > fix my Smoothie box and install a Debian server/firewall on it.
> > I know if I have been hacked I'll have to re-format and install
> > everything from scratch on my workstation.
> >
> > I am a paranoid person BTW and do get easily spooked. ;)
> >
> > Jul 17 03:59:00 tabby /USR/SBIN/CRON[29392]: (root) CMD ( rm -f
> > /var/spool/cron/lastrun/cron.hourly)
> > Jul 17 03:59:00 tabby kernel: uhci.c: e800: host controller halted. very
> > bad Jul 17 03:59:31 tabby last message repeated 2299 times
> > Jul 17 04:00:32 tabby last message repeated 4576 times etc...... (my
> > logs are full of last message repeated so many times)
> >
> > Jul 17 09:10:56 tabby ip-up: Warning: detected activated samba, enabling
> > FW_SERVICE_SMB!

I presume that this is some sort of firewall add-on, custom chain or userspace 
packet inspection tool related to Samba/SMB. Any SuSE experts care to 
enlighten us?

> > Jul 17 09:10:56 tabby ip-up: You still have to allow tcp port 139 on
> > internal, dmz and/or external.
> > Jul 17 09:10:56 tabby kernel: uhci.c: e800: host controller halted. very
> > bad
> >
> > Jul 17 09:29:54 tabby kernel: SuSE-FW-DROP-DEFAULT IN=ppp0 OUT= MAC=
> > SRC=217.56.254.131 DST=217.158.156.143 LEN=48 TOS=0x00 PREC=0x00 TTL=120
> > ID=29683 DF PROTO=TCP SPT=1205 DPT=445 WINDOW=16384 RES=0x00 SYN URGP=0
> > OPT (020405B401010402)
> > Jul 17 09:29:54 tabby kernel: uhci.c: e800: host controller halted. very
> > bad Jul 17 09:29:54 tabby last message repeated 23 times
> > Jul 17 10:47:29 tabby kernel: SuSE-FW-UNAUTHORIZED-TARGET IN=ppp0 OUT=
> > MAC= SRC=195.8.69.184 DST=217.158.156.151 LEN=60 TOS=0x00 PREC=0x00
> > TTL=62 ID=29479 PROTO=TCP SPT=110 DPT=1900 WINDOW=57344 RES=0x00 ACK SYN
> > URGP=0 OPT (020405B4010303000101080A7E035B7A016367E8)
> > Jul 17 10:47:29 tabby kernel: uhci.c: e800: host controller halted. very
> > bad Jul 17 10:47:30 tabby last message repeated 104 times

> > Jul 17 10:47:30 tabby SuSEfirewall2: Firewall rules successfully set
> > from /etc/sysconfig/SuSEfirewall2

As Bambam commented, it looks almost as if these log messages occured while 
the firewall was in the process of being set up. Ideally, the firewall script 
should load the entire iptables configuration in one go (iptables-restore 
command, acting on a file previously created with iptables-save), in order to 
avoid the brief moment where part of the ruleset is loaded and part of it 
isn't.

> > Jul 17 10:47:31 tabby kernel: uhci.c: e800: host controller halted. very
> > bad Jul 17 10:47:31 tabby last message repeated 5 times
> >
> > thanks
> >
> > Jayne

Unless there's any other evidence to the contrary, there's a good chance that 
you havn't actually been hacked after all. Of course, if you HAVE been hacked 
then the logs can't be fully trusted and could easily have been tampered 
with. The log extracts provided seem to contain:

 - One "hostile" packet blocked by the firewall
 - A packet from a POP3 session with your ISP's mail server. Logged for 
reasons unknown. Not possible to tell whether it's also been blocked.
 - Hardware fault with USB
 - Firewall scripts starting up (boot-up or runlevel change???)


James