Transcript Searching the Searchers with SearchAudit

Searching the Searchers
with SearchAudit
JOHN P. JOHN
FANG YU
YINGLIAN XIE
MARTÍN ABADI
ARVIND KRISHNAMURTHY
PRESENTATION BY SAM KLOCK
Motivation
We can find this via a Google search
Motivation (cont’d)
 Search engines open opportunities for attackers
 Construct clever queries
 Find vulnerable sites
 Plant malware; spam (e.g., MyDoom)
 Do so stealthily and cheaply
 Mitigation strategy: identify malicious queries
 May be able to deny results to user
 Identify attackers (probably bots)
 Interpret strategy, then anticipate and prevent
 The question: how to do so
Proposed Approach
 SearchAudit

Framework for generating
malicious queries
 Input:


Seed set of known
malicious queries
Search logs
 Output:


Large set of suspicious
queries
Regular expressions
matching queries
Seed set
Search logs
inurl:gotoURL.asp?url=
filetype:asp
inurl:"shopdisplayprod
ucts.asp"
ext:pl inurl:cgi
intitle:"FormMail *"
-"*Referrer" -"*
Denied" -sourceforge
-error -cvs -input
filetype:cgi
inurl:tseekdir.cgi
...
SearchAudit
inurl:gotoURL.asp?url=
inurl:gotoURL.asp?url=
filetype:asp
inurl:gotoURL.asp?url=
filetype:asp
inurl:"shopdisplayprod
filetype:asp
inurl:"shopdisplayprod
ucts.asp"
inurl:"shopdisplayprod
ucts.asp"
ext:pl
inurl:cgi
ucts.asp"
ext:pl
inurl:cgi
intitle:"FormMail
ext:pl
inurl:cgi *"*"
intitle:"FormMail
-"*Referrer"
-"*
intitle:"FormMail
*"
-"*Referrer"
-"*
Denied"
-sourceforge
-"*Referrer"
-"*
Denied"
-sourceforge
-error
-cvs-sourceforge
-input
Denied"
-error
-cvs -input
filetype:cgi
-error
-cvs
-input
filetype:cgi
inurl:tseekdir.cgi
filetype:cgi
inurl:tseekdir.cgi
...
inurl:tseekdir.cgi
...
...
Expanded set
"/includes/joomla\.php
" site:\.[a-zAZ]{2,3}
"/includes/class_item\
.php"
site:[^?=#+@;&:]{2,
4}
"php-nuke"
site:[^?=#+@;&:]{2,
4}
"modules\.php\?op=modl
oad" site:\.[a-zAZ0-9]{2,6}
Regular expressions
Proposed Approach (cont’d)
 Needed to implement:
 Seed set: milw0rm.com
 Search logs: Microsoft Research  Bing
 Way to expand seed set into more queries
 Way to infer regular expressions
 Intended benefits:
 Harvesting lots of information




Three months: ~1.2 TB of logs
Interpret relationship between queries and attacks
Use queries to find potential victims
Stop attacks
SearchAudit
Query
identification
Query analysis
Query Identification: Expansion
 Basic idea: bootstrap on
seed set



Search logs for exact
matches to seed queries
Record IPs of hosts
making seed queries
Add other queries from
those IPs to set

Intuition: make one
malicious query, will
probably make more
 Account for DHCP
Seed queries
Log search
IP addresses
Queries
made on
same day
Queries made
by IPs
Query Identification: Regular Expressions
 Goals:
 Account for variation in
queries
 Take advantage of scripting
 See paper for generation
algorithm
 Compute score for
generated expressions


Lower score: more specific
Goal: discard overly general
expressions (score > 0.6)
 Consolidate to avoid
overlap
 Avoid proxies, public NAT
for performance
 Loopback for more queries
Query Identification: Results
 Data from Bing and milw0rm
 500 queries
 Logs for Feb. 2009, Dec. 2009, Jan. 2010

~2 billion views per month
 System implemented on Dryad/DryadLINQ
 Initial observations:
 Using specificity scores < 0.6
seems to be effective


Based on cookie heuristic
Proxy elimination does not limit
results
Query Identification: Results (cont’d)
 Query expansion:
 122 of 500 queries
