From an Experience of Vulnerability Reporting

https://lepidum.co.jp/ Copyright © 2004-2015 Lepidum Co. Ltd. All rights reserved.
From an Experience of
Reporting a Vulnerability
- Case of CCS Injection -
Tatsuya HAYASHI (@lef)
Kaoru Maeda (@mad-p)
Lepidum Co. Ltd.
"SSR 2015" (2015/12/15)

Copyright © 2004-2015 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Agenda
 CCS Injection Vulnerability
 How did we find it?
 Reporting a Vulnerability
 Disclosing a Vulnerability
 Lessons Learned

Focus Area | Lepidum
 Applied Research and Development
 Personal Data, Digital Identity and Privacy
 Secure and Safety Software Technology
 Web and Internet Technology
 De-Facto and Forum Standardization
 Keywords:
 Personal Data, Trust Framework, Privacy, ID Federation,
Authentication/Authorization, Protocol Specification,
* of Things(IoT, WoT), Software Defined Network,
Autonomic Network, etc...

CCS INJECTION
VULNERABILITY

CCS Injection Vulnerability
CVE-2014-0224 (June 2014)
 CCS = Change Cipher Spec
 Early CCS Attack
 http://ccsinjection.lepidum.co.jp/
1. MITM crafts a CCS too early than expected
2. OpenSSL accepts it without necessary validation
3. Cipher Suites changed with uninitialized
parameters
4. MITM can decrypt all the traffic

How was it found?
Masashi Kikuchi (reporter) thought
 Wanted to create a formal verification for that
 Peeked into existing implementations
 Found a flaw in OpenSSL's validation
Most complex transitions in the
SSL/TLS statemachine:
handle ChangeCipherSpec

Reporter's intial motivation
 Everyone competes to hunt bugs. I
want to do it efficiently
 Want to use Coq somewhere
 Select a suspicious module by
experience
 Want a clue to understand code that is
difficult

Reporter's intial motivation
 Everyone competes to hunt bugs. I
want to do it efficiently
 Want to use Coq somewhere
 Select a suspicious module by
experience
 Want a clue to understand code that is
difficult
But,
he didn't need
even Coq

A VULNERABILITY:
REPORTING AND DISCLOSING IT

To whom should it be reported?
 In Japanese or in English?
 OpenSSL？CERT？
 Correct impact analysis done?
 Is our analysis correct, in the first place?
 PoC attack
 Information control intra company

After reported...
 Prepare against possible 0-day attacks
 We could not do anything than just wait for a
response
 We could not ask to/discuss with other
organizations
 Employees are instructed not to talk about it
 We could not believe that "our reporting
process is correct" without an response

After reported...
 Prepare against possible 0-day attacks
 We could not do anything than just wait for a
response
 We could not ask to/discuss with other
organizations
 Employees are instructed not to talk about it
 We could not believe that "our reporting
process is correct" without an response
Bitter days

What we have done: Blog it
 Take a new domain (against domain dropping)
 Do not place any ads (better trust)
 Prepare for high loaded access
 Selecting a CDN
 Cacheable blog pages
 Test that the pages and CDN work, without disclosing
 Review how to update the pages
 Collect and manage incoming updates
lessons
learned

What is the right way to disclose it?
 No one actually tell us the best practice
 Schedule an announcement
 Domain name gives a hint about the
vulnerability. DNS settings delayed
 ccsinjection.lepidum.co.jp
 No rules, no guidelines
 Commonsense ⇒ What's that?
lessons
learned

The day it announced
 Disclosure date is told, but not the time
 No one (incl. CERT) tells the reporter exactly when the CVE
appears
 Inqueries, interviews
 Media handling, English support, customers, SNS...
 The Guardian, New York Times, etc...
 "Proper" interviews and not
 Explain to customers what we have done
 Fortunately, we had blog pages!
 Updates
 Catch up with software updates, etc.
 Distinguish suggestions from experts and non-experts

The day it announced
 Disclosure date is told, but not the time
 No one (incl. CERT) tells the reporter exactly when the CVE
appears
 Inqueries, interviews
 Media handling, English support, customers, SNS...
 The Guardian, New York Times, etc...
 "Proper" interviews and not
 Explain to customers what we have done
 Fortunately, we had blog pages!
 Updates
 Catch up with software updates, etc.
 Distinguish suggestions from experts and non-experts
A whole company work!
Daily job suspended

FAQ, other things to consider
 Why a logo?
 "How much did you earned from this?"
 Engineers' stresses
 Business value

Information control
 Avoid unnecessary sense of crisis
 Deliver precise information to where necessary
 Announce counter measures when they are
ready

Vulnerability disclosure is not easy
 Cannot call for a help,
no help comes
 We, a geek company, could do it.
We could do it because we are an organization.

Vulnerability disclosure is not easy
 Cannot call for a help,
no help comes
 We, a geek company, could do it.
We could do it because we are a organization.
But it was
worth doing it!

LESSONS LEARNED

Vulnerability and Reporting
 It comes, even when not prepared
 Do it without how-to's nor guidelines
 Prepare blog pages
 But without disclosing much before the
announcement
 Be careful when setting up CDN and DNS

Message: Implementation is the key
Write specifications after implementing it
That way, you should know where pitfalls are
"Handle a complex protocol like TLS with Coq, you might
need an experience of implementing it"

Please contact us
https://lepidum.co.jp/ @lepidum @lef @mad-p
mailto:{hayashi,maeda}@lepidum.co.jp

From an Experience of Vulnerability Reporting

Recommended

Recommended

More Related Content

Similar to From an Experience of Vulnerability Reporting

Similar to From an Experience of Vulnerability Reporting (20)

More from Kaoru Maeda

More from Kaoru Maeda (20)

Recently uploaded

Recently uploaded (20)

From an Experience of Vulnerability Reporting