s0lst1c3 / eaphammer

Targeted evil twin attacks against WPA2-Enterprise networks. Indirect wireless pivots using hostile portal attacks.
GNU General Public License v3.0
2.19k stars 313 forks source link

Feature Request: Import External Certs (orig: Importing Certificates) #35

Closed tjt263 closed 5 years ago

tjt263 commented 6 years ago

I'm trying to import my own certs into eaphammer. What's the best way to do this? I tried replacing the .pem files in the eaphammer/certs/ directory but to no avail.

The --cert-wizard is good for a quick demo, but easily thwarted by a decent EAP supplicant.

s0lst1c3 commented 6 years ago

We can probably throw in some flags that allow you specify certs manually. This is actually really good timing, since we're about to merge a ton of new changes that allow more granular control by advanced users. Let's Encrypt integration for attacking BYOD devices is something that's on the horizon as well. Does this sound good to you or is there anything else you'd like to see added as well?

Thanks for the feedback and suggestions.

tjt263 commented 6 years ago

Let me think on it and I'll get back to you with some ideas.

In the meantime, how can I get this to work, manually? Can I just replace the certificate files? Is the client.cnf file required?

s0lst1c3 commented 6 years ago

You'll need to replace just about everything except the client.cnf file, which is only required if you're trying to create an access point that uses EAP-TLS or PEAP/TTLS with client-side certs (which pretty much defeats the purpose of using this tool).

If you don't mind me asking, where'd you get the certs from and how were they created? Can you give me a list of the files you're trying to import?

tjt263 commented 6 years ago

The details of this particular network are: 802.1x (PEAP/MSCHAPv2) WPA2 Enterprise.

They're legitimate certificates exported from a MacBook Pro. The first time a legitimate user connects to the network, they're prompted to accept or deny the server certificate. Upon accepting, the relevant certificates (including Root CA & Intermediate CA) are saved to disk. On macOS, they can be accessed, evaluated, deleted, exported, and so on with the native Keychain\ Access.app. Export formats are .cer, .pem, and .p7b. I chose .pem because I noticed that format in the eaphammer/certs/ directory.

After exporting the certificates, I just pushed them to my Linux laptop via scp and tried replacing the 01.pem, ca.pem, and server.pem files that were generated by the --cert-wizard. But I couldn't get it to work.

I can't really share them publicly, but I'm happy to continue this in private if you like.

s0lst1c3 commented 6 years ago

Very interesting! Shoot me an email if you want: gabriel@digitalsilence.com. I have a sneaking suspicion as to what may be causing this issue, but let's take this offline for now.

s0lst1c3 commented 6 years ago

@tjt263 - Ok, I have a temporary workaround that may make your life a lot easier. Instead of trying to replace the files in the certs directory, try the following steps:

  1. Create a self-signed cert using --cert-wizard
  2. Run eaphammer using whatever flags you were planning on using as part of your attack, but also include the --save-config-only flag. This will cause eaphammer to create a hostapd config file instead of launching the attack
  3. Open the config file you just created in a text editor of your choice, and then modify or remove the following values as needed: __ca_cert__, server_cert, private_key, private_key_passwd, and dh_file.
  4. Launch your attack, but make sure to use the --manual-config flag to load your config file.

I'm working on a better solution, but hopefully this will at least allow you to do whatever you're trying to do.

tjt263 commented 6 years ago

Just read this.

keyhugger commented 6 years ago

Very nice, thank you! I just searched for that! I would like to outpoint this nice paper: https://arts.units.it/retrieve/handle/11368/2915044/203999/2018-CS-EvilTwinsSecurityDisaster.pdf

It's quite new and it's interesting that some Clients seem to don't care whatever cert is used, as long as it is trusted. Yo my Idea was to create just any domain (if you doing RedTeam you might use a similar name = double chance) for example evilcorp.com vs. eviicorp.com and obtain a LetsEncrypt (or whatever you want) certificate.

One can use that certificate, cause some clients aren't locked to a specific CA and therefore trust that certificate (well it is, in the end, trusted :-D).

s0lst1c3 commented 6 years ago

Thanks! I’ll definitely check that out, it sounds interesting and could definitely make this project stronger.

-- Gabriel Ryan Email: gabriel@solstice.me mailto:gabriel@solstice.me Twitter: @s0lst1c3 https://twitter.com/s0lst1c3 Phone: +1-410-920-8101 <tel:+1-410-920-8101>

On Oct 29, 2018, at 11:07 AM, keyhugger notifications@github.com wrote:

Very nice, thank you! I just searched for that! I would like to outpoint this nice paper: https://arts.units.it/retrieve/handle/11368/2915044/203999/2018-CS-EvilTwinsSecurityDisaster.pdf https://arts.units.it/retrieve/handle/11368/2915044/203999/2018-CS-EvilTwinsSecurityDisaster.pdf It's quite new and it's interesting that some Clients seem to don't care whatever cert is used, as long as it is trusted. Yo my Idea was to create just any domain (if you doing RedTeam you might use a similar name = double chance) for example evilcorp.com vs. eviicorp.com and obtain a LetsEncrypt (or whatever you want) certificate.

One can use that certificate, cause some clients aren't locked to a specific CA and therefore trust that certificate (well it is, in the end, trusted :-D).

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/s0lst1c3/eaphammer/issues/35#issuecomment-433945353, or mute the thread https://github.com/notifications/unsubscribe-auth/AFJSC3CCh81MHDHjHXo_QWHhcRZqheeLks5upxmbgaJpZM4TCZTq.