1258598 - Download Protection bypass with Automated File Extension Changing

Status: RESOLVED DUPLICATE of bug 1213459

(Toolkit :: Safe Browsing, defect)

Description

[pickleboyonline]

Attachment: Demonstration archive

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36
Firefox for Android

Steps to reproduce:

Created a batch file that with change the extension of malicious code from .txt to .exe and execute it. I then packaged that in a .exe format. Downloading the new program from the website show no warning; however, both programs will end up doing the exact same thing.


Actual results:

It allows the user to download a Program which has malicious code that will be executed


Expected results:

It should have blocked it from downloading, just as it did with the content.exe

Comment 1

[:Gijs (he/him)]

Because Google's malware protection stuff uses signatures, I expect that this is a known limitation of their system, but I'll defer to :gcp or :francois to confirm.

Comment 2

[Gian-Carlo Pascutto [:gcp]]

IIRC .zip files cause us to query for a remote verdict. The remote service should be able to deal with such renaming tricks.

Chrome gives a warning for the attachement, we do not. This *may* be a known issue, we are missing some parts of Application Reputation.

Francois should be able to clarify exactly what's up.

Comment 3

[pickleboyonline]

Inside the file, Chrome says it is malicious because it contains example malware. The archive contains a test website, and a program that isn't block by chrome. I will attach the file that isn't detected.

Comment 4

[pickleboyonline]

Attachment: Program that is not recognized by Firefox or Chrome, however it launches "content.exe"

Comment 5

[pickleboyonline]

Attachment: Setup.exe

Comment 6

[Daniel Veditz [:dveditz]]

Note: Firefox is not an anti-virus. The protection we offer is based on reputation and lists, not any kind of heuristics based on the contents itself. It is trivially easy to bypass all of the SafeBrowsing protections (phishing, malware sites, unwanted downloads) with a one-off targeted attack. That doesn't diminish the protection offered to most users most of the time from mass attacks and compromises.

Comment 7

[Gian-Carlo Pascutto [:gcp]]

