when testing the authenticated scans, I encountered an error when elevated privileges was activated. Under Ubuntu 20.04 the authenticated scans worked with and without elevated privileges. On Ubuntu 22.04 and 24.04 only the authenticated scans without elevated privileges worked.
By manually running the NASL script ‘ssh_authorisation.nasl’ I was able to confirm and probably find the error. If elevate privileges is enabled, the function ‘ssh_cmd( socket:sock, cmd: “whoami”, timeout:60, pty:FALSE, ignore_force_pty:TRUE, return_errors:FALSE );’ is called, with Ubuntu 20.04 the correct value (in this case ‘ubuntu’) is returned. With Ubuntu 22.04 and 24.04, an incorrect value is returned (in this case ‘?2004lubuntu ?2004h"). Since the returned value is compared with ‘ubuntu’, an error is returned for 22.04 and 24.04.
Does anyone have an idea how I can fix this problem?
The feature is still experimental. Depending on the target system and its configuration, the feature may not be reliable.
Currently this feature is provided “as is” and if it doesn’t work against the target in question it might be required to disable it again and to choose a different approach to scan the system.
Suggestions how to extend / introduce compatibility with additional operating systems (this is not about “fixing” something so a “fix” is not required) can be always posted here.
Not sure though if, when or how this is getting picked up (at least currently i’m not aware on any plans to work / extend this functionality).
After looking around a little about the shown ?2004l and ?2004h those seems to be commands sent by the remote system and are “bracketed paste control sequences” if “bracketed paste mode” is enabled.
In turn this means that it might be required to configure the target system itself in a way that it doesn’t send these commands back when receiving any SSH commands remotely.