1. Vetting SSL Usage in Applications with SSLINT
Boyuan He[1], Vaibhav Rastogi[2], Yinzhi Cao[3], Yan Chen[2][1], Venkat Venkatakrishnan[4], Runqing Yang[1], Zhenrui Zhang[1]
Good afternoon everyone, I am Boyuan He , a PhD student from Zhejiang University, China.
And today it is great honor for me here to present our work – SSLint, a tool we implemented to automatically verify SSL API usage in application by static analysis and report vulnerabilities whenever this verification fails.
This work is conducted with the joint Lab of Internet and Security Technology (LIST) at Zhejiang University and Northwestern Univ., supervised by my advisor Yan Chen, also collaborated with our alumni Yinzhi Cao from Columbia University and Prof. Venkatakrishnan from University of Illinois at Chicago.
Lab of Internet and Security Technology (LIST)
[1] Zhejiang University, China
[2] Northwestern University, USA
[3] Columbia University, USA
[4] University of Illinois, Chicago, USA

2. Motivation & Problem Statement
TCP
SSL/TLS
HTTP
SMTP
As we all know, SSL and TLS protocols have become the security backbone of Internet today.
As a transport layer protocol, SSL usually uses TCP as underlying protocol. And many application layer protocols are built on top of it.
SSL provides end-to-end encrypted communication security over the Internet. As a result, many software including mobile and desktop applications are protected by SSL/TLS protocols.
SSL/TLS is based on the model of Public Key Infrastructure (PKI) and X509 certificates, and is designed to guarantee confidentiality, authenticity, and integrity for communications against Man-In-The-Middle (MITM) attacks.
POP3
Use an X509 certificate for
authentication
IMAP 2 2

3. Motivation & Problem Statement
Many application vulnerabilities due to improper usage of SSL/TLS are mentioned in previous papers.
Georgiev et al. [CCS’ 12] (Black-box testing)
Is it possible to automatically detect such SSL vulnerabilities in large scale and in a more general way with high efficiency and accuracy?
However, recent studies show that some SSL applications are still vulnerable to MITM attacks because of implementation flaws.
In many cases, SSL library APIs are not well designed so the developers fail to understand them correctly.
Previous work has already mentioned this “incorrect API usage” problem , especially in server certificate validation on the client side, showing that many applications are affected by this problem and making all of them vulnerable to MITM attack.
Motivated by such SSL API usage vulnerabilities, we wonder that since SSL is so important and widely used, how many such unknown vulnerabilities are still there? And whether it is possible to automatically detect such SSL vulnerabilities in large scale and in a more general way with high efficiency and accuracy. 3 3 3

4. Contributions
Design a systematic approach to automatically detect incorrect SSL API usage vulnerabilities.
Implement SSLint, a scalable automated tool to verify SSL usage in applications.
Automated candidate app selection and compilation.
Results.
—— Automatically analyzed 22 million lines of code.
—— 27 previously unknown SSL/TLS vulnerable apps.
To answer this question,
In this paper, we propose an approach as well as a tool called SSLINT– a scalable, static analysis tool – which is aimed towards automatically identifying incorrect use of SSL/TLS APIs in client-side applications.
Our work has the following main contribution:
We design a systematic approach to automatically detect incorrect SSL API usage vulnerabilities.
Implement SSLint, a scalable automated tool to verify SSL usage in applications.
In order to find those apps using SSL library APIs as our candidates, we leverage on existing package managers in Linux distributions for automatic compilation and analysis, and then acquire all the target applications with SSL/TLS libraries as their building dependences.
We did a large scale measurement and analyzed 22 MLoC, and discovered 27 previously unknown SSL/TLS vulnerabilities in software packages from the Ubuntu 12.04, and we confirmed all of them and 4 have already fixed. 4 4 4

5. Agenda Motivation & Problem Statement
Background on SSL Vulnerabilities
SSLint Design and Implementation
Results
Here comes the agenda for the rest of my presentation today.
We start from some background knowledge of SSL vulnerabilities, and show how Man-in-the-middle attacks can happen due to incorrect API usage.
Then we present our SSLint design and implementation including code representation we use in static analysis and signature design.
At the end of this presentation, we give a summary of our findings. 5 5

6. Background on SSL Vulnerabilities
How SSL/TLS works?
TCP SYN
TCP SYN ACK
TCP ACK
ServerHello
Certificate ServerHelloDone
ClientHello
Client Key Exchange Certificate Verify [Change Cipher Spec] Finished
[Change Cipher Spec]
Finished
We start from some background knowledge showing how SSL protocol works.
As a transport layer protocol, SSL is built on top of TCP. So after a successful TCP three-way handshake, SSL handshake is established from the client side.
Then server present its certificate to client and the client will validate this certificate in order to verify server’s identity. This is the authentication phase of SSL.
Usually, client certificate is optional according to RFCs. So in fact, one-way authentication is a common practice in SSL as shown in this example.
After a successful authentication, keys and ciphers will be exchanged between client and server before the handshake is done.
In the end, a secure communication channel is established, and encrypted application data can be transferred over this channel.
Application Data
Application Data
Client
Server
(RFC 5246) 6 6 6

7. Background on SSL Vulnerabilities
Man-in-the-middle attacks caused by incorrect certificate validation.
A hijacked SSL channel
A secure SSL channel
As mentioned earlier, SSL is deigned to secure an end-to-end channel between client and server to avoid man-in-the-middle attacks. However, it may still be vulnerable to such attacks if SSL protocols are not implemented correctly.
Incorrect use of SSL API makes it possible for attackers to bypass certificate validation, in this way, attackers can easily intercept, decrypt or tamper all the information inside SSL channel.
In other words, SSL is completely broken under these attacks.
We will present a demo video of such attack against one vulnerable app we found at the end of this presentation.

8. A Motivating Example Vulnerable example (OpenSSL API)
Create SSL context.
ctx = SSL_CTX_new(method);
...
ssl = SSL_new(ctx);
SSL_connect(ssl); …
if(SSL_get_verify_result(ssl)
==X509_V_OK){
//Validation succeeds. }
else{
//Validation fails and terminate connection
Create SSL session.
Launch SSL handshake
Check the built-in certificate validation result after handshake, but if no certificate is presented, X509_V_OK flag can still be set.
In order to show details of these vulnerabilities and the idea of our system design, now we present a motivating example from a real vulnerable app we found.
This app use OpenSSL as its SSL implementation.
The1st API SSL_CTX_new is called to create a SSL context, which is for SSL configuration.
Then, the 2nd API SSL_new is called to create SSL session using SSl context.
Next, SSL handshake is launched using SSL_connect() API.
After the successful establishment of the connection, API SSL_get_verify_result() is called to see if certificate validation is successful and terminate connection if necessary. This is one of the common practice or “correct usage” when developing apps using OpenSSL and we refer it as “check after handshake”.
However, OpenSSL API is not well designed and well documented. SSL_get_verify_result() API function will still return a successful flag if no certificate is presented by server.
So this app is vulnerable.

9. A Motivating Example Cont’d
Fix of vulnerable example
ctx = SSL_CTX_new(method);
...
ssl = SSL_new(ctx);
SSL_connect(ssl); …
cert = SSL_get_peer_certificate(ssl);
if (cert != NULL){
if(SSL_get_verify_result(ssl)
==X509_V_OK){
//Validation succeeds. }
else{
//Validation fails and terminate connection
//Validation fails and terminate connection
Check if server’s certificate is presented (is NULL?) together with the validation result.
To fix this vulnerable app, another API, SSL_get_peer_certificate() should be called when checking certificate validation result.
In this way, the app will terminate connection when no certificate is presented.

10. SSLint Framework Check whether validation APIs are called correctly.
SSL Client Apps
Check whether validation APIs are called correctly.
Encode “correct” usage in a signature and match this signature.
Pass if match succeeds
Static Analyzer
Code
Representation
Signatures
In order to automatically detect such SSL vulnerabilities including those shown in the motivating example
we first model the correct usage of SSL APIs as signatures.
Then we design SSLint, which takes source of apps as input, transforms the source code into a certain kind of code representations in static analyzer, and then matches the signatures to detect vulnerability.
Remember that it is the correct logic that we modeled in the signature, so vulnerabilities will only be reported whenever signature matching fails.
Matcher
Vulnerability
Report

11. SSLint Signatures Fixed vulnerable example Data Flow & Control Flow
1 ctx = SSL_CTX_new(method);
...
2 ssl = SSL_new(ctx);
3 SSL_connect(ssl); …
4 cert =
SSL_get_peer_certificate(ssl);
5 if (cert != NULL){
if(SSL_get_verify_result(ssl)
==X509_V_OK){
//Validation succeeds.
8 SSL_read(ssl…) or SSLwrite(ssl,…) }
else{
//Validation fails and terminate connection }
13 }
14 else{
//Validation fails and terminate connection }
@1 SSL_CTX_new
@2 SSL_new
@3 SSL_connect
@4: SSL_get_peer_certificate
@6: SSL_get_verify_result
In order to show our ideas of signature design, here again, we use our motivating example.
This is the fixed version, representing the correct logic of OpenSSL APIs when validating certificate.
To model this correct logic, first, our signature need to track data flows between all of these APIs.
Starting from SSL_CTX_new() at line 1, here are the API realted data flows we need to track.
In addition to data flow, control flows related to SSL API usage also need to be modeled in the signature.
For example, SSL_read() and SSL_write() are two main APIs for apps to send and receive data over SSL channel.
So these two APIs should be called only after a successful certificate validation. As a result, in this example, we also need to track this control flow from two if condition to SSL_read/SSL_write API.
@5: If condition
(cert!=NULL)
@6: If condition
(==X509_V_OK)
@8: SSL_read/SSL_write
Data Flow & Control Flow

12. SSLint Signatures
We use Program dependence graphs (PDGs) as code representation as well as signature representation, in order to capture both control flow and data flow
In our solution, we use program dependence graph as code representation as well as signature representation.
In this way, we successfully capture both control flow and data flow in our signature.
And here we show our signature for OpenSSL APIs, which is very similar to the flow chart shown in the last page.
You may already noticed that there are two parts in the signature.
That ‘s because OpenSSL has two correct API usage for certificate validation. One is already shown in the motivating example as “check after handshake”, another is “check during handshake”, which I will not go into details due to limited time.
We model correct API usage for both cases. If neither of the two parts is matched, a warning will be triggered.
Signature for OpenSSL APIs

13. SSLint Implementation
Technical Challenges:
Defining and representing correct use.
Identifying the preliminary condition for signature matching.
Automated candidate app selection and compilation.
SSL_new()
Our SSLint implementation has the following technical challenges:
Given an SSL library, how do we model correct use of the API to facilitate detection?
Our solution is to use PDG as our signature representation and us graph queries to do signature matching.
Given a signature, are there any preliminary conditions for signature matching?
We develop algorithm to integrate preliminary conditions into the signature matching process. For example, in OpenSSL signature shown in the last page, the data flow from SSL_new() to SSL_read or SSL_write must be captured before the PDG based signature is matched.
3. From an OS distribution, how do we identify and select candidate apps using SSL libraries and successfully compile these apps for analysis?
The answer is that we leverage on package managers existing in many Linux distributions to resolve dependencies and compile automatically.
SSL_read() or
SSL_write()

14. SSLint Implementation
Certificate Validation Vulnerability Scanner
CodeSurfer provides static analysis
2.6K LoC (in C++)
Generated PDGs matched with signatures
– Signature Expressions motivated from Cypher, a graph query language
– Custom algorithm to perform the matches
In our implementation, SSLint acts as a certificate validation vulnerability scanner.
We use CodeSurfer, a static analyzer provided by Grammtech, for static analysis and generating PDGs.
SSLint is implemented in C++ and it is about 2,600 lines of code.
Our signature expression design is motivated from Cypher, a graph query language used in a popular graph database –Neo4j.
We also design custom algorithm to perform the signature matches.

15. Results Signatures implemented for OpenSSL and GnuTLS
– the most popular two SSL/TLS libraries
Scanned the entire Ubuntu distribution
– Scanned 22 million LoC in static analysis.
– 485 applications using OpenSSL and GnuTLS
Detected 27 vulnerabilities
– All reported and confirmed
– 4 fixed, 14 responses from developers
In our evaluation, we investigated apps leveraging on the most popular two SSL libraries on C/C++ platform: OpenSSL and GnuTLS.
We designed signatures form both libraries, automatically scanned over 22 million lines of code and detected 27 previous unknown vulnerable apps out of 485 Ubuntu Linux apps.
We have reported all of our findings to developers or maintainers, and got 14 confirmation.

16. Results Vulnerable E-mail Software Vulnerable IRC Software
– Xfce4-Mailwatch-Plugin, Mailfilter, Exim,
DragonFly Mail Agent, spamc
Vulnerable IRC Software
– Enhanced Programmable ircII client (EPIC), Scrollz
Other Vulnerable Software
Web(https): Prayer front end, xxxterm
Database: FreeTDS
Admin tool: nagircbot, nagios-nrpe-plugin, syslog-ng
Performance testing tool: siege, httperf, httping
Our result shows that vulnerable apps are from various categories.
As you ca see we have apps, IRC apps Web apps, and even database apps and admin/testing tools.
These vulnerabilities can lead to serious consequences such as privacy leakage and privilege escalation and may cause great trouble for users.

17. Results App Name LoC Vulnerability Type SSL library Dynamic Auditing
Developer
Feedback
dma
12,504
Certificate Validation
OpenSSL
Proved
Confirmed
exim4
94,874
Hostname Validation
GnuTLS
Fixed
xfce4-mailwatch-plugin
9,830
spamc
5,472
prayer
45,555
epic4
56,168
epic5
65,155
scrollz
78,390
xxxterm
23,126
httping
1,400
pavuk
51,781
crtmpserver5
57,377
freetds-bin
80,203
Here are our mesurement results in detail.
As we can see, the size of code for each vulnerable app is between a few thousands lines to more than one hundred thousand lines.
14 of vulnerabilities are either confirmed or fixed.
For those we have not heard from maintainers or developers, we successfully launched MITM attacks on all of them, showing that they are really vulnerable. We refer this part of job as manual auditing.

18. Certificate Validation
Results
App Name
LoC
Vulnerability
Type
SSL library
Dynamic
Auditing
Developer
Feedback
nagircbot
3,307
Certificate Validation
OpenSSL
Proved
picolisp
14,250
Fixed
nagios-nrpe-plugin
3,145
Confirmed
citadel-client
56,866
mailfilter
4,773
suck
12,083
proxytunnel
2,043
Hostname Validation
GnuTLS
siege
8,581
httperf
6,692
syslog-ng
115,513
medusa
18,811
hydra
23,839
ratproxy
4,069
dsniff
24,625
One interesting fact we found in the evaluation is that:
Ubuntu developers are only responsible for maintaining a small number of apps in its software repository.
Other apps are maintained by the community.
In our evaluation, we found that both Linux distribution developers and community developers feel no obligation to fix bugs or vulnerabilities in Linux distributions.
We even found examples which has already got fixed in community upstream but is still vulnerable in the latest Linux distributions.
It is also true for Linux distributions other than Ubuntu.
We think such security problem in open-source software need to be settled in a proper way to avoid more vulnerabilities.

19. Conclusion & Ongoing work
– We design and implement SSLint to verify SSL API usage in large scale.(22M LoC)
– We discover 27 previously unknown vulnerable apps due to misuse
Ongoing work
– SSLint is our 1st step to verify API usage by static analysis. (A generic approach?)
– Fix failed applications in analysis by automatically identify SSL-relevant modules in application code.
To conclude our work, we start from the motivating example that there are a lot of misuse of SSL library APIs in applications, and design and implement SSLint, a system to verify SSL API usage in large scale. We discover 27 previous unknown vulnerable apps in Ubuntu software, most of which are also shared in other Linux distributions.
SSLint is our 1st step to verify API usage by static analysis. But we believe that this approach is not restricted in SSL APIs.
So, currently we are focusing on the following ongoing work:
1. We are building generic system to verify API usage in applications of different programming language. Such as Java apps.
2. We are trying to Fix those failed application in analysis due to memory explosions and other errors by automatically identify SSL-relevant code in application and only focus on that part of code to reduce the workload of our analysis.

20. Attack Demo Video against Xfce4-mailwatch-plugin
In the end, I’d like to show you an attack demo video against one of the vulnerable app we found.
Meanwhile, I’d like to take your questions.
That’s the end of my presentation today. Thank you!

21. Thank you! http://list.zju.edu.cn/ http://list.cs.northwestern.edu/
Questions?

22. BackUp

23. A Motivating Example Vulnerable example (OpenSSL API)
Specify the protocol: TLSv1
const SSL_METHOD *method;
SSL_CTX *ctx;
SSL *ssl; …
method =
TLSv1_client_method();
...
ctx = SSL_CTX_new(method);
ssl = SSL_new(ctx);
SSL_CTX_set_verify(ctx,
SSL_VERIFY_NONE,...);
SSL_connect(ssl);
Create SSL context.
Create SSL session.
Configure OpenSSL built-in certificate validation, but fail to enforcement this validation during handshake
Launch SSL handshake

24. A Motivating Example Cont’d
Fix of Vulnerable example
const SSL_METHOD *method;
SSL_CTX *ctx;
SSL *ssl; …
method =
TLSv1_client_method();
...
ctx = SSL_CTX_new(method);
ssl = SSL_new(ctx);
SSL_CTX_set_verify(ctx,
SSL_VERIFY_PEER,...);
SSL_connect(ssl);
Use SSL_VERIFY_PEER flag instead of SSL_VERIFY_NONE to enforce OpenSSL built-in certificate validation during handshake.
To fix this vulnerable app, one options is to replace this SSL_VERIFY_NONE flag with another flag: SSL_VERIFY PEER, which tells the OpenSSL library to terminate SSL connection immediately whenever certificate validation fails during handshake.
This is also a common practice or correct usage when developing apps using OpenSSL.

25. OpenSSL API

26. Incorrect use of SSL API
Poisoned DNS cache
Man-in-the-middle attacks caused by incorrect hostname validation.

27. Measurement results
Here are summaries of our evaluation, showing the distribution and coverage of our analysis.
There are about 20% of apps which we failed to analyze because of scalability issues (Most of them fails due to memory explosion).
Empirically, we are able to analyze apps within 100 thousand lines of code.
For those failed apps, we plan to leave them for our future works.

28. Accuracy

29. Static Analysis