The amount of criminal online activities rises. Protective measures such as firewalls and intrusion detection systems are being actively developed. We accompany this development by offering a case-based reasoning prototype to detect similar attacks based on previous cases. The instantiation of the SEASALT framework allows us to distinguish between two different views on network traffic: the request itself, and the traffic overall. Here, the focus has been set on SQL-injections and cross site scripting - two of the most commonly used attack vectors in the last decade1. As we store cases containing these attacks, we are able to detect slightly similar attacks, which would be difficult to detect, for example, by a set of rules. Depending on the use-case, we identified up to 16 relevant attributes, predominantly text attributes. However, the similarity assessment needs improvement to reduce the rate of false-positives.
We distinguish between a normal and a malicious casebase. Initially, we fill the normal casebase our agents with XML/CSV training imports, which do not contain malicious traffic to establish a model of valid traffic. In a second step, we fill the malicious casebases with hand-crafted malicious requests and public lists of known SQLi/XSS attacks (‘payloads’) to establish a model of malicious traffic. By using Burp and the OWASP Juice Shop, we are located in a controlled environment without noisy data. In a third step, for training purposes, we import a CSV or a XML file and search for malicious traffic.
Our test is similar to the third step: We upload a XML file with six malicious requests out of a total of 795 requests. These malicious requests are manually created and are not part of the malicious casebase. We aim to automatically identify the malicious requests after comparing each of the 795 requests against cases in our malicious casebase. Basically, we query the CBR system automatically for each request against the malicious casebase which has been trained with malicious cases before. We expect to find similar cases with at least 90 % similarity. Indeed, we can identify an attack containing: {‘email’:’ ’ AND INSERT INTO users VALUES(1,2,3,4); –’,’password’:’123’}.
This attack revolves around guessing the number of columns the queued table contains by adding numbers in the round brackets after VALUES, which is a common testing approach. However, unfortunately, we only found one out of six attacks. Lowering the threshold to at least 85 % similarity sheds light onto the situation: now, we also do find more payloads which adds up to identifying four out of six attacks. Nevertheless, we also find false-positives in 11/16 cases (0,6875 %) and one redundant finding.
More information in the video! https://www.youtube.com/watch?v=XBJYp6GG4tM