Earlier last month Ripple20 became popular as it has listed some vulnerabilities found in a custom IP stack used by many IoT devices. Despite the hype on Ripple20, in essence the tool used to fingerprint vulnerable devices sends either malformed or valid (with some values in the allowed range albeit with values deprecated or obsolete) packets that are easy to catch (see Suricata and Zeek rules for detection). In essence IDS rules/scripts are checking whether packets sent on the wire are valid or if they contain unexpected values used by Ripple20. Note that these rules are NOT checking packets in general (for instance check if the TLS header is valid, or if ICMP packets contain valid type/code that are not deprecated) but they are designed to spot only Ripple20, so if a future Ripple21 will use the same method but a different value, we’ll be back to square one and new set or rules/scripts will need to be defined. This is how signature-based system work, and as you can see they are easy to circumvent making little changes in network traffic, not to mention that constantly adding new rules/scripts will make these systems slow.
In order to have a more general solution to this problem, we have decided to introduce in nDPI (and thus on all applications that use it) a new type of analysis we have named “risk factor” that analyses the traffic and produces a bitmap of issues found on traffic. This of course not based on signatures/scripts to be prepared to catch Ripple21 if/when will be disclosed. In essence nDPI when dissecting traffic, will also evaluate some risks and report them to the application using it, this in addition to the application protocol. This mechanism is extensible and we are constantly adding new values to make it more pervasive. Applications using nDPI can use the risk factor to block or issue an alert, this without having to implement complex detection methods as nDPI has already done everything. As of today nDPI is able to detect the following issues:
- XSS (Cross Site Scripting)
- SQL Injection
- Arbitrary Code Injection/Execution
- Binary/.exe application transfer (e.g. in HTTP)
- Known protocol on non standard port
- TLS self-signed certificate
- TLS obsolete version
- TLS weak cipher
- TLS certificate expired
- TLS certificate mismatch
- HTTP suspicious user-agent
- HTTP numeric IP host contacted
- HTTP suspicious URL
- HTTP suspicious protocol header
- TLS connections not carrying HTTPS (e.g. a VPN over TLS)
- Suspicious DGA domain contacted
- Malformed packet (Ripple20 is detected here)
If your nDPI-based application can assign a score to the above risks, you have already spotted most of the problems that IDSs detect, this without the headache of constantly updating rules/scripts. For instance in this pcap, a malware is transferring a binary application (.exe) as PNG file, this to avoid security policies.
As you can see int he above picture, ntopng (that uses nDPI and so that is beneficing from this traffic analysis without having to implement anything but just to interpret the risk factor reported by nDPI) reports this issue and triggers an alert. Simple and effective isn’t it?
Enjoy!