(In reply to Daniel Veditz [:dveditz] from comment #6)
> Note: Firefox is not an anti-virus. The protection we offer is based on
> reputation and lists, not any kind of heuristics based on the contents
> itself. 

Well, technically we query a remote Google server if we can't decide locally based on the lists, and although we officially don't know what that server does, it likely acts as a kind of anti-virus scanner. Case in point is that Chrome's Application Reputation seems to detect the attachment in this bug as evil, see comment 2. Unless Chrome has some other defense that is activating here, this seems to point to a difference in the Application Reputation that we'll want to ix.

> It is trivially easy to bypass all of the SafeBrowsing protections
> (phishing, malware sites, unwanted downloads) with a one-off targeted
> attack. That doesn't diminish the protection offered to most users most of
> the time from mass attacks and compromises.

That is true, though.

But this case seems fixable and we likely already have a bug open on whatever difference caused it - our AppRep implementation is unfinished.

Comment 8

[François Marier [:francois]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #2)
> IIRC .zip files cause us to query for a remote verdict. The remote service
> should be able to deal with such renaming tricks.

That's only true on Windows until bug 1167040 is fixed.

> Chrome gives a warning for the attachement, we do not. This *may* be a known
> issue, we are missing some parts of Application Reputation.

I don't actually know the exact reason why they are blocking Report_.zip because I copied it to http://people.mozilla.org/~fmarier/tmp/Report_.zip and that's not blocked in Chrome.

Another known issue which I am working on (see bug 1213459) is that we don't yet consider all of the extensions that Chrome looks at.

Other than the two existing bugs I've linked to here, I'm not sure there's anything else we can do to help detect the kinds of binaries attached here.

Comment 9

[Matt Wobensmith [:mwobensmith][:matt:]]

Triage group debated this. Based on comment 6, it feels like something similar to a case where new malware is being targeted at this user, whereas this bug involves repurposing old malware with a new file extension. Therefore, rating sec-audit for now, feel free to change when more details surface.

Comment 10

[Gian-Carlo Pascutto [:gcp]]

(In reply to François Marier [:francois] from comment #8)
> (In reply to Gian-Carlo Pascutto [:gcp] from comment #2)
> > IIRC .zip files cause us to query for a remote verdict. The remote service
> > should be able to deal with such renaming tricks.
> 
> That's only true on Windows until bug 1167040 is fixed.

The renaming still needs an "executable" to do the actual renaming, so I think the Chromium heuristic would correctly detect the .bat and judge that the .zip has executable files, ergo, bug 1167040 would not change the outcome.

https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/safe_browsing/download_protection_util.cc&sq=package:chromium&l=305&rcl=1459251151

> > Chrome gives a warning for the attachement, we do not. This *may* be a known
> > issue, we are missing some parts of Application Reputation.
> 
> I don't actually know the exact reason why they are blocking Report_.zip
> because I copied it to http://people.mozilla.org/~fmarier/tmp/Report_.zip
> and that's not blocked in Chrome.

Mozilla.org is trusted :-)

Try this:
http://sjeng.org/ftp/work/Report_.zip

Chrome blocks it, we do not.

> Other than the two existing bugs I've linked to here, I'm not sure there's
> anything else we can do to help detect the kinds of binaries attached here.

If you're sure there's no open bug that could relate to this (and as far as I can tell the two you mentioned are not?) then you'll have to ask Google what exactly causes Chrome to mark it. But maybe a run with more logging could already reveal it? Does my link (and observing that mozilla.org probably foiled you) help with this?

Comment 11

[François Marier [:francois]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #10)
> (In reply to François Marier [:francois] from comment #8)
> > (In reply to Gian-Carlo Pascutto [:gcp] from comment #2)
> > > IIRC .zip files cause us to query for a remote verdict. The remote service
> > > should be able to deal with such renaming tricks.
> > 
> > That's only true on Windows until bug 1167040 is fixed.
> 
> The renaming still needs an "executable" to do the actual renaming, so I
> think the Chromium heuristic would correctly detect the .bat and judge that
> the .zip has executable files, ergo, bug 1167040 would not change the
> outcome.

I wasn't very clear here. What I meant is that right now only Windows does a remote lookup when it sees a zip file. Mac and Linux don't.
Once we fix bug 1167040 (which is about looking inside zip files) then I will re-enable remote lookup for zip files on these two platforms.

So right now, you have to be on Windows to test this.

> > > Chrome gives a warning for the attachement, we do not. This *may* be a known
> > > issue, we are missing some parts of Application Reputation.
> > 
> > I don't actually know the exact reason why they are blocking Report_.zip
> > because I copied it to http://people.mozilla.org/~fmarier/tmp/Report_.zip
> > and that's not blocked in Chrome.
> 
> Mozilla.org is trusted :-)

Is it? I wasn't aware that we're treating that domain differently. The whitelist we have is for signed binaries.

In fact, when I open http://people.mozilla.org/~fmarier/tmp/Report_.zip, with the debug PRLOGs:

  export MOZ_LOG_MODULES="UrlClassifierDbService:5,nsChannelClassifier:5,ApplicationReputation:5"

I get the same output/behavior as when I open http://sjeng.org/ftp/work/Report_.zip.

Or maybe you mean they have a list of domains that they whitelist on the server side?

> Try this:
> http://sjeng.org/ftp/work/Report_.zip
> 
> Chrome blocks it, we do not.

Right, we get a VERDICT_SAFE:

  [Main Thread]: D/ApplicationReputation Got unsigned binary for remote application reputation check [this = 7fbcc6b3d700]
  [Main Thread]: D/ApplicationReputation Serialized protocol buffer [this = 7fbcc6b3d700]: (length=149) 
  %http://sjeng.org/ftp/work/Report_.zip"
   �>��"���l��n�$�%5�h�
  ����/��2���")
  %http://sjeng.org/ftp/work/Report_.zip
  [Main Thread]: D/ApplicationReputation Destroying pending DB lookup [this = 7fbcbb144300]
  --DOCSHELL 0x7fbcbac20000 == 6 [pid = 24068] [id = 9]
  [Main Thread]: D/ApplicationReputation Application Reputation verdict is 0, obtained in 207.645497 ms [this = 7fbcc6b3d700]
  [Main Thread]: D/ApplicationReputation Application Reputation check passed [this = 7fbcc6b3d700]

so my guess is that we either don't send as much information about downloads as Chrome does (e.g. bug 1162842) or we are sending a different hash from Chrome (bug 1190020).

> > Other than the two existing bugs I've linked to here, I'm not sure there's
> > anything else we can do to help detect the kinds of binaries attached here.
> 
> If you're sure there's no open bug that could relate to this (and as far as
> I can tell the two you mentioned are not?) then you'll have to ask Google
> what exactly causes Chrome to mark it. But maybe a run with more logging
> could already reveal it? Does my link (and observing that mozilla.org
> probably foiled you) help with this?

I'll ask Google to see if they can provide any info on the file that's hosted on your domain. Please leave it there :)

Comment 12

[Gian-Carlo Pascutto [:gcp]]

(In reply to François Marier [:francois] from comment #11)

> I wasn't very clear here. What I meant is that right now only Windows does a
> remote lookup when it sees a zip file. Mac and Linux don't.

Argh, right, that will have messed with my testing.

> > Mozilla.org is trusted :-)
> 
> Is it? I wasn't aware that we're treating that domain differently. The
> whitelist we have is for signed binaries.
...
> Or maybe you mean they have a list of domains that they whitelist on the
> server side?

I think that is likely. On the other hand, that does not explain why downloading it from this bug (bugzilla.mozilla.org) triggers the warning in Chrome. So maybe you should ask about this too.

I think a contributing issue may be that the scanner can't fetch the file from this bug as you need credentials to access it?

> 
> > Try this:
> > http://sjeng.org/ftp/work/Report_.zip
> > 
> > Chrome blocks it, we do not.
> 
> Right, we get a VERDICT_SAFE:
> 
>   [Main Thread]: D/ApplicationReputation Got unsigned binary for remote
> application reputation check [this = 7fbcc6b3d700]
>   [Main Thread]: D/ApplicationReputation Serialized protocol buffer [this =
> 7fbcc6b3d700]: (length=149) 
>   %http://sjeng.org/ftp/work/Report_.zip"
>    �>��"���l��n�$�%5�h�
>   ����/��2���")
>   %http://sjeng.org/ftp/work/Report_.zip
>   [Main Thread]: D/ApplicationReputation Destroying pending DB lookup [this
> = 7fbcbb144300]
>   --DOCSHELL 0x7fbcbac20000 == 6 [pid = 24068] [id = 9]
>   [Main Thread]: D/ApplicationReputation Application Reputation verdict is
> 0, obtained in 207.645497 ms [this = 7fbcc6b3d700]
>   [Main Thread]: D/ApplicationReputation Application Reputation check passed
> [this = 7fbcc6b3d700]
> 
> so my guess is that we either don't send as much information about downloads
> as Chrome does (e.g. bug 1162842)

Does Chrome peek inside the .zip to send this information? If it does not, that can't be the cause.

> I'll ask Google to see if they can provide any info on the file that's
> hosted on your domain. Please leave it there :)

Will do.

Comment 13

[François Marier [:francois]]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #12)
> Does Chrome peek inside the .zip to send this information? If it does not,
> that can't be the cause.

That's what's happening:

"Chrome is reporting the sha256 digest of any binary inside the zip archive. The example you mention is a case where the server flagged the download because it contains a blacklisted binary file (content.exe) inside the zip archive."

I filed bug 1260856 for that, which, along with the two it depends on, should cover all of the gaps that this bug has highlighted.

Comment 14

[François Marier [:francois]]

I think this bug can be closed since the work that needs to happen is already covered by bug 1260856, bug 1167040 and bug 1213459.