E-Mail Attacks , IM attacks , SMTP attacks

E-mail bombs

E-mail bombs can crash a server and provide unauthorized administrator
access. They attack by creating DoS conditions against your e-mail software
and even your network and Internet connection by taking up so much bandwidth
and requiring so much storage space.

Attachments
An attacker can create an attachment-overloading attack by sending hundreds
or thousands of e-mails with very large attachments.

Attacks
Attachment attacks may have a couple of different goals:
The whole e-mail server may be targeted for a complete interruption of
service with these failures:
• Storage overload
Multiple large messages can quickly fill the total storage capacity
of an e-mail server. If the messages aren’t automatically deleted by
the server or manually deleted by individual user accounts, the
server will be unable to receive new messages.
This can create a serious DoS problem for your e-mail system,
either crashing it or requiring you take your system offline to clean
up the junk that has accumulated. A 100MB file attachment sent
ten times to 80 users can take 80GB of storage space. Yikes!

• Bandwidth blocking
An attacker can crash your e-mail service or bring it to a crawl by
filling the incoming Internet connection with junk. Even if your
system automatically identifies and discards obvious attachment
attacks, the bogus messages eat resources and delay processing of
valid messages.

An attack on a single e-mail address can have serious consequences if
the address is for a really important user or group.

Countermeasures

These countermeasures can help prevent attachment-overloading attacks:
Limit the size of either e-mails or e-mail attachments. Check for this
option in e-mail server configuration options (such as those provided in
Novell GroupWise and Microsoft Exchange), e-mail content filtering, and
e-mail clients.

This is the best protection against attachment overloading.
Limit each user’s space on the server. This denies large attachments
from being written to disk. Limit message sizes for inbound and even
outbound messages if you want to prevent a user from launching this
attack inside your network. 10MB to 20MB to be good limits.Consider using
FTP or HTTP instead of e-mail for large file transfers. By
doing so, you can store one copy of the file on a server and have the
recipient download it on his or her own. This can help keep message
store sizes at a minimum.

Connections
A hacker can send a huge amount of e-mails simultaneously to addresses on
your network. These connection attacks can cause the server to give up on servicing
any inbound or outbound TCP requests. This can lead to a complete
server lockup or a crash, often resulting in a condition where the attacker is
allowed administrator or root access to the system!


Countermeasures

Many e-mail servers allow you to limit the number of resources used for
inbound connections. It can be next to impossible tocompletely stop an unlimited amount of inbound requests. However, you canminimize the impact of the attack. This setting limits the amount of server processor time, which can help prevent a DoS attack.

Even in large companies, there’s no reason that thousands of thousands of
inbound e-mail deliveries should be necessary within a short time period.
Some e-mail servers, especially UNIX-based servers, can be programmed to
deliver e-mails to a daemon or service for automated functions. If DoS protection
isn’t built into the system, a hacker can crash both the server and the
application that receives these messages.

Autoresponders
An interesting attack seen is to find two or more users on the same or different
e-mail systems that have autoresponder configured. Autoresponder is
that annoying automatic e-mail response you often get back from random
users when you’re subscribing to a mailing list. A message goes to the mailinglist
subscribers, and then users have their e-mail configured to automatically
respond back, saying they’re out of the office or, worse, on vacation. This is a
great way to tell thousands of people that your house and belongings are possibly
available for taking.

Attacks
An autoresponder attack is a pretty easy hack. Many unsuspecting users and
e-mail administrators never know what hit them! The hacker sends each of the
two (or more) users an e-mail from the other simply by masquerading as that
person (an easy hack I outline in this chapter). This attack can create a neverending
loop that bounces thousands of messages back and forth between
users. This can create a DoS condition by filling either the user’s individual
disk space quota on the e-mail server or the e-mail server’s entire disk space.

Countermeasures

The best countermeasure for an autoresponder attack is to make it policy
that no one sets up an autoresponder message. Those messages are too
annoying to be of value anyway, right?
Prevent e-mail attacks as far out on your network perimeter as you can. The
more traffic or malicious behavior you keep off your e-mail servers and clients,
the better.
Automatic e-mail security
You can implement the following countermeasures as an additional layer of
security for your e-mail systems.

Tarpitting
Tarpitting detects inbound messages destined for unknown users. If your
e-mail server supports tarpitting, it can help prevent spam or DoS attacks
against your server. If a predefined threshold is exceeded — say, more than
ten messages — the tarpitting function effectively blocks traffic from the sending
IP address for a period of time.

E-mail firewalls
E-mail firewalls and content-filtering applications (such as CipherTrust’s
IronMail and NetIQ’s MailMarshal, respectively) can prevent various e-mail
attacks. These tools protect practically every aspect of an e-mail system.

Perimeter protection
Although not e-mail–specific, many firewall, IDS, and IDP systems can detect
various e-mail attacks and shut off the attacker in real time. This can come in
handy during an attack at an inconvenient time.

SMTP attacks

