Communication Encryption

Communication Encryption

The use of VPN technology, or application level encryption, reduces the
scope of gathering useful information by sniffing the network, however
the implementation of those technologies may still provide an attacker
with the opportunity to capture information.
Consider network VPNs that are often implemented in a point to point
fashion, e.g. Firewall to Firewall or border Router to border Router
rather than client to server. If the sniffer is placed within one of the
secure domains connected by the VPN rather than attempting to
compromise the VPN traffic between those domains, then the traffic
viewed is no longer in encrypted form.
In the example of application level security, proprietary encoding or
encryption is often not of a high enough standard to repel a sustained
attack, PC Anywhere’s password security is acknowledged by the
vendor to be a relatively weak encoding algorithm, able to withstand
only a cursory attack.

L0pht Crack

Similarly, the LANMAN password hashes password with the NT
password hashes used in NT authentication have been proven to be
weak, and susceptible to a sustained brute force attack. The security
group L0pht Heavy Industries have produced a widely used tool L0pht
Crack capable of brute forcing LANMAN hashes gathered either from
the registry or disk of a compromised machine, or by sniffing
authentication exchanges on the network.

Local Scanning and Sniffing

Local Scanning and Sniffing

If local access to the target network can be obtained, the range of
information that may be gathered is greatly increased.
Network Sniffers
Within the context of a security assessment, local network access for
sniffing simulates that an attacker has installed sniffing software on a
host to attempt to gain further access. This may have been achieved in
one of two ways:
• Physical access - An attacker may have gained physical access to
part of the target site.
• System compromise - An attacker may have previously
compromised an internal host or system.
Many applications used over the Internet and corporate networks have
no intrinsic security within their communications. Typical examples
include Telnet and FTP, but more complex functions are often
conducted using clear or weakly encoded network traffic. Example of
this are:
• Network shares
• Thin client
• Remote control
By utilizing the promiscuous mode on many network cards, this
passing traffic can be monitored, analyzed, filtered and captured for
surreptitious purposes. In the case of applications such as telnet, the
username and password are easily identified during a session. Data
transferred during an FTP or network share session could be captured
and reconstructed later, recovering some or all of the data.

Traceroute through DNS

Traceroute through DNS

Consider the case of a Firewall configured to permit DNS domain
queries through, on UDP port 53. As UDP is a connectionless protocol,
the Firewall would need to allow the traffic in both directions - indeed
the default policy settings of Checkpoint’s Firewall-1 to version 4.0
permitted not only 53/UDP but 53/TCP too.

A standard traceroute to a host behind the Firewall would be blocked
by the ruleset, leaving the last hop revealed to be the gateway upstream
from the Firewall.
If, however, we construct our traceroute such that the source packet of
the traceroute packet that arrives at the packet filter is UDP/53, then
the DNS query rule would allow the packet through, revealing data for
one further hop.
Further information on how to calculate the correct initial port to
exploit a Firewall ruleset and reveal network information through a
Firewall can be found in David Goldsmith and Michael Schiffman’s
article Firewalking [1998] -
http://www.packetfactory.net/Projects/Firewalk/firewalk-final.html
Risk Level
Whether constructed traceroutes are discovered is dependant on how
the security device has been configured. If this type of attack is
expected, then special filters could have been set up on key UPD ports.
As such, we will categorize this technique as a Medium risk.

Advanced Techniques

Advanced Techniques

Although we have mentioned techniques for identifying and possibly
circumventing a network security device such as a firewall, we will
now examine more advanced techniques for coaxing information from
a gateway.
Pinging Firewalled Hosts
Whilst standard ICMP pings will often be filtered at some gateways,
there are other techniques for identifying viable target hosts.
By using a tool such as nmap, or even manual techniques given time,
we may systematically probe the target IP range for hosts listening on
specific ports. For example, sweeping the IP range on TCP ports 80 and
443 will detect web servers, whilst scanning on TCP/21 should find any
FTP servers. Since the service ports must be open through a Firewall for
the service to function, by probing known service ports we may find
extra hosts despite our ICMP echo/replies being barred.
Advanced Traceroute
We have already discussed that traceroute may operate on ICMP or
UDP packets, and that both should be used because filters and other
devices may react differently to the different types of traffic.
Traceroute also provides options to vary the source port of a UDP scan,
which provides useful opportunities for at least partially penetrating
the firewall.

