VNISA 2 Dec 2014

PART I.
FUZZING FOR UNKNOWN

VULNERABILITIES
SAMI PETAJASOJA VICE PRESIDENT APAC
OLLI JARVA LEAD SECURITY SPECIALIST APAC
VNISA Workshop, 1-2 December 2014
@codenomicon
Fuzzing: Background
2014 All Rights Reserved
12/2/2014
SOFTWARE IS INFRASTRUCTURE
Software is buggy, question is how many exploitable, known or unknown, vulnerabilities
are out there?
We are entering an age where software vulnerabilities can cause more kinetic damage
(impact on physical world) than ever before
12/2/2014
Proactive
Reactive
THE KNOWN AND THE UNKNOWN

1995-2000
Satan/Saint
1999Nessus, ISS
2000Qualys, HP, IBM, Symantec ...

2013: Codenomicon AppCheck
Known Vulnerability Management

Unknown Vulnerability Management (UVM)
SAST Approach
1980PC Lint, Coverity,
Fortify, IBM...
DAST Approach
2000Fuzzing:
Codenomicon
Defensics
Whitebox testing
Blackbox testing
Total
Vulnerability
Management
Unknown Vulnerability Also known as zero-day vulnerability

12/2/2014
ZERO-DAYS: BLACK MARKET COMMODITY
*) Source: http://www.forbes.com/sites/andygreenberg/2012/03/23/
shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/
High monetary reward for zero-days attracting hackers to find them. Organisations need to invest for
discovery to harden their infrastructure.
12/2/2014
PERIMETER SECURITY ISNT ENOUGH SYMANTEC

Antivirus software only catches 45% of malware attacks and is "dead", according to a senior manager
at Symantec.
Remarks by Brian Dye, senior vice-president for information security at the company, which invented
commercial antivirus software in the 1980s and now develops and sells Norton Antivirus, suggest
that such software leaves users vulnerable.
Dye told the Wall Street Journal that hackers increasingly use novel methods and bugs in the
software of computers to perform attacks, resulting in about 55% cyberattacks going unnoticed by
commercial antivirus software.
Same limitations apply to any fingerprint based approaches like

Firewalls, IPS/IDS
12/2/2014
PROGRAMMING BUG == VULNERABILITY
12/2/2014
Fuzzing: How it works
12/2/2014
SO, HOW DO YOU FIND UNKNOWNS?

Fuzzing is the process of sending intentionally invalid data to a product in the
hopes of triggering an error condition or fault. These error conditions can
lead to exploitable vulnerabilities. HD Moore
KNOWN VULNERABILITIES
Fuzzing is about managing your Unknown Vulnerability

exposure
Technology of choice for several industries internationally
UNKNOWN
VULNERABILITIES
12/2/2014
10
FUZZING, ROBUSTNESS TESTING,

NEGATIVE TESTING
Hackers are using Fuzzing to find vulnerabilities
Found vulnerabilities [Zero-Days] are developed to exploits or used to launch DoS attacks
Gaining intelligence to be prepared for cyber attacks
As a mitigation, companies have started to integrate the same security techniques

Fuzzing tools to automate security testing
Harden devices and networks against attacks
Not just against hacking

General quality improvement and preparedness for unexpected
Any software processing input can be fuzzed: network interfaces, device drivers,
user interface.
12/2/2014
11
FUZZING PROCESS
Fuzzer
Anomaly sent
Normal
response
GET AaAaAaAaAaAaAaAaAaAa HTTP/1.1

Accept: image/gif, image/xxbitmap, image/jpeg, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: Keep-Alive
HTTP/1.1 404 Not Found
Date: Wed, 07 Nov 2007 09:49:27
GMT
Server: MyWebServer/2.1 (Linux)
Content-Length: 284
Connection: close
Content-Type: text/html;
charset=iso-8859-1
12/2/2014
Target
12
FUZZING PROCESS FIREWORKS
Fuzzer
Anomaly sent
GET http://[?aAaAaAaAaAa::0]
HTTP/1.1
Accept: image/gif, image/xxbitmap, image/jpeg, */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: Keep-Alive
12/2/2014
Target
13
EXPECTED RESULTS
The purpose of fuzzing is to find flaws
All the found issues are true implementation errors
Typical first indication of problem is target crash
Subset of found issues do have immediate security implications, others may become
exploitable over time
Typically, there are very few or no false positives with Fuzzing
All stacks or services can be vulnerable

Any protocol implementation can fail under negative testing
And based on experience, most do
Complexity level predicts amount of flaws