Some hacker attacks exploit weaknesses in the Simple Mail Transfer Protocol
(SMTP). This e-mail communications protocol — which is over 20 years old —
was designed for functionality, not security.

Account enumeration
A clever way that hackers can verify whether e-mail accounts exist on a server
is simply to telnet to the server on port 25 and run the VRFY command. The
VRFY — short for verify — command makes a server query to check whether
a specific user ID exists. Spammers often automate this method to perform a
directory harvest attack (DHA). It’s a way of gleaning valid e-mail addresses
from a server or domain so hackers know who to send spam messages.

Attacks

The SMTP command EXPN — short for expand — may allow attackers to verify
what mailing lists exist on a server as well. You can simply telnet to your e-mail
server on port 25 and try EXPN on your system if you know of any mailing lists
that may exist. Figure 15-6 shows what this result may look like. It’s simple to
script this attack and test thousands of mailing-list combinations.
You may get bogus information from your server when performing these two
tests. Some SMTP servers don’t support the VRFY and EXPN commands, and
some e-mail firewalls simply ignore them or return false information.

Countermeasures
The best solution for preventing this type of e-mail account enumeration
depends on whether you need to enable the VRFY and EXPN commands:

Disable VRFY and EXPN unless you need your remote systems to be able
to gather user and mailing-list information from your server.

If you need VRFY and EXPN functionality, check your e-mail server or
content filtering documentation for the ability to limit these commands
to specific hosts on your network or the Internet.

Relay
SMTP relay lets users send e-mails through external servers. Open e-mail
relays are one of the greatest problems on the Internet. Spammers and hackers
can use an e-mail server to send spam or attack through e-mail under the
guise of the unsuspecting open-relay owner.
Keep in mind the following key points when checking your e-mail system for
SMTP-relay weaknesses:

Test your e-mail server by using more than one tool or testing method.
Multiple tests minimize any errors or oversights.

Test for open relay from outside your network. If you test from the
inside, you may get a false positive, because outbound e-mail relaying
may be configured and necessary for your internal e-mail clients.

Automatic testing
Here are a couple of easy ways to test your server for SMTP relay:

Free online tools.
One of my online tools is located at www.abuse.net/relay.
html. You can perform the anonymous test without entering your e-mail
address — unless you’re an abuse.net member. It immediately displays
the test results in your browser.

Using EXPN
to verify that
a mailing list
exists.

Other Windows-based tools, such as Sam Spade for Windows.

Some SMTP servers accept inbound relay connections and make it look
like relaying works. This isn’t always the case, because the filtering may
take place behind the scenes. Check whether the e-mail actually made it
through by checking the account you sent the test relay message to.

Manual testing
You can manually test your server for SMTP relay by telnetting to the e-mail
server on port 25. Follow these steps:

1. Telnet to your server on port 25.
You can do this two ways:
• Use your favorite graphical telnet application, such as HyperTerminal
(which comes with Windows) or SecureCRT (www.vandyke.com).

• Enter the following command at a Windows or UNIX command
prompt:
telnet mailserver_address 25
To see what’s entered, you may have to enable local echoing of characters
in your telnet program, such as Hyper Terminal.
You should see the SMTP welcome banner when the connection is made.

2. Enter a command to tell the server, “Hi, I’m connecting from this
domain.” Enter the command like this:
helo yourdomain.com
After each command in these steps, you should receive a differentnumbered
message, like 999 OK. You can ignore these messages.

3. Enter a command to tell the server your e-mail address, like this:
mail from:yourname@yourdomain.com

4. Enter a command to tell the server who to send the e-mail to, like this:
rcpt to:yourname@yourdomain.com

5. Enter a command to tell the server that the message body is to follow,
like this:
data

6. Enter the following text as the body of the message:
A relay test

7. End the command with a period on a line by itself.
This marks the end of the message. After you enter this final period,
your message will be sent if relaying is allowed.

8. Check for relaying on your server:
• Look for a message like Relay not allowed to come back from the
server.
If you get a message like this returned, SMTP relaying is not
allowed on your server.

You may get this message after you enter the rcpt to: command.
• If you don’t receive a message back from your server, check your
inbox for the relayed e-mail.
If you receive the test e-mail you sent, SMTP relaying is enabled on
your server.

Countermeasures
You can implement the following countermeasures on your e-mail server to
disable or at least control SMTP relaying:

Disable SMTP relay on your e-mail server. If you don’t know whether you
need SMTP relay, you probably don’t. You can enable SMTP relay for
specific hosts if needed.
www.mailabuse.org/tsi/ar-fix.html provides information on disabling
SMTP relay on e-mail servers.

Enforce authentication, if your e-mail server allows it. You may be able
to require such authentication methods as password authentication or
an e-mail address that matches the e-mail server’s domain. Check your
e-mail server and client documentation for details on setting up this
type of authentication.

Instant Messaging

The hottest new technology taking networks by storm is instant messaging
(IM). Although IM offers a lot of business value, some serious security issues
are associated with it. This is especially true if it’s not managed properly and
end users are free to install, configure, and use it in any way they want.

