vanhauser-thc/thc-hydra

hydra rlogin - needs extra options to be effective

Open

#504 opened on Mar 10, 2020

View on GitHub
 (2 comments) (0 reactions) (0 assignees)C (8,689 stars) (1,913 forks)batch import
enhancementhelp wanted

Description

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

Contributor guide

Tech stack
c
Domain
securityauthentication
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
4
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
mostly clear
Prerequisites
C programminghydra codebaserlogin protocol
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
15
Research direction
The issue requests adding support for rlogin passwordless entry types 1 and 2 in hydra. This requires modifying the rlogin module (likely in `modules/rlogin.c`) to accept two additional parameters: `identity` and `logonName`. The module should be able to iterate over wordlists for both parameters. Study the existing rlogin module and hydra's module API. There are no linked PRs or detailed maintainer guidance; the implementation path involves understanding the rlogin protocol and adapting the module's authentication flow.