Security

and why you need to review yours.

David Busby

Percona Remote DBA EMEA team lead / RDBA Security lead

2014-04-02

Who am I?

• David Busby

– Remote DBA for Percona since January 2013

– 14 some years as a sysadmin

– Paranoid about security and legal agreements.

– Ju-Jitsu instructor for a UK based not for profit club.

– Help to teach computing at a UK Secondary school to children. (volunteer)

2

Agenda

• What is an “attack surface” ?

• Why password complexity is important.

• Why GRANT ALL is a bad idea.

• SELinux `setenforce 1`

• What is a CVE?

• 0-days dispelling the F.U.D

• 5.6 Security

• Q&A

3

What is an “attack surface” ?

• Points at which your system could be attacked.

– Application

– Database

– Physical systems

– Network

– Your employees

– Hosting provider

4

Reducing your “attack surface”

• Application

– Sanitize ALL user inputs

– CSRF / XSRF tokens

– W.A.F e.g. mod_security

– I.P.S (do not leave in I.D.S. mode!)

– Recurring audit procedures

– Mandatory Access Controls (e.g. SELinux)

– Ingress and Egress controls

5

Reducing your “attack surface”

• Database

– Network segregation from application where possible

– Selective GRANT

– Complex passwords

– Avoid “... IDENTIFIED BY 'plaintext_password'” SQL

– Mandatory Access Controls (e.g. SELinux)

– Ingress and Egress controlls

6

Reducing your “attack surface”

• Physical systems

– Limit physical access to hardware

– Barclays £1.3M “haul” could have been avoided (Image credit BBC UK)

– “Social engineering” just a new term for con artistry.

– Challenge “implied trust” a Badge / Uniform != identification

– Don't rely only on biometrics (just ask the

Mythbusters about “unbeatable fingerprint readers”)

– Remove unneeded service and devices from your hardware (You're rackmount system

probably doesn't need bluetooth).

7

Reducing your “attack surface”

• Network

– Selective ACL (even if it's only iptables)

iptables -N MySQL

iptables -I INPUT -j MySQL

iptables -A MySQL -s aaa.bbb.ccc.ddd/CIDR -p tcp –dport 3306 -m comment –comment “application range access to MySQL” -j ACCEPT

– MySQL doesn't need to be accessible from everywhere on the internet

– Lest we forget CVE-2012-2122

– Segregation

– I.P.S

– I.D.S

8

Reducing your “attack surface”

• Employees (Layer 8 / Meat ware)

– Awareness training

– Social media betrays a wealth of information

– B.Y.O.D your “smart” phone is perhaps the single largest repository of personal

information you own.

– Physical attacks: Theft “Wanna see a magic trick with your phone?”, lock screen

bypasses, debug abuse (p2p-adb, vendor “hidden” USB host debug), NFC

– Remote attacks: Karma / Jassegar, App (e.g. crafted apk) malware, Bluetooth (

android remote bluetooth (bluedroid) crash)

9

Reducing your “attack surface”

• Employees (Layer 8 / Meat ware) cont.

– Malicious H.I.D devices: Teensy Duino HID , DLP Bypass ,

– Malicious Thunderbolt chain devices (still theory at the time of writing).

– Challenge identity and “implied trust”

It's OK to ask for ID!

– “Hello I'm calling from the computer security center we're receiving alerts about the

virus on your windows machine ...”

– “Wouldn't you like a christmas tree in your bankaccount sir?” (Fonejacker)

10

Reducing your “attack surface”

• Teensy Duino H.I.D

11

Reducing your “attack surface”12

Reducing your “attack surface”

• Certain allowances must be made.

– Trust in Service / Hosting provide (ensuring you're done your own due diligence).

– You want to know about their upt ime S.L.A. why not ask about any regulatory

compliance they have been subject to as well?

PCI, SOX, HIPAA ... etc.

– Trust in mobile networks .. however GSM is broken and there's lots of

“fun” to be had with femtocells.

13

Why rigid grants are important

• How often do you see:

– “ALL PRIVILEGES ON *.*”?

e.g. cacti, phpmyadmin

– “WITH GRANT OPTION” aka “The Keymaker”

– Also need to be concerned about Super_priv, Create_routine, Insert_priv, FILE.

14

Why rigid grants are important

• SUPER

– Kill any process

– Stop/reset slaves

– Write regardless of read_only

– Part of “ALL”

• FILE && Create_routine

– We're going to abuse this shortly to inject a malicious UDF.

• INSERT_Priv: could be used to insert directly into mysql schema tables, create users + access.

15

Why rigid grants are important

• WITH GRANT OPTION

– Get's it's very own slide.

– “The keymaker”

– “keys to the kingdom”

– No internet facing application should need to create grants.

16

Why password complexity is important

• Consider the following

– I've compromised your application.

– Application MySQL users does not have sufficent privileges to escalate the compromise

into the DB server.

– However it does have privileges to select on mysql.user and obtain a “hashdump”

– So now I want to go after an account with more privileges.

17

Why password complexity is important

• We're going to “recover” the passwords for the following

ACA068D24BC58DB72E9D3C2D8D29D43FB6F674D9

B415DD9C4FB5EF59FE80C4FEBC1F9C715E6E97C4

F469EBEEF4AD5F9DE9A0703EABF87DD88A7AF52D

CB7DFF0540F8C51BF178A1502A286FB8F4A2691E

F49091CCA44CEC66E65D3D97EA2C3F92D7636734

– Don't believe me?

18

Why password complexity is important19

Why password complexity is important

• We've going to “recovered” the passwords

MUCH: ACA068D24BC58DB72E9D3C2D8D29D43FB6F674D9

PASS: B415DD9C4FB5EF59FE80C4FEBC1F9C715E6E97C4

SUCH: F469EBEEF4AD5F9DE9A0703EABF87DD88A7AF52D

BAD: CB7DFF0540F8C51BF178A1502A286FB8F4A2691E

WOW: F49091CCA44CEC66E65D3D97EA2C3F92D7636734

Fedora 19 x64, AMD catalyst 13.11, oclHashcat 1.01 Kernel 3.12.9-201 2 x AMD 7750

20

Why password complexity is important

• Alternative methods

– “sniff” network packets hoping to capture a privileged user MySQL handshake

SHA1(password) XOR SHA1(salt <concat> SHA1(SHA1(password)))

– MySQL 5.5 password hash is simply SHA1(SHA1(password))

21

Why password complexity is important

• Know what you're up against.

– oclHashcat (from the demo) uses openCL for GPU base hash calculation

In the demo we just used “brute force” which easily does 270M/s

– pre-computed hash tables (database / file with computed hashes with their original

counterpart).

– Skullsecurity.org is a great resource for lists

22

Why password complexity is important

• Conclusion? The greater the complexity of the password:

– The longer it takes to derive from its hash.

– The less likely it is to be on any pre-computed list.

– Increases the time for “privilege escalation” (via the demoed method).

– Increases the potential for remediation to occur “before things get worse”.

23

SELinux: `setenforce 1`

• The what before the why

– SELinux is a M.A.C which uses “labels”

– I'll cover in brief the “targeted” policy (not MLS / Strict)

– /etc/selinux/config

SELINUX=enforcing

SELINUXTYPE=targeted

24

SELinux: `setenforce 1`

• Labels

– SELinux contexts applied to files, ports, etc.

“user:role:type:level” level is optional and the targeted policy is only really

interested in the “type”

– Type enforcement (policies)

– A process is running in context X

– X is allowed access to a resource with context Y

– But not context Z

25

SELinux: `setenforce 1`

• Context X (mysqld_t)

– Context Y: You want this process to be able to access

/var/lib/mysql (mysqld_db_t)

/var/log/mysql (mysql_log_t)

*:3306 (mysql_port_t)

– Context Z: But probably not

/etc/passwd (passwd_file_t)

/etc/shadow (shadow_file_t)

http_port_t, ssh_port_t, etc.

26

SELinux: `setenforce 1`

• Many standard linux utilizes take the -Z argument.

– ls -Z /var/lib/mysql/ibdata1

-rw-rw----. mysql mysql unconfined_u:object_r:mysqld_db_t:s0

/var/lib/mysql/ibdata1

– ps -Z (system_u_system_r_mysqld_t:s0)

– id -Z (unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023)

27

SELinux: `setenforce 1`

• Many people still feel this happens when SELinux is enabled

28

SELinux: `setenforce 1`

• `setenforce 0`

– Permissive, not OFF

useful for debugging but always ensure you got back to `setenforce 1`

– New tools make things easier

setroubleshoot-server, libselinux-python

– “Most” issues are just incorrect labeling.

– A couple “gotchas”: New files / Dirs inherit contexts, Moved/copied files / dirs keep

their original contexts.

29

SELinux: `setenforce 1`

• So it's useable, why should I care?

– Additional layer of security

– Arrests “out of context” behavior

– Unlike D.A.C which “trusts running software” - assumes it should have access to

everything the user it is running as can.

– We're going to see just how bad things can get

30

The worst case scenario

• “Perfect storm” example

– Command line injection present in web app or CVE-2012-1823 PHP CGI cli injection.

– `setenforce 0`

– “BAD” Grants: ALL PRIVILEGES ON *.*

– “BAD” File (D.A.C) Permissions

– Attack flow:

1. Deploy PHP shell to web server and “pop” a reverse shell

2. Deploy UDF to the MySQL server and “pop” a reverse shell

31

The worst case scenario

• DISCLAIMER!

– We're showing abused of everything we have already noted as being “bad”

– This isn't a “how to hack” (legal wouldn't let me do that :-()

– You can repeat everything here yourself! (GPL code + resources @ Github (current code

will be committed after the conference))

– This demo is on a local VM environment purposely made vulnerable only.

– For informational purposes only.

– Use at your own risk.

32

The worst case scenario33

The worst case scenario34

What is a CVE?

• Common Vulnerabilities and Exposures

– Common classification and notation of known vulnerabilities.

– $vendors and $researchers use this to classify vulnerabilities (along with CVSS scoring)

– Not always used as intended however, may “Unspecified vulnerability … unknown

vectors” e.g. CVE-2013-3826

– A CVE filing can be used to check for patches releases.

– Or contact a vendor requested a patch.

– Even where enough detail exists use J.I.T. methods to mitigate. e.g. CVE-2013-2094

could be mitigated using SELinux

35

What is a CVE?

• Syntax from Jan 2014 changed

36

What is a CVE?

• Additional resources

– Open Source Vulnerability Database

– Secunia

– National vulnerability Database

– Exploit DB

– /r/netsec

– Full disclosure list has unfortunately closed

37

0-days dispelling the F.U.D.

• Zero Day / Oh Day

– An attack / exploit using an unknown vulnerability

– Beware of “claims” which are just posturing.

– Proof or S.T.*.* (look for p.o.c code and test in a lab environment)

– “hardening” is the best defense you can take against the “unknown”

– Reducing your attack surface is essential.

– Prepare for the worst and hope for the best.

– “By failing to prepare, you are preparing to fail.” - Benjamin Franklin

38

0-days dispelling the F.U.D.

• It's all about being prepared

– Build “hardened” systems from the “ground up”

– Avoid the “foolish man who build his house on the sand”

– Orchestration tools make management EASY! (Ansible, puppet, chef, salt … etc.)

39

5.6 Security

• Password Expiration policy

• Password Validate plugin

– validate_password_policy = LEVEL

– LOW

>= 8 chars

– MEDIUM

LOW && >=1 number && >=1 upper case

– STRONG

MEDIUM && substrings >=4 chars must not appear in defined dictionary.

40

5.6 Security

• Customizable

– validate_password_dictionary_file = ''

– validate_password_length = 8

– validate_password_mixed_case_count = 1

– validate_password_number_count = 1

– validate_password_special_char_count = 1

• Circumventable

41

5.6 Security

• Pluggable authentication

– e.g. sha256 password

mysql.users.authentication_string

– “opens the door” for stronger algorithms

• SSL

– Tunable cipherspec

--ssl-cipher=DHE-RSA-AES256-SHA:AES128-SHA

– Fairly high performance overhead

– Client can not “force” an SSL connection / TLS cipherspec

42

Q&A

Thank you for attending.

Questions?

43