Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

VNC Scanners trigger binpac exceptions #320

Open
JustinAzoff opened this Issue Apr 1, 2019 · 3 comments

Comments

Projects
None yet
2 participants
@JustinAzoff
Copy link
Contributor

JustinAzoff commented Apr 1, 2019

This dpd log is triggered thousands and thousands of times by a vnc scanner:

{"analyzer":"RFB","failure_reason":"Binpac exception: binpac exception: out_of_bound: RFBSecurityTypes37:types: 2 > 0"}

Likely it just isn't sending any security types or something.

@jsiwek

This comment has been minimized.

Copy link
Member

jsiwek commented Apr 1, 2019

A pcap may be best for this -- it looks like RFBSecurityTypes37 is in the server response and it's saying there's 2, but not sending anything, so it may be a legit exception to throw. Maybe either the ProtocolConfirm needs to happen later, or need a way to generally limit/blacklist logging per-type in dpd/main.bro, or something else is going wrong.

@JustinAzoff

This comment has been minimized.

Copy link
Contributor Author

JustinAzoff commented Apr 1, 2019

was able to extract + anonymize this from a larger pcap

5900_scan_one_anon_fixed.zip

$ bro -r 5900_scan_one_anon_fixed.pcap
$ cat dpd.log |bro-cut failure_reason
Binpac exception: binpac exception: out_of_bound: RFBSecurityTypes37:types: 2 > 0

Interesting that wireshark also complains about a malformed packet

@jsiwek

This comment has been minimized.

Copy link
Member

jsiwek commented Apr 2, 2019

Thanks, this seems like it may be due using datagram instead of flowunit. I.e. we need incremental parsing, but I'll need to update a bunch of records in the protocol grammar to get that to work -- looking into it.

@jsiwek jsiwek self-assigned this Apr 2, 2019

jsiwek added a commit that referenced this issue Apr 3, 2019

GH-320: Improve RFB (VNC) protocol parsing
Mostly rewrote the parsing logic to support incremental parsing and
to support parsing of client messages.  Though I did not add events
for client messages, that's easy to add later.

Parsing now stops for both client and server if either encounters
any parsing error or invalid state.

After a complete handshake, server messages are no longer parsed.
Support for that is incomplete and not sure it's that useful anyway
since it mostly contains pixel data.

@jsiwek jsiwek referenced a pull request that will close this issue Apr 3, 2019

Open

Improve RFB (VNC) protocol parsing #324

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.