View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003663 | Kali Linux | General Bug | public | 2016-10-10 21:39 | 2016-10-11 17:48 |
| Reporter | [email protected] | Assigned To | muts | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Summary | 0003663: Security Issue | ||||
| Description | R7-2016-25: Offensive Security Kali Linux PWK VM SSH Key Summary The following vulnerability affects users of Offensive Security's Kali Linux Penetration Testing With Kali (PWK) VM with SHA1 of A user who changes to root on the PWK VM, then attempts to login via SSH to an account that uses the provided SSH key can gain access to those accounts without further authorization. Note that, by default, this key is not listed in any authorized_users file that ships with the PWK VM. This vulnerability was discovered by Lance Sanchez of Rapid7, Inc., and this advisory was prepared in accordance with Rapid7's disclosure policy. (Disclosure trimmed to try to avoid hitting the WAF.) | ||||
| Steps To Reproduce | Fire up the PWK VM. Notice the id_rsa keypair in the root home directory. | ||||
| Additional Information | This issue was discovered by Lance Sanchez of Rapid7, Inc., after a weird sequence of events. One, he generated a new RSA keypair, but then managed to paste the shipping public key in his clipboard, unbeknownst to him. This was probably an ssh-agent issue. Next, when he went to register the shipping key on GitHub (again, accidentally having had the pre-existing key), he hit a collision; another GitHub user had already registered with the key. We'll be reaching out to that affected GitHub user separately. In other words, while people shouldn't be using the shipping key for access control, it seems like it's at least a little bit easy to accidentally use it. | ||||
|
Thanks for this report, however the VM you link to is not a publicly available VM distributed by the Kali Linux project, it is a private VM distributed by Offensive Security as part of the OffSec courseware. Therefore i'm closing this bug. I have notified the responsible Offsec parties and they will look into correcting the issue. |
|
|
Oh and just fyi, the business of bug trackers automatically copying bugs into cleartext email is a little contentious when it comes to trying to maintain some security around communications. I don't mind using web forms at all -- HTTPS is way easier than PGP -- but that transport security is a little ruined after the fact. I think Bugzilla has a mechanism for PGP'ing updates on private issues, but afaict, nobody uses it. Also, reporting this bug initially caused your WAF to freak out. It might have been the fact that I was trying to post a private key? Can't tell. Again, just FYI. Also also, I've written to the holder of this key who registered it on GitHub, let him know the situation, and asked him to respect the disclosure embargo of 60 days. Feel free to reclose this bug and let me know if OffSec needs anything else from me. Just wanted to get these comments in here. |
|
|
Thanks for the update. |
|
|
Sure, users shouldn't use pre-generated keys, but it appears that it's at least a little bit easy to accidentally use this pre-generated key (given that we've found it at least once in the wild). I agree that the severity is quite low; it doesn't appear to be tied to an authorized_users file or anything like that. But if that's the case, why ship it at all? There doesn't seem to be any legitimate utility with this key. IOW, users shouldn't use it, and OffSec shouldn't be handing it out. :) That's my take, anyway. |
|
|
Agreed, however - distinguishing between "user error" and "product vulnerability" should be fairly easy when it comes to bug classification. I find it somewhat strange that Rapid7 would go through the whole process of vulnerability disclosure with CERT and requesting 60 day disclosure embargos from users - for something that can be chalked up as a cosmetic issue. Regardless, the keys have been removed from the VM, and a new PWK image is currently being uploaded...so thanks for the heads up in any case! |
|
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-10-10 21:39 | [email protected] | New Issue | |
| 2016-10-11 05:23 | muts | Note Added: 0006044 | |
| 2016-10-11 05:23 | muts | Status | new => closed |
| 2016-10-11 05:23 | muts | Assigned To | => muts |
| 2016-10-11 05:23 | muts | Resolution | open => no change required |
| 2016-10-11 14:23 | [email protected] | Note Added: 0006047 | |
| 2016-10-11 14:23 | [email protected] | Status | closed => feedback |
| 2016-10-11 14:23 | [email protected] | Resolution | no change required => reopened |
| 2016-10-11 14:23 | [email protected] | Note View State: 0006047: private | |
| 2016-10-11 17:09 | muts | Note Added: 0006049 | |
| 2016-10-11 17:10 | muts | Note Edited: 0006049 | |
| 2016-10-11 17:20 | [email protected] | Note Added: 0006050 | |
| 2016-10-11 17:20 | [email protected] | Status | feedback => assigned |
| 2016-10-11 17:29 | [email protected] | Note View State: 0006050: private | |
| 2016-10-11 17:42 | muts | Note Added: 0006051 | |
| 2016-10-11 17:43 | muts | Status | assigned => closed |
| 2016-10-11 17:43 | muts | Resolution | reopened => no change required |
| 2016-10-11 17:43 | muts | View Status | private => public |
| 2016-10-11 17:44 | muts | Note Edited: 0006051 | |
| 2016-10-11 17:48 | muts | Note Edited: 0006051 | |
| 2016-10-11 19:07 | muts | Note View State: 0006047: public | |
| 2016-10-11 19:07 | muts | Note View State: 0006050: public |