The more complex the implementation, the more flaws there will be
12/2/2014
14
Different types of Fuzzing
12/2/2014
15
FUZZING TECHNIQUES - RANDOM
Pump random bits at a port

No protocol knowledge
Dumb
Occasionally effective
Shallow code coverage
Something like waiting for the

monkeys to write Shakespeare
Better than no Fuzzing
12/2/2014
16
FUZZING TECHNIQUES - TEMPLATE
Capture and play back

Introduce anomalies during playback
Good: closely resembles capture
Bad: closely resembles capture
Better than Random

May be possible to manually improve
automatically built model
12/2/2014
17
FUZZING TECHNIQUES - GENERATIONAL

Test suite has complete model of the protocol
Implemented according to specifications

RFCs, 3GPP etc.
Systematically fuzzes messages and fields
Smart engine for fuzzing fields, message structure and sequence
Boundary conditions
Bad checksums, lengths
Troublesome strings
12/2/2014
18
GENERATIONAL FUZZING
Fully state aware testing for all
protocols
Smart behavior adaptation based on

SUTs responses
Model based test material

Complete protocol spec coverage
Tests extend to rare and often

vulnerable protocol elements
Not only data on wire
12/2/2014
19
INTELLIGENT ATTACKS DESIGNED TO MAXIMIZE

VULNERABILITY DISCOVERY
Minimizing Infinity
INPUT
ANOMALIES
system under
test
FIELD LEVEL
overflows
integer anomalies
crashes
denial of service
security exposures
degradation of service
thrashing
anomalous behavior
STRUCTURAL
underflows
repetition of
elements
unexpected elements
SEQUENCE
out of sequence
omissions
unexpected messages
repetition of messages
EXPOSE
VULNERABILITIES
SYSTEMATIC
REPEATABLE
INTELLIGENTLY
TARGETED
12/2/2014
20
Fuzzing: Industry adoption
12/2/2014
21
FUZZING: INDUSTRY ADOPTION

Best practices & standards
http://www.cisco.com/web/about/security/cspo/csdl/index.html
IEC 62443
Modern SDLs such as Microsoft SDLC,
Cisco SDLC, Adobe Secure Product Lifecycle (SPLC) and
BSIMM all recognize
that fuzzing has a key role in creating
a secure and rugged software. Furthermore
Its endorsed by giants like Google and IBM.
http://www.microsoft.com/security/sdl/default.aspx
http://www.adobe.com/security/splc/
http://www.ibm.com/developerworks/java/library/j-fuzztest/
http://www.google.com/googlebooks/chrome/
12/2/2014
Vz SIT Lab Entry Criteria (LEC)
22
FUZZING IS PART OF ICS SECURITY CERTIFICATION
12/2/2014
23
IEC 62443 STANDARD SERIES

12 standards originally created for industrial automation
ISA Secure certification process is based in IEC 62443 series
Originally device level security certification
Recently released system level certification process
FDA has recognized IEC 62443 series as foundational

standards for medical device cybersecurity.
The Medical Device Innovation, Safety, and Security Consortium
(MDISS) is basing their vendor requirements on IEC 62443
12/2/2014
24
IEC 62443-4-1 DRAFT

(1) Network robustness testing shall be done for all accessible network interfaces
(2) For each accessible network interface, network robustness testing shall include
fuzzing of all protocols implemented that are recommended or required to be
enabled for normal operation as defined in the security guidelines.
(3) The files or packets that will be "fuzzed" shall be automatically generated so
that a large number of test cases (in the thousands) can be executed.
Latest version, to be ratified soon, will officially require Fuzz

testing for all available communication interfaces
12/2/2014
25
US FOOD AND DRUG ADMINISTRATION (FDA)

TESTING MANDATE FOR CONNECTED MEDICAL
DEVICES
12/2/2014
26
End of Part I. Questions?
12/2/2014
PART II. HOW HEARTBLEED WAS

FOUND
@codenomicon
28
Heartbleed Discovery
12/2/2014
29
HOW WE DISCOVERED HEARTBLEED

Codenomicon develops fuzz testing software
While implementing new fuzzing test suites, interoperability
is usually tested against open source implementations
Testing open source implementation comes as a byproduct
12/2/2014
30
FUZZ TESTING
Fuzzing: Negative testing technique for feeding invalid,
unexpected or random data to SUT
Goal is to find security vulnerabilities and other defects in SUT
File formats and protocol implementations
Does not require access to source code

Can be used for testing proprietary software
12/2/2014
31
HEARTBLEED IS NOT OUR FIRST BIG DISCOVERY

