Jump to content

finding hidden essid


ret

Recommended Posts

ok so i've got a little challange in working on and hope someone here can give a hint. I have a wireless AP using WEP (i know its only a training scenario) with a hidden ESSID. I was given the ESSID and that was it. My task is to find the netowrk, crack the wep and issue a report of my methods.

I have ran airodump and found several AP's. many of them are <lenght 0>. I can however in the clients table see a bssid = unassociated client = <mac> connecting to hidlan

ive attempted to run mdk3 ath0 -p -e hidlan it ran about 20 min but then i had to go.

so to my question....

What method could i use to find the bssid of an AP with a hidden essid in this scenario? am i on the correct path with mdk3?

Thanks,

- Ret

Link to comment
Share on other sites

Thanks for the reply, i am using a BT3 live CD. I have a card in monitor mode. my concern is that there are several <lenght 0> / <lenght 1> AP's showing. i dont want to connect to the wrong device. Oddly enough i tried this out of the lab environment (at home) using a wrt54g, disabled xmit of essid, airodump found it as soon as my iphone connected. the only exception is that im using WPA2 Personal w/TKIP+AES.

Link to comment
Share on other sites

I can see a ssid when a client connects (lower half of airodump-ng) it will show me the clients mac but not the AP's bssid.

how can you not see the AP's bssid? the access points BSSID/MAC ADDRESS IS ALWAYS VISIBLE! observe

starwars.png

Thats me cracking my own WPA-PSK...

as you can see under the BSSID column, my AP's mac address == 00:0F:B5:AC:B7:D6

and under the STATION column, the client that was connected's mac address is 00:11:50:78:78:7E

maybe your just confused... STATION is the clients mac address, BSSID is the access points mac address!

I always start out with

airodump-ng [deviceinterface]

which shows me all the access points within range, their bssid's and ssids(if not hidden) even if the ssid is hidden it will show when a client connects so you'll have to wait for that if there are no clients connected, or if there is a client already connected you can deauth them to make them reconnect...

I don't understand how the BSSID won't show? can you take a screenshot maybe? ksnapshot from the menu since your using backtrack! ;)

always always when I do airodump the bssid of every wireless access point shows!

for WPA you capture the handshake and brute force the key with a dictionary, for WEP you capture IV's which gives aircrack-ng an idea of what the key probably is, then brute force to finish the job! :)

WEP is very easy to crack, WPA you won't crack unless the exact passphrase is in your dictionary!

Link to comment
Share on other sites

I will have to get a screenshot for you.

In the lower section it will show a bssid of <not associated> and a station id of the client's mac under probe i will see the essid im looking for "hidlan"

In the upper section i will see several <lenght: 0> and <lenght: 1> essid's. The instructor has given one more clue... this is a multiple cisco ap environment (3ap's) there are 2 essid's on the network. "publan" and "hidlan"

publan is open hidlan is 128WEP.

Link to comment
Share on other sites

You will sometimes see ”<length: ?>” as the SSID on the airodump-ng display. This means the SSID is hidden. The ”?” is normally the length of the SSID. For example, if the SSID was “test123” then it would show up as ”<length: 7>” where 7 is the number of characters. When the length is 0 or 1, it means the AP does not reveal the actual length and the real length could be any value.

To obtain the hidden SSID there are a few options:

  • Wait for a wireless client to associate with the AP. When this happens, airodump-ng will capture and display the SSID.
  • Deauthenticate an existing wireless client to force it to associate again. The point above will apply.
  • Use a tool like mdk3 to bruteforce the SSID.
  • You can use Wireshark combined with one or more of these filters to review data capture files. The SSID is included within these packets for the AP.

wlan.fc.type_subtype == 0 (association request)

wlan.fc.type_subtype == 4 (probe request)

wlan.fc.type_subtype == 5 (probe response)

http://www.aircrack-ng.org/doku.php?id=air...en_ssids_length

@ret: I think you have the more understanding of the actual problem than anyone else.

@Steve8x: There's another world with other stuff than just the things you have seen.

Link to comment
Share on other sites

Thanks for the info. I actually already got this one reslved. It was ia real pain. What i ended up doing was running airodump-ng on 3 systems (there were 3 ap's) and mdk3 with p -e essid. There was verry little data coming across and the essid in airodump-ng would switch back and forth between the public open and private "hidden". unfortunately i was unable to get aireplay to work since it was unable to obtain a beacon of the hidden essid, it would default to the public which was open anyhow so the data was useless.

Anyhow, after running the 3 laptops on each bssid after about 20 hours i was able to gather about 100000 IV's and crack the WEP. It was quite an interesting exersize. I am sure there are other tools to use that would have made life easier but for now im satisfied that i was able to complete the task.

Thanks everyone for your assistance.

Link to comment
Share on other sites

There aren't any tools that can detect an essid unless the AP broadcasts it, or unless one of the clients probes and connects.

You can't get that kind of information out of thin air. And anyway, no clients == no cracking under 5 minutes, so usually no point in trying.

Oh, and using multiple laptops will not boost results in any way possible.

Link to comment
Share on other sites

@ret: Well I'm glad you accomplished your goal and finally did what you were trying to do! 20 hours sounds a bit long though are you sure were talking about WEP here? ;)

@CrashandDie: No clients != no cracking in under five minutes! Not at all! If you have a good connection to the access point you can get the job done fast! For WEP at least :)

