thc-hydra icon indicating copy to clipboard operation
thc-hydra copied to clipboard

hydra rlogin - needs extra options to be effective

Open Stefan-mcp opened this issue 4 years ago • 2 comments

RServices use a funky auth mechanism that hydra doesnt really understand at the moment. in r there are three elements to the transaction identity - who we say we are (normally == our local username) logonName - who we want to log on as on the remote system password - when relevant == the remote users password

access rules allow passwordless logon and are based on the attributes:

  • we have a certain hostname (as per dns, not hydras concern, out of scope)
  • we say we are a certain person (identity)
  • we ask to be certain person (logonName) or combinations of these.

so effectively there are three models that should be considered: Type 1: brute forcing host equiv entries host.equiv entry - any or a specifed user may log in as any valid user without pass (from given host) cmd: rlogin -i $identity -l $logonName xx.xx.xx.xx server: come in :)

Type 2: rhosts entries /.rhosts - any or specified user may log in as this user (from given host) cmd rlogin -i $identity> -l $userhomeUser xx.xx.xx.xx server: come in :)

Type 3: normal password attack as no exceptions no host.equiv or ~/.rhost exception -- password required now cmd rlogin -i $identity -l $logonName xx.xx.xx.xx server: password please we reply: $logonName>'s password server: come in :)

at the moment hydra only understands the type 3, which is essentially just a normal brute force where you guess the username and pass. to attack type 1 and type 2, hydra would need to understand that its actually bruteforcing the username combinations.

For type 1 you need -a valid identity* (as appears in a rule in hosts.equiv), but wont necessarily be a valid username on the target -a valid logonName - that exists on the remote machine if these conditions are met we get passwordless entry

For type 2 you need - a valid identity* (as appears in LogonName's .rhosts file) - a valid logonName

Type 3 only uses a logonName and tries to guess the users password and isnt affected by the passwordless entry rules.

we need somethign to grind type 1 and 2 as these are much easier to exploit than regular password guessing. essentially we need a "\00$identity\00$logonName\00" extension to the rlogin module where we can cycle the identity and logonName against two (or the same) wordlists

Stefan-mcp avatar Mar 10 '20 20:03 Stefan-mcp

ive implemented the type 1 and type 2 attacks in python for Rlogin and RSH - had to reverse engineer the protocols as they're too old for there to be any good documentation. the only RSH clients available (rsh-netkit package) dont support an identity parameter - even though the underlying protocol does, and finding a rexec client was just impossible. i can provide the python crackers to anyone who would be happy to convert to hydra format. i also wrote a couple of clients, one for executing against rsh with spoofed identities, and the same for rexec. i didnt make one for Rlogin as its supported natively. itd be good to get them packaged in somehow too if possible so you can abuse the creds the crackers find

PS Rservices feature in a notable security certification and some CTF's - hence the interest in an relatively obsolete protocol

Stefan-mcp avatar Mar 11 '20 04:03 Stefan-mcp

@Stefan-mcp I am on vacation and business trips for > 2 weeks. if you want add the features and send a PR. I wont have much time for this for the coming weeks.

vanhauser-thc avatar Mar 11 '20 08:03 vanhauser-thc