CS 558 Internet Systems and Technologies



Similar documents
Cross Site Scripting in Joomla Acajoom Component

A Server and Browser-Transparent CSRF Defense for Web 2.0 Applications. Slides by Connor Schnaith

EVILSEED: A Guided Approach to Finding Malicious Web Pages

An analysis of exploitation behaviors on the web and the role of web hosting providers in detecting them

Locking down a Hitachi ID Suite server

JOOMLA SECURITY. ireland website design. by Oliver Hummel. ADDRESS Unit 12D, Six Cross Roads Business Park, Waterford City

Recon and Mapping Tools and Exploitation Tools in SamuraiWTF Report section Nick Robbins

Guidelines for Web applications protection with dedicated Web Application Firewall

Baidu: Webmaster Tools Overview and Guidelines

Web Vulnerability Scanner by Using HTTP Method

Table of contents. HTML5 Data Bindings SEO DMXzone

Poisoned search results: How hackers have automated search engine poisoning attacks to distribute malware.

WEB ATTACKS AND COUNTERMEASURES

Check list for web developers

FortiWeb 5.0, Web Application Firewall Course #251

Web Application Security

Creating Stronger, Safer, Web Facing Code. JPL IT Security Mary Rivera June 17, 2011

Still Aren't Doing. Frank Kim

Recommended Practice Case Study: Cross-Site Scripting. February 2007

How to break in. Tecniche avanzate di pen testing in ambito Web Application, Internal Network and Social Engineering

Web Application Attacks And WAF Evasion

Bank Hacking Live! Ofer Maor CTO, Hacktics Ltd. ATC-4, 12 Jun 2006, 4:30PM

Web applications. Web security: web basics. HTTP requests. URLs. GET request. Myrto Arapinis School of Informatics University of Edinburgh

REAL-TIME WEB APPLICATION PROTECTION. AWF SERIES DATASHEET WEB APPLICATION FIREWALL

EVALUATING COMMERCIAL WEB APPLICATION SECURITY. By Aaron Parke

1. Introduction. 2. Web Application. 3. Components. 4. Common Vulnerabilities. 5. Improving security in Web applications

Webapps Vulnerability Report

Web Security CS th November , Jonathan Francis Roscoe, Department of Computer Science, Aberystwyth University

Hack Proof Your Webapps

CS 356 Lecture 17 and 18 Intrusion Detection. Spring 2013

CS5008: Internet Computing

Ruby on Rails Secure Coding Recommendations

Networks and Security Lab. Network Forensics

ASL IT SECURITY BEGINNERS WEB HACKING AND EXPLOITATION

LASTLINE WHITEPAPER. Large-Scale Detection of Malicious Web Pages

Banking Security using Honeypot

Apache: Analyze Logs for Malicious Activities & Monitor Server Performance

The purpose of this report is to educate our prospective clients about capabilities of Hackers Locked.

ASL IT Security Advanced Web Exploitation Kung Fu V2.0

Where every interaction matters.

Web Security Threat Report: January April Ryan C. Barnett WASC Member Project Lead: Distributed Open Proxy Honeypots

Security Analysis on Craigslist (December 2009)

Grandstream Networks, Inc. UCM6100 Security Manual

WEB SECURITY CONCERNS THAT WEB VULNERABILITY SCANNING CAN IDENTIFY

Rise of the Machines: An Internet-Wide Analysis of Web Bots in 2014

ArcGIS Server Security Threats & Best Practices David Cordes Michael Young

Finding and Preventing Cross- Site Request Forgery. Tom Gallagher Security Test Lead, Microsoft

Sitefinity Security and Best Practices

Malware Analysis Quiz 6

Web and Security 1 / 40

Application Security Testing. Generic Test Strategy

Chapter-1 : Introduction 1 CHAPTER - 1. Introduction

CSE598i - Web 2.0 Security OWASP Top 10: The Ten Most Critical Web Application Security Vulnerabilities

Detecting and Exploiting XSS with Xenotix XSS Exploit Framework

Cross Site Scripting Prevention

Insecurity breeds at home

Adobe Systems Incorporated

[state of the internet] / SEO Attacks. Threat Advisory: Continuous Uptick in SEO Attacks

Acunetix Website Audit. 5 November, Developer Report. Generated by Acunetix WVS Reporter (v8.0 Build )

Using Nessus In Web Application Vulnerability Assessments

HTTPS Inspection with Cisco CWS

Out of the Fire - Adding Layers of Protection When Deploying Oracle EBS to the Internet

Mingyu Web Application Firewall (DAS- WAF) All transparent deployment for Web application gateway

SECURING APACHE : THE BASICS - III

Web Application Threats and Vulnerabilities Web Server Hacking and Web Application Vulnerability

