Knowledge Base

Ask A Question



InsightAppSec: POST vs GET, CORS, and long run times

We are new R7 users (one day old) and are noticing what could be false flags. Wondering if any one has any thoughts on the below. Are #1 and #2 false flags or should we do what describe? 1) R7 is performing an POST on a GET. "R7 reported POST requests to those urls. But from the user's perspective those urls are browser urls when user switches from page to page. Those are not API urls (which starts with /api). When I open Chrome dev tools and network tab I notice that when we go from page to page all those URLs are accessed with GET request. So I am confused. Why did R7 access those URLs with POST method at all?" Is the solution to deny POST here to close this out? 2) CORS issue. Currently the rule is that we return back client's ip address as a value of ACCESS-CONTROL-ALLOW-ORIGIN header. But if client didn't send Origin header with it's ip address or url, we return wildcard *. We could instead send an error back if client sent a request without Origin header. So a wildcard would never be sent back as a regular value in response header. In normal situations when client access the app from the browser, Origin header will always be present. However, R7 is sending this request without Origin header. So if I deny requests without Origin header, client's experience should not be affected. Is that what R7 is suggesting we do to close this out? 3) Long scans. It took a few hours to run the scan in the demo, and now as a customer it is taking longer. Some of this could be us (greater attack surface as we change the product). But looking at the log for our scan, it looks like R7 is constantly logging out and back in. Is this expected behavior? Thanks, Judah

Posted by Judah Phillips 9 months ago


Metasploit Bruteforce Errors

I use metasploit pro for penetration testing. For one of the servers, i was running bruteforce check. While checking, i received these errors. Can anyone tell me if someone has come across such errors and solution for it? One thing I notice is that, whenever target OS closes the port (because of account lockout policy), this kind of error occurs. But ideally, it should not give such call trace errors and continue the other tests. In my case, it abruptly ends the bruteforce check. Metasploit pro version: 4.14.3 Host OS: Ubuntu Target OS: Fortios Error log: [+] [2018.09.20-13:40:33] SUCCESSFUL - username:password [-] [2018.09.20-13:40:33] - No authentication required [-] [2018.09.20-13:40:33] - No authentication required [*] [2018.09.20-13:40:33] INCORRECT - username:password [-] [2018.09.20-13:40:33] - No authentication required [-] [2018.09.20-13:40:33] - Unexpected HTTP response code 302 (is this really Chef WebUI?) [-] [2018.09.20-13:40:33] UNABLE TO CONNECT - username:password [-] [2018.09.20-13:40:47] Auxiliary failed: Errno::ECONNRESET Connection reset by peer [-] [2018.09.20-13:40:47] Call stack: [-] [2018.09.20-13:40:47] <internal:prelude>:76:in `__read_nonblock' [-] [2018.09.20-13:40:47] <internal:prelude>:76:in `read_nonblock' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/vendor/bundle/ruby/2.3.0/gems/rex-core-0.1.13/lib/rex/io/stream.rb:72:in `read' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/vendor/bundle/ruby/2.3.0/gems/rex-core-0.1.13/lib/rex/io/stream.rb:202:in `get_once' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/vendor/bundle/ruby/2.3.0/gems/metasploit-framework-4.17.11/lib/rex/proto/http/client.rb:550:in `block in read_response' [-] [2018.09.20-13:40:47] /opt/metasploit/ruby/lib/ruby/2.3.0/timeout.rb:74:in `timeout' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/vendor/bundle/ruby/2.3.0/gems/metasploit-framework-4.17.11/lib/rex/proto/http/client.rb:539:in `read_response' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/vendor/bundle/ruby/2.3.0/gems/metasploit-framework-4.17.11/lib/rex/proto/http/client.rb:230:in `_send_recv' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/vendor/bundle/ruby/2.3.0/gems/metasploit-framework-4.17.11/lib/metasploit/framework/login_scanner/http.rb:192:in `check_setup' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/modules/auxiliary/pro/bruteforce/quick.rb:242:in `block in run_scanner' [-] [2018.09.20-13:40:47] /opt/metasploit/ruby/lib/ruby/2.3.0/timeout.rb:91:in `block in timeout' [-] [2018.09.20-13:40:47] /opt/metasploit/ruby/lib/ruby/2.3.0/timeout.rb:33:in `block in catch' [-] [2018.09.20-13:40:47] /opt/metasploit/ruby/lib/ruby/2.3.0/timeout.rb:33:in `catch' [-] [2018.09.20-13:40:47] /opt/metasploit/ruby/lib/ruby/2.3.0/timeout.rb:33:in `catch' [-] [2018.09.20-13:40:47] /opt/metasploit/ruby/lib/ruby/2.3.0/timeout.rb:106:in `timeout' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/modules/auxiliary/pro/bruteforce/quick.rb:238:in `run_scanner' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/modules/auxiliary/pro/bruteforce/quick.rb:109:in `block (3 levels) in run' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/modules/auxiliary/pro/bruteforce/quick.rb:105:in `loop' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/modules/auxiliary/pro/bruteforce/quick.rb:105:in `block (2 levels) in run' [-] [2018.09.20-13:40:47] /opt/metasploit/apps/pro/vendor/bundle/ruby/2.3.0/gems/metasploit-framework-4.17.11/lib/msf/core/thread_manager.rb:100:in `block in spawn'

Posted by Jenis 9 months ago