THROUGH FUZZ TESTING
Among hundreds of cases, several have been multi-vendor cases applying to
wide range of services/devices:
Numerous flaws in MIME in 1998
Numerous flaws in ASN.1/SNMP in 2001/2002
Apache IPv6-URI flaw in 2004
Numerous flaws in image formats in 2005

Numerous flaws in XML libraries in 2009
Several flaws in Linux Kernel IPv4 and SCTP in 2010
RSA signature verification vulnerability in strongSwan in 2012

Several OpenSSL and GnuTLS vulnerabilities in 2004,
2008, 2012 and 2014
12/2/2014
32
HOW WE DISCOVERED HEARTBLEED

Heartbleed would not have been found merely by fuzzing and
monitoring for crashes
More sophisticated test oracle was needed
We were developing new SafeGuard features and new test cases for our
TLS fuzzing tool
The newest versions of OpenSSL (1.0.1f) and GnuTLS (3.2.12) were used
as test targets
12/2/2014
HEARTBEAT PROTOCOL
Extension for TLS and DTLS protocols

DTLS: used for figuring out if the other peer is still alive
TLS: used for keeping the connection alive
The peer sends a heartbeat request and the other peer should
respond to it by sending a copy of the request's payload
The use of the Heartbeat extension should be negotiated
during the TLS handshake
12/2/2014
33
34
TLS SESSION
client
server
Client Hello
Server Hello
Server Certificate *
Server Key Exchange *
Certificate Request *
Server Hello Done
Client Certificate *
Client Key Exchange
Certificate Verify *
Change Cipher Spec
Client Finished
Change Cipher Spec

Server Finished
Application data
Heartbeat Request *
Heartbeat Response *
Close Notify (Alert)

Close Notify (Alert)
12/2/2014
35
Test case that drew our attention (1/4)

Valid Client Alert (Close Notify)
12/2/2014
36

Anomalized Client Alert (Close Notify)
12/2/2014
37

Unexpected data check notified us that the amount of received data had been
bigger than it was received with the valid case
Varying sized responses:
12/2/2014
38

Response content:
Decrypted payload:
12/2/2014
39
Heartbeat message structure

RFC 6520:
The Heartbeat protocol messages consist of their type and an
arbitrary payload and padding.
struct {
HeartbeatMessageType type;
uint16 payload_length;
opaque payload[HeartbeatMessage.payload_length];
opaque padding[padding_length];
} HeartbeatMessage;
enum {
heartbeat_request(1),
heartbeat_response(2),
(255)
} HeartbeatMessageType;
12/2/2014
40
The Heartbleed test case (1/2)

Next logical step was to try to request the maximum amount
of Heartbeat payload:
12/2/2014
41
The Heartbleed test case (2/2)

And 64KB of uninitialized memory content was dumped:
12/2/2014
42
12/2/2014
43
12/2/2014
44
What makes Heartbleed so bad
12/2/2014
45
DREARY ASPECT OF HEARTBLEED

Heartbeat protocol support is compiled in OpenSSL by default
OpenSSL does not require the negotiation of Heartbeat
extension
OpenSSL does not require that TLS handshake is completed
before Heartbeat request can be sent
Default OpenSSL installation supported Heartbeat protocol
Vulnerability can be exploited before authentication

OpenSSL copies private key material around the heap during
execution
Attack leaves no traces
12/2/2014
46
WHAT WAS LEAKED?

We have tested some of our own services from attackers perspective. We
attacked ourselves from outside, without leaving a trace. Without using any
privileged information or credentials we were able steal from ourselves the
secret keys used for our X.509 certificates, user names and passwords, instant
messages, emails and business critical documents and communication.
http://heartbleed.com
12/2/2014
47
How to mitigate Heartbleed
12/2/2014
48
HOW TO REACT
Workaround:
Disable Heartbeat functionality by recompiling OpenSSL with
Heartbeat flag off
Fix:
Upgrade OpenSSL library
Afterwards:
Create new secret and public key-pair
Apply for new certificates and revoke old certificates
Change passwords
12/2/2014
49
HOW TO REACT
Reduce the impact:
Forward secrecy (also known as perfect forward secrecy or PFS)
Random stack, zeroed heap, difficult to find keys
Finding statically linked OpenSSL libraries from binaries, embedded

devices, copy & pasted code.
Constant monitoring of applications and device firmware
Fuzzing for more similar weaknesses
12/2/2014
50
Heartbleed aftermath
12/2/2014
51
UNPRECEDENTED AWARENESS
Heartbleed got more publicity than any vulnerability before
Upside
Community was able to react quickly and start mitigating problem
Raised awareness of importance of dealing security vulnerabilities in general
Downside
Haste in mitigation, leading to mistakes
Partly compounded by the fact that mitigation requires multiple steps
False sense of security
12/2/2014
52
LATEST STUDY ON MITIGATION

University of Maryland analyzed HB patch status of over a million popular
websites in US (November 2014):
discovered that while approximately 93 percent of the websites
analyzed had patched their software correctly within three weeks of
Heartbleed being announced, only 13 percent followed up with other
security measures needed to make the systems completely secure
Missed mitigation steps

Many people seem to think that if they reissue a certificate, it
fixes the problem, but, actually, the attack remains possible just as
it did before. So, you need to both reissue and revoke the
certificates, says Dumitras
http://www.umiacs.umd.edu/~tdumitra/papers/IMC-2014.pdf
12/2/2014
53
VULNERABILITIES DRIFTING THROUGH SUPPLY

CHAIN
OPEN
SOURCE
LIBRARY
VENDOR
PRODUCT
SYSTEM
INTEGRATOR
END CUSTOMER
In ideal world: Shared responsibly. Testing should take place in each

stage
In reality: Too much outsourced security with no clear visibility in the
real state of affairs
12/2/2014
54
WHAT THE FUTURE HOLDS: CRITICAL

INFRASTRUCTURE AND OPEN SOURCE
Open source components used in security-critical environment require
testing. It is not safe to assume SW robust and secure. Even widelydeployed open source software may have major flaws
New features need to be tested and analyzed whether they are really necessary
Possible to make mistakes when deploying open source libraries
Contribution to open source projects

OpenSSL project was typically receiving $2,000 in donations a year, and was developed
by a handful of people.
12/2/2014
55
End of Part II. Questions?
12/2/2014
PART III. CHASING ELUSIVE

VULNERABILITIES
@codenomicon
57
Background
12/2/2014
58
FUZZING IS DESIGNED TO FIND VULNERABILITIES

Remember: Bug == Vulnerability
Traditionally in Fuzzing, were finding
Crash level failures
Easy to detect by test solution / tester
But there is more

Elusive vulnerabilities that are not easy to detect
Can still be triggered with Fuzzing
12/2/2014
59
HEARTBLEED BUG
Example of elusive vulnerability
At first glance, only indication was
suspiciosly large size of server replies
Would be very hard for human to notice
from hundreds of thousands of lines from
test logs
Automation is needed
12/2/2014
60
SAFEGUARD FEATURE IN DEFENSICS

Innovative feature in Defensics security testing platform
Detects subtle, yet critical weaknesses that expose network to attacks
Automatically interprets test data, eliminating the possibility of human
error.
Tests things like encryption and authentication
Next step in evolution of Fuzzers
12/2/2014
61
THIS IS WHERE IT STARTED IN 2012
12/2/2014
62
DISCOVERY OF STRONGSWAN BUG IN 2012

Codenomicon discovered in June 2012 a VPN bug, which allowed
anyone to authenticate as a legitimate user to VPN end-point (CVE2012-2388)
The Authentication Bypass vulnerability was triggered by fuzzing, but in

order to identify the bug, one had to manually interpret test result logs
12/2/2014
63
VPN TUNNEL
12/2/2014
64
WHAT DID IT LOOK LIKE
12/2/2014
65
VALID AUTH MESSAGE
12/2/2014
66
ANOMALOUS AUTH GENERATED BY FUZZER
12/2/2014
67
SERVER HANDLING ANOMALOUS AUTH RIGHT
12/2/2014
68
LETS TRY AGAIN
12/2/2014
69
WAIT A SEC, WHAT JUST HAPPENED
12/2/2014
70
THAT OPENED OUR EYES

Impact: Anyone, with no valid credendials, can establish VPN tunnel
An idea arose, what if we could locate these bugs automatically?
We thought, Codenomicon fuzzers already trigger these elusive bugs,
we just need a new analysis method to flag them automatically
No need for a manual log interpretation
12/2/2014
71
THAT REALIZATION WAS WORTH OF PATENT
12/2/2014
72
Defensics SafeGuard feature was born
12/2/2014
73
SAFEGUARD DETECTS FAULTS
Login credentials parsing errors allowing authentication bypass

Certificate validation errors
Weak cryptography usage
Information leakage in error responses
Amplification vulnerabilities
LDAP, SQL injections, Cross-Site Scripting vulnerability
12/2/2014
74
Examples
12/2/2014
75
AUTHENTICATION BYPASS CHECK

Can a hacker bypass our service authentication?
Defensics sends an empty password in authentication
System under test verifies username and password, accepts it and
sends a normal response
Defensics notices that password verification has not been implemented
correctly as session proceeds normally. Check is flagged as failed.
Example: StrongSwan authentication CVE-2012-2388
12/2/2014
76
CRYPTO AND CERTIFICATE CHECKS

Are you concerned about Man-in-the-middle attacks or eavesdropping?
Defensics changes the CAs validating signature for server TLS certificate
Certificate is sent to system under test as TLS server response
- System under test verifies certificate, accepts it and sends a
normal request
Defensics notices that certificate verification has not been implemented
correctly as session proceeds normally. Check is flagged as failed.
Example: Apple Goto Fail; GnuTLS Certificate validation bug
12/2/2014
77
INSUFFICIENT RANDOMNESS CHECK

Worried about someone hijacking your session during banking or online
shopping?
Defensics creates multiple sessions to a web server
Defensics receives web form with a random token protecting against
cross-site request forgery
Token is compared to previous sessions. Token is noticed to be the same
as previous session. Check is flagged as failed.
Example: static XSRF token in web application
12/2/2014
78
AMPLIFICATION CHECK
Does the system configuration enable it to be used for DDoS attacks?
Defensics executes a valid session with system under test
In later tests, erraneous information is sent to system under test
- System under test parses the message data incorrectly, sends a
large amount of memory in response
Defensics compares received after-error message to valid message,
notices the data reeived is much larger. Check is flagged as warning
Example: Heartbleed, NTP Protocol amplification, DNS amplification
12/2/2014
79
HOW BAD GUYS ARE EXPLOITING AMPLIFICATION

TO LAUNCH DDOS
But Im at
192.98.1.2!!
Im at
192.98.1.2
Vulnerable DNS/NTP Servers

Modern DDoS is
not about
choking the
victim system
Its about
choking the pipe
12/2/2014
Send me
DNS/NTP
Reply
80
THANKS!
End of Part III. Questions?
12/2/2014

VNISA 2 Dec 2014

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

VNISA 2 Dec 2014

Hochgeladen von

Copyright:

Verfügbare Formate

PART I.

FUZZING FOR UNKNOWN

2014 All Rights Reserved

2014 All Rights Reserved

THE KNOWN AND THE UNKNOWN

2000Qualys, HP, IBM, Symantec ...

Known Vulnerability Management

Unknown Vulnerability Also known as zero-day vulnerability

ZERO-DAYS: BLACK MARKET COMMODITY

PERIMETER SECURITY ISNT ENOUGH SYMANTEC

Same limitations apply to any fingerprint based approaches like

PROGRAMMING BUG == VULNERABILITY

2014 All Rights Reserved

Fuzzing: How it works

2014 All Rights Reserved

SO, HOW DO YOU FIND UNKNOWNS?

Fuzzing is about managing your Unknown Vulnerability

FUZZING, ROBUSTNESS TESTING,

As a mitigation, companies have started to integrate the same security techniques

Not just against hacking

2014 All Rights Reserved

GET AaAaAaAaAaAaAaAaAaAa HTTP/1.1

FUZZING PROCESS FIREWORKS

2014 All Rights Reserved

All stacks or services can be vulnerable

Complexity level predicts amount of flaws

Different types of Fuzzing

2014 All Rights Reserved

FUZZING TECHNIQUES - RANDOM

Pump random bits at a port

Something like waiting for the

2014 All Rights Reserved

FUZZING TECHNIQUES - TEMPLATE

Capture and play back

Better than Random

2014 All Rights Reserved

FUZZING TECHNIQUES - GENERATIONAL

Implemented according to specifications

Systematically fuzzes messages and fields

Smart engine for fuzzing fields, message structure and sequence

2014 All Rights Reserved

Smart behavior adaptation based on

Model based test material

Tests extend to rare and often

2014 All Rights Reserved

INTELLIGENT ATTACKS DESIGNED TO MAXIMIZE

2014 All Rights Reserved

Fuzzing: Industry adoption

2014 All Rights Reserved

FUZZING: INDUSTRY ADOPTION

2014 All Rights Reserved

Vz SIT Lab Entry Criteria (LEC)

FUZZING IS PART OF ICS SECURITY CERTIFICATION

2014 All Rights Reserved

IEC 62443 STANDARD SERIES

FDA has recognized IEC 62443 series as foundational

IEC 62443-4-1 DRAFT

Latest version, to be ratified soon, will officially require Fuzz

US FOOD AND DRUG ADMINISTRATION (FDA)

2014 All Rights Reserved

End of Part I. Questions?

2014 All Rights Reserved

PART II. HOW HEARTBLEED WAS