Detecting Web Application Vulnerabilities Using Open Source Means. OWASP 3rd Free / Libre / Open Source Software (FLOSS) Conference 27/5/2008

Detection of SQL Injection and XSS Vulnerability in Web Application

Security Threat Kill Chain What log data would you need to identify an APT and perform forensic analysis?

Overview of the Penetration Test Implementation and Service. Peter Kanters

3. Broken Account and Session Management. 4. Cross-Site Scripting (XSS) Flaws. Web browsers execute code sent from websites. Account Management

Honeypots & Honeynets Overview. Adli Wahid Security Specialist, APNIC.net adli@apnic.net

Client vs. Server Implementations of Mitigating XSS Security Threats on Web Applications

Intrusion detection for web applications

Secure Web Development Teaching Modules 1. Threat Assessment

INFORMATION SECURITY REVIEW

Hardening Joomla 1. HARDENING PHP. 1.1 Installing Suhosin. 1.2 Disable Remote Includes. 1.3 Disable Unneeded Functions & Classes

Web Application Security

(WAPT) Web Application Penetration Testing

Removing Web Spam Links from Search Engine Results

OWASP Top Ten Tools and Tactics

CS 161 Computer Security

Simple security is better security Or: How complexity became the biggest security threat

ONLINE RECONNAISSANCE

Web Application Attacks and Countermeasures: Case Studies from Financial Systems

Arrow ECS University 2015 Radware Hybrid Cloud WAF Service. 9 Ottobre 2015

Cross-Site Scripting

Web Vulnerability Assessment Report

SANDCAT THE WEB APPLICATION SECURITY ASSESSMENT SUITE WHAT IS SANDCAT? MAIN COMPONENTS. Web Application Security

Cyber Security Workshop Ethical Web Hacking

Protection, Usability and Improvements in Reflected XSS Filters

Joomla Security Report

Transcription:

CS 558 Internet Systems and Technologies Dimitris Deyannis deyannis@csd.uoc.gr 881 Heat seeking Honeypots: Design and Experience Abstract Compromised Web servers are used to perform many malicious activities. Attackers are constantly searching for vulnerable servers as they provide free resources and have high page ranks. In this work, the authors aim to understand how attackers find, compromise and misuse vulnerable servers. They present heat seeking honeypots that actively attract attackers, dynamically generate and deploy honeypot pages. Then they analyze the logs to identify attack patterns. Introduction Compromised Web servers are utilized for conducting malicious activities such as serving phishing and malware pages, act as open proxies and redirecting user traffic to malicious sites. Almost 90% of Web attacks take place through legitimate but compromised sites. Attackers also populate compromised servers with content that contains popular search keywords in order to poison search results from search engines. Over 50% of this keywords have at least one malicious link to a compromised site. The Heat seeking Web server based honeypots have four components. First they have a module to identify Web pages that are currently targeted by attackers. Previous work has shown that many attackers find vulnerable servers with the help of search engines, therefore the authors look through the search logs of the Bing search engine. Then they generate Web pages based on these queries without setting up the actual software that is targeted. At the next step these pages are advertised through search engines, and all received traffic is logged. Finally they analyze the honeypot logs, with custom methods of separating attacker traffic from crawler and legitimate traffic. Heat seeking honeypots have the following attractive properties: 1. Honeypot pages can be generated automatically without understanding the latest exploits or knowing which software is affected.

2. Web pages are put up to attract attackers, without the heavy overhead of installing the real software. After analyzing attacker visits, if additional information is needed about a particular attack, a high interaction honeypot can be set up by installing the actual software. 3. Since the honeypot pages look identical to pages generated by actual software, the attackers assume the presence of the software and conduct attacks. This allows the monitoring of a wide range of attacks. Obtaining attacker queries Attackers often use two methods to find vulnerable Web servers. The first is to perform brute force port scanning on the Internet, and the second is to make use of Internet search engines. For example, a query phpizabi v0,848b c1 hfp1 to a search engine will return to the attacker a list of Websites that have a known PHP vulnerability. SBotMiner and SearchAudit is used to automatically identify malicious queries from attackers in the Bing log. Attacker queries are grouped and used to generate regular expressions. For example: inurl:/includes/joomla.php [a z]{3,7}. From each such group, most popular query is picked and fed to the next component. Creation of honeypot pages Each query obtained by the previous step is issued to Bing and Google search engines. Then the top three results are picked to be emulated. A crawler fetches those URLs and other elements required, such as images and stylesheets. All Javascript content is stripped and all links are rewritten to point to the local versions. The HTML content is then encapsulated in a PHP script which logs all information regarding each visit to a database. The URL structure of the original pages is designed to be the same in the emulated ones. In some occasions, the authors manually install a few common Web applications that are frequently targeted in separate VMs. Advertising honeypot pages to attackers The URLs of the honeypot pages are submitted to the search engines. Surreptitious links pointing to the honeypot pages are then added in other public Websites in order to boost their chance of being delivered in response to malicious queries to a search engine. Detecting malicious traffic Heat seeking honeypots expect three types of traffic. Malicious traffic, crawler traffic and legitimate user traffic.

