Tài liệu Network Mapping / Information Gathering pptx

Trang 1

Network Mapping / Information Gathering

• This is the reconnaissance section

We will examine a number of

traces where the would-be attacker

is trying to gather information to

target a specific exploit.

– Host by host scanning

– Broadcast scanning

– Infrastructure scanning

Hello, and welcome to the Network Mapping and Information Gathering section of the course The purpose of this section is to show you many different methods that attackers will use in order to perform reconnaissance on your network and systems

Trang 2

Host Scanning TCP Port 110 – POP3

This scan looks for a single service, but on many hosts.

Let us start off by talking about host-by-host scanning, where an attacker issues packets to a number

of hosts on the targeted network to probe for presence of potential victims

Many of the traces we have looked at have been port scans A port scan is when an attacker checks for various services on one host Another common tactic is the host scan; this is when an attacker scans many hosts for one service

Please note that the attacker whose scan is shown on this slide appears to have knowledge of the 14 subnet, and the attacker is scanning only active hosts This would serve as an indicator that the attacker has already done reconnaissance In this case, the attacker is doing a host scan for TCP port

110, usually associated with POP3

Trang 3

Sequential Countup Using ICMP Echo Requests

[Using ICMP Echo Requests]

01:00:38 pingmapper > 192.168.6.1: icmp: echo request

This may appear very trivial, but when a ping gets more

than one reply, attackers know they have found

a subnetwork.

We have already introduced the concept of network mapping This example shows an attacker pinging each address in a subnet in order ICMP echo requests should be blocked at the firewall or filtering router in most environments, which would protect against this type of scan

An ICMP echo request scan is a great way for an attacker to identify broadcast addresses on your subnet, if you permit ICMP echo requests into your network and ICMP echo replies out of your network Any address that returns multiple echo replies from one ping is probably a broadcast address So if your network is using variable length subnet masks, this technique can identify those subnets

Trang 4

ICMP Echo Request

23:14:11 normalping > normal: icmp: echo request

4500 0054 5336 0000 ff01 6a70 7f00 0001 7f00 0001 0800 1e15 2263 0000 13ca 0339 b181 0400 0809 0a0b 0c0d 0e0f 1011 1213

an 8-byte timestamp and a fill pattern The FreeBSD ping packet on this slide follows the

convention (Detect and analysis by Andrew Korty, GCIA)

The 20 octet IP header is grayed out; immediately after it is the 8-byte ICMP header, shown in bold The first two bytes of the ICMP header, 0800, are the type and code for an echo request (type 8, code 0) After that is 1e15, the checksum Next is 2263, the identifier, which is normally the process ID

of the sending process on Unix The last part of the ICMP header is 0000, which is a sequence number that normally starts at 0 The next 8 octets, italicized above, is the timestamp You will notice that the rest of the packet consists of increasing hex values from 08 through 37, which is the fill pattern

Trang 5

ICMP Echo Request (2)

195.61.132.6 > 128.210.67.55: icmp: echo request (DF)

4500 0028 7873 4000 f101 0614 c33d 840680d2 4337 0800 656a beef dead 3901 885d

0008 6f87 80d2 4337 0000 0000 0000

195.61.132.6 > 128.210.67.74: icmp: echo request (DF)

4500 0028 7873 4000 f101 0601 c33d 840680d2 434a 0800 5928 beef dead 3901 885d

Trang 6

ICMP Payload Change

in Large Scan

63.98.234.3 > good.guys.net.163: icmp: echo request

4500 001c 70ac 0000 1e01 ca65 3f62 ea03

**** 66a3 0800 8d3f 3bbd 2f03 23f8 6673

5010 0c00 b3ce 0000 0000 0000 0000 63.98.234.3 > good.guys.net.164: icmp: echo request

4500 001c a01c 0000 1e01 9af4 3f62 ea03

**** 66a4 0800 883f 3bbd 3403 c37a 0000

0001 0000 0000 0000 0133 0332 3334 63.98.234.3.62287 > good.guys.net.163.80: ack

Detect by George Bakos

Trang 7

The packet shown in this slide is asking the target system to answer with the version of BIND that it

