Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-11-13 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

A loan offer or two

Published: 2006-11-13
Last Updated: 2006-11-13 18:38:43 UTC
by donald smith (Version: 1)
0 comment(s)
Today I received two loan offers which is unusual because I have not applied for any loans in years. When I first tried to resolve the site (~8:00 MDT) it failed. It has since come on line. The site is not rendering correctly in firefox It worked in Internet Explorer. At the bottom of their page they make it clear that they will send your information to "participating lenders" and that those lenders could call you even if your on the "do not call" list.
I suspect they are building a list for telemarketers. Also at the bottom of their page is a graphic that states "we are fully compliant with the can spam act of 2003". I removed the URL from the email because I don't wish to advertise for them. I modified the email headers to remove unimportant details and obstificate my email address.

Body of the loan offer 1:
"Thank you for your loan request, which we recieved yesterday,
we'd like to inform you that we are accepting your application, bad credit ok, We are ready to give you a $236,000 loan for a low month payment.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second form.

Body of load offer 2:
"Thank you for your loan request, which we recieved yesterday,
we'd like to inform you that we are accepting your application, bad credit ok, We are ready to give you a $234,000 loan for a low month payment.

Approval process will take only 1 minute.

Please visit the confirmation link below and fill-out our short 30 second form."


Header of the First email:

Received: from 105.12.117.87.donpac.ru (105.12.117.87.donpac.ru
[87.117.12.105])by mail.notmydomain (8/8) with ESMTP id
kADFeJhv023656for <NotMyEmail@notmydomain>; Mon, 13 Nov 2006 08:40:29 -0700 (MST)

Received: from 66.179.38.137 (HELO smtp3.harrisinfo.com)    by notmydomain
with esmtp (J.E5*P/Y,8@ XS,;)    id D2,237-/3J2I3-OH    for
NotMyEmail@notmydomain; Mon, 13 Nov 2006 15:34:57 -0180

From: "Meagan Howell" <akstcharrisinfomnsdgs@harrisinfo.com>
To: <NotMyEmail@notmydomain>
Subject: We accepted your loan request
<SNIP> 

Header from email 2:
Received: from ploy-433d4dd4c8 (ppp-124.121.125.171.revip2.asianet.co.th
[124.121.125.171])by mail.notmydomain (8/8) with ESMTP id
kADErFu6026071for <NotMyEmail@notmydomain>; Mon, 13 Nov 2006 07:53:19 -0700 (MST)

Received: from 194.2.3.145 (HELO smtp.oleane.net)    by notmydomain with esmt
(439O>US,1*K0 5L2V)    id ,5X4+H-IM**Y5-T'    for NotMyEmail@notmydomain;

Mon, 13 Nov 2006 14:53:18 -0420
Message-ID: <01c70733$74a1dd40$6c822ecf@akstcapcmmnsdgs>
From: "Marquita Rosenberg" <akstcapcmmnsdgs@apcm.fr>
To: <NotMyEmail@notmydomain>
Subject: Your loan request approved

<SNIP>

Keywords:
0 comment(s)

Packet Challenge: Fragments and a Blast from the Past

Published: 2006-11-13
Last Updated: 2006-11-13 17:44:50 UTC
by Johannes Ullrich (Version: 1)
0 comment(s)
This time around, packets from one of my own DNS servers. If you would like to follow along, you can find the full unobfuscated packet trace here.

