full-disclosure - Odd packet?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.58.0405271945020.11706@damun.fork.ouz>
From: ouz at people.it (Valentino Squilloni - Ouz)
Subject: Odd packet?

On Wed, 26 May 2004, Mike Klinke wrote:

[...]
> > Even the OP didn't mentioned this.  I'm proned to believe those
> > packets have 127.0.0.1 as the source of the packets.
>
> You're correct. I thought I'd sent this to the list last night but
> didn't watch the to: field carefully enough on my reply.
>
> I don't know the mechanism but I think I know what you were
> seeing.  Here is an ethereal packet capture from the time.  We, too,
> were constantly seeing our ISP controlled perimeter router sending
> these packets to our internal equipment. The source MAC address here
> is the perimeter router (Cisco 1700) and the ISP was pretty much
> stumped over the cause.

[...]
> Internet Protocol, Src Addr: 127.0.0.1 (127.0.0.1),
>   Dst Addr: xxx.xxx.xxx.xxx (xxx.xxx.xxx.xxx)
> Time to live: 121
> Protocol: TCP (0x06)
>   Src Port: 80 (80), Dst Port: 1319 (1319),
>   Seq: 0, Ack: 986251265, Len: 0
> Source port: 80 (80)
> Destination port: 1319 (1319)
> Flags: 0x0014 (RST, ACK)

Ok.  It seems the case described.  A spoofed packet with your IP as the
source tries to connect to the compromised machine to port 80 at
localhost.  The compromised machine doesn't have a webserver listening at
127.0.0.1:80 so the tcp stack replyes ACK RST and sends this packet to
your spoofed address.