blacklanternsecurity / bbot

A recursive internet scanner for hackers.
https://www.blacklanternsecurity.com/bbot/
GNU General Public License v3.0
4.68k stars 423 forks source link

WPSCAN Stuck? #1729

Open Sh4d0wHunt3rX opened 2 months ago

Sh4d0wHunt3rX commented 2 months ago

During Scan, it seems wpscan stuck.

image

Keep seeing this in debug

2024-09-01 16:30:23,788 [DEBUG] bbot.scanner scanner.py:1029         - wpscan.handle_event(TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'})) running for 15 minutes, 53 seconds:
TheTechromancer commented 2 months ago

If you run wpscan manually on that URL, does it behave okay?

Sh4d0wHunt3rX commented 2 months ago

In the debug log, it says: host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...",

I think because of url': 'http://dev... , is this ok?

Sh4d0wHunt3rX commented 2 months ago

debug.log

This is the complete log, for example line 8016.

domwhewell-sage commented 2 months ago

The "{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev..." is just because its been truncated in the log file

domwhewell-sage commented 2 months ago

I have re-run bbot on just the host dev.gardenmaster.co.za with the same modules enabled and it ran without issue.

2024-09-02 12:58:51,796 [DEBUG] bbot.modules.wpscan base.py:1235 Got TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'}) from wappalyzer
2024-09-02 12:58:46,938 [DEBUG] bbot.modules.wpscan base.py:1235 TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'}) passed post-check
2024-09-02 12:58:46,939 [DEBUG] bbot.modules.wpscan base.py:1235 Handling TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'})
2024-09-02 12:58:46,939 [HUGEVERBOSE] bbot.core.helpers.command logger.py:132 run: wpscan --url https://dev.gardenmaster.co.za/ --user-agent 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36 Edg/119.0.2151.97' --max-threads 5 --request-timeout 60 --connect-timeout 30 --enumerate vp,vt,tt,cb,dbe,u,m --disable-tls-checks --format json
2024-09-02 12:58:48,525 [DEBUG] bbot.modules.wpscan base.py:1235 Finished handling TECHNOLOGY("{'host': 'dev.gardenmaster.co.za', 'technology': 'wordpress', 'url': 'http://dev...", module=wappalyzer, tags={'in-scope'})
TheTechromancer commented 2 months ago

It might make sense to put an idle_timeout= on the wpscan command, in case it decides to get stuck again.

Sh4d0wHunt3rX commented 2 months ago

Unfortunately, it got stuck again on another scan, stuck on wpscan(930:1:0) for 45 minutes and killed manually : (

wpscan.handle_event(HTTP_RESPONSE("{'url': 'https://stories.flipkart.com/', 'timestamp': '2024-09-03T10:32:31.27834...", module=httpx, tags={'ip-192-124-249-115',

Part of the debug: wpscan.txt

Is it possible to skip a url if stuck on it and goes to the next one?

domwhewell-sage commented 2 months ago

We can put the idle_timeout= on the wpscan command but it already has a --request-timeout 60 and --connect-timeout 30 on the tool command. So I'm not 100% sure its stuck, im running it now and it is getting data its just not very fast (or verbose) 15+ minutes so far. I wouldn't want to set an idle_timeout just for it to kill the process when its actually getting results just not within the time limit

domwhewell-sage commented 2 months ago

(Ugh wpscan --verbose option only works through the CLI not the json output bbot needs :( ) Anyway, ive done some testing and looks like the bruteforce enumeration is eating the time, e.g. When request-timeout=60 and connect-timeout=30 (canceled after 45 minutes)

Fingerprinting the version - Time: 00:11:13 <===============================================================> (702 / 702) 100.00% Time: 00:11:13

[+] Enumerating Vulnerable Themes (via Passive and Aggressive Methods)
 Checking Known Locations - Time: 00:04:16 <=====                                                             > (56 / 652)  8.58%  ETA: 00:45:34

When request-timeout=5 and connect-timeout=5 (canceled after 30 minutes)

Fingerprinting the version - Time: 00:02:32 <===============================================================> (702 / 702) 100.00% Time: 00:02:32

[+] Enumerating Vulnerable Themes (via Passive and Aggressive Methods)
 Checking Known Locations - Time: 00:07:31 <============================================                     > (446 / 652) 68.40%  ETA: 00:03:29

[+] Enumerating Timthumbs (via Passive and Aggressive Methods)
 Checking Known Locations - Time: 00:02:41 <===                                                             > (161 / 2575)  6.25%  ETA: 00:40:25

So the fingerprinting takes a long time adjusting the request/connect timeout did help but there are so many potential requests that it has to make for full enumeration

version detection = 702 requests
vp = unknown
vt = 652 requests
tt = 2575 requests 
cb = 137 requests
dbe = 
u1-10 = 
m1-100 = 

So the best way forward here seems to be adjusting the default module options!

Default request/connect timeout is 60s/30s

These are the available options for enumeration, the default is vp,vt,tt,cb,dbe,u,m

    -e, --enumerate [OPTS]                        Enumeration Process
                                                  Available Choices:
                                                   vp   Vulnerable plugins
                                                   ap   All plugins
                                                   p    Popular plugins
                                                   vt   Vulnerable themes
                                                   at   All themes
                                                   t    Popular themes
                                                   tt   Timthumbs
                                                   cb   Config backups
                                                   dbe  Db exports
                                                   u    User IDs range. e.g: u1-5
                                                        Range separator to use: '-'
                                                        Value if no argument supplied: 1-10
                                                   m    Media IDs range. e.g m1-15
                                                        Note: Permalink setting must be set to "Plain" for those to be detected
                                                        Range separator to use: '-'
                                                        Value if no argument supplied: 1-100
                                                  Separator to use between the values: ','
                                                  Default: All Plugins, Config Backups
                                                  Value if no argument supplied: vp,vt,tt,cb,dbe,u,m
                                                  Incompatible choices (only one of each group/s can be used):
                                                   - vp, ap, p
                                                   - vt, at, t

So removing them enumeration options could speed it up massively.

@Sh4d0wHunt3rX if you want to change those options right now you can use modules.wpscan.enumerate=, modules.wpscan.request_timeout= and modules.wpscan.connection_timeout=

So we could enhance this module by changing the defaults to make it faster. And users can change the module options to increase coverage if they wish

domwhewell-sage commented 1 month ago

@Sh4d0wHunt3rX did you run it using those options? I was thinking to change the defaults to

Sh4d0wHunt3rX commented 1 month ago

Hey @domwhewell-sage , unfortunately, still I have not tested with different settings but I guess the new set that you have in mind will be much faster. ❤️