Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for OpenSSL > 1.0.2x #12

Closed
wiire-a opened this issue Mar 30, 2017 · 19 comments
Closed

Add support for OpenSSL > 1.0.2x #12

wiire-a opened this issue Mar 30, 2017 · 19 comments

Comments

@wiire-a
Copy link
Collaborator

wiire-a commented Mar 30, 2017

Debian and some other distros by default have installed the latest version of libssl-dev (1.1.0x).

Some API changes in the newer versions of the OpenSSL library break compatibility with Bully, which won't compile.

To successfully get it to compile, downgrade libssl-dev to the previous version (libssl1.0-dev) while a fix is being worked on.

@soxrok2212
Copy link
Collaborator

soxrok2212 commented Mar 30, 2017

This includes Kali-Linux (including Rolling 2016.x).

@kcdtv
Copy link

kcdtv commented Mar 30, 2017

Great to know that Bully is back !
Thanks maestro... 😸

@wiire-a
Copy link
Collaborator Author

wiire-a commented Apr 15, 2017

I created a temporary new repository over my github: https://github.com/wiire/bully-vanilla/tree/openssl-1.1.

Before I merge everything here I need some help testing.

@kcdtv
You are the most valuable tester I know of.

@OscarAkaElvis
Copy link

Yeah, @kcdtv is the best for this! I know him well 😄 . Anyway, here is my report:

Compiled and installed on Latest Kali Linux using libssl-dev (1.1). It compiles well.

Then using bully -V the version shown is v1.0-22. This is nice because at last there is no more compile errors on Kali. Anyway, this version has not implemented integration with pixiewps. @kcdtv told me you are the creator of pixiewps, so in first place hail! to you and thanks for your work. The version aanarchyy did was version 1.1 with pixiewps integrated. It could be nice to have a higher version (maybe 1.2 or whatever) with this wonderful changes you did and pixiewps integration!

@kcdtv and me (and others) are collaborating in a script called airgeddon. On that script bully is fully integrated and could be nice to have new versions there too. We use to control the bully version in order to determine if pixie-dust attacks can be integrated or not using bully.

On the other hand. It seems recently, aanarchyy bully 1.1 version was integrated (at last) on Kali repositories, it is show here: https://bugs.kali.org/view.php?id=3745 . It was proposed by one of our team. And of course this changes after finished will be proposed in the same way!

Good work!

@wiire-a
Copy link
Collaborator Author

wiire-a commented Apr 16, 2017

Thank you for helping. The plan is already to integrate the changes over this repo, however, before I do that, I need to know that everything works. Not only compiling but also "live" testing. It's important because I fused together sources from two different versions of wpa_supplicant. It seemed the most effective (or rather efficient) way.

I made all the changes on a clean repo because I was testing and still unsure what I needed to do to get it working. I chose to test over the vanilla version of Bully simply because I'm more familiar with it and if something doesn't work I know it's my fault and not someone else's (generally speaking, there are more non-vanilla versions) .

I want to clarify a couple of things though. At the time that aanarchyy was making his changes I had already a modified version of Bully which however I had not publicly released. It integrated pixiewps but was used to test other "theories" and speculations about new attacks or vulnerable devices. When this version came out I decided to not publish mine because really... it's practically the same (it does the same thing, using pixiewps).

That said I have no problem with maintaining this repository but I don't think I will make substantial changes to it. It's not my repository, the owner is MIA and if I were to port the changes I made to my own version, that would mean overwrite every change aanarchyy has made since the very beginning.

@OscarAkaElvis
Copy link

OscarAkaElvis commented Apr 16, 2017

Ok. Good to know. Let me some time and I'll test it, not only compilation what I already did.

I understand you prefer to do it on your own repo. Anyway, Can I ask you two things? in order to maintain coherence for the "bully integrators" (which we are):

  • Bully version should be higher than 1.1. In that way our script can detect bully is able to do pixiewps integrated attacks without any change in our side (we are already detecting version and allowing bully-pixiewps integrated attack if version is 1.1 or higher).
  • Can be the option for pixiewps integrated attack using "-d" argument in the same way than aanarchyy 1.1 version?

I'm not sure if that is too much to ask to you, but the point is if that two points are respected, we can work in airgeddon with any bully version without any change (old one, aanarchyy or your future version). I guess the original bully arguments will be in the same way and I'm only concerned about this. If finally these requests are not possible we'll need to launch different command lines depending of the version.

Thanks in advance, I'll be back to you with a report of using your bully version.

@wiire-a
Copy link
Collaborator Author

wiire-a commented Apr 16, 2017

​I write this to help clarify since others have asked too:

I'm maintaining this repository, but I'm not going to make substantial changes.

If I'll ever feel like adding more stuff then I'll do it in a new repository (that I own and have full control over).

The repository I created over my git is called bully-vanilla because it's the original version of bully with all the commit history imported. No pixiewps, no other changes (rather than very small fixes if strictly needed).

Again, if I'll ever decide to make substantial changes I'll create a new repository (new name, new versioning etc.).

@kcdtv
Copy link

kcdtv commented Apr 16, 2017 via email

@OscarAkaElvis
Copy link

I did some tests. I tried to connect to an Access Point knowing previously the PIN. Is an AP I have for testing and sadly I must say I tried and didn't achieved the password using this version of bully.

I tried using two different interfaces (Ralink RT3070 and Atheros AR9271) on latest Kali Linux.

My command line was:
bully wlan0mon -b 00:00:00:00:00:00 -c 8 -L -F -B -v 3 -p 12345670

Of course replacing 00:00:00... by my real bssid and 12345670 by my real PIN. This is the log

[!] Bully v1.0-22 - WPS vulnerability assessment utility
[+] Switching interface 'wlan0mon' to channel '8'
[!] Starting pin specified, defaulting to sequential mode
[!] Using '00:00:00:00:00:00' for the source MAC address
[+] Datalink type set to '127', radiotap headers present
[+] Scanning for beacon from '00:00:00:00:00:00' on channel '8'
[+] Got beacon for 'mySSID' (00:00:00:00:00:00)
[+] Index of starting pin number is '12345670'
[+] Last State = 'NoAssoc'   Next pin '12345670'

I deleted also the .bully dir before each test to avoid possible mismatching.

With the other bully versions and the same command line I used to get easily the password. Hope it helps!

@wiire-a
Copy link
Collaborator Author

wiire-a commented Apr 16, 2017

I realized I copied the wrong sources yesterday when testing (I compiled with 2.5 but uploaded 2.6, thinking I had solved everything).

It works flawlessly with 2.5.

In short, it's still broken.

The ideal solution would be to remove the dependency from OpenSSL entirely.

Thank you for testing.

@wiire-a
Copy link
Collaborator Author

wiire-a commented Apr 16, 2017

The dragon has been defeated!

wiire-a/bully-vanilla@03c37f6

It was easier than I thought...

@OscarAkaElvis
Copy link

Nice, do you need compilation and testing now?

@wiire-a
Copy link
Collaborator Author

wiire-a commented Apr 16, 2017

Compiling only should suffice.

@OscarAkaElvis
Copy link

Compiled without any problem on latest Kali. I tested twice. First as normal and then removig libssl-dev package before compiling. LGTM.

Not tested yet, only compilation.

@kcdtv
Copy link

kcdtv commented Apr 17, 2017 via email

@wiire-a
Copy link
Collaborator Author

wiire-a commented Apr 17, 2017

Thanks. I'll merge the changes later.

I'll be on IRC.

@wiire-a
Copy link
Collaborator Author

wiire-a commented Apr 17, 2017

Got rid of OpenSSL entirely: 04185d7.

@wiire-a wiire-a closed this as completed Apr 17, 2017
@OscarAkaElvis
Copy link

I don't know if my late feedback of testing is useful now. Anyway, tested and it works. It got the password of my AP. Congratz!

@cristi28
Copy link

cristi28 commented Apr 18, 2017

it's install and works very well thanks very good job

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants