Addressing SMTP-based Mass-Mailing Activity Within Enterprise - - PowerPoint PPT Presentation
Addressing SMTP-based Mass-Mailing Activity Within Enterprise Networks. David Whyte, Paul van Oorschot and Evangelos Kranakis. 22st Annual Computer Security Applications Conference (ACSAC), December 2006. Miami, Fl. CSE 544- Advanced System
David Whyte, Paul van Oorschot and Evangelos Kranakis. 22st Annual Computer Security Applications Conference (ACSAC), December 2006. Miami, Fl. CSE 544- Advanced System Security Presented by: Mohamed Hassa mhassan@cse.psu.edu
Target System
Pennstate e-mail system (130,000 users )
Expected Results
Disable communication between administration offices,
Take down or affect some services (psu email, listserv, angel)
How we will do it:
Generate a hit list for the psu domain (xyz123@psu.edu)
“[a-z][a-z0-9] [a-z0-9][0-9]{0,5}@psu.edu” Size:3369.6x106 Time:3 days
filter the list to 130,000 using psu directory search
find a group of zombie machines (with smtp engine) where we can launch the attack from (not hard to find “botnet”)
What will we send:
spam, phishing, attachment with viruses
few hundred messages for each user might take the server down (servers are overloaded)
more fun! malformed spam will also take some clients down (outlook, Eudora,..)
How can we prevent that?
Internet protocol suite
Introduced in early 70’s and standardized in early
80’s
Is the basis for the Internet Insecure by definition
SYN attacks, IP Spoofing. Connection Hijacking,
ICMP attacks, DNS attacks,…
Application Level vulnerabilities (a lot in http,
smtp pop,…) How can we fix it
Replace it. Is that possible ?!!
Unfortunately no
Cost (Hardware, software,)
Time, lack of coordination
So if we cannot replace it we find work around to
prevent attacks.
Internet users receive daily tens
even hundreds of emails which falls in the category of spam, phisihing, worms and viruses
These mass mailing attacks
without the owner’s knowledge
Using the interaction between
smtp engines and DNS, it is possible to detect malicious mass mailing activity within an enterprise network
DNS is used to translate domain
name to ip address, reverse lookup and lists mail servers for a certain domain
Categories of DNS records
A : maps hostname to IPv4
address\
AAAA: maps hostname to IPv6
address
CNAME: for hostname aliasing MX: maps a domain to a list of
mail servers
NS: maps a domain to a list of
domain servers
PTR: maps IPv4 address to
hostnam
Example: cse.psu.edu cse.psu.edu. 7146 IN A 130.203.4.2 psu.edu. 178 IN A 128.118.142.114 cse.psu.edu. 7116 IN NS psuvax1.cse.psu.edu. cse.psu.edu. 7116 IN NS neuromancer.cse.psu.edu. cse.psu.edu. 7116 IN NS taylor.ems.psu.edu. cse.psu.edu. 7116 IN NS leibniz.math.psu.edu. cse.psu.edu. 7200 IN MX 5 psuvax1.cse.psu.edu. cse.psu.edu. 7200 IN MX 80 neuromancer.cse.psu.edu. cse.psu.edu. 7200 IN MX 90 meatwad.cse.psu.edu.
Speed of detecting attacks Ability to detect zero-day worms Fast response by blocking port 25 of the melecious
Low false positives Ease of deployment
Zoe et al. Modeled a mass mailing worm that
makes use of users behavior
Sidiroglou et al. build a system to detect zero
day attacks by analyzing email content
Gupta et al. use specification based anomaly
detection that looks for change in mail traffic.
Wong et al. characterize mass mailing activity
wrt network traffic traces
Musashi et al. a similar work that process DNS
logs looking for MX queries associated with PTR queries
Normal Mail delivery Malicious Mail delivery
Hypothesis
MX query behavior from ordinary clients are different then the behavior of malicious client
Experiment to prove the hypothesis
A university network of 300 users (heterogeneous environment)
Monitored all internal and external DNS traffic and MX query activityfor a week
Results of the Experiment
Only 5 clients made MX query request. One was running SpamAssassin and the second is a mis-configured client and the other 3 are unknown !! (DHCP assigned)
Conclusion
most clients don’t need to perform MX queries (assuming that this network is representative)
Any client performing an MX query (not an authoritative mail server nor white listed) is considered malicious ;
The prototype
The solution is a linux box placed over the network (probably
at the gateway)
It detects any client performing an MX query and contain that
client by blocking port 25 using iptables.
To deal with false positives a threshold can be configured to
allow blocking after certain number of MX queries
Also a whitelist is added to exempt some clients from the
detection mechanism
Results
The system was able to prevent contain and prevent a worm
aby detecting the first MX query and blocking the client
What Was mentioned
Worms can use mail clients rather than
smtp-engines. Therefore, they will go undetected because they use normal mail delivery
The malicious client could have a
predefined list of mail server to send to. Therefore, it will bypass the DNS server.
DNS queries are done through remote
DNS rather than local DNS (resolv.conf)
Not mentioned
The whitelited clients are the malicious
clients
Not all networks uses local DNS or local
mail servers
It doesn’t prevent relaying attacks
What is good
KISS
No sophisticated mathematical models or state
protocol
Detecting attacks at the source rather than the
destination seems to be a good approach.
What is bad
Approach
The way they proved the hypothesis is lame The network they used is not representative They could have studied more of how different
MX records
They only tested that on one worm.
Solution
Limitations and assumptions makes their solution
useless