hydra rlogin - needs extra options to be effective

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