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
Can we get an user agent collector module ? #85
Comments
Not a bad idea. Do you know of any open databases that will return the vulnerability of a browser based on the UA? If I were to design this module, I would use a captive portal that lets anyone through after they just land on it once. Store their metadata, and return. |
@foxtrot if you assign this to me I can probably put something together. @minanagehsalalma you can choose the module name :) |
It's my pleasure.. what about UAC stands for user agent collector 😅? |
Maybe not wait for them to land on a page but catch apps connection requests if possible to get the metadata even faster. |
@minanagehsalalma You would have to wait for a request made over HTTP, which would take longer no? If you drop them into a "passive" captive portal they would hit your HTTP page, then you can grab the metadata and redirect them to wherever they were going. |
Yup you are right ... But I am talking about in case of karma attack where the phone screen shouldn't be necessary turned on... So the apps in the background will do the trick I think. |
Ah I see, maybe it would be best to implement both, and neither if they are already captured. |
I agree it can't be better. |
Bare in mind that if you're trying to figure out client OS / Device type and not just strictly user agents, you can use more than HTTP requests. |
I think most of the time user agent contains the client os but maybe not it's version. Incase of mobile device it's either Android or iOS and you can tell that from just the model name. |
I think the easiest way to do this would be a captive portal. The second they connect to your device you can serve a blank page, snag the headers, then close the portal/authenticate the client. |
Yup that's the easiest way. Although i don't think that capturing that header from apps requests is hard |
@minanagehsalalma heres a small update on what I have working so far. I have the module drop a portal that authorizes users right away, while grabbing some profile information. I still have a lot of editing to do to make sure formatting looks good, as well as add some options like downloading these captures, etc. etc. |
great job mate this looks good so far. |
Can you make a checklist on the original post for objectives like
That way I can go through each and check off points |
Hi first where is the device model in the picture you uploaded just like this |
And about the objectives should i include the karma attack part ? |
|
Yup but shouldn't there be a model number just like the pic ? |
I would leave the karma attack out of this module. This module is more like a Second-Stage attack. I was thinking more like adding "Controls". For example, alongside the captive portal we could have a URL sniffer that pulls out profiling information. So the controls column reads like: Captive Portal [On] |
No idea, these are the Headers from the HTTP request. |
Other than the useragent ?
Hmm.. can you try this site and check if it gives you the same results ! Also check the original post i have added the check list ... what do you think? |
I will just assume for now those Headers are correct. Perhaps Apple does not give away that info?
Looking good so far |
Yup i checked it and it doesn't Edit : it sometimes does and sometimes doesn't |
@foxtrot what do you think the ios model number fix is ? |
Not sure what you mean. If the client browser isn't sending the model number in the User Agent string, then it simply is not there. It's entirely up to the browser what is and isn't sent. |
Yup but i meant a way around it So would connection requests from such applications contain it right ? In this article there is much better solutions Like using JavaScript to determine the phone model via it's screen height, width and pixel density. @trashbo4t should i add this to the check list ? |
@trashbo4t does this gives you any additional info ? More than just the useragent for ios? |
This seems better and stable solution WURFL script from a stack over flow answer And of course we can download it to get it working offline Then console.log(WURFL); Or maybe this iDevice.js although i think wurfl is better. |
@trashbo4t Ehh... Were they watching the thread or what !! |
@trashbo4t what do you think of the new one #88 it's has a bit in common with this ! |
Perhaps a step by step implementation of your attack might be more readable. Also, loved the google chrome article haha |
@trashbo4t
Just check this ... It's the very same idea but requires doing it manually Half handshake capturing (from failed connection by answering saved networks prob requests )and cracking them to find a password from a weak one that can be used later to get the victim auto connected to our fake ap when there is no available saved open networks on his device. |
Or in numbered steps from another post 2- launch 2 version of the ssids one open and one secure if it connects to the open one put a red check mark on it (in the list of the probed networks ) and if connects to the secure one capture the handshake and put a green check mark on it (in the same list ) 3-after capturing a Good number of handshakes then start brute forcing 4- when it cracks a weak one.. broadcast it to get the victims connected This should be a work around for karma attack when the targeted device doesn't have saved open networks. |
@trashbo4t |
While I do think thats a good Idea, Im also keen on the idea of keeping modules "modular". As in separate functionality with a common means of communication. Something like microservices. An nmap module already exists to do port scanning, so if that module does a port scan, users can collect that information and store it in their "Notes" with an association to a mac address. Any other module that needs to know about open ports can run the scanning module, or reference their "Notes", and use that collected information. |
@trashbo4t |
But then there should be a merged module that can do all of this in a one run with the title of "clients info collector" |
What do you mean by merged? |
All in one ..... Or they can just run the nmap module after this one. |
Modules can interact with other modules using the API, FYI.
|
Great we can add it to the description "to gather more info about the clients run the nmap module using the api" |
@trashbo4t What do you think ? This the most somewhat new one i could come up with (currently ;) |
Here's how it should be
1- get the clients from other aps connected to our pineapple using deauth/karma
2- grab their user agent from their connection requests(apps and sevices ) or using a captive portal page to get it faster
3- store their (device name - mac address - useragent - and the network name that they was connected to or their ssids prob requests ) in a db
4- it would be great if we could automatically rank the vunrablite status of the devices from the db..
Thanks .... would do you think of this idea ?
Edit: the objectives check list
1- do a network scan on the target network and save the clients mac and prob requests to a db
2- you got two options
waiting for the client to connect manually
Or
karma attack ( deauth and replicate a probe network ssid )
3- they will land on the captive portal page
catch the useragent headers and save it
catch the ip and mac address of that device and save it with the headers
About number unfortunately i can't think of a way to automate it ...
I think we can leave to the user to manually perform it by searching the device model or os version for known vunrablites on the web.
The text was updated successfully, but these errors were encountered: