Скачать презентацию A walk through a Grid Security Incident HEPi
3df3a44ee6699cff514e13f96250abd7.ppt
- Количество слайдов: 19
A walk through a Grid Security Incident HEPi. X Vancouver, October 24, 2004 Dane Skow, Fermilab
Players • • • Users Resource Administrators Sites Virtual Organizations Certificate Authorities Authorization Authorities
Risk Assessment for Grid • What is the level of risk ? + + – – Grid is not (yet) widely used with limited resources Resources are typically made available through a gatekeeper “Grid is an error amplifier on steroids” An opportunistic Grid job is much like a worm: spread to all available resources and perform some coordinated task – Needs and desires are outpacing controls – Participants in a Grid announce themselves • What do the bad guys want ? – Most attacks are automatic these days (limited worry about War. Games attackers, but sk attack is counter argument) – Spread itself is the game – Spread to pop up untraceable service – Spread to setup some mass action
Vulnerabilities: Authentication • Authentication system can be compromised: – – CA compromise User private key compromise Proxy (authentication token) compromise Protocols implemented to fail open • Responsibilities – – CA operators have to follow CP/CPS Resource Administrators have to protect proxies Users have to protect their private keys. All parties need to perform due diligence on checks
Vulnerabilities: Resources • Software applications (including OS) can be attacked. – DOS attacks – resource attacks (eg. “filez”, crackers, …) – Parallel for a sniffer attack would be a proxy hijacker. • Responsibilities – Resource Administrators have to keep software current – Application authors have to patch defective software – Incident Response ?
Vulnerabilities: Authorization • Authorization (Auth. Z) system can be compromised – – Auth. Z authority compromise Authorization managers’ authentication compromise Policy statements (eg. ACL) compromise Auth. Z token (attribute certificate ? ) compromise • Responsibilities – Auth. Z operators have to follow an acceptable operations policy (CP/CPS or equiv) – Auth. Z admins have to protect their identities – Resource Admins have to protect policy enforcement
Private Keys • Today’s story focuses on user private keys. • Whoever has access to the private key can assert the public identity to which it corresponds. • FNAL does not accept user-held private key PKI for general access systems save for a few Grid test systems. Considering the future. – FNAL PKI for user certs uses KCA. – Fair test of incremental load of 3 rd party authentication • Debate over user diligence on protecting private keys tested by looking at site network file systems. Storing a private key on any network file system exposes the key to network and file system attacks. • openssl is your friend and the Grid incident investigator’s Swiss army knife.
AFS and User Private Keys • Many users have home areas in AFS. • Many users do not understand how AFS access control lists work. It is easy for users to leave their private keys world readable in AFS space. • Should one proactively create a. globus directory in all users $HOME with the proper permissions ? • What about SSH RSA keys, browser credential caches, PGP keys, …
The Stats • Of 18 directories, 14 were world readable. 11 had valid certificates. • After 40 days, 8 had still not been revoked. 3 directories were still readable. 1 new exposure had occurred. • Distribution of sources 5 DOEGrids 5 DOESciencegrids 1 Princeton self-signed
The Timeline • September 5, scanned all $HOME areas for readable. globus directories. – Found 14 of 18 directories were world readable – 11 had valid certificates for the matching keys • September 5, sent mail to all affected users – Basic statement of problem – telling them how to fix the AFS permissions – recommending they get certificates revoked
Details of a user private key more ~/. globus/userkey. pem Bag Attributes friendly. Name: Dane Skow 995399's ID local. Key. ID: 53 E 0 A 1 4 A 57 DE 10 E 6 79 DF DD AF DA 7 D 4 F 94 AD 90 E 3 51 Key Attributes:
Details of a certificate more ~/. globus/usercert. pem $ Bag Attributes friendly. Name: Dane Skow 995399's ID local. Key. ID: 53 E 0 A 1 4 A 57 DE 10 E 6 79 DF DD AF DA 7 D 4 F 94 AD 90 E 3 51 subject=/O=doesciencegrid. org/OU=People/CN=Dane Skow 995399 issuer= /DC=net/DC=es/OU=Certificate Authorities/OU=DOE Science Grid/CN=pki 1 -----BEGIN CERTIFICATE----MIIDFj. CCAf 6 g. Aw. IBAg. ICAMQw. DQYJKo. ZIhvc. NAQEFBQAwd. TETMBEGCgm. SJom. T 8 ixk ARk. WA 25 ld. DESMBAGCgm. SJom. T 8 ixk. ARk. WAm. Vz. MSAw. Hg. YDVQQLExd. DZXJ 0 a. WZp. Y 2 F 0 ZSBBd. XRob 3 Jpd. Gllcz. EZMBc. GA 1 UECx. MQRE 9 FIFNja. WVu. Y 2 Ug. R 3 Jp. ZDENMAs. GA 1 UE Ax. MEc. Gtp. MTAe. Fw 0 w. Mj. A 1 MTYx. Nj. E 2 Mjla. Fw 0 w. Mz. A 1 MTYx. Nj. E 2 Mjla. MEkx. Gz. AZBg. NV BAo. TEm. Rv. ZXNja. WVu. Y 2 Vncmlk. Lm 9 y. Zz. EPMA 0 GA 1 UECx. MGUGVvc. Gxl. MRkw. Fw. YDVQQD Ex. BEYW 5 l. IFNrb 3 cg. OTk 1 Mzk 5 MIGf. MA 0 GCSq. GSIb 3 DQEBAQUAA 4 GNADCBi. QKBg. QDi Umn. Cnjw/0 cp. L 9 JSzc 6 VEw. Uz. Vk. B 72 e. Ou. Sj. W+VQ 1 NSJ+q. IEm 2 f 6 q/7 TA 8 xt. SXa. Om 6 w IMhqa. N 95 i. S 0 Klmavd 3 ga. Ua 4 e 0 rvk. Kltt+7 dmqh. VU 7 p 9 DI 74 Tnp. Qf. JLV/CICIKc. Wu mf. O 3 QBns. LPPUYy 4 n 819 LGhg. SVjr. XWOym. Qx. ODp 9 t 31 QIDAQABo 2 Aw. Xj. ARBglghkg. B hvh. CAQEEBAMCBe. Aw. Dg. YDVR 0 PAQH/BAQDAg. Tw. MB 8 GA 1 Ud. Iw. QYMBa. AFFQXi. Mo. Dw. Tkm u. FWmx. Jn 0 Kw. Krvg. Dp. MBg. GA 1 Ud. EQQRMA+BDWRhbm. VAZm 5 hb. C 5 nb 3 Yw. DQYJKo. ZIhvc. N AQEFBQADgg. EBAGKm. Q 5 a. Nx. Fz. CHlnfhtt. EQq. BH 1 lz/3 n 1 Whfd 4 iyy. Yz. Zqlc. Ob 8 U 7 L 3 /owv. B 4 O 4 z. OAt 5 v 4 ech. Sr. Qxx. Emp 8 O 8 T 0 ZZl. N 9 yb. Ow. UBhy 5 us. Tcz. Op. Tmdoku. Cu. NUs. I Cq. IBY 6+ia. Qlaq 5 y. Do. ILCjt 30 ysl. Do. T+oin. J+fx. Os. OHltsc. NWCz. NUju 65 cnz 3 Hjqm d. Hq. GWOLOozmr. Ovo. Rc 44 y 0 Bro. J 5+TF 79 YKl 7 wb. H 8 Jbiw. L 4 EOI 85 EOz. Pk. QC 9 ZGoo 2 a d. ZFa 5 z. Y/OFk 5 eki. Xvk 5 m. TMn. Xb. TQF 8 kd. Ti 5 p. G 7 Qw. F 9 KL 7 f 4 Nctux 85 Ogn. Po. F 5 VZWg FTjyr. RYui. KHa. ZEJacz. Aj 4 JXIjs. Aqz. H 800/U= -----END CERTIFICATE----- Human readable version available via “openssl x 509 –text –in ~/. globus/usercert. pem”
Timeline (cont’d) • September 6 -8, had first round of followup with users and their management to explain the problem and why removal from the gridmapfile is insufficient. • September, discussed with CA admins their policy on certificate revocation. No proof of association nor compromise. • September 25, Tested SAZ revocation of site access for compromised certificates • Oct 15 , raised issue with LCG Security Group on appropriate response. – Agreement that site blocks until CRL issued may be prudent. • Some concern about only triggering on “real” exposures. – Agreement to distribute lists of compromised certificates to collaborating sites in the “grid”. • Complaint from at least one CSIRT about noise and unknown expectations. • Concerns about DOS and spoofed reports.
Timeline (cont’d) • Oct 15, – repeated scan • 3 directories remained open • 1 new exposure had occurred – Tested CRLs • 2 certificates had been revoked • 1 was stuck in process
Certificate Revocation Lists • Where do you find them ? – Supposed to be referenced in the certificate – List of CA’s useful reference page http: //marianne. in 2 p 3. fr/datagrid/ca/ca-table-ca. html • Guess what they look like ? -----BEGIN X 509 CRL----- MIIBm. TCBgj. ANBgkqhki. G 9 w 0 BAQQFA… -----END X 509 CRL----- • Need to use tools to compare contents – Certificates identified by serial number only – Case of hex serial number not standard
Followup Issues • What constitutes a private key compromise ? – To prove it, one has to crack the private key encryption. – Do we run Grid. Crack on our filesystems regularly (ala passwd/shadow checks) ? – If anything else, how does one establish trust between the CA and the reporter ? • Correct assessment of exposure • Correct association of key to certificate
Followup II • What coordination between resource providers, VOs, users, … is necessary ? – Learn of suspected compromised identities • Trusted communication chain • Agreement on “compromise” • Determine appropriate scope of response – Is disable everywhere overkill ? – Investigate the problem • Coordinate forensics investigations • Present conclusions and summarize confidence – Remediate the problem • Issue the “all clear” • Agree on followup responsibilities
Followup III • Incident Response – How does the case of compromise of a host/service private key differ from this ? • Are there restrictions on types of access ? • Are there differences in service to service transactions ? – How does case of application hole exploit differ from this ? • Does the grid contain its own advertisement (ala NIS) ?
Followup IV • Authorization handled by gridmapfile for each resource. – Think of a gridmapfile as an /etc/passwd file on a host • Authorization done by DN (Distinguished Name) only – How to deal with replacement certificates with same DN ? • Maintenance of gridmapfile either manual or disconnected from incident response teams.