Thread Info
  • State Verified Answer
  • Replies 8 replies
  • Subscribers 4 subscribers
  • Views 3693 views
  • Users 0 members are here
Options
Suggested

BUG? - Sometimes XG doesn't hold the last packet. (DPI Engine)

Prism

Hi,

 

Something interesting has been happening while using the DPI Engine, I've found this happens sometimes after an user accidentally tried to download a malware and managed to do it.

Sometimes the DPI Engine doesn't hold the last packet, and let the user to download the file entirely, apparently without AV scan.

Here's the Rules I've used to test on my computer:

And here's a video of it happening with the standard Eicar file test.

After downloading it entirely for the first time, trying for a second time will throw you a notification, as it's supposed.

The interesting part, It never happens on a HTTP connection, only on HTTPS.

 

Is this a mistake on my part? or it's already known? This is happening since when v18 EAP 1 came out.

 

Thanks,

Parents
  • 0

    It is not supposed to do that.  :)

    I think this is an artifact of eicar.  At 68 bytes it fits entirely in the first packet along with all the headers.  So the last packet is also the first packet.

    We will try to recreate internally.

  • 0 in reply to Michael Dunn

    Hi Prism.  We've tried to recreate this internally and not got the same results.  Can you re-share the video (currently private) and give me some details about your setup including the firewall rule.

  • 0 in reply to Michael Dunn

    Hi Michael,

     

    This is hard to replicate, I've got lucky with Eicar file test, but also managed to download some from [REDACTED BY MICHAEL DUNN]. (Yes, I know, It's actual malware, and that's why I've been using it.)

    It's most of time 1/50 that happens, but I got the most lucky with small files such as 38KB size. (Don't know why.)

    Sorry I didn't record this time, but If it's needed I will do.  (I've also Unlisted the video you asked.)

     

    Here's the rules:

     

     EDIT, more explanation on what happens:

    As I said before It's hard to replicate, I've also tried on both Chrome & Firefox.

    The interesting part is: After I manage to download it, when I try the second time the connections get killed, as It's supposed.

    I didn't managed to download anything while using the Web Proxy, but the difference is, Web Proxy has on Batch Mode instead of Real Time. I'll try with real time later to see If happens the same thing as DPI.

     

    EDIT 2: Web Proxy works perfectly, I didn't managed to download anything with it (On both Real Time and Batch Mode), this issue is only on DPI.

    After clicking to download it on batch mode it automatically throws me on a Warning page. while on real time most of the time It send me directly to the warning page, doesn't even let me start the download.

     

    EDIT 3: While using Web Proxy, checking the logs after trying to download any malware shows as expected. While on DPI mode It doesn't even show it being blocked on the Log viewer.

     

    Thanks,

    If a post solves your question use the 'Verify Answer' button.

    Ryzen 5600U + I226-V (KVM) v21 GA @ Home

    Sophos ZTNA (KVM) @ Home

  • 0 in reply to Prism

    I think we have recreated it.

     

    Can you confirm, when you are able to download the malware:

    Open log viewer, detail view, and search for "HTTP parsing error encountered".

    If you have a parsing error when this occurs then the response body is not scanned.  If the body contains a virus then the virus may be downloaded.

     

    Why we are randomly getting parsing errors, we still need to determine.  No ETA.

     
  • 0 in reply to Michael Dunn

    Hi Michael,

     

    I can confirm "HTTP parsing error encountered" in the logs.

    2020-01-06 19:16:57Web filtermessageid="16002" log_type="Content Filtering" log_component="HTTP" log_subtype="Denied" status="" fw_rule_id="7" user="prismpc" user_group="Clientless Open Group" web_policy_id="12" web_policy="" category="Information Technology" category_type="Acceptable" url="REDACTED SINCE ITS MALWARE" content_type="" override_token="" response_code="" src_ip="10.0.0.200" dst_ip="REDACTED" protocol="TCP" src_port="48178" dst_port="443" bytes_sent="532" bytes_received="0" domain="REDACTED" exception="" activity_name="" reason="HTTP parsing error encountered." user_agent="Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0" status_code="403" transaction_id="" referer="REDACTED" download_file_name="" download_file_type="" upload_file_name="" upload_file_type="" con_id="0" app_name="" app_is_cloud="0" override_name="" override_authorizer="" used_quota="0"

     

    It's strange since It's shows as DENIED, but I'm still able to download.

     

    Thanks,

    If a post solves your question use the 'Verify Answer' button.

    Ryzen 5600U + I226-V (KVM) v21 GA @ Home

    Sophos ZTNA (KVM) @ Home

  • 0 in reply to Prism

    We have a suspicion about the root cause.

    In Firefox can you go to about:config and search for false_start.  Set it to false.

    Can you reproduce the downloads that should be blocked in Firefox with that setting off?

    Have you ever reproduced this in Chrome?  If the root cause is correct then you should never have had it in Chrome.

     

    Note: on the other malware site you were testing, all files are password protected.  All download should be blocked due to "scanning error" not due to virus detected.  Can you confirm?

  • 0 in reply to Michael Dunn

    Hi Michael,

    Michael Dunn said:

    In Firefox can you go to about:config and search for false_start.  Set it to false.

    Can you reproduce the downloads that should be blocked in Firefox with that setting off?

    After changing security.ssl.enable_false_start to false, I've not been able to reproduce anymore. It's also showing the Block Page correctly now.

    Michael Dunn said:
    Have you ever reproduced this in Chrome?  If the root cause is correct then you should never have had it in Chrome.


    I've tried again on chrome, I believe I've wrote wrong before, I'm still unable to reproduce on it.

    Michael Dunn said:
    Note: on the other malware site you were testing, all files are password protected.  All download should be blocked due to "scanning error" not due to virus detected.  Can you confirm?

    Can confirm, There's another website which I don't want to put in here, which have password-less .zip, I've tried before on last month but didn't got any "good" results on that.

     

    Logs on the last failed attempt:

    2020-01-14 16:42:19Web filtermessageid="16002" log_type="Content Filtering" log_component="HTTP" log_subtype="Denied" status="" fw_rule_id="7" user="prismpc" user_group="Clientless Open Group" web_policy_id="12" web_policy="" category="Information Technology" category_type="Acceptable" url="###" content_type="application/zip" override_token="" response_code="" src_ip="10.0.0.200" dst_ip="###" protocol="TCP" src_port="53550" dst_port="443" bytes_sent="543" bytes_received="262967" domain="###" exception="" activity_name="" reason="" user_agent="Mozilla/5.0 (X11; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0" status_code="403" transaction_id="618b427f-45e2-4357-ad23-23a2d074e8ec" referer="###" download_file_name="###.zip" download_file_type="application/zip" upload_file_name="" upload_file_type="" con_id="0" app_name="" app_is_cloud="0" override_name="" override_authorizer="" used_quota="0"

     

    It also doesn't show "reason=HTTP parsing error encountered." anymore.

    Thanks,

     

    EDIT: Well, interesting find, most of the issues I had before with decryption on Firefox (unrelated to this) seems to be fixed after changing security.ssl.enable_false_start to false.

    Thanks again,

    If a post solves your question use the 'Verify Answer' button.

    Ryzen 5600U + I226-V (KVM) v21 GA @ Home

    Sophos ZTNA (KVM) @ Home

  • +1 in reply to Prism

    Issue has been resolved internally.  Will be part of the next release.

     

    Background: There are a few different threads and internally reported issues that all come down to the Firefox-only setting of tls false start.  Anyone experiencing Firefox-only problems can do about:config and change security.ssl.enable_false_start to false.  This can be reset back to true after the fix is released.

Reply
  • +1 in reply to Prism

    Issue has been resolved internally.  Will be part of the next release.

     

    Background: There are a few different threads and internally reported issues that all come down to the Firefox-only setting of tls false start.  Anyone experiencing Firefox-only problems can do about:config and change security.ssl.enable_false_start to false.  This can be reset back to true after the fix is released.

Children
No Data
Unfiltered HTML