Can we get an user agent collector module ?

[minanagehsalalma]

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.

[pidgy]

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.

[pidgy]

@Foxtrot if you assign this to me I can probably put something together.

@minanagehsalalma you can choose the module name :)

[minanagehsalalma]

you can choose the module name :)

It's my pleasure.. what about UAC stands for user agent collector 😅?

[minanagehsalalma]

I would use a captive portal that lets anyone through after they just land on it once

Maybe not wait for them to land on a page but catch apps connection requests if possible to get the metadata even faster. @Foxtrot what do you think ?

[pidgy]

@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.

[minanagehsalalma]

You would have to wait for a request made over HTTP, which would take longer no?

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.

[pidgy]

Ah I see, maybe it would be best to implement both, and neither if they are already captured.

[minanagehsalalma]

best to implement both, and neither if they are already captured.

I agree it can't be better.

[foxtrot]

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.

[minanagehsalalma]

not just strictly user agents

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.

[pidgy]

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.

[minanagehsalalma]

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 Just like fluxion webserver tab

[pidgy]

@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.

[minanagehsalalma]

@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.

[pidgy]

@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

• Capture HTTP Headers.
• Capture MAC address.
• Make Request to blah.com

That way I can go through each and check off points

[minanagehsalalma]

@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

• Capture HTTP Headers.
• Capture MAC address.
• Make Request to blah.com

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

[minanagehsalalma]

And about the objectives should i include the karma attack part ?

[pidgy]

@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

• Capture HTTP Headers.
• Capture MAC address.
• Make Request to blah.com

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

Here -> device is an Ipad

[minanagehsalalma]

@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

• Capture HTTP Headers.
• Capture MAC address.
• Make Request to blah.com

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

Here -> device is an Ipad

Yup but shouldn't there be a model number just like the pic ?

[pidgy]

And about the objectives should i include the karma attack part ?

I would leave the karma attack out of this module.

This module is more like a Second-Stage attack. Getting the user onto your network is the First-Stage.

I was thinking more like adding "Controls".

Like this:

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] URLSniffer [On] DNS Sniffer [On} etc. etc.

[pidgy]

@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

• Capture HTTP Headers.
• Capture MAC address.
• Make Request to blah.com

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

Here -> device is an Ipad

Yup but shouldn't there be a model number just like the pic ?

No idea, these are the Headers from the HTTP request.

[minanagehsalalma]

could have a URL sniffer that pulls out profiling information.

Other than the useragent ?

No idea, these are the Headers from the HTTP request.

Hmm.. can you try this site and check if it gives you the same results !
https://www.whatismybrowser.com/detect/what-is-my-user-agent

Also check the original post i have added the check list ... what do you think?

[pidgy]

could have a URL sniffer that pulls out profiling information.

Other than the useragent ?

No idea, these are the Headers from the HTTP request.

Hmm.. can you try this site and check if it gives you the same results ! https://www.whatismybrowser.com/detect/what-is-my-user-agent

I will just assume for now those Headers are correct. Perhaps Apple does not give away that info?

Also check the original post i have added the check list ... what do you think?

Looking good so far

[minanagehsalalma]

I will just assume for now those Headers are correct. Perhaps Apple does not give away that info?

Yup i checked it and it doesn't Ref: https://deviceatlas.com/blog/mobile-browser-user-agent-strings

Edit : it sometimes does and sometimes doesn't Ref: https://51degrees.com/blog/detect-apple-iphone-model-numbers-and-user-agents

[minanagehsalalma]

Edit : it sometimes does and sometimes doesn't Ref: https://51degrees.com/blog/detect-apple-iphone-model-numbers-and-user-agents

@Foxtrot what do you think the ios model number fix is ?

[foxtrot]

@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.

[minanagehsalalma]

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.

Yup but i meant a way around it In the ref link the author said "In select cases, most commonly when requested through a web application such as Facebook, Snapchat or Instagram, we are treated with a device identifier."

So would connection requests from such applications contain it right ?

In this article there is much better solutions https://51degrees.com/blog/device-detection-for-apple-iphone-and-ipad

Like using JavaScript to determine the phone model via it's screen height, width and pixel density. Or cpu stress or WebGL API ... which i think are a bit complicated than the screen resolution one.

@trashbo4t should i add this to the check list ?

[minanagehsalalma]

@trashbo4t does this gives you any additional info ? More than just the useragent for ios? https://51degrees.com/resources/user-agent-tester

[minanagehsalalma]

This seems better and stable solution WURFL script from a stack over flow answer Just add this to the captive portal page <script type='text/javascript' src=“//wurfl.io/wurfl.js"></script>

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.

[minanagehsalalma]

@trashbo4t @Foxtrot

Ehh... Were they watching the thread or what !! https://www.zdnet.com/article/google-to-phase-out-user-agent-strings-in-chrome/

[minanagehsalalma]

At least it still works with fb or Ig... If we get them to open the captive portal page with them... Or of course... Other browsers like the default one : Android webview will simply work.

[minanagehsalalma]

@trashbo4t what do you think of the new one https://github.com/hak5/wifipineapple-modules/issues/88 it's has a bit in common with this !

[pidgy]

@minanagehsalalma

Perhaps a step by step implementation of your attack might be more readable.

Also, loved the google chrome article haha

[minanagehsalalma]

loved the google chrome article haha

@trashbo4t Yup although that's gonna Impedes us a little bit ... It still a good thing .

Perhaps a step by step implementation of your attack might be more readable.

Just check this ... It's the very same idea but requires doing it manually https://github.com/dxa4481/WPA2-HalfHandshake-Crack

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.

[minanagehsalalma]

Or in numbered steps from another post 1-capture the prob requests

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.

[minanagehsalalma]

@trashbo4t I was thinking what about if we add a port scan to this ? So we know which ports are open on the device.. to identify the vunrablites better !

[pidgy]

@trashbo4t I was thinking what about if we add a port scan to this ? So we know which ports are open on the device.. to identify the vunrablites better !

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.

[minanagehsalalma]

@trashbo4t I was thinking what about if we add a port scan to this ? So we know which ports are open on the device.. to identify the vunrablites better !

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 Yup you are right

[minanagehsalalma]

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"

[pidgy]

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?

[minanagehsalalma]

What do you mean by merged?

All in one ..... Or they can just run the nmap module after this one.

[foxtrot]

Modules can interact with other modules using the API, FYI.

$scope.func = (function() {
    $api.request({
         module: 'Recon',
         action: 'StartScan',
    }, function(response) {
        // etc...
    })
});

[minanagehsalalma]

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"

[minanagehsalalma]

@trashbo4t https://github.com/hak5/wifipineapple-modules/issues/89

What do you think ? This the most somewhat new one i could come up with (currently ;)