Unable to scan ROSSH from version 7.12rc7 and up
hilt86 opened this issue · 12 comments
Thanks for making this tool! If you scan a routeros ssh service with a version number greater than 7.12 it throws and error :
panic: error while reading packet length of binary packet: EOF
goroutine 1 [running]:
main.main()
/home/ubuntu/go/pkg/mod/github.com/!r!u!b-!n!d!s/!terrapin-!scanner@v1.0.2/main.go:314 +0x1e4
I built Terrapin scanner from source using :
go install github.com/RUB-NDS/Terrapin-Scanner@latest
with "go version go1.21.5 linux/arm64" on Ubuntu Jammy
Here is a table of the versions I tried (unknown means it throws that error above) :
+---------+----------------+
| version | vulnerable |
+---------+----------------+
| 6.49.6 | not vulnerable |
| 6.49.8 | not vulnerable |
| 7.12rc7 | unknown |
| 7.11.2 | not vulnerable |
| 7.12.1 | unknown |
| 7.13 | unknown |
+---------+----------------+
Thanks for the report; I will have a look at it tomorrow. It doesn't surprise me that the scanner can't scan all SSH implementations just yet, given the fact that it isn't a fully-fledged SSH implementation. The guess from my side would be that the server is waiting for the client to send its KEXINIT message (which it does not), although this is just speculation.
Is there a way to reproduce this issue without having to buy a Mikrotik router?
Yep if you DM me your IP on twitter I will open up ssh to your IP for testing
Alternatively you can download a VMDK / OVA from https://mikrotik.com/download (the the cloud hosted router images)
Check your DMs. If you can provide me with a suitable host for testing, this will save me some time.
done!
I successfully scanned the router you provided me using a similar setup (Ubuntu 22.04 server, go 1.21.5) - not vulnerable. This aligns with our communication during Responsible Disclosure, which included Mikrotik as a vendor. Can you recheck whether this issue is still present for you?
Okay, that did the trick. Re-running the scanner multiple times will eventually cause it to run into something that seems like a timeout. Will dig into this.
Okay, I believe this is fixed now. Please check v1.0.3 and see if this does the trick. I was able to successfully scan your server > 10 times without any issues. The issue was that the scanner used a bufio.Reader during banner exchange, but switched to io.ReadFull on the connection for the KEXINIT. Although calling the buffered reader with a delimiter, the underlying calls to the connection reader caused more bytes to be read if the KEXINIT was available. As the buffered reader was discarded, the received KEXINIT was discarded as well. The scanner now uses a single buffered reader (and writer) throughout the scan, avoiding accidentally discarding any bytes.
Just a quick note: either v1.0.3 or v1.0.2 also fixed the scanning behaviour for ProFTPd + mod_sftp. There was a timeout too. Now I get a consistent result. Thank you very much!
Most likely v1.0.3, the fix was not specific to ROSSSH but rather a general issue when KEXINIT was available during banner exchange. Will most likely affect a few other implementations as well.