{"vuid":"VU#442569","idnumber":"442569","name":"MIT Kerberos vulnerable to ticket splicing when using Kerberos4 triple DES service tickets","keywords":["MIT","Kerberos","triple DES","VU#623217","ticket"],"overview":"Several cryptographic vulnerabilities exist in the basic Kerberos version 4 protocol that could allow an attacker to impersonate any user in a Kerberos realm and gain any privilege authorized through that Kerberos realm.","clean_desc":"The MIT Kerberos Development team has discovered a serious cryptographic flaw in the Kerberos version 4 protocol. This flaw could allow an attacker to compromise the entire affected Kerberos realm. In addition to the vulnerability described in VU#623217, an additional vulnerability was discovered in the MIT Kerberos implementation of triple-DES encryption of service tickets. From the MIT advisory: \"As a result of concerns about single DES weaknesses, MIT implemented support for Kerberos 4 tickets encrypted in triple DES service keys. This support shares all the cryptographic weaknesses of single DES Kerberos 4. In addition, since it uses CBC mode rather than PCBC mode, it introduces new weaknesses not found in other Kerberos 4 implementations. When certain alignment constraints are met, it is possible to splice two tickets together, allowing an attacker to get a ticket with a known session key for a client without knowing that client's long term key. This attack does require sniffing a ticket for that client.\" As a result, MIT implementations of Kerberos version 5 or derived implementations that include support for triple-DES keys in Kerberos version 4 are vulnerable.","impact":"In addition to the impacts described for VU#623217, an attacker may impersonate any principal to a service keyed with triple-DES Kerberos version 4 keys, given the ability to capture network traffic containing tickets for the target client principal.","resolution":"Apply a patch from the vendor The MIT Kerberos team has released MIT krb5 Security Advisory 2003-004 regarding this vulnerability. Sites are strongly encouraged to apply the patches referenced in the advisory.","workarounds":"Workarounds In the absence of patching, the following workarounds have been proposed by the MIT Kerberos team: 1) V4 Cross Realm Considered Harmful Kerberos implementations should gain an option to\n    disable Kerberos 4 cross-realm authentication both in the KDC and\n    in any implementations of the krb524 protocol. This configuration\n    should be the default. 2)  Application Migration Application vendors and sites should migrate from Kerberos version 4\n    to Kerberos version 5. The OpenAFS community has introduced features\n    that allow Kerberos 5 to be used for AFS in OpenAFS 1.2.8. Patches\n    are available to add Kerberos 5 support to OpenSSH. Several other\n    implementations of the SSH protocol also support Kerberos 5. Applications such as IMAP, POP and LDAP already support Kerberos 5. 3) TGT Key Separation One motivation for the V4 triple DES support is that if a single\n    DES key  exists for the TGT principal then an attacker can  attack\n    that key both for v4 and v5 tickets. Kerberos\n    implementations should gain support for a DES TGT key that is used\n    for v4 requests but not v5 requests. 4) Remove Triple DES Kerberos 4 Support The cut and paste attack is a critical failure in MIT's attempt at\n    Kerberos 4 Triple DES. Even without cross-realm authentication,\n    this can be exploited in real-world situations. As such the\n    support for 3DES service keys  should be disabled.","sysaffected":"","thanks":"The CERT/CC thanks Sam Hartman, Ken Raeburn, and Tom Yu of the Kerberos group at MIT for their detailed analysis and report of this vulnerability.","author":"This document was written by Chad R Dougherty.","public":["h","t","t","p",":","/","/","w","e","b",".","m","i","t",".","e","d","u","/","k","e","r","b","e","r","o","s","/","w","w","w","/","a","d","v","i","s","o","r","i","e","s","/","M","I","T","K","R","B","5","-","S","A","-","2","0","0","3","-","0","0","4","-","k","r","b","4",".","t","x","t"],"cveids":["CVE-2003-0139"],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2003-02-13T15:35:08Z","publicdate":"2003-03-15T00:00:00Z","datefirstpublished":"2003-03-20T15:49:20Z","dateupdated":"2003-05-09T19:11:54Z","revision":14,"vrda_d1_directreport":"","vrda_d1_population":"","vrda_d1_impact":"","cam_widelyknown":"15","cam_exploitation":"0","cam_internetinfrastructure":"10","cam_population":"10","cam_impact":"19","cam_easeofexploitation":"10","cam_attackeraccessrequired":"10","cam_scorecurrent":"8.90625","cam_scorecurrentwidelyknown":"10.6875","cam_scorecurrentwidelyknownexploited":"17.8125","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":8.90625,"vulnote":null}