Sergey. [Status report 03/17]

[Sergey Khegay <g.sergeykhegay () gmail com>]

[Report 03/17]
Hello Nmap Community,

Accomplishments:
- Absolute failure on the first improvement approach. Let me describe.
  So far I test my approach on ftp-brute script. I modified the script
  according to a new API that I implemented in the brute.lua.


  Environment. For testing purposes I use
  - Ubuntu virtual machine
  - vsftpd - ftp server daemon
  - I limited the number of connections from an IP to 5. So you can
    have at most 5 parallel connections from a single IP.  If you
    happen to have more, the ftp server will reply with code 421 "There
    are too many connections from your internet address"
  - A list of usernames - 2 entries, including valid one
  - A list of passswords - 40 entries, including valid one
  - So total of 80 pairs of credentials.


  Approach:
  If the status of some action (connect or login) is false, brute.lua
  expects to receive 3 return values: status, response, report (as
  opposed to only two in the initial implementation).

  New return value, report, if present, contains the last credential
  that were attempted to be used but were not. The structure of report:
  {
    cmd: "decrease",           -- The command to the engine, probably
                               -- useless as we will try to increase
                               -- after successful attempts.

    limit_to: <integer>,       -- If the protocol specifies the maximum
                               -- allowed number of parallel connections

    creds: {                   -- The credentials that we used when the
      username: "<username>",  -- error occurred
      password: "<password>",
    },
  }

  If report is nil, then the engine works as it worked before, otherwise
  it adds the credentials in the report to the retry list and lets the
  coroutine that got the error die. Thus every error decreases the
  number of running coroutines by 1. (I should try to decrease more
  aggressively, but I have not come up with a good idea yet.)

  If there were no errors between two consecutive runs of the base
  thread, then the number of coroutines is increased by 1.

  In this draft implementation I assumed that ftp-brute always wants
  the brute library to run in the adaptable mode described above. So
  for old script the engine should work as it did before. (This can be
  done by requiring a specific function implementation in the
  bruteforcing script.)


  Problems:
  - Probably because the server updates the connection statistics less
    frequently than connections are being made by the script, the
    following situation is possible:
    Assume the number of connections is limited to 5. We have 6 running
    coroutines.  So the first coroutine gets an error message, we let
    the connection to be closed and let the coroutine die. Logically,
    now the second coroutine should be fine, but it is not, because
    probably the server has already sent a response before we closed
    the first connection, at that moment there were 6 connections, thus
    the second coroutine gets error message and then dies. So all 6
    connections die, the script has not iterated through all accounts.

    Possible solution is to let only one coroutine die, and restart
    others with the same credentials. This will slow down the execution,
    but will be more accurate.

  - I need to come up with an elegant way to support back-compatibility.


  Comparison:
  - Ncrack does not find the valid credentials as well. Even though it
  tries to reduce the number of connections towards 5, it always stick
  to 6 and prematurely closes a lot of probes.

  > Ncrack done: 1 service scanned in 12.02 seconds.
  > Probes sent: 398 | timed-out: 0 | prematurely-closed: 331

  - THC-Hydra stubbornly holds the number of 12 threads and spits
  error messages. No positive results as well.


Goals:
o: Develop the ideas described above.
o: Start thinking about ssh-brute.


I would highly appreciate any comments and suggestions.


Best regards,
Sergey.

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/