cyber side-effects - cloud databases and modern malware

© 2014 Imperva, Inc. All rights reserved.

Cyber Side-Effects: Cloud Databases and Modern Malware

1

Amichai Shulman, CTO, Imperva


Agenda

2

§  Introduction §  The story of a malware and a database § DAMP – Database as a malware platform J § Reflections on malware and DB access § Reflections on DBaaS and DB vulnerabilities § Summary and conclusion § Q&A


Amichai Shulman, CTO, Imperva

3

§ Speaker at Industry Events •  RSA, Appsec, Info Security UK, Black Hat

§  Lecturer on Information Security •  Technion - Israel Institute of Technology

§  Former security consultant to banks & financial services firms

§  Leads the Application Defense Center (ADC) •  Discovered over 20 commercial application vulnerabilities

§  Credited by Oracle, MS-SQL, IBM and others

Amichai Shulman one of InfoWorld’s “Top 25 CTOs”


HII Reports

Confidential 4

§ Hacker Intelligence Initiative (HII) is focused at understanding how attackers are operating in practice •  A different approach from vulnerability research

§ Data set composition •  ~350 real world applications •  Anonymous proxies

§ More than 30 months of data § Powerful analysis system

•  Combines analytic tools with drill down capabilities


The Story of a Malware and a Database

5


Malware Sample

6

§ Obtained sample in June 2013 •  Phishing email

§ Made in Brazil § Uses popular hosting service for Drop and C&C

•  C&C stores functional code and bot management information •  Drop server stores stolen information

§ Uses local SQLOLEDB provider for database communication


Malware Sample – Infection Flow

7

§ Starts with a phishing email •  Notice of debt from known bank in Brazil •  “E-mail verified by windows live anti-spam” •  Link to alleged pdf file (detailing the debt)



8

§ Starts with a phishing email •  Notice of debt from known bank in Brazil •  “E-mail verified by windows live anti-spam” •  Link to alleged pdf file (detailing the debt)



9

§  Link leads to a screen saver file § Practically an executable


Follow the Rabbit

10


§ MIM “attack” between payload and hosted database •  Capture negotiation packet •  Switch from encrypted to plain text •  Connect with plaintext credentials to hosted DB

Follow the Rabbit

11


§ MIM “attack” between payload and hosted database •  Capture negotiation packet •  Switch from encrypted to plain text •  Connect with plaintext credentials to hosted DB

Follow the Rabbit

12


Follow the Rabbit

13

§ After connection is established to DB •  Malware stub invokes stored procedure “retorna_dados”

(retrieve data)

•  Retrieves 3 binary payloads from table “carrega” (payload) •  Stub selects one (according to column number)

§  Saves it in %AppData%

§  Names it govision.dll


§ VirusTotal results for original binary: 30/46 •  Categorized as “banker”

§ Other 2 binaries less “notorious” achieving 4/47 and 10/47

Follow the Rabbit

14


§ VirusTotal results for original binary: 30/46 •  Categorized as “banker”

§ Other 2 binaries less “notorious” achieving 4/47 and 10/47

Follow the Rabbit

15


Follow the Rabbit

16

§  2nd stored procedure called “add_avs” •  Registers new bot agent in the C&C database


Follow the Rabbit

17

§  2nd stored procedure called “add_avs” •  Registers new bot agent in the C&C database •  Identifier (C volume), version, Windows OS, browsers (Explorer

and FireFox), date and some more ambiguous info “ins###”


Jumping Into the Rabbit Hole

18



19

§ Connecting to the DB and collaborating with the service provider revealed: •  5 C&C databases and 2 Drop servers •  C&C grouped by different binaries in “carrega”

§  CC1.db1, CC1.db2, CC1.db3

§  CC2.db1, CC2.db2

•  Drop servers §  Drop1 – compromised mail accounts

•  Correlated machines from CC1&2 with data in Drop1

§  Drop2 – stolen banking activity information •  From the same bank in initial phishing email



20


C&C Servers

21

§ Similarities •  Same table structure •  Same set of stored procedures •  Some agents found in multiple tables

§  Due to multiple infections / test machines

•  Binaries (divided to 2 groups)

§ Differences •  Mostly disjointed sets of agents •  Names •  Differences in format of stored data

§  Hyphen instead of parenthesis §  Version number


C&C Servers

22

Same machine in all tables


C&C Servers

23

§ Overall ~350 machines infected between Feb-June 2013


C&C Servers

24

§  95% of infections occurred between June 3 – June 10 •  Earlier infection perhaps QA tests •  Attacker ran small simultaneous campaigns – wasn't detected by

anti-spam mechanism


C&C Servers

25

§ OS distribution •  54% use old XP OS •  65.5% enterprise editions


C&C Servers

26

§ OS distribution •  54% use old XP OS •  65.5% enterprise editions


Drop Servers

27

§ DROP 1 •  Compromised email accounts •  SMTP & POP3 servers •  Contact lists

§ Extracted from Outlook or Outlook express § Some “hand picked” accounts were found to be blocked

due to spam §  From April 10 - June 10, 2013 §  ~600 infected machines & 767 compromised accounts §  Thousands of stolen contacts


Drop Servers

28

§ DROP 1 •  Compromised email accounts •  SMTP & POP3 servers •  Contact lists