Risk Level

Risk Level

An SMTP header analysis, if constructed carefully to look like a
genuine mistake (e.g. using John.smit@example.com) will pass
inspection unnoticed, and is therefore a low risk (and potentially high
value) technique.

Dig results showing mail exchange records

Dig results showing mail exchange records

 From our dig results in Figure 10, we see that there are 3 mail exchanger
(MX) records:
• atla-mx1.iss.net.
• mutex.netrex.com.
• chcg-mx1.iss.net.
Clearly, the iss.net hosts are of interest, so we will target one by using
telnet to connect to the SMTP port (TCP/25), as shown BELOW


glyng@TERROR [~] $ telnet atla-mx1.iss.net 25
Trying 208.21.0.9...
Connected to atla-mx1.iss.net.
Escape character is ’^]’.
220 atla-mx1.iss.net ESMTP Sendmail 8.9.3/8.9.2; Wed, 19 Jul 2000
10:43:53 -0400 (EDT)


The last line of  shows the mail server introducing itself to us,
including local system time and software and version numbers.



 we introduce ourselves with a false domain name. The
server, however, shows it has logged our real IP address. We now
construct an e-mail from an address capable of receiving the bounced
mail, to a mis-spelt user account, as shown in .



mail from: glyng@bigfoot.com
250 glyng@iss.net... Sender ok
rcpt to: glyngg@iss.net
250 glyngg@iss.net... Recipient ok
data
354 Enter mail, end with "." on a line by itself
Subject: testing
asd
.
250 KAA09440 Message accepted for delivery
quit
221 atla-mx1.iss.net closing connection
Connection closed by foreign host.
glyng@TERROR [~] $

Dig results showing mail exchange records

Dig results showing mail exchange records

 glyng@TERROR [~] $ dig iss.net mx

; <<>> DiG 2.2 <<>> iss.net mx

;; res options: init recurs defnam dnsrch

;; got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34885

;; flags: qr aa rd ra; Ques: 1, Ans: 3, Auth: 9, Addit: 10

;; QUESTIONS:

;; iss.net, type = MX, class = IN

;; ANSWERS:

iss.net. 3600 MX 5 atla-mx1.iss.net.

iss.net. 3600 MX 10 mutex.netrex.com.

iss.net. 3600 MX 15 chcg-mx1.iss.net.

;; AUTHORITY RECORDS:

iss.net. 3600 NS ehecatl.iss.net.

iss.net. 3600 NS sfld-ns1.netrex.com.

iss.net. 3600 NS chcg-ns1.netrex.com.

iss.net. 3600 NS dnvr-ns1.netrex.com.

iss.net. 3600 NS ns1-auth.sprintlink.net.

iss.net. 3600 NS ns2-auth.sprintlink.net.

iss.net. 3600 NS ns3-auth.sprintlink.net.

iss.net. 3600 NS phoenix.iss.net.

iss.net. 3600 NS ns.commandcorp.com.

;; ADDITIONAL RECORDS:

atla-mx1.iss.net. 3600 A 208.21.0.9

mutex.netrex.com. 3200 A 206.253.239.132

ehecatl.iss.net. 3600 A 208.21.0.7

sfld-ns1.netrex.com. 3200 A 206.253.239.135

chcg-ns1.netrex.com. 3200 A 216.89.220.19

dnvr-ns1.netrex.com. 3200 A 206.253.249.130

ns1-auth.sprintlink.net. 18924 A 206.228.179.10

ns2-auth.sprintlink.net. 18924 A 144.228.254.10

ns3-auth.sprintlink.net. 5788 A 144.228.255.10

phoenix.iss.net. 3600 A 208.21.0.13

;; Total query time: 491 msec

;; FROM: TERROR to SERVER: default -- 212.13.193.20

;; WHEN: Wed Jul 19 15:42:39 2000

