odd packets with 127.0.0.1:80 as source adres

I need some input from the infinite knowledge of AO :D

On our firewall we are receiving some odd packets. They originate on the Internet and are directed to our webservers. All packets have 127.0.0.1 port 80 as a source and all of them are RST packets. The source mac adres is our ISP router and the destination mac is our firewall. So i'm sure these are 'generated' outside our infrastructure. I've also contacted our ISP to ask them if they can spot anything funny on that router.

What could be generating these packets? Is it a badly configured router somewhere? Is it some clueless wannabee scanner?

BTW none of those packets will get through. They're all blocked on the firewall but it's going on for some time now and it's driving me nuts :confused:

Here's a capture of some of those packets (captured using tcpdump -n -e host 127.0.0.1) :

Code:

---

14:51:31.314480 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.17.1348: R 0:0(0) ack 1106706433 win 0
14:52:11.834661 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.15.1529: R 0:0(0) ack 716898305 win 0
14:52:13.121266 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.30.1551: R 0:0(0) ack 164888577 win 0
14:52:23.435843 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.28.1165: R 0:0(0) ack 1912864769 win 0
14:52:32.677496 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.13.1307: R 0:0(0) ack 110690305 win 0
14:52:33.836762 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.13.1609: R 0:0(0) ack 920846337 win 0
14:53:22.145970 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.14.1395: R 0:0(0) ack 112459777 win 0
14:53:27.828275 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.35.1988: R 0:0(0) ack 1490550785 win 0
14:53:39.791186 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.25.1783: R 0:0(0) ack 1848901633 win 0
14:54:02.720954 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.11.1344: R 0:0(0) ack 616824833 win 0
14:54:09.907746 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.37.1288: R 0:0(0) ack 1197867009 win 0
14:55:02.874700 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.37.1587: R 0:0(0) ack 1462173697 win 0
14:55:13.576690 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.12.1361: R 0:0(0) ack 1119289345 win 0
14:55:14.673549 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.11.1895: R 0:0(0) ack 1 win 0
14:55:20.060383 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.20.1435: R 0:0(0) ack 1955528705 win 0
14:55:26.276786 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.24.1531: R 0:0(0) ack 83689473 win 0
14:55:35.559046 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.10.1440: R 0:0(0) ack 428998657 win 0
14:55:44.766284 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.23.1400: R 0:0(0) ack 1 win 0
14:55:54.062842 0:a:b7:51:79:c0 0:e0:b6:5:f0:1b 0800 60: 127.0.0.1.80 > x.x.x.9.1542: R 0:0(0) ack 1623654401 win 0
14:56:05.658767 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.22.1946: R 0:0(0) ack 1925447681 win 0
14:56:15.016338 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.22.1967: R 0:0(0) ack 34668545 win 0
14:56:18.776838 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.12.1507: R 0:0(0) ack 946470913 win 0
14:56:49.728211 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.13.1495: R 0:0(0) ack 1901002753 win 0

---

Blind spoof of some type?

http://cert.uni-stuttgart.de/archive.../msg00013.html
http://forums.zonelabs.com/zonelabs/...essage.id=2194

Apparently you're not alone however. I'd hazard to guess that someone has made a new IP spoofing tool/worm that uses 127.0.0.1 for source ip and HTTP for port.

Quote:

---

14:55:13.576690 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.12.1361: R 0:0(0) ack 1119289345 win 0
14:55:14.673549 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.11.1895: R 0:0(0) ack 1 win 0
14:55:20.060383 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.20.1435: R 0:0(0) ack 1955528705 win 0
14:55:26.276786 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.24.1531: R 0:0(0) ack 83689473 win 0
14:55:35.559046 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.10.1440: R 0:0(0) ack 428998657 win 0
14:55:44.766284 0:a:b7:51:79:c0 0:e0:b6:5:f3:f3 0800 60: 127.0.0.1.80 > x.x.x.23.1400: R 0:0(0) ack 1 win 0

---

I went back to look at your capture (think you could get more and make it more verbose?). look at the packets I've bolded. Struck me as odd. (Old Sesame Street song comes to mind -- which one doesn't belong)

Sequence numbers are going way weird with the occassional "repeat" of sequence 1 and window size is 0 (?? what OS/Protocol uses a window size of 0)