Known Crawlers One way of identifying crawlers is from their agent strings. For example the Google crawler uses Mozilla/5.0 (compatible;googlebot/2.1;+http://www.google.com /bot.html) as its user agent. The IP address of the crawler should also match the organization it claims to be from. Unknown Crawlers There are two types of links that a crawler can visit, static and dynamic links. A static link can be visited many times but a dynamic only once. By analyzing the Bing logs, regular expressions matching the groups of dynamic links are generated. The group of dynamic links is called E. Links that doesn t match these sets are the crawlable group C. A crawler should access a large fraction of the URLs (P) with a threshold K = P / C and outside of group C, only pages from group E. Malicious Traffic Attackers try to access non existent files or files that were not meant to be publicly accessed, or to provide spurious arguments to scripts, assuming that the full software package is installed and running. Since the exact set of links that are present in each of the honeypots is known, they can be treated as a whitelist. Requests for links not in the whitelist are considered suspicious. Crawler Visits The Web honeypots consist only of static HTML pages and the software honeypots have many dynamic links. At the figure below we can see that Google, Bing

and Yahoo crawlers visited all the static links but the set of the dynamic links is visited by only one crawler. Totally they found 16 ASes (comprising 375 different IP addresses) crawling more than 75% of the hosted pages, and another 18 ASes (comprising 79 IP addresses) visiting less than 25% of the pages. Therefore 75% is picked as the threshold K, and anyone visiting more than this is considered a crawler, while others are considered legitimate users that reach the honeypot pages. Attacker Visits After eliminating crawler visits and legitimate traffic, 5,980 attacker IP addresses are responsible for 44,696 visits. Different pages received drastically different number of attacks. The most popular honeypot page with over 10,000 visits was for a site running Joomla, a content management system. Comparing Honeypots 1. Web server : Just a Web server (Apache) running on a machine that can be publicly accessed on the Internet. The machine has no hostname, so the only way to access the machine is by its IP address. There are no hyperlinks pointing to the server, so it is not in the index of any search engine or crawler. 2. Vulnerable software: Four commonly targeted Web applications are installed. The application pages are accessible on the Internet, and there are links to them on public Web sites. Therefore, they are crawled and indexed by the search engines. 3. Heat seeking honeypot pages: These pages are generated as described before. They are simple HTML pages, wrapped in a small PHP script which performs logging. Similar to software pages, the honeypot pages are also crawled and indexed by search engines.

All three setups were deployed for a period of 3 months. At the figure below we can see that Heat seeking honeypots that only advertise that the actual software is running are as good at attracting attackers as the real software. Attacks Seen The next figure shows which attacks are observed by each setup. In general the heat seeking honeypots receive instances of almost all the different attacks. The software honeypot mainly sees two types of attacks: attackers trying to register accounts and post in the forums and comments (COMMENT), and attackers trying to access the administrator console on these Web applications (ADMIN). The Web server mostly sees requests that check if it is accessible as an open proxy. Additionally, in spite of there being no running software, attackers still try to probe for file disclosure and other vulnerabilities.

Applying whitelists to the Internet The authors found servers whose HTTP access logs are indexed by search engines, took a random set of 100 such servers and obtained their access logs. A request is defined to be from an attacker, if it tries to fetch a link which isn t whitelisted (i.e., a link which has not been accessed by a crawler). Since this heuristic would lead to falsely flag any dynamically generated links as attack traffic, an additional requirement is placed: the requested link should not be present on the server, i.e., the request results in an HTTP404 error. The next figure plots what fraction of each site s non crawler traffic is from attackers. Only sites that had at least 25 visits in all are considered. For 25% of the sites, almost 90% of the traffic came from attackers; i.e., less than 10% of the traffic was due to legitimate visitors. This use of whitelists suggests that one may rely on public Web server logs to augment information obtained from honeypots for attack detection and analysis. Conclusions In this paper, heat seeking honeypots were presented, which deploy honeypot pages corresponding to vulnerable software in order to attract attackers. They generate honeypot pages automatically without understanding the latest exploits or knowing which software is affected. During three months of operation, the prototype system attracted an order of magnitude more malicious traffic than vanilla Web servers, and captured a variety of attacks including password guesses, software installation attempts, SQL injection attacks, remote file inclusion attacks, and cross site scripting (XSS) attacks. The system can detect malicious IP addresses solely through their Web access patterns, with a false negative rate of at most 1%. Heat seeking honeypots are low cost, scalable tools and that help us to understand attackers targets and methods, and that their use can effectively inform appropriate monitoring and defenses.