Penetration Test Report (iSEC): ncc docker notary audit 2015 07 31

Docker Notary
Application Penetration Test
Prepared for:
Prepared by:
Tom Ritter
Aleks Kircanski
Tyler Curtis
CryptographyServicesFinalReport—DockerNotary Page2of23
©2015,NCCGroup,Inc.
PreparedbyNCCGroup,Inc.forDocker.Portionsofthisdocumentandthetemplatesusedinitsproductionare
thepropertyofNCCGroup,Inc.andcannotbecopiedwithoutpermission.
Whileprecautionshavebeentakeninthepreparationofthisdocument,NCCGroup,Inc,thepublisher,andthe
author(s)assumenoresponsibilityforerrors,omissions,orfordamagesresultingfromtheuseoftheinformation
contained herein. Use of NCC Group services does not guarantee the security of a system, or that computer
intrusionswillnotoccur.
July31,2015 Docker Version1.1
CryptographyServicesFinalReport—DockerNotary Page3of23
Table of Contents
1 ExecutiveSummary ........................................................ 4
1.1 CryptographyServicesRiskSummary ........................................... 5
1.2 ProjectSummary ............................................................. 6
1.3 FindingsSummary............................................................ 6
1.4 RecommendationsSummary................................................... 7
2 EngagementStructure ..................................................... 8
2.1 InternalandExternalTeams ................................................... 8
2.2 ProjectGoalsandScope ....................................................... 9
3 DetailedFindings .......................................................... 10
3.1 Classifications................................................................ 10
3.2 Vulnerabilities ............................................................... 12
3.3 DetailedVulnerabilityList ..................................................... 13
Appendices .................................................................... 21
A Non-SecuritySuggestions.................................................. 21
A.1 DefenseinDepth............................................................. 21
A.2 UnusualSelf-DoS............................................................. 21
B KeyCompromiseAnalysis ................................................. 22
July31,2015 Docker Version1.1
CryptographyServicesFinalReport—DockerNotary Page4of23
1 Executive Summary
ApplicationSummary
ApplicationName Notary
ApplicationVersion 1.0
ApplicationType Go
EngagementSummary
Dates July27,2015– July31,2015
ConsultantsEngaged 3
TotalEngagementEffort 3person-weeks
EngagementType ApplicationPenetrationTest
TestingMethodology WhiteBox
VulnerabilitySummary
TotalHighseverityissues 2
TotalMediumseverityissues 0
TotalLowseverityissues 4
TotalInformationalseverityissues 2
Totalvulnerabilitiesidentified: 8
Seesection3.1onpage10fordescriptionsoftheseclassifications.
CategoryBreakdown:
AccessControls 0
AuditingandLogging 0
Authentication 1 (cid:4)
Configuration 1 (cid:4)
Cryptography 1 (cid:4)
DataExposure 3 (cid:4)(cid:4)(cid:4)
DataValidation 0
DenialofService 1 (cid:4)
ErrorReporting 1 (cid:4)
Patching 0
SessionManagement 0
Timing 0
July31,2015 Docker Version1.1
CryptographyServicesFinalReport—DockerNotary Page5of23
1.1 Cryptography Services Risk Summary
TheCryptographyServices(CS)RiskSummarychartevaluatesvulnerabilitiesaccordingtobusiness
risk. The impact of the vulnerabilityincreasestowardsthe bottom of the chart. The sophistication
requiredforanattackertofindandexploittheflawdecreasestowardstheleftofthechart. Thecloser
avulnerabilityistothechartorigin,thegreaterthebusinessrisk.
• HSM PIN supplied via command line
• Notary Signer server lacks authentication
w
o
L
• Temporary access to Timestamp, Snapshot, or
Targets key enables persistent lockout
k
s
i
R
s
s
e
n
i
s
u
B
• Compromise of Authority Keys
allows extended freeze/compromise
• Secret data not zeroed after use
h
g
iH
• Signature algorithm not matched to key
Simple Attack Sophistication Difficult
©2008 iSEC Partners, Inc.
July31,2015 Docker Version1.1
CryptographyServicesFinalReport—DockerNotary Page6of23
1.2 Project Summary
DockerengagedNCCGrouptoperformareviewoftheNotarysystem. Notaryisanew, fullyopen-
source solution for signing Docker images. Notary allows publishers to manage and sign their own
images,usingkeysthattheymanage. NCCGroup'sCryptographyServices(``CS'')reviewedthesecu-
rityofNotary'scryptographicandapplicationaspects. TheengagementbeganonJuly27, 2015and
concluded on July 31, 2015. Three consultants worked on the project during one calendar week. In
addition,oneinternassistedtheproject. Thefollowingcoreitemswerelookedinto:
• NotaryClient/Server
• NotarySigner
• TheUpdateFramework's(TUF)usewithinNotary
TheeffortsCSprovidedduringthisreviewshouldnotbeconsideredacomprehensivereviewofthe
completeNotarysystem. DuetothecomplexityoftheTUFlibraryanditsusewithinNotary,thetime
allotteddidnotallowanexhaustivereview. Theareaofleastreviewwastheuser'sinteractionwiththe
notaryclientapplication,whiletheareathatreceivedthemostwasthegotuflibrary.
CSreviewedtheNotaryframeworkforTUFspecificissues,generalcryptographicconcernsandpoten-
tialvulnerabilitiescommonforclient/serverapplications. Thereviewofnotaryandthegotuflibrary
wereprimarilyperformedthroughsourcecodereview.
1.3 Findings Summary
Inthegotuflibrary,thefindingwiththemostimpactwasasignatureconfusionattacklistedinfind-
ing1onpage13. Thiscouldallowanattackertoforgesignaturesbytrickingaclientintointerpreting
one encryption algorithm's key as another algorithm's key. For instance, if a RSA-PSS key is mis-
interpreted as an ed25519 key, the attacker may be able to perform the Elliptic Curve Discrete Log
algorithm to recover the private key corresponding to this (weak) ed25519 key, and sign documents
withit.
Theotherfindingsinthegotuflibraryrelatetoconditionsthatoccurifoneormoreoftheauthority
keysiscompromised. Infinding3onpage15,ascenarioinwhichanattackerwhocompromisesthe
Timestamp Authority key and signs a document with a version number that is excessively high is
discussed. Itisshownthatsuchanattackerwhohasstolenanauthoritykeycanlocktheuseroutfrom
updatingastheversionnumbercannotbeexceeded. Alackofexpiryverificationontherootkeysis
reportedinfinding2onpage14. ThisallowsanattackerwhomanagestocompromisetheTimestamp,
SnapshotandTargetKeystocontinuetooperatetherepositoryasperusualandaddmaliciousfiles.
Asshowninfinding4onpage16, thereisalackofauthenticationintheNotarySignerservice. An
attackerwhoisabletoaccesstheNotarySignernetworkcanperformarbitrarysignatureswitharbitrary
keysstoredinthedatabaseaswellasremoveandaddnewkeys.
July31,2015 Docker Version1.1
CryptographyServicesFinalReport—DockerNotary Page7of23
1.4 Recommendations Summary
ShortTerm
Shorttermrecommendationsaremeanttoberelativelyeasyactionstoexecute,suchasconfiguration
changes or file deletions that resolve security vulnerabilities. These may also include more difficult
actionsthatshouldbetakenimmediatelytoresolvehigh-riskvulnerabilities.Thisareaisasummaryof
shorttermrecommendations;additionalrecommendationscanbefoundinthevulnerabilitiessection.
DeprecateanddocumentuseofPrefixHashes.Prefixeshashesmayinadvertentlyopennewfolders
uptocontrolbyunauthorizedpersons,ifthefolderaddedhappenstocontainahashprefixthatanother
role is authorized for. This model makes it extremely dangerous to use prefix hashes if folders are
expectedtobeaddedtoahierarchyinthefuture.
AddauthenticationtotheNotaryServer. Even though the Notary Signer is meant to be behind
firewallsandonlyaccessiblefromtheNotaryServerhost,differentdeploymentsoftheNotarysystem
may not respect this. Require strong authentication tokens when executing the Notary Signer API
functions.
LongTerm
Longtermrecommendationsaremorecomplexandsystematicchangesthatshouldbetakentosecure
the system. These may include significant changes to the architecture or code and may therefore
require in-depth planning, complex testing, significant development time, or changes to the user
experiencethatrequireretraining.
Specifythemaximumexpirytimeallowedforeachkeyintherootdocument. Thiswilllimitthe
impactofacompromiseofany