Earlier last month, Ripple20 became very popular as it listed several vulnerabilities discovered in a bespoke IP stack used by many IoT devices. Despite the hype around Ripple20, essentially, the tools used to identify vulnerable devices send malformed or valid packets (some values are within an acceptable range but are deprecated or outdated), which are easy to capture (see Suricata and Zeek rules for detection). Essentially, IDS rules/scripts are checking if the packets sent on the wire are valid or if they contain unexpected values used by Ripple20. Note that these rules do not typically verify packets (e.g., if a TLS header is valid, or if an ICMP packet contains a non-deprecated valid type/code), they are used solely to discover Ripple20. Therefore, if a future Ripple21 were to use the same method but with different values, weâd be back to square one needing to define a new set of rules/scripts. This is how signature-based systems work and as you can see, they are easily circumvented by making slight changes to network traffic. Not to mention, continuously adding new rules/scripts can slow these systems down.
To provide a more generic solution to this issue, we decided to introduce a new type of analysis in nDPI (and in all applications using it), which we call ârisk factor.â This can analyze traffic and generate a bitmap of issues discovered in the flow. Of course, this isnât based on signatures/scripts in preparation to catch Ripple21 if/when it is disclosed. Essentially, nDPI evaluates some risks as it inspects traffic and reports them to the application using it, beyond application protocols. This mechanism is extensible, and we are continuously adding new metrics to make it more pervasive. Applications using nDPI can use the risk factor to block or alert without requiring complex detection implementations as nDPI has already completed everything. As of now, nDPI is capable of detecting the following issues.
- XSS (Cross-Site Scripting)
- SQL Injection
- Arbitrary Code Injection/Execution
- Binary / .exe Application Transfer (e.g., in HTTP)
- Known Protocols on Non-Standard Ports
- TLS Self-Signed Certificate
- TLS Outdated Version
- TLS Weak Cipher
- TLS Expired Certificate
- TLS Certificate Mismatch
- HTTP Suspicious User Agent
- Contacted HTTP Numeric IP Host
- HTTP Suspicious URL
- HTTP Suspicious Protocol Header
- TLS Connection without HTTPS (e.g., TLS-based VPN)
- Suspicious DGA Domain Contact
- Malformed Packet (Ripple20 Detected Here)
If your nDPI-based application can score the above risks, you have already uncovered most of the issues detected by IDS, eliminating the burden of continually updating rules/scripts. For example, in this pcap, a piece of malware changes a binary application (.exe) to a PNG file to evade security policies.
As shown above, ntopng (which uses nDPI, hence can benefit from this traffic analysis without requiring any effort other than interpreting the risk factor reported by nDPI) will report this issue and trigger an alert. Simple yet effective, isnât it?
Original Statement: This article is authorized by the author for publication by the Tencent Cloud Developer Community. Reproduction is prohibited without permission.
If there is any infringement, please contact [email protected] for removal.
Network Asset Risk Monitoring SystemSecurity VulnerabilitySQLVulnerability Scanning ServiceEnterprise