matched in logs: 174
unique IPs
 Expanded to 800 unique
queries, 264 IPs
 Regular expressions
matched 3,560 queries,
1,001 IPs
 Incomplete seeds
 Tried with subsets of
original set
 Coverage still good
Query Identification: Results (cont’d)
 Loopback:


Multiple loopbacks got
more results
One iteration is good
enough
 Overall statistics


10,000s IPs each month
100,000s unique queries
each month

Dec. 09: set of unusual
attacker IPs cause spike
Query Identification: Verification
 Want to show queries are
malicious


Sometimes easy: 73% of
queries associated with
security/hacker sites
What about others?
 Individual bots


 Groups of bots

 No ground truth exists


Individual level (one IP)
Group level (multiple IPs)
Data often fixed by
botnets
User agent string
 Metadata for requests

 So: look for bot-like
features
New cookie
Whether a link was clicked

Tendencies dictated by
scripts
Pages viewed per query
 Time between queries

Query Identification: Verification (cont’d)
Substantial variation between host behavior for
normal queries and suspicious queries
Observations on Stage One
 Regular expressions can become obsolete
 Just need fresh logs and a new seed to get new ones
 Attacker awareness of technique yields adaptation
 Example: mix in normal user queries
Goal: trick SearchAudit into identifying as proxy
 Hard to do: needs to be appropriate to time and place
 Anyway: proxy elimination is optimization only



Injecting randomness also possible, but makes querying less
productive
Could obviate cookie heuristic, but it is replaceable
 All attackers need to be careful to succeed
Query Analysis
Query Analysis
 42,000 IPs gave suspicious queries globally
 U.S., Russia, China contribute almost 50%
 10% of IPs gave 90% of queries
 Found 200 regular expressions
 Reveal three kinds of attack-related queries:
 Vulnerable web sites
 Forum spamming
 Phishing on Windows Live Messenger
Queries for Vulnerable Websites
 Queries look for exploitable
inurl:index.php?content=X
server vulnerabilities


http://www.example.com/ind
ex.php?content=X’%20OR%20’
1’%20OR%20‘1=1’
GET variables embedded in
URL (for SQL injection)
Server software with known
vulnerabilities (e.g., status
pages)
 SearchAudit as a defense:
 Pull suspicious queries for
vulnerabilities
 Run queries; gather results
 Inspect results for
vulnerabilities
 Notify sites of vulnerabilities
Queries for Vulnerable Websites (cont’d)
 With identified queries:
 Sampled 5,000 queries
 Obtained 80,490 URLs from
39,475 sites
 Compared to
malware/phishing lists:


3-4% on anti-phishing lists
1.5% on anti-malware lists
 SQL injection vulnerability:
 Add a single-quote to
variable in URL
 Look for SQL error
 12% of examined URLs
showed an error
Queries for Forum Spamming
 Query motivation:
 Find scriptable forums
 Good for spam, PageRank
 Found 46 applicable
regular expressions
 Most IPs show transient
behavior: probably bots

All regular expression
groups show at least one
group similarity feature
 IPs got less aggressive
over time: more stealthy
Queries for Forum Spamming (cont’d)
 Validation
 Project Honey Pot
Dynamically generate email address for each
visiting IP
 E-mail received: must be
spam


12% of all IPs listed (vs.
0.5% for normal IPs)
 Applications
 Use queries to find and
clean targeted pages
 Deny results to malicious
queries
Phishing via Windows Live Messenger
 Queries triggered by
normal users

Victim receives message
from a contact



Follow link for party
photos
Taken to fake WLM login
After giving credentials,
redirected to Bing search
for “party”
 Bing search to avoid
costs of hosting
Phishing via WLM (cont’d)
 Detect via query referral
field (source page)


Found two regular
expressions for referrals
Both expressions: victim
username embedded in
URL
 Over 180 phishing
domains for 12 IPs
detected
 Compromised accounts
show different login
behaviors
Conclusion
 Presented framework for finding suspicious queries
 Input: search logs, small set of seed queries
 Output: regular expressions, millions of suspicious queries
 Analyzed suspicious queries
 Identified possible attacks
 Suggested means of prevention
 Generally: attempted to demonstrate relationship
between suspicious queries and the possibility of
attack