;; MSG SIZE sent: 25 rcvd: 492

glyng@TERROR [~] $

SMTP Headers

SMTP Headers

Where an SMTP mail server is present, internal topology may be
discovered by passing an e-mail though the system and examining the
resulting headers. For example, if a mail is sent to
in.valid.user@example.com on our example network, we should
(eventually) receive a bounced e-mail back from mail whose headers
would revel each stage of the mail’s path through the organization - in
this example potentially giving us IP’s and machine names for the
Firewall (both DMZ IP’s and the internal address), the external mail
server (smtp), the content scanner (scan) and the internal mail server
(mail).
Although this hasn’t involved accessing any systems illegitimately, the
internal addressing and naming discovered could prove useful later in
the attack.
Example
Retrieving a set of SMTP headers from a target is a relatively straight
forward task. An online mail account (e.g. mail.yahoo.com) can be used
to send a message to a non-existent user at the target, or an SMTP mail
can be constructed as below.
First we establish the mail servers for the company, using a tool such as
dig.

Network Mapping

Network Mapping

Although various network mapping tools are available, from the
excellent and free Cheops to commercial tools such as HP Openview
and Visio, these tools have often been designed to map local and
trusting networks.
When trying to map subnets across the Internet, they are less reliable at
producing a comprehensive network map. This problem is greatly
exasperated by any IP filtering, which is almost guaranteed to be
present in a modern, secured gateway. It is often worth launching a
network mapper as a background activity, as the results may
corroborate or refute the assumptions we have made by manually
examining our data.

Risk Level

Network mapping tools are not designed with stealth in mind, and
therefore present a High risk of discovery. As the security devices often
impair their operation, their use is limited in this sort of remote
enumeration.

Traceroute

Traceroute

More topological information may be gathered using traceroute.
Traceroute identifies each device a packet must pass through en route
to its final destination through the use of packets with incremental
TTL’s.
Hosts that failed to respond to ping should be tracerouted to establish
where the path to the host fails. If the final successful hop is one of the
previously identified routers or gateways, that gateway may well be
filtering inbound traffic. We will examine other techniques for
identifying live hosts despite the presence of such filtering in a later
section.
Traceroute Variations
Both ICMP and UDP traceroutes are common - UDP originated on
UN*X systems, whereas the NT tracert command used an ICMP
variant. Both are useful in network enumeration, as filters may block
only one of these two IP protocols, and dual-homed intermediate
devices may return different interfaces IP’s based on the source packet
protocol. Both are available in many UN*X implementations - UDP is
the default and ICMP is available using the -I switch.
Routers
By examining the output from traceroute, we may establish key
upstream devices by simply analyzing the name assigned to it.
• ISP routers - These commonly follow naming conventions giving
away their geographical location and purpose.
• Customer routers and gateways - These frequently contain hints at
the company name or use generic names such as gateway or gw.
Routers R1 and R2 in the example represent the routers either end of
the serial connection between the ISP and the company. R2 may be
managed either by the ISP or the company.

Ping Sweeps

Ping Sweeps
ping, gping and fping
Having identified potential targets, it is useful to initiate a ping sweep
to see which hosts appear to be alive. This may simply be a series of
ICMP echo-reply exchanges from a standard ping application, or the
ping sweep function of an application, for example:
• fping
• WS Ping Pro
• nmap
Although this will immediately identify readily available hosts, a
negative result will require further examination, possible reasons being:
• The host could truly be down or disconnected from the network.
• The packet has simply been rejected.
• An up-stream filter may have silently dropped the packet.
fping
fping has certain advantages over a batched set of standard pings, as it
is designed to initiate multiple requests, processing the results in
parallel. When combined with its accompanying IP generator, gping,
fping represents a fast and flexible tool for a ping sweep.
Risk Level
Whilst a small number of pings would likely be overlooked, and
therefore carry a Low risk, automated ping sweeps with short time outs
could become visible both to an administrator and to security devices,
and therefore carry a High risk. By increasing the timeout between
checking each host, the risk of discovery would be greatly reduced,
although the scan time would obviously increase.