§ Extracted from Outlook or Outlook express § Some “hand picked” accounts were found to be blocked

due to spam §  From April 10 - June 10, 2013 §  ~600 infected machines & 767 compromised accounts §  Thousands of stolen contacts


Drop Servers

29

§ Drop1 had (only) 7 agents correlated to C&C servers •  Strengthens the hypothesis that these servers are from the same

family •  Size of unknown operation much bigger than we had access to •  Much more C&C servers than Drop servers

§  Infection achieved by multiple small campaigns rather than single large one

§  Botnet army more resilient to server “takedowns”


Drop Servers

30

§ Drop 1 email accounts gives visibility to geographical distribution

§  Top: Brazil, USA, Argentina, Spain


Drop Servers

31


Drop Servers

32

§ Drop2 contains stolen banking activity § Same banking application that was targeted by the

phishing campaign § Each record contains

•  Serial number •  Machine ID •  Unstructured data •  Timestamp

§ No machines were correlated with entries in other databases

§ Over 400 entries from 12 different machines


Drop Servers

33

§ Attackers targeted corporate accounts •  Offer greater financial rewards •  Bank is dedicated to corporate accounts •  The bank itself was not breached

§  Timeline between May 17 - June 15, 2013


Drop Servers

34

§ Attackers targeted corporate accounts •  Offer greater financial rewards •  Bank is dedicated to corporate accounts •  The bank itself was not breached

§  Timeline between May 17 - June 15, 2013


Drop Servers

35

§ Drop2 entries come from 5 different malware versions: •  118, 126, 127, 128, 129 •  Only one machine “evolved” from 128 to 129


Drop Servers

36

§ Version entries by date


Drop Servers

37

§ Entries in same timeframe contain the same “CONTROLE” (session) value

§ Entries are a form of stripped HTML pages sent to the drop server by the malware

§ All accounts are business accounts of small organizations in Brazil


Drop Servers

38





Drop Servers

39





DBaaS as a Malware Service

40


Database as a Service

41

§  For legitimate users •  Easy to setup •  No maintenance needed

§  For criminals •  C&C and Drop servers •  Jeopardize “neighbors”


Database as a Malware Service

42

§ Cheap and safe playground for hackers •  Easy to setup •  Anonymous •  Affordable

§ Hiding in plain sight •  Hacker activity is masked with normal activity •  Difficult to pick up the specific DB used by hacker

§ Resilient •  Certainly impossible to take down the entire DB machine •  Impossible to “hijack” C&C DNS •  IP blacklisting is not possible


Reflections on Malware & DB Access

43


DB Access by Malware

44

§ Embedded Code (TrendMICRO report) § Packaging DB drivers into modern malware modules § Malware access C&C databases § Stuxnet manipulating internal database


DB Access by Malware

45

§ Stuxnet

§ Narilam

•  Updates MSSQL accessible by OLEDB & tamper stored data

§ Kulouz


Reflections on DB Vulnerabilities

46


DB Vulnerabilities

47

§ DB vulnerabilities pose small risk to enterprises § None of the breaches of past decade involving internal

DB were attributed to vulnerabilities §  Internal breaches usually carried out by non technical

perpetrators BUT § Hosted databases are exposed to the web §  “Sitting duck” for criminal hackers


Protocol Layer Vulnerabilities

48

§ DB protocols are a mess •  Proprietary, ill documented (to say the least) •  Designed for internal network use

§  In DBaaS they become web protocols used over public networks

§ CVE-2013-1899 open source PostgreSQL DB •  Sample exploit: psql --host 10.1.1.1 --dbname=”-rpg_hab.conf” –

user=”aaaaaaa” •  DoS of the entire server •  Catastrophic results in shared environment


Knock Knock Jokes

49

§ CVSS 2.0 is the standard for computing risk score of a vulnerability

§ Authentication requirement accounts for 1 point out of 10 §  In a shared DB hosting environment everyone can

authenticate to the DB § CVE-2012-5611 MySQL vulnerability

•  Sample exploit: GRANT select ON MYSQsssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssLqqqqaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.* TO ‘user11’@’%’

•  DoS of the entire server


Who Stole My Cheese?

50


Summary & Conclusion

51


Summary

52

§ Attackers continue to show creativity •  Using cloud DB offering as an alternative to traditional C&C / Drop

servers •  Harder detection and takedown

§ Commercial malware is gradually becoming more “database aware” •  Attackers have the tools to pry into your database •  Next step: autonomous malware targeting internal databases

§ Shared DB hosting platforms imply higher risk •  Exposure to protocol layer vulnerabilities •  Actual vulnerability score is at least 1 point higher


Recommendations

53

§  It’s all about the data, stupid! § While “network” and “end point” hygiene is important,

attackers are ultimately looking for your data •  In large, modern, enterprise networks – infection is inevitable

§ Enterprise must invest in security layers closer to their data assets

§ DB service providers (and their customers) must re-asses risks and invest in virtual patching


Webinar Materials

54

Post-Webinar Discussions

Answers to Attendee

Questions

Webinar Recording Link Join Group

Join Imperva LinkedIn Group, Imperva Data Security Direct, for…

http://www.linkedin.com/groups?home=&gid=3849609


www.imperva.com

55