Jump to content

digininja

Global Moderators
  • Posts

    3,819
  • Joined

  • Last visited

  • Days Won

    167

Everything posted by digininja

  1. You can't control the webview though, only the http response. An extra thought, you'd have to find one that was running over http or didn't do certificate checking to inject your code in.
  2. Did you check about webview caching responses? Looks like it doesn't by default so you would need to find an instance where it is enabled https://stackoverflow.com/questions/34606785/how-to-enable-caching-in-webview-android#:~:text=You can use the WebView cache to enable caching in WebView.
  3. If you can write it as a very stable module that works in over 90% of cases and appealed to the masses then it might get added. But I can't see this getting there, as I said before, this seems like a very niche attack that is going to be quite fiddly to get working practically outside the lab.
  4. If it is Burp, not brup, you want help with, not sure where to ask, have you looked to see if Portswigger has a forum?
  5. I don't know, I'm not an active user of that forum, but if anyone can help with getting your captive portal working, it will probably be them.
  6. Good luck with it. I still think getting beyond a very limited lab environment will be tricky.
  7. I guess if you have a specific target in mind it would be easier to pull off. I was thinking of a more general attack.
  8. It is an interesting concept but seems very unlikely to work reliably in the real world. A lot of routers now ship with unique passwords, so that kills quite a few of the attacks. I've not used a default router for a while so don't know how many contain the wifi password in the GUI, certainly not all of them, so that kills off some more of the targets. Even for default creds, you'd need to pick a very limited range of devices to have a working list of default IPs, credentials, and ways to extract the wifi password. I can see it maybe working in a lab environment, or if you know exactly what devices the victim has, but there just seem like too many variables to make it practical. There may be shortcuts and smart ways to do call outs to external sites to offload some of the processing, but still not sure.
  9. But if you can't get it working in the browser then you are unlikely to get it working elsewhere. And does it matter where you target if all you want is to have it make a request that causes a portal to be shown?
  10. Try intercepting a browser request and see if you can do anything with that. I'd start there.
  11. If it is code making the requests and not a browser then I can understand why it wouldn't cause any alerts.
  12. It all depends on what is making that request and how it handles the response.
  13. google.com would be treated as a relative file rather than absolute as it doesn't have the protocol on it.
  14. Action -> intercept response That would give you a single shot edit of the response.
  15. Not sure where this is going, but just a warning, if you start posting links to recruitment sites or job adverts, they will be removed and you will potentially banned for spamming. If you really want help from the community, post a question or something that someone can respond to.
  16. I gathered that from the original question. What do you mean by track it? What kit do you have available, over what area, give us some more information to work on. If you are planning to try to track a single phone anywhere in the world from your home, forget it, if you have an array of wireless devices that you can deploy around a target area then there are options.
  17. What is it you are attempting to achieve? What do you mean by track?
  18. OK, obviously you know your stuff so don't really need any help, good luck with it all.
  19. If the client expects the network to be encrypted and it isn't, it will try to connect, find out that WPA isn't offered, and then disconnect. You could setup a WPA version of the network, collect message two of the 4 way handshake, take that away and try to crack it, but it wouldn't be instant, and the server would not be able to authenticate itself to the client in message 4 of the handshake so the client would disconnect. For a standard Karma attack, which is to lure clients to connect to your open wifi network, the client expecting WPA or WEP will prevent the attack.
  20. If you understood the basics then you would understand that none of the WPA or WEP family would be affected by Karma.
×
×
  • Create New...