Upload
elttam
View
1.480
Download
0
Embed Size (px)
Citation preview
1
EFF “Secure” IM Scorecard Review
2
Hello.
3
We’re going to be talking about Privacy vs Security.
4
We’re also going to talk about challenges in securing IM communication.
5
Agenda
• Epilog• Review Part 1 – RetroShare• Review Part 2a – libotr• Threat landscape • Hardening approaches• Prolog
6
Epilog
7
Privacy and encryption has been a regular mainstream topic
8
It’s common for security and privacy to be talked about in the same breath
9
It’s common for security and privacy to be talked about in the same breath
Security is a foundation to building privacy “features”
10
Introducing…
EFF “Secure” “IM” “Scorecard”
“Which apps and tools actually keep your messages safe”.
11
“Actually”?!
12
13
EFF “Secure” IM Scorecard Summary
• A webpage on the EFF site guiding users on the security of IM clients
• It drastically simplifies the problem domain into several “features”:
14
The scorecard logic is a bit perplexing to us...
15
We decided to set aside time to investigate…
• Spend casual hours through 2016 reviewing a selection of clients
• Dedicate up to 24 hours to each client and document the process
• Research the development lifecycle, patching, bug tracking, etc.• Responsibly disclose any vulnerabilities uncovered during the
audits
16
Review Part 1 - RetroShare
17
Retroshare
• Started in 2006• Transport via TLS (OpenSSL)• Auth via PGP keys• Features include:
• Chat / chat channels• Voice and video• Mail• File sharing• Forums• Support Tor / I2P
18
Code Repo
19
First impressions
• Trivial web-based vulnerabilities (e.g. XSS) via the UI• Large attack surface:
• HTTP protocol handling• Rich UI• Low-level serialised protocols• File handling• Multiple 3rd party libraries
• General code quality below par:• Inconsistent retval checking• Signed-ness inconsistencies• Relaxed edge-case handling• Poor usage of typecasting
20
21
22
23
Static analysis results
24
Static analysis results
25
• Vanilla integer overflows to heap corruption in VOIP:
26
• Vanilla integer overflows to OOBR in base serialisation library:
27
28
Developer response
• Communication was easy to establish with PGP keys• Overnight response – very positive and friendly• Issues patched promptly, updated binaries shortly following
11th Jan 2016
Disclosure and
response
13th Jan 2016Patch
developed
9th Feb 2016
Binaries published
29
Developer response
30
Review Part 2 – libotr
31
Libotr
• Is a library, not a client.• Many popular clients for IM protocols leverage it as a plugin to
provide privacy based communication.• Pidgin• Irssi• Miranda• Jitsi• Etc
32
Code repo
33
Initial Impressions• Relatively small code repository• Inconsistency with defensive programming patterns
• A lot of repetition / lack of centralised routines• A lot of “potentially” unsafe integer arithmetic• Not testing return values of memory allocators etc
It was clear to see “knee jerk” patching, where validation is done in response to security advisories.Some crushing of hopes..
34
35
36
37
<- check
38
Developer Responses• We sent one e-mail overnight and had a response waiting in the
inbox by the next morning.• The bug trucker shows a keen interest in resolving issues.• The developers seem to understand secure coding and pay
attention to bug reports that might have an impact.• So far so good.
39
Threat landscape
40
Things may not reach NSA proof…
41
Things may not reach NSA proof… However attacker cost needs to be as high as possible
42
Privacy applications also have different security requirements Compromising the confidentiality of “secrets” == RCE
43
Application functionality
• These clients often have fairly extensive functionality, which each have their own potential attack scenarios, including:• Web and XML-style bugs in UI and rendering = RCE or
deanonymisation• Memory corruption = RCE • Memory leaks = critical information disclosure, RCE reliability• File handle issues = potential information disclosure / RCE• And the list goes on…
44
Further, these clients also pass heavy-lifting to libraries PGP, SSL, Onion Routing, UI, Compression, Images/Video/Audio…
45
Scenario breakdown
• Low investment Common application-level vulnerability classes (web to low level)
• Moderate investment More intricate application-level vulnerabilities Logic level and design issues with adverse security impact Common 3rd party dependency vulnerabilities Passive end-point classification and intrusive targeting
• High investment Overarching low-level protocol vulnerabilities (both passive/intrusive)
46
Hardening improvements
47
Bug bounties (pentesting v2.0)
• Bug bounties can certainly serve a purpose, but its fit and limitations need to be well understood (or else it resembles the next slide)
• If at a certain proven maturity level, then high value bounties can entice skilled researchers to invest time to identify moderate-high resource attack scenarios and findings
• Can be excellent for quickly identifying low hanging fruit and uncovering a range of vulnerability classes, but:• It should not be viewed as a level of assurance or maturity for the
project• Introduces a risk for bandaid / kneejerk patching for specific
vulnerability constructs, without getting to the systemic or implementation pattern flaw
• Create a false sense of security by eradicating simpler bugs while higher skilled threat actors sit on moderate-high skill strategic attacks
48
General best practices
• Clear documentation of architecture, protocols, possible configuration options, and edge cases.
• Security focused “unit” test cases• Hardened binaries adopting latest best practice exploit
mitigation approaches• Sandboxing and hardened platform policies would be ideal, e.g.
grsec policies for containing the running binary – access to the underlying file-system and syscalls
• Good issue tracker, easy to find security contact with PGP keys available
49
Fuzzing
- Very useful in bashing out bugs of all kinds without much human effort
- Needs initial time investment to get fuzzer implemented- Needs some time investment to follow up on its results
- It’s important that if fuzzing is used that it’s done correctly – otherwise lack of results might lead to a false sense of security.- For example, encryption heavy code is likely to fail early on each
mutation. Your fuzzer should hopefully take this into consideration then and do what’s needed to get better code coverage.
- It’s unlikely to find more complicated issues, so shouldn’t be relied upon as the only security testing for a project.
50
Static analysis
• There is a number of potential compile time static analysis techniques, both open-source (e.g. clang) to commercial (e.g. Coverity)
• Static analysis tooling can introduce both false negatives and false positives (the latter being time heavy to investigate)
• Can be beneficial identifying LHF but also identify bad constructs in code – encourages overall cleanliness and developers to follow best practices
• Can provide useful metrics and tracking of security issues and improvements over time
51
Code audits
• The quality of a code audit depends on who you have on it, and the auditors understanding and experience of the relevant technology stack – this influences the effectiveness drastically (e.g. the read() example)
• Code audits should not be a simple snapshot of “findings”, but provide ongoing guidance to the developers for the overall architecture and coding practices of the application
• We believe dedicated audits from experienced folk should only really occur after applications meet a certain bar
52
Prolog
53
Key takeaways
• Neither products so far meet the bar required for “keeping you safe”, factoring in the complicated threat scenarios for privacy software
• Judging software security on publicised vulnerabilities is misleading
• The scorecard needs improvements and ongoing maintenance otherwise it may introduce risk to users
General rule of thumb:• simple foundations + minimal functionality = promising
54
Next steps
• We’re in disclosure with libotr now and will do part 2b at Wahckon
• A part 2 blog post will be coming out in May • We will review 1 or 2 clients not in the scorecard, including
Richochet• We will review 1 or 2 other popular clients in the scorecard soon• Potentially, we will look at common libraries used by many
clients
55
Thanks for listening!
Questions?