Leak Test Mbtest (Mbcx8nlp)

Leak Test Mbtest (Mbcx8nlp - mbcx8nlp@hotmail.com)

Mbtest s'installe proprement et, pour le détruire, il suffit de supprimer les fichiers suivants : mbtest.c mbtest.exe mbtest.h mbtest.mak readme.txt La tâche qui s'exécute est "mbtest.exe" Télécharger le leak test MBTest.exe Télécharger le code source et les instructions MBTest.zip Le package est en open source et nécessite l'installation de 2 des fichiers de WinPcap version 3, packet.dll et npf.sys, également en open source. Suivre les instructions de l'auteur de MBTest: MBTEST | mbcx8nlp | mbcx8nlp@hotmail.com MBTEST is designed to test the susceptibility of 'software firewalls' to being bypassed via low-level packet injection and capture. In cases where the firewall is able to filter the relevant traffic they can often be bypassed by packet fragmentation or other means and so we test for that too. Please note that this is only a simple demonstration, not a full evaluation of the technique or your firewall's ability to deal with it. Eight packets are sent during the test: A TCP packet with the SYN flag set, ports 1024 -> 80 The same as 1 but with the IP 'more fragments' bit set The same as 1 but with fragment offset of 8 An emtpy IP packet with IP protocol = 50 (ESP) An empty IP packet with IP protocol = 47 (GRE) An ICMP echo request A UDP packet ports 500 -> 500 (ISAKMP) A UDP packet ports 1024 -> 53 (DNS) Two instances of the program are required - a 'sender' and 'receiver'. The sender sends the test packets and then waits for replies. The receiver waits for one or more packets that get through and then replies in kind (i.e. with a SYN/ACK to the TCP packets, etc). Usage: Install WinPCap 3.0 from http://winpcap.polito.it/install/default.htm on both sender and receiver. (See the notes below). Disable any firewall software on one machine (not the one being tested! :) and ensure that it is not in the 'trusted zone' or otherwise given any special treatment by the firewall software on the other. Note that the presence of a real (standalone) firewall or NAT device situated between sender and receiver will result in false negatives (see the notes below). Ligne vide Run mbtest in receiver mode on the receiver like so: mbtest <ip address of sender> 1 Run mbtest in sender mode on the sender like so: mbtest <ip address of receiver> If the firewall software creates any pop-up alerts, quickly click 'deny'. You have a few seconds to transmit (or block) all of the packets before things go wrong :). Determine the significance of the results (see below). Notes Dependence on WinPcap / a kernel driver MBTEST is coded against packet.dll of the winpcap distribution. This means that only two files from the distribution are actually required; appropriate versions of packet.dll and npf.sys. A hypothetical trojan based on this method would need only copy the two files to the relevant system directories to be able to operate. It takes only a few lines of code to accomplish this and * no reboot is necessary *. Interpretation of results All of the test packets are routable, however a real firewall (i.e. a decent standalone device or NAT box) will eat the fragmented packets in an attempt at reassembly (which will obviously fail). Therfore if your firewall fails only test 2 OR 3 then such a device would protect you from this issue. If your firewall fails tests 2 AND 3 then it's possible to emulate 'real' fragmentation and thereby traverse such devices without problem. All the other test packets traverse such devices just fine (assuming, of course, that they aren't eaten by filters). The firewalls I've tested fall into three basic categories: The firewall doesn't even see the traffic (all or most tests failed). Obviously, this is bad. A hypothetical trojan using this technique could use any traffic it likes (valid UDP or TCP for example) to communicate with anyone / thing on the 'net without as much as a peep from your firewall. It's likely that your firewall fails regardless of whether it's the sender or receiver and therefore a trojan *server* running on your computer could receive connections (or whatever (literally)) despite the firewall and without your knowledge (it wouldn't even show up in netstat output). The firewall is able to inspect the traffic but is unable to associate it with the program. It fails at least one of the tests. In this case, the basic issue is voided - the firewall is able to inspect the traffic. However, it's still possible to bypass it by exploitation of a design choice (e.g. let's not bother inspecting fragments) or a default rule. How miserable you should be really depends on which tests were failed. Basically, unless you only failed test 2 OR 3 and have a standalone firewall device you probably aren't a whole lot better off than those using the firewalls described in 1. The firewall recognises mbtest.exe or npf.sys as the source of the traffic and produces a pop-up alert as soon as the first ARP frame is sent. Your firewall passed :). This is the ideal result. You should run the test in reverse to make sure it can drop the packets coming in as well as out. Problems on 9x There seems to be some problems with adapter detection on 9x when PPPoE, ICS or similar is in use. The library (packet.dll) is responsible for the retrieval of adapter information so it's not my fault (I think) :). I haven't experienced the problem and therefore have no suggestions for workarounds or any idea about how to fix it, sorry :). Other security tools Please note that this is merely a demo intended to highlight a deficiency of (some) software firewalls. I'm not at all interested in hearing about how your HIDS / "sandbox" / registry watcher or other security tool 'defeats' this test. Sorry :). Building from source Please see the comments at the top of the included makefile (mbtest.mak). Disclaimer The program comes with no warranty whatsoever. I am not responsible for anything you do with this program nor any damage or loss of data that that may result from it's use. Thanks to Steve Friedl, Wildcatboy, CrazyM, Joseph Morris and Philip Sloss.

Rédigé en écoutant