is running If an attacker sends a packet like this one to a DNS name server, and that server responds with its BIND version, then the attacker can use the appropriate exploit to compromise the server Notice that two octets have been highlighted: byte 12 (value 07) and byte 20 (value 04)

In the detect below, we have a slight variation of this packet from the same attacking host You will notice that the second packet still has the 07 value in the 13th octet into the packet (byte 12) and the

04 value another 8 octets later (byte 20) This will be detected by the standard Snort ruleset There

is still one more variation of this attack that you see sometimes, which is almost the same as these and is yet another version query, but it has the byte pattern “00 0010 0008”

05/24-14:56:53.166333 213.1.248.131:3575 -> z.y.w.98:53 UDP TTL:49 TOS:0x0ID:63647 Len: 38

4B 2B 01 80 00 01 00 00 00 00 00 00 07 76 65 72 K+ ver

73 69 6F 6E 04 62 69 6E 64 00 00 10 00 03 sion.bind

If your host responds to this query, this is not a good sign There is a good chance it will be

compromised shortly thereafter

Trang 8

RPC packets will generally have the 00 01 86 prefix shown

in the signature for this detect.

SUNRPC is the building block for a number of services, the most well known and frequently used being NFS RPCs and even NFS can be implemented over TCP as well as over UDP Remote Procedure Calls are not programmed to sockets, but to functions The log file entries from systems tend to reflect this, including the ever popular dump() call

There are common attacks for many well known RPC services such as tooltalk and statd Here is one more that is slightly different, but you still have the same signature:

01 86 A0 00 00 00 02 00 00 00 04

[**] RPC Info Query [**]

05/18-18:35:50.788732 203.231.10.220:872 -> z.y.w.98:111

TCP TTL:47 TOS:0x0 ID:22796 DF

*****PA* Seq: 0x356EBD5D Ack: 0x51D3CF02 Win: 0x7D78

TCP Options => NOP NOP TS: 187385869 565623365

Trang 9

By looking up port numbers on the internet, we found that port 9100 is the standard port used by networked Hewlett Packard LaserJet printers Searching the network traces shows other connections

to destination port 9100 to machines that are definitely networked HP LaserJet printers

A check of myhost's print queue showed that a print job has been trying to print to a remote LaserJet printer for about a month The IP address of this printer in the hosts file is correct and does not match the IP for remotehost However, looking back in the system change log, we find that the current IP of remotehost is the same as the original IP of the printer that the print queue is going to This IP was updated in /etc/hosts when the network was subnetted and new IP's were assigned

Printing on myhost is done via HP's JetDirect software When the print job was cancelled, the TCP connection attempts to remotehost stopped When the printer was removed and re-added with the correct IP address via JetDirect, printing went to the printer and not to remotehost

Trang 10

By mid 1999, it was clear that many of these scans had a purpose; they were looking for malicious code, or trojans In this case, port 7306 is commonly associated with the NetMonitor trojan.

Trang 11

Network Mapping

• Network mapping refers to an

attacker probing your systems in

order to determine what their IP

addresses are

Another technique that attackers use to gain information about your systems is network mapping There are many ways to do network mapping, but they all have the same goal: determining what the

IP addresses of your systems are

In many cases, network mapping is done with the most commonly used port numbers, such as 53 (DNS) and 80 (HTTP) This is done for two main reasons: because firewalls are very likely to permit this traffic to pass through, and because attackers can “hide” their mapping attempts among all the other traffic going to these ports

Trang 12

Data in a SYN

0000: 00 e0 1e 94 5f 00 00 10 0b 49 d9 00 08 00 45 00 |0010: 00 68 83 24 00 00 f2 06 f4 2b c8 d3 bb c2 xx xx |

0020: 06 08 08 98 00 35 05 d8 b2 5b 00 00 00 00 50 02 |

0030: 08 00 95 62 00 00 00 00 00 00 00 00 00 00 00 00 |0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |

This is a pattern used for load balancing;

the DNS server responds with a SYN/ACK.

Detect by Dave Eberlien:

“The attacker starts out by sending three crafted Syn packets with 64 octets of null data added By itself this is unusual behavior because an initial SYN is normally sent without a payload The reason for the payload could be to give a truer representation of response time with a larger packet size At the IP level all of the packets that I captured had IP source ports from 2000 to 4000 in increments of

100 The source port would increment by one for the three Syn packets The initial packets are received at the trace tool with less then one millisecond separating them On the trace the summery [sic] information calls these packets DNS query requests with an ID=0 The reason for this is the tool will try to interpret the data as a DNS query because of the destination port 53 In fact this is not a DNS query but simply a TCP Syn packet with 64 octets of null data (all zeros).”

NOTE: In this case the targeted DNS server responds with a SYN/ACK as if nothing is wrong

The “global load balancing” concept is described by Howard Kash in his “Analysis of the Type0 (Class 0) DNS that has been detected, version 1.0” located at:

http://www.sans.org/newlook/resources/IDFAQ/DNS.htm

Trang 13

02:08:48 mapper.com.3066 > 192.168.134.117.echo: udp 6

udp 6 = UDP packet, 6 bytes payload

Stealthy scan: slow scan rate and address interleaving

Network Mapping with UDP Echo Requests

In this slide, we see an attacker performing network mapping through UDP echo requests Don’t confuse these with ICMP echo requests; there is a service called echo that Unix systems may have on UDP port 7 This service is unrelated to ICMP echo requests and replies The echo service will

“echo” whatever characters it receives back to their sender

If an attacker finds systems that are running the echo service, he or she can use them for a variety of denial of service attacks Since it is trivial to spoof a UDP packet (since UDP is connectionless), an attacker could spoof packets with a forged source address; the system with echo would then send all

of its responses to the spoofed system

Although many attackers know about the echo service, this particular scan is using an uncommon technique; we have to give these folks extra points for interleaving the Internet address families and keeping the scan rate down to stealthy levels

Trang 14

Three address families, two loops – “in your face” scan

IMAP + SOCKS Variation

This scan shows an attacker first scanning various addresses for TCP port 143, IMAP Hours later, the same address scans some of the same addresses for TCP port 1080, SOCKS

Another thing we like to look for is the order of a probe We realized long ago that we weren’t the sole focus of these attacks As we continue to deploy sensors in interesting locations, we get a better and better picture of the list of internet addresses that is being fed to various attack scripts As the months go by, it is possible to categorize the input files

Trang 15

[**] SNMP access, public [**]

02/22-06:36:32.633503 158.36.37.2:1289 -> x.x.x.z:161

UDP TTL:118 TOS:0x0 ID:51169

Len: 246

30 81 EB 02 01 00 04 06 70 75 62 6C 69 63 A1 81 0 public

DD 02 02 3B E7 02 01 00 02 01 00 30 81 D0 30 0B ; 0 0.

06 07 2B 06 01 02 01 01 01 05 00 30 0B 06 07 2B + 0 +

06 01 02 01 01 03 05 00 30 0B 06 07 2B 06 01 02 0 +

… 01 01 07 05 00 30 10 06 0C 2B 06 01 04 01 0B 02 0 +

03 09 05 01 03 05 00 30 10 06 0C 2B 06 01 04 01 0 +

06 01 04 01 0B 02 04 03 0A 07 05 00 30 0F 06 0B 0

2B 06 01 04 01 0B 02 04 03 0A 0D 05 00 30 0F 06 + 0

0B 2B 06 01 04 01 0B 02 04 03 0D 01 05 00 +

Password guessing example in the notes pages SNMP Probe Default Community String This is a Snort style detect of an SNMP probe Only one packet is shown above, but this is part of a large scan Note that this is using the public community string and they haven’t yet begun walking the tree Another packet, shown below, is guessing the SNMP password: 08/08-11:16:12.737426 216.217.80.201:8314 -> xx.xx.xx.23:161 UDP TTL:116 TOS:0x0 ID:6285 Len: 48 30 26 02 01 00 04 04 64 65 76 61 A0 1B 02 03 2C 0& deva ,

90 B7 02 01 00 02 01 00 30 0E 30 0C 06 08 2B 06 0.0 +

01 02 01 01 02 00 05 00

There are a handful of other SNMP packets, with the following names: private, gene and fred

