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 Security Presented by: Mohamed Hassa mhassan@cse.psu.edu

An Attack Plan Target System  Pennstate e-mail system (130,000 users )  Expected Results  Disable communication between administration offices,  organizations, professors and students. 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.6x10 6  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? 

The big problem  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.

Problem definition  Internet users receive daily tens even hundreds of emails which falls in the category of spam, phisihing, worms and viruses  These mass mailing attacks originate from zombie machines 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 Records  DNS is used to translate domain Example: cse.psu.edu name to ip address, reverse cse.psu.edu. 7146 IN A 130.203.4.2 lookup and lists mail servers for a psu.edu. 178 IN A 128.118.142.114 certain domain cse.psu.edu. 7116 IN NS psuvax1.cse.psu.edu. cse.psu.edu. 7116 IN NS neuromancer.cse.psu.edu.  Categories of DNS records cse.psu.edu. 7116 IN NS taylor.ems.psu.edu.  A : maps hostname to IPv4 cse.psu.edu. 7116 IN NS leibniz.math.psu.edu. address\ cse.psu.edu. 7200 IN MX 5 psuvax1.cse.psu.edu.  AAAA: maps hostname to IPv6 cse.psu.edu. 7200 IN MX 80 neuromancer.cse.psu.edu. address cse.psu.edu. 7200 IN MX 90 meatwad.cse.psu.edu.  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

Contributions  Build a software prototype that identifies mass mailing activities by observing DNS MX requests from a client.  Reasons why the system is appealing (what they claim):  Speed of detecting attacks  Ability to detect zero-day worms  Fast response by blocking port 25 of the melecious client  Low false positives  Ease of deployment

Related work  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

Methodology  How it works? Normal Mail delivery Malicious Mail delivery

Methodology 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 ;

Solution and results  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

Limitations  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

Conclusion  What is good  KISS  No sophisticated mathematical models or state machines. Just use the basic behavier of the 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 operating systems and applications that requires MX records  They only tested that on one worm.  Solution  Limitations and assumptions makes their solution useless

Take Away  Observing some trivial behavior of protocols could be a way to detect attacks.  Too many limitations and assumption makes the solution less effective  Overall, what do you think about the paper?

Questions? Thank You