(quick update... turns out that the router and DNS queries involved are part of www.nlnetlabs.nl, a network research labs that does experiment with DNS servers... so maybe this is all some side effect of an experiment they are running. Thanks to Don for pointing this out to me. After visiting their website, I did see a number of similar ICMP admin prohibited packets with flipped fragmentation bytes, but the embeded packet's source port was 80! ;-) )

You should find 9 packets. To abbreviate, I am using the following notation:
DNS = my DNS Server
Q = DNS Query Source
R = router sending ICMP Admin Prohibited messages.

Here the "big picture":
  Q  -> DNS: Query for NS sans.org
Q -> DNS: Query for A sans.org
DNS -> Q : Response, Server failure
DNS -> Q : Response, Server failure
Q -> DNS: Query for MX sans.org
DNS -> Q : Response, Server failure
R -> DNS: ICMP Admin prohibited
R -> DNS: ICMP Admin prohibited
R -> DNS: ICMP Admin prohibited
These are all the packets my system exchanged with these three systems at the time. Overall, this happened in about 0.13 second. The server failure was actually a temporary issue. The DNS server is authoritative for 'sans.org' and usually responds to these queries.

Lets look at the big picture first:
We got three DNS queries, three DNS responses and three "admin prohibited" packets. Kind of makes sense. A host is requesting information from our DNS server, but a (misconfigured?) router is rejecting the responses. The timing is a bit off (would have expected 'Query','Response','ICMP' ... 'Query','Response','ICMP'...). But this is not that unusual.

So lets look at the packets in detail. First the Query for 'NS sans.org':

Internet Protocol, Src: 213.154.224.17 (213.154.224.17), Dst: 70.91.145.9 (70.91.145.9)
Total Length: 65
Identification: 0x4aa5 (19109)
.0.. = Don't fragment: Not set
Time to live: 47
Protocol: UDP (0x11)
User Datagram Protocol, Src Port: 63417 (63417), Dst Port: domain (53)
Length: 45
Domain Name System (query)
Transaction ID: 0x3180
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
sans.org: type NS, class IN
Name: sans.org
Type: NS (Authoritative name server)
Class: IN (0x0001)
Additional records
: type OPT
Name:
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0


I removed some lines from the tethereal output. The packet looks "normal" withe the one exception of EDNS0 being used. EDNS0 is used to indicate to the receiving DNS server that the querying DNS server is able to receive more then 512 bytes of the response as a UDP packet. In this case, its 4k. A bit large, and frequently large EDNS0 packets are used to increase the amplification f or denial of service attacks.

Couple other things if you compare the packets:

  • the IP ID is incrementing. So these appear to be the only packets sent by the 'Q'.
  • the source port is constant... odd...
  • the DNS query IDs appear random.
Now lets look at the responses:

Internet Protocol, Src: 70.91.145.9 (70.91.145.9), Dst: 213.154.224.17 (213.154.224.17)

Flags: 0x04 (Don't Fragment)
Fragment offset: 0
User Datagram Protocol, Src Port: domain (53), Dst Port: 63417 (63417)
Length: 45
Transaction ID: 0x3180
Flags: 0x8002 (Standard query response, Server failure)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
sans.org: type NS, class IN
Name: sans.org
Type: NS (Authoritative name server)
Class: IN (0x0001)
Additional records
: type OPT
Name:
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x8000
Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
Bits 1-15: 0x0 (reserved)
Data length: 0

The response from my DNS server: well, nothing unusual here. I would like to point out that no fragmentation is used (well, there is no need to). The 'DF flag is set. The IPID is set to 0, which is typically for recent Linux kernels if the DF flag is set.

Now lets look at the ICMP packets. These are the packets that caused me to look at this issue in the first place. So far, we don't actually have much out of the ordinary. I am using the last ICMP packet here:
Internet Protocol, Src: 213.136.31.102 (213.136.31.102), Dst: 70.91.145.9 (70.91.145.9)
Total Length: 56
Identification: 0x0000 (0)
Time to live: 50
Internet Control Message Protocol
Type: 3 (Destination unreachable)
Code: 13 (Communication administratively filtered)

[decoded embedded packet from ICMP message]
 Internet Protocol, Src: 70.91.145.9 (70.91.145.9), Dst: 213.154.224.17 (213.154.224.17)
Total Length: 16640 (0x4100)
Identification: 0x0000 (0)
Flags: 0x00
Fragment offset: 512
Time to live: 50
Protocol: UDP (0x11)
Header checksum: 0xbb7b [incorrect, should be 0xba7c]
Good: False
Bad : True
Source: 70.91.145.9 (70.91.145.9)
Destination: 213.154.224.17 (213.154.224.17)
Data (8 bytes)

0000 00 35 f7 b9 00 2d 3b 8b .5...-;.

Now this is where the "blast from the past" shows up:

Fragment offset 512Bytes. If you look at the Flag/Fragment offset bytes: 00 40.. flip them and you end up with '40 00' or: no fragment offset and 'do not fragment' flag set. hm... interesting...

Now if we just forget for a moment that this packet claims to be fragmented, we see that the "payload" is actually a normal UDP header: Source port 53 and Destination port 63417. This is the same port we had as a source port earlier. So if you ignore the fragmentation issue, this kind of looks like the result to the DNS response we sent earlier. Even the TTLs work out right! But then again... the size of the packet is HUGE. Looks like another byte-order issue: a size of 0x41 (65 bytes) is much closer to the size of the packet we sent.

We had a case a couple years ago with a similar byte order issue. But this is odd in the sense that the spoofed packet appears to be a direct result of the real packet. The spoofed packet is very close to the real packet. Maybe its not actually spoofed but just "mangled" by some kind of in-line device?





Keywords:
0 comment(s)
Diary Archives