This scan was generated with the “SolarWinds Network Management Toolset”, probably the demo version This was certainly not a quiet scan for this particular kiddie

Reported by Jeremy Hansen in August 13, 2000 GIAC

Trang 16

In this example, we see a scan that is using SNMP requests and ICMP echo requests in order to gather information This is similar to a pattern used by printer software to scan for printers It is still troubling.

Trang 17

In addition to using SNMP for intelligence gathering,

some MIB variables are writeable.

SNMP Write Attempt

This is a fairly rare pattern, an attack that is often postulated and rarely detected

This is definitely someone hostile trying to rewrite some SNMP information on our machines The destination port is UDP 161, and the payload is clearly an SNMP write command

There are many more attempts than just the one shown in this slide They all follow the same technique The source port is being reused, the packets arrive in a very fast succession, and the IDs are incremented by one for each packet All of this indicates that an automated method is being used

Also notice the low TTL: these packets have most likely not been traveling that far, so the sender is

probably intentionally setting a low TTL when constructing the packets

Snort detect and analysis by Tomas Halvarsson, GCIA.

Trang 18

Network Mapping Using ICMP Broadcast Echo Requests

In contrast to the Smurf attacks, here we see that the

broadcast echo requests are spaced reasonably far apart in time The source IP address is not spoofed The time delay

between broadcasts gives the attacker time to process the

echo replies without getting overloaded.

A word about social engineering It was actually on a different scan than this, but when the analyst finally located the attacker, here was their reply ( [ ]s) indicate sanitized material:

Howdy there! Yeah, we ought to update our contact info Sigh Well, it's not a spoof, this is coming from our network One of the people who we host here (who runs the [ATTACKER].com host) has been doing a scan of the internet for places that still are vulnerable to directed broadcasts, and thus may be used in smurf attacks He's a security consultant, and hopes to help contact these sites and tell them how to fix their stuff We've forwarded this on to him, and I'm sure he'll be responding shortly with a longer explanation

So the upshot is: don't worry All is aboveboard If you'd like to get in touch with me in particular, you can give me a call at work at (510)555-1212, or on my cellular at (415)555-1212 But I think that the best person to talk to about this is Max, who will be contacting you shortly I'm sure Have fun!

-[Prober DNS Point of Contact]

Trang 19

Net Map for Subnet Mask

02:21:06 echo.net > 172.20.64.0: icmp: echo request

ICMP address mask request would be a lot easier!

In this detect, we see an attacker sending ICMP echo requests to potential broadcast addresses You may

be saying to yourself, 172.20.64.0 isn’t a broadcast address That is true of most systems; however, some older Unix implementations used 0 as a broadcast address instead of 255 So this attacker is searching for the old style and new style broadcast addresses that would be used by various subnets

A much simpler way of collecting the same information would be to send ICMP address mask requests

If your border routers and firewalls do not block address mask requests, then an attacker can just issue an address mask request, and your network will send an address mask reply with your subnet mask

02:21:06.700002 echo.net > 172.20.64.0: icmp: echo request

02:21:06.701270 205.67.232.33 > echo.net: icmp: host 172.20.64.0 unreachable - admin prohibited filter

Trang 20

This is another example of an SNMP scan Note that the second detect is a scan to a broadcast address It should be noted that network designers often place core systems at host address “1” SNMP should always be blocked at the firewall or filtering router Many devices such as X-terminals and print servers come with SNMP agents built in.

Additional analysis was done by Marc Panet-Raymond, GCIA:

The object the attacker appears to be interested in is specific to the HP SNMP tree-based IANA assignments; 1.3.6.1.4.1.11 is assigned to hp The particular MIB the attacker is trying to access is listed below From the description below, I am not aware of the value of that piece of information, but if the attacker is successful in retrieving this information, he may also retrieve other information that can be of use Also, if the attacker has the read/write community string, he may change the configuration of the targeted system

MIB:

.iso.org.dod.internet.private.enterprises.hp.nm.interface.npCard.npIpx.npIpxSapInfo

MIB Description:

This is a 50 byte array that contains the following information

2 bytes: bindery object type (always 030c in hi-lo order)

12 bytes: Mac address of card (ASCII)