Vulnerabilities

IM has several critical security vulnerabilities, including the following:

Name hijacking, allowing a hacker to assume the identity of an IM user

Launching a DoS attack on an IM client, allowing the attacker to take
remote control of the computer

Capturing internal IP address information (similar to the way it’s disclosed
in e-mail headers)

Transferring malware, including viruses and malicious Trojan horses

You can remedy most of these vulnerabilities by applying the latest software
patches and keeping antivirus signatures up to date. However, two IM vulnerabilities
are susceptible to malicious attack, so they deserve a little more discussion.
These affect most of the popular IM clients, including AOL Instant
Messenger (AIM) and ICQ. These vulnerabilities are just problems with file
sharing and log files, but these weaknesses can make all the difference in the
world when it comes to securing your network.

Sharing network drives
The biggest problem with IM clients is the ability to share files. This feature
may be pretty neat for home users or others with stand-alone computers, but
it can pose a real security risk to your network and information. Practically
every IM client gives users the ability to share both local and network files.
Once untrained or careless users share your network drives via their IM
clients, they’ve just granted potentially anyone on their IM network permission
to view and copy those files.

If you know of IM users on your network, follow these steps to assess the
security of their software and configuration:
1. Determine IM clients that are running on your network.
You can detect IM software with
• Manual inspection of the local workstation
• A third-party workstation hardware and software inventory
program
• A network analyzer that shows IM traffic. For instance, you can use
Ethereal to capture and display various types of IM protocols, such
as AOL Instant Messenger (AIM protocol), ICQ (ICQ protocol), and
MSNMS (MSN Messenger).
2. Install the IM clients on your own system.
Avoid creating your own security holes: Download and install the latest
client versions, and don’t enable file sharing.
3. Find your network’s IM users.
You can identify IM users by either looking up users with a directory
search in the IM client (many IM clients publish this information by
default) or asking users for their handles for all their IM clients.
4. For each user, check settings to see whether they’re sharing files.
It’s often just a simple right-click on their IM handle within the IM software
to copy files to and from their system.

Log files
Many IM clients can log all IM conversations. Some clients log all conversations
by default. Have users enabled logging and inadvertently shared their
log files with the world? It’s a smoking gun for a hacker to use! Figure 15-13
shows part of an ICQ conversation stored in communications gobbledygook
in a log file found in the c:\Program Files\ICQ folder.

Countermeasures
IM vulnerabilities can be difficult to detect, because most rogue IM software
is desktop-based. If you have a large network, checking every computer for
these vulnerabilities is pretty much impossible. Spot checks can be inaccurate,
because every desktop and every user can be different.
Even if you disallow IM — or any messaging software — on your network, users
always install it. If you implement these countermeasures, you’re better prepared
to protect your users from themselves and hackers.

Detecting IM traffic
In addition to a network analyzer, you can detect IM traffic by using the following
tools:

IM traffic-detection tools from Akonix (www.akonix.com) work like a
network analyzer.

Rogue Aware (www.akonix.com/products/rogueaware.asp) is a free
tool. Rogue Aware detects such traffic on the network as IM and other P2P communications (such as Kazaa and Gnutella) and file sharing on the network. I recommend that you check it
out and use this tool as part of your ethical hacking toolkit. Ideally, you
install it on a computer that’s connected to a monitor port on a switch
or a hub adjacent to your firewall to ensure that you see all the traffic.

Akonix’s Enforcer and L7 Enterprise are commercial utilities that have
more functionality. Other vendors offer similar solutions, such as FaceTime
Communications (www.facetime.com) and IM Logic (www.imlogic.com).
If you can justify the cost — which is relatively easy — I recommend that
you check these products out.

Desktop auditing utilities can show you which applications are installed
and their specific settings. Such products as Ecora’s Enterprise Auditor
(www.ecora.com/ecora/products/enterprise_auditor.asp),
Microsoft’s Systems Management Server (www.microsoft.com/
smserver/default.asp) and some lower-end shareware tools can
offer this type of functionality.

Maintenance and configuration
In addition to the tools listed in the previous section, you can implement
these IM hacking countermeasures:

User behavior:
• Have a policy banning or limiting the usage of all P2P software.
• Instruct users not to open file attachments or configure their IM
software to share or receive file attachments.
• Instruct users to keep their buddy lists private and not share their
information.

System configuration:
• Change default IM software installation directories to help eliminate
automated attacks.
• Apply all the latest IM software patches.
• Ensure that the latest antivirus software and personal-firewall software
is loaded on each instant-messaging client.
• Ensure that proper file and directory access controls are in place
to effectively give your users the minimum necessary rights for
their jobs. This countermeasure helps keep prying eyes out if
someone can exploit an IM vulnerability.
• If you allow IM on your network for business purposes, consider
standardizing an enterprise-based IM application such as Jabber or
Lotus Sametime. These applications have more-robust and manageable
security options, which can ensure control.

Must Read :--

Password cracking , decrypting , encrypting ..

Malwares , trojans , RATs etc ..