Those looked odd to me too. They appear quite often but not really on a regular basis.
I'll see if I can capture some more. I'll also see if I can log the payload (if any).

Quote:

---

Originally posted here by MsMittens
Blind spoof of some type?

http://cert.uni-stuttgart.de/archive.../msg00013.html
http://forums.zonelabs.com/zonelabs/...essage.id=2194

Apparently you're not alone however. I'd hazard to guess that someone has made a new IP spoofing tool/worm that uses 127.0.0.1 for source ip and HTTP for port.

---

These look strangely familiar indeed. But for a blind spoof I would expect to see at least a couple of SYN packets and I only get RST packets.

A'ight. Did some more digging myself in the mean time and there's not a lot to be found about this. The only responses I saw where people brushing this off as a side effect of blaster attacking windowsupdate.com. The explaination is that some DNS servers (hosts file?) are (mis)configured to return 127.0.0.1 when queried for windowsupdate.com. That would stop the attack from ever reaching the intended site. Blaster then sends a SYN to 127.0.0.1:80 with a spoofed source and doesn't get very far. So far so good. I can understand that. Unfortunately the resulting RST packets are send to the spoofed address/ports, which happen to be ours. But why on earth are these RST packets with source address 127.0.0.1 routed to the rest of the world? Why does it even leave the infected machine? Seems odd. I cannot see any reason for responses to packets send to the loopback address to even be able to leave the local machine. Isn't localhost the only one able to send something to localhost? Or is this some tcp/ip stack implementation feature?

No feature I know of. I'm leaning towards new tool or something like that.. new scanner maybe? Checking to see what routers/switches let the packets through? New DoS (DDoS?)?

Right now, gut says this is not "expect" or part of an existing system but rather intended by a creator for a particular reason..

I may be way off base, but I've noticed that after running a program to capture what software is comunicating on what ports, I always get IE with an address of 127.0.0.1 port 80 sending packets back to my real address.

Looks like a spoof......but 127.0.0.1 shouldn't be routeable on the "internet"...somewhere from within the compnay bouncing around...........idk

MsMittens: A RST packet always has a windowsize of 0. The only time an RST packet would have a sequence number of 1 is when an existing connection is torn down.

danara: You can rest assured it's nothing I introduced myself. There isn't a windows machine anywhere near that connection. It's a segment with only networking equipment. There are no hosts on that segment.

shaded: I'm 100% sure it comes from our Internet connection and not the other way around. The source MAC address belongs to the ISP's router.

D'oh. Right.

Could be timeout from existing/previous connections and the firewall is closing it (don't think so but doing random thoughts on this one). Do the sequence numbers match for existing connections?

[isp router]------*----[firewall]------[webservers]

I'm sniffing the connection marked with a *.

The firewall will only allow connections on port 80 to the webservers. The webservers aren't able to communicate with the outside world. If there's something going out the firewall with an address of 127.0.0.1 I would have sniffed it.

But please keep stabbing, you might hit something I overlooked ;)

As Arthur Conan-Doyle said: "if you've eliminated all the possibilities, whatever is left, however improbable, must be the answer."

It look like blind scanning.

By using this kind of packet, some firewall may be fooled. The only part puzzle me, is how the scanner can get the information back. Maybe a second, legal, packet is sent to know if the sequence number bumped.

Forn: That's a darned unreliable form of scanning. The theory is based on an idle host scan where the host really is idle. On a busy network you aren't going to get any viable data by checking the sequence number because anyone or anything could have bumped it in the meantime.

I've been getting port scans from 127.0.0.1 as well. During the last half hour the scans have gone from port 1088, 1355, 1530 to 1517. Approximately an hour earlier the "Attack Type" showed an RST Attack from 127.0.0.1 in my Outpost log.

If anyone else has any further information regarding this subject, I'd appreciate hearing about it. Thanks so much.

V.

Hey SirDice, I've just started reading Hacking: Art of Exploitation and noticed in the networking chapter a section on "RST Hijacking".

Quote:

---

Source from Hacking: The Art of Exploitation, page 157

A very simple form of TCP/IP hijacking involves injecting an authentic-looking reset (RST) packet. If the source is spoofed and the acknowledgement number is correct, the receiving side will believe that the source actually sent the rest packet and reset the connection

---

Again a wild stab but could it be someone attempting something like this? It's suggested that someone could use tcpdump, awk and packet creation tool like nemisis for this.

You may have a point here MsMittens :) Does the destination port this RST get send to matter?


ISP is being a jurk and doesn't want to help. They say it could come from anywhere. They're not even going to trace it :(

I also did some more background checking. I found this article that talks about a loopback and multi-homed routing flaw in the TCP/IP stack. That pointed me to RFC-1122 section 3.2.1.3 which states:

Quote:

---

(g) { 127, <any> }

Internal host loopback address. Addresses of this form
MUST NOT appear outside a host.

---

This would mean that the 'side effect of Blaster' explanation cannot be true unless the windows tcp/ip stack is flawed.

Which wouldn't be the first time the TCP/IP Stack in Windows was flawed. Just because the address must not come from outside doesn't mean that the packet wouldn't be alterted. Changing the Source address is relatively easy (check the post I did in Addicts about netsed). I suspect that all TCP/IP stacks are flawed in that they acknowledge packets that physically coming from outside as being local (hence the reason that your firewall should defend against this).

As for the ISP I think it's more a matter of "we don't know enough, don't have the resources nor have we kept records" kind of thing. But that's my opinion.

when i read the message, i immediately thought of nmap's idlescan fuction. http://www.insecure.org/nmap/idlescan.html check the egreess filtering under idlescan challenges. It kinda of makes sense to do it this way, ecspesially if you are a .inc, since an admin might contact the spoofed ip, tell the admin of the spoofed ip what to look for, etc. hrmmm..... I wonder if it would be possible to code it so that more than one host can be used as a zombie to cover tracks even further.

The idle scan only seems to work if you spoof an actual existing address. I don't see the use in using 127.0.0.1 as a source with an idle scan. It may be part of a decoy though or as MsMittens noted an attempt to kill existing connections by guessing the sequence numbers.

I forgot about this thread.... Hogfly had something like this happen to him recently but it used something other then 127.0.0.1, but all the packets were RST packets. If I see him I will ask him to post what he found out.

without looking in to this post(I don't have time just right now) What I was seeing a while back was DoS backscatter from an irc network being DoS'ed offline. 127.0.0.1:80 seems more like a spoof attempt but I will take a better look later.
-hog

p.s. sirdice: run tcpdump -netttvXi next time. It'd help to have more info.

i came across the same thing using"iptraf' on my linux box seems to be something to do with loopback?or as they say a spoofed ip. must be one h*** of a program

Has anybody who's been reading this thread been looking at this one at Full Disclosure? I dunno why but I wonder if it's related or the same?!

Unfortunately I had to put this on hold because of the flu :( After that I had to do some code audits. If I have some time left I'll try and pick this up again. AFAIK this is still going on. I will try to capture some of the packets with the switches hogfly mentioned.

ok, this looks almost exactly like what I had seen. TCP ACK:RST's, matching/repeating sequence numbers etc etc. The fact that everything is coming from 127.0.0.1:80 is an indication. In my experience, everything was coming from one IP address(the victim of the DoS) and hitting numerous nodes across our campus. The 127.0.0.1 could be nothing more than the IP configuration of the machine in a dns zone on someones network. This screams of backscatter to me at this point ,and I would attribute it to that. Read the paper on the following link. It seems to fit the mold here.

http://www.caida.org/outreach/papers...security01.pdf

-hog


Msmittens: the blind tcp hijack/insertion technique I don't think applies here. The attack is more advanced than 90% of the people reading that list, and it wouldn't be as uniform and clean IMO in a packet dump. I think you would be able to see the the attempt in action. I could be wrong though.

Has anyone got any further explainations of this yet. There are many different posts all over the Internet, which I have been watching for over 2 years since I first started seeing the problem, I've read posts and arguments from some very smart people. I have not yet seen a definitive answer to the problem. In my case the attack is either from beyond the Default Gateway Router or from the ISP router itself (less likely).

The Linux server receiving the attacks correctly identifies them as a Martian Source (for those who don't know, it's an IP address seen where it shouldn't physically exist) I've included the syslog entry below, the dest IP has been changed to protect the innocent...

Sep 27 21:57:03 joepass kernel: martian source 217.X.X.X from 127.0.0.1, on dev eth0
Sep 27 21:57:03 joepass kernel: ll header: 00:04:75:7e:0b:e4:00:d0:ff:8d:f4:00:08:00

This shows the destination Mac (eth0) and the source Mac (default gateway) so not much info to be had there. The next thing I have to contribute is a packet dump from tcpdump. The actual command used was: tcpdump -ne -ttt -v -X -i eth0 src 127.0.0.1


000000 00:d0:ff:8d:f4:00 > 00:04:75:7e:0b:e4, ethertype IPv4 (0x0800), length 60: IP (tos 0x0, ttl 123, id 63314, offset 0, flags [none], length: 40) 127.0.0.1.80 > 217.x.x.x.1669: R [tcp sum ok] 0:0(0) ack 502530049 win 0
0x0000: 4500 0028 f752 0000 7b06 7517 7f00 0001 E..(.R..{.u.....
0x0010: d99e 7ac6 0050 0685 0000 0000 1df4 0001 ..z..P..........
0x0020: 5014 0000 b7a0 0000 0000 0000 0000 P.............
736091 00:d0:ff:8d:f4:00 > 00:04:75:7e:0b:e4, ethertype IPv4 (0x0800), length 60: IP (tos 0x0, ttl 123, id 63403, offset 0, flags [none], length: 40) 127.0.0.1.80 > 217.x.x.x.1038: R [tcp sum ok] 0:0(0) ack 1119682561 win 0
0x0000: 4500 0028 f7ab 0000 7b06 74d1 7f00 0001 E..(....{.t.....
0x0010: d99e 7ab3 0050 040e 0000 0000 42bd 0001 ..z..P......B...
0x0020: 5014 0000 9561 0000 0000 0000 0000 P....a........ssd


If anyone can shed any light on this, it's be great! No prizes for figuring the IP from the hex'

T.

im not really good at packets and IP but isnt 127.0.0.1 the computer's IP?

IE this comps ip is 24.XX.XXX.XXX and that is how it is seen online but to the computer itself it is seen as 127.0.0.1?

gonna blindly hit this but wouldnt that sugest that the computer is scanning its self?

I am unable to help on this problem, but feel bound to post this:

This is a good question, but you have used a VERY old thread to attach it to, it MIGHT have been better if you had linked to this thread from a new thread.

That said, this is still a valid post, so don't shoot him down too soon ............ :p
And Yes; the green is from me, as a sort of protection from random reds :D

[edit] hex: if you read the whole thread, you will see that it has been vexing folks for a LONG LONG time, or at the very least, they didn't come back with a definitive answer. [/edit]

[edit 2] Bliss is mine ........... MsM has said the same as ME...... only she got there first: Damn typewriting skills. [/edit 2]

Well, given this was never solved AFAIK, it's not a bad thing to bring this particular thread up. Perhaps Sir Dice can let us know if he did ever find a solution or identify what the source of all this was.

hexadecimal, did you read the whole thread?

I figured the old thread displayed the detail better, and since people often don't follow links to old threads they wouldn't have to...... that said, someone has already replied without reading the previous thread ;)

I used the tcpdump args requested by a previous poster to provide more details.

I've since read the follwing URL. Not sure if it throws any light on the subject:

http://securityresponse.symantec.com...ster.worm.html

Also there is a nother lengthy thread here:

http://www.dslreports.com/forum/rema...flat~days=9999

Which culminated in the following link:

http://groups.google.com/groups?q=g:...40pita.alt.net

Apologies if I broke any etiquette by dredging up an old thread.

T.

no i didnt have time...was at school doing some extra work after hours on my term paper and i swung buy...reading it now

Quote:

---

"Reroute windowsupdate.com to 127.0.0.1. This may result in lots of
RSTs on your network (Windows may send RSTs from 127.0.0.1 to the
spoofed addresses)"

---

Argh! This means windows doesn't follow RFC-1122 (see my previous post regarding rfc-1122). I'm not ready to believe that. I'll accuse MS from doing all sorts of stuff but most of the time they follow RFCs to the letter.

Unfortunately, I still haven't found anything :( And AFAIK it's still going on.

Quote:

---

Originally posted here by SirDice
The source mac adres is our ISP router

---

this is not something out of the normal. as the frame passes through your router it strips off the frae and then adds its own frame.

Quote:

---

Originally posted here by wassup
this is not something out of the normal. as the frame passes through your router it strips off the frae and then adds its own frame.

---

No ****?!? :D

I posted that info so everyone knows the packets are originating from the Internet and not from our own netwerk.