2 bytes: frame type also high bit (8000) is set if card is not configured

2 bytes : unit type (hex 81 for NetJet card)

32 bytes: node name (ASCII) which is:

print server name for Queue Server mode

printer name for RPTR mode

IANA Asssignment: ftp://ftp.isi.edu/in-notes/iana/assignments/enterprise-numbers

Trang 21

This is either a very broken application or a poorly crafted

packet ; p robably not dangerous, certainly an anomaly.

SNMP Crafted Header

These packets were printed with the -vv option to get more information The first clue that

something was wrong was that misspelling in GetNextRequest Also, note that the ID field has not changed, nor has the source port I would ignore the TTL differences normally, but the countdown is just too weird After checking more data, we see that each host is scanned four times and each time

we have the same TTL pattern

Now what is the analysis? Do we just have an inept coder trying to write an SNMP application, or is

an inept coder trying to write an exploit? We may never know

Trang 22

Scan Using Source Port 0

With Both SYN and FIN Flags Set

Source port 0 or 65535 and SF set are a good signature

So why are these packets being crafted? Part of the

reason is that some security devices filter on SYN only.

There are several interesting aspects to this scan pattern First, the source port in each attempt is set

to 0, which you should not normally see Second, both the SYN and FIN flags have been set This is

a classic sign of crafted packets, since SYN and FIN should never both be set in the same packet Historically, SYN/FIN packets have been used to evade filtering and intrusion detection systems FINs may be allowed through even if SYNs are not This improves the probability of a response Since the FIN signals connection teardown, some logging systems will potentially fail to report the connect

Several security folks in the trade have commented that Windows systems will answer a packet with SYN and another flag set as if it were a SYN only packet That may be, but Windows systems do not tend to host IMAP and NFS; this scan is more likely to be targeted at Unix systems Therefore, the purpose(s) of the SYN/FIN must be to avoid getting logged and evade filtering devices

Currently, SYN/FIN scans occur against many different ports

Final note: the attack tool here may be linuxportz

Trang 23

Over two years after the first 0 SF pattern was detected, this

DNS probe was located.

Here is another example of a scan where the SYN and FIN flags are set and the source port is always set to zero In this case, it appears to be targeting DNS We have seen a number of reports of detects from systems that had source port zero and SF set, which is anomalous The combination is used for both penetration and stealth

Detect by Erik Fichtner, obfuscation.org, first reported on GIAC on February 2, 2000

Trang 24

DNS Update

Apr 8 18:07:53 dns1 named[11759]: unapproved update

from [208.243.251.37].65532 for edu

Apr 8 18:07:54 dns1 named[11759]: unapproved update

from [208.243.251.37].65531 for edu

This system log file shows activity that occurs on UDP port

53 This is a potential problem for sites with Windows 2000

systems that are not hardened Detailed explanation of

update is included in your notes pages.

Detect and analysis below by Suzanne Hernandez, GCIA:

Apr 03 02:05:33 ns1 named[1337]: unapproved update from [13.1.1.1].1025 forour.domain

This message came from our syslog running on our DNS server I had never seen this message before and investigated it in DNS and BIND It turns out this is a feature in the 8.x version of BIND that allows you to remotely add to or delete records from a domain We run a second level domain on our network,

so further investigation was necessary, even though the update was unsuccessful This feature is necessary to allow a DHCP server to add records to a DNS server whenever a machine registers itself with the DHCP server The nsupdate works on UDP port 53 just like a regular DNS query To recreatethis, I created a bogus domain with an mx record and added the following to the options section in the DNS configuration file:

allow-update { any; };This option is off by default

I then typed the following from another server:

root@server] # nsupdate

> update delete bogus.domain in mx

> update add bogus.domain 99999999 in mx 0

hacker.exchange.server

When this was completed, I did an mx lookup and got the following result:

Nslookup q=mx bogus.domain

Bogus.domain preference = 0, mail exchanger = hacker.exchange.server

Now I have effectively hijacked bogus.domain’s mail and redirected it to my exchange server

Trang 25

11:16:44.611343 ns1.uta.edu > myhost.woe.is.me.com: icmp:

ns1.uta.edu udp port 1075 unreachable (DF)

11:16:44.611345 dns.Princeton.EDU.1075 >

myhost.woe.is.me.com.53: 65196 (41) (DF)

11:16:44.611499 myhost.woe.is.me.com.53 >

dns.Princeton.EDU.1075: 65196* q: woe.is.me.com 0/0/0 (41)11:16:44.624771 as4100c.javanet.com.1075 >

myhost.woe.is.me.com.53: 10825 (41)

11:16:44.624942 myhost.woe.is.me.com.53 >

as4100c.javanet.com.1075: 10825* q: woe.is.me.com 0/0/0 (41)11:16:44.655498 dns.Princeton.EDU > myhost.woe.is.me.com:

icmp: dns.Princeton.EDU udp port 1075 unreachable (DF)

11:16:44.661939 as4100c.javanet.com > myhost.woe.is.me.com:

icmp: as4100c.javanet.com udp port 1075 unreachable

DNS Denial of Service

The query host is spoofed

These queries come from a very diverse set of source addresses The query (q: field) contains the domain name (woe.is.me.com) rather than a host The query is successful, as myhost returns one answer (1/1/1)

The random source ports seem normal enough, but the intensity of the timing of the requests is highly unusual for this very lightly-used DNS server Each host sends two seemingly identical requests back-to-back, but each has a separate DNS ID, which increments a small amount for each connection, which would seem normal for two requests close together if ID's are assigned

sequentially

I found a tool on rootshell.com called doomdns whose purpose is to send DNS requests to a server with spoofed source addresses in a sort-of smurf style flooding DoS attempt The comments in the source claimed a very large amplification factor can be achieved with DNS There's also a tool called abusedns mentioned at the sans web site This tool is a follow-on to doomdns

Detect and analysis by Mike Harvey, GCIA

Trang 26

date time source IP src port dest IP dest port04/26/98 20:27:37 202.256.20.6 31337 256.34.229.38 80 t04/26/98 20:27:37 202.256.20.6 31337 256.34.229.2 80 t04/26/98 20:27:37 202.256.20.6 31337 256.34.229.40 80 t04/26/98 20:27:37 202.256.20.6 31337 256.34.229.42 80 t04/26/98 20:27:37 202.256.20.6 31337 256.34.229.4 80 t04/26/98 20:27:37 202.256.20.6 31337 256.34.229.44 80 t04/26/98 20:27:37 202.256.20.6 31337 256.34.229.6 80 t04/26/98 20:27:37 202.256.20.6 31337 256.34.229.8 80 t04/26/98 20:27:37 202.256.20.6 31337 256.34.229.46 80 t

Trang 27

Information Gathering

Using NetBIOS

One of the characteristics of NetBIOS is that UDP 137 is often caused by

something a site initiates For example, if you send email to a site running Microsoft Exchange, they will often send a port 137 attempt So we look

for the causing factor:

Here is the pattern:

NOTE: 207.256.242.26 is on the same Class C net as www.srnaccess.com

We love NetBIOS! We could keep an analyst employed full time evaluating the various patterns The slide above shows a common case, where a web server is accessed by a PC and then sometime later the PC is accessed with a name lookup Think of this in terms of stimulus and response; when you see activity from port 137 to port 137, you need to determine if it is stimulus from an attacker or

a response to an action from your own site

Trang 28

A connection from any source port other than

137 to 137 may indicate a samba system.

Information Gathering Scanning for NetBIOS Name Service

This slide shows more examples of port 137 scans Although there are many reasons why an attacker might try to access NetBIOS ports, one of the primary reasons is reconnaissance Port 137 provides a lot of information to an attacker; if at all possible, this port should be blocked at your network perimeter

Although we typically think of NetBIOS connections occurring from UDP port 137 to port 137, this

is not always the case For example, connections involving a Samba system may only have port 137

as a source or destination, not both

Tiêu đề	Network Mapping and Information Gathering
Trường học	Sanskrit University
Chuyên ngành	Network Security
Thể loại	Giáo trình/Presentations
Năm xuất bản	2000, 2001

Định dạng
Số trang	57
Dung lượng	1,08 MB