airbase-ng -w <WEP key> (Maybe a bug?)

[Nick_the_Greek]

Hello to all.

You can say I am a semi-n00b and I started a small project in:
http://forums.remote-exploit.org/wireless/27676-how-e-z-setup-transparent-proxyed-sslstripped-wlan-based-fake-ap-6.html#post157045
which is mostly based on the airbase-ng. Lately I was trying to add WEP encryption and it will be very nice if someone cleared up some things.

The (-w) option in airbase-ng says :

-w WEP key       : use this WEP key to en-/decrypt packets

and man page says:

-w <WEP key>
              If WEP should be used as encryption, then the parameter "-w <WEP
              key>" sets the en-/decryption key. This  is  sufficient  to  let
              airbase-ng set all the appropriate flags by itself.  If the sof‐
              tAP operates with WEP encryption, the client can choose  to  use
              open  system  authentication  or shared key authentication. Both
              authentication methods are supported by airbase-ng. But to get a
              keystream,  the  user  can try to force the client to use shared
              key authentication. "-s" forces a shared key auth and "-S <len>"
              sets the challenge length.

Obviously (find out while trying various key) airbase-ng accepts only HEX keys. So, these keys must be 10 HEX characters long or 26 HEX characters long.

Using Aircrack-ng 1.0 rc3 r1552

The followings are all accepted as valid keys.
40bit keys (10 characters long)

Code:

airbase-ng -w 1234567890 mon0
airbase-ng -w 12:34:56:78:90 mon0

104bit keys (26 characters long)

Code:

airbase-ng -w 12345678901234567890123456 mon0
airbase-ng -w 12:34:56:78:90:12:34:56:78:90:12:34:56 mon0

all are good until now.

Here starts the "strange" part:
11 characters long

Code:

airbase-ng -w 12345678901 mon0
airbase-ng -w 12:34:56:78:90:1 mon0

and 27 characters long

Code:

airbase-ng -w 123456789012345678901234567 mon0
airbase-ng -w 12:34:56:78:90:12:34:56:78:90:12:34:56:7 mon0

are also accepted. Don't know if this is bug and my thought was to report it.

Also, it will be nice if we could use airbase-ng with ASCII passphrases  and only with HEX keys. Off course we can  easily convert ASCII passwords to HEX passwords:

Code:

echo -n $WEPKEY | xxd -p

I am very sorry for my bad English and maybe the wrong place to post. (Haven't notice the BUG section)

Keep up the good work.

Nick

[darkAudax]

Nick,

Yes, an odd number of characters are truncated to the last even number of characters.  IE 11 characters are treated as 10 which is valid.

So, yes it is a minor bug that an error message is not provided.

d.

[Nick_the_Greek]

darkAudax,

Thank you for your reply.

Something similar with the -w is happening with the -e option of airbase-ng. Airbase-ng doesn't care how long is the ESSID. Correct if I am wrong, but I think that this must be up to 32 printable characters long without spaces. Airbase-ng accepts loooong ESSIDs up to 255 characters long. Like this one:

Code:

airbase-ng -e 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345 mon0

Windows clients doesn't show up the ESSID of airbase-ng created AP(hidden).

Linux clients show:(example: airbase-ng with 100 char long ESSID)
iwlist <interface> scanning shows: multiple cells of the same AP, ESSID is blank and "IE: Unknown: 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890"
To be honest, I don't know what is this "IE: Unknown: "

On the other hand airodump-ng can read correctly this false ESSID.

CH 11 ][ Elapsed: 0 s ][ 2009-11-10 15:11

 BSSID              PWR  Beacons    #Data, #/s  CH  MB   ENC  CIPHER AUTH ESSID

 00:1C:F0:D6:F3:0C    0       28        0    0  11  54   OPN              1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

 BSSID              STATION            PWR   Rate    Lost  Packets  Probes

 (not associated)   00:22:43:5E:71:43  -40    0 - 1      7        9  12345678901234567890123456789012

Hope I helped in some way.

Nick

PS One question: The -x (nbpps) is related with the injection speed of the card that is used? In other words if a card can inject 500 packets per second then we can change that value to 500? This is effecting the overall behavior of the FakeAP? I am a little bit confused with that.

[darkAudax]

Nick,

The -x injection rate applies to packets injected for the attack modes if I remember correctly.

d.

[Jano]

Hi Nick_the_Greek,
DarkAudax is right.

- For default option, Aireplay-ng inject at 500 nbpps, and min/max range of -x number/value of packets per second, is 1 --> 1024.
- With Wlan-ng/HostAP drivers, the default injection rate is set to 200 nbpps.

Bye Jano

[Nick_the_Greek]

darkAudax and Jano,

Thank you for your replies.

Jano, maybe I wasn't clear enough. I was referring to airbase-ng''s nbpps but after all it is the same with aireplay-ng. I was hopping that the nbpps for airbase-ng particularly is referring to the transmission rate of the FakeAP and not to packets injected for the attack modes.

One parallel usage of the airbase-ng is to build up a wireless LAN which I am interest on. I have found out that there is a huge difference between the drivers that have been used. One example is the ath5k and ath_pci drivers. Ath5k are extremely slow in comparison with ath_pci (madwifi-ng) both patched for injection. With the term slow I mean how fast can receive data the clients of my wireless LAN. Sorry if I am not using the right terminology. I thing you understand what I am talking about.

I already know that airbase-ng supports fragmentation and it don't like some Alpha cards.

The overall behavior of the FakeAP based WLAN is related only to the card (chipset) and the drivers that I am using? In short, is there something I can do with airbase-ng to fine-tune the wireless LAN?

Thank you in advanced.

Nick

[Mister_X]

Nick_the_Greek, you are right saying that the ESSID can be up to 32 characters long but in theory, this field can have up to 255 characters.