I cracked my friends wifi in about 2 minutes (I didn't take the picture immediately) with absolutely no clients connected!!!!

3minutecrack.png

Mainly because his computer was pretty close to the router so I had a great connection to it. Plus the key was only a 64 bit key!

I collected over 46,000 IV's in only 3 minutes but all it took was 22,738! I used a simple "Interactive Packet Replay" attack once associated which was very effective! Oh and I didn't forget to specify the device interface when I typed the aireplay command to do the attack, When I copied the bssid from the text file I accidentally selected the white space after the bssid so when I hit shift + insert to paste it, it hit enter for me! so now I'm more careful when selecting from a text file to copy from... ;)

Also using multiple laptops CAN boost the speed of cracking (if they all have wifi devices which are capable of monitor mode && packet injection!)

You could use each one to do multiple attacks on the AP simultaneously! So say you've collected 33,333 IV's on each of the three laptops, now you could rename each of the capture files "something-01.cap, something-02.cap, something-03.cap"

and put them all in the same place, then when you run aircrack-ng

with something like

aircrack-ng something*.cap

it will use all three capture files instead of just one to crack the key :)

Link to comment
Share on other sites

Oh, and using multiple laptops will not boost results in any way possible.

Actually thats incorrect for this situation. using multiple laptops listening on seperate channels was more effective in capturing more IV's in less time. My total time spent on the scenario was just shy of 1/3 less than the rest of the students. I do however appriciate the advice.

Link to comment
Share on other sites

Also using multiple laptops CAN boost the speed of cracking (if they all have wifi devices which are capable of monitor mode && packet injection!)

You could use each one to do multiple attacks on the AP simultaneously! So say you've collected 33,333 IV's on each of the three laptops, now you could rename each of the capture files "something-01.cap, something-02.cap, something-03.cap"

and put them all in the same place, then when you run aircrack-ng

with something like

aircrack-ng something*.cap

it will use all three capture files instead of just one to crack the key :)

and that is exactly what i did to crack the wep key. It was a 128 bit key, the "clients" attached were a wireless printer and a desktop that was hibernating (on each of the 3 AP's). the only data transmission was the occasional beacon from the printer back to the ap. Anyhow, gathering all the capture files and running aircrack-ng *.cap proved to be successful.

Thanks again to everyone's advice.

Link to comment
Share on other sites

Have you ever tried netstumbler. It will get the ssid's of any AP, their MAC address and Channel they are on.

http://www.netstumbler.com/

Kismet for Linux will also do the same thing.

Link to comment
Share on other sites

netstumbler is cool for windows however it doesnt do passive scanning hence no discovery of hidden ap's

I've found stuff with netstumbler that windows normal wifi finder doesn't seem to find. Not sure how its doing it, but my work uses hidden AP's on the internal lan, yet Netstumbler finds them as well as Linux with Kismet. These are WPA encrypted networks(Yet netstumbler tells me they are wep) and I can see them just fine. What version of Netstumbler are you using?

Link to comment
Share on other sites

its a fundamental driver issue with windows... There's only a few wireless cards that allow you to do passive scanning in windows and there's more in Linux that allow you to do passive scanning. Anyways im just going to paste text from a website that explains it better.

"Passive vs. Active Sniffers

Kismet is a passive sniffer. Unlike NetStumbler, which broadcasts a request for access points responding to the SSID name “ANY,” Kismet does not send any packets at all. Instead, Kismet works by putting the wireless client adapter into RF monitor mode. While in so-called “rfmon” mode, the wireless client is not (and cannot be) associated with any access point. Instead, it listens to all wireless traffic. Consequently, your wireless card cannot maintain a functional network connection while under Kismet control.

Users often report that Kismet finds more APs than NetStumbler. This is because NetStumbler only knows about access points that respond to its “ANY” SSID probe request. Some network administrators configure their APs not to broadcast, or to “hide” their SSID. These do not respond to NetStumbler’s probe. Because the AP blanks out its SSID, Kismet will detect its presence, but without a network name. However, when a legitimate client associates with that AP, its real SSID is included in the initial handshake. Because Kismet sees all network management traffic, it will pick up these packets and discover the SSID which was supposedly “hidden.”

Supported Hardware

Whereas NetStumbler can provide at least some functionality with any wireless card supported by OS drivers, Kismet functions only with network cards with drivers that support RF monitoring mode. In general, this includes wireless cards based on the PRISM 2, 2.5, 3, and GT chipsets; older ORiNOCO cards without the HermesII chipset, such as the Orinoco Gold; and Atheros a/b/g chipsets.

In practice, there are dozens of wireless cards on the market, and it is not always obvious whether there are supported drivers available. Some of the more popular supported wireless adapters include the ORiNOCO Gold, the original Apple Airport (not Extreme) card, and Intel Centrino.

To further complicate things, drivers available for one platform, such as Linux, may not be available for another, such as OS X, even though Kismet itself is available for both. In general, Linux has the most supported drivers for Kismet.

The Kismet Web site hosts a forum for discussion and questions about supported cards and driver availability."

Link to comment
Share on other sites

I've found stuff with netstumbler that windows normal wifi finder doesn't seem to find. Not sure how its doing it, but my work uses hidden AP's on the internal lan, yet Netstumbler finds them as well as Linux with Kismet. These are WPA encrypted networks(Yet netstumbler tells me they are wep) and I can see them just fine. What version of Netstumbler are you using?

I'm sure that windows just displays "unnamed network" does it not? I've seen these same AP's in netstumber and simply have no essid in the list.

Link to comment
Share on other sites

Just wanted to put my two cents in. The newest version of Kismet has some wicked abilities to detect "cloaked" ssids. Yes, you will still need to have a client connected, it definitely doesn't take as long any more. They will show up in Kismet as blue ESSIDs when you get them. An easy way to generate that traffic that will reveal a ESSID is the old school blanket deauth.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...