lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 11 Oct 2015 19:22:11 -0500
From: Lee <curtlee2002@...il.com>
To: Stefan Kanthak <stefan.kanthak@...go.de>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Watch your Downloads: the risk of the "auto-download"
 feature on Microsoft Edge and Google Chrome

Stefan Kanthak, everything you said is true but from the point of view
of an enterprise with controlled user accounts.  A home user uses the
default administrator account the manufacturer added to MS Windows.
For someone that installed MS Windows themselves, they use the default
administrator account the MS Windows installer helped them create.
Then when they run into something not working how they want, they read
the first post online about how to disable those software restriction
policies.

The OS installer gave the user an administrator account with no
instructions to not use is for daily use.  It does not even force or
advise the user to add lower privileged accounts.  This is true with
almost all OS installers, not just MS Windows.

You asked me to define "untrusted file".  I don't know MS's criteria
for using "Open File - Security Warning", but that criteria is what I
meant.  I have seen it when executing a file from a flash drive with a
fat32 file system, so it must go beyond just the "zone identifier" in
NTFS.  I was just suggesting this could be expanded to add Haifei
wanted feature.

OS package files would only stop the malicious DLL problem but doesn't
solve the larger problem.  For many years I have seen "Coupon
Printer.msi" stored in users's Downloads folder.  The user agrees to
the terms and clicks next through the installer until it is completely
installed.  It installs a service that monitors their activity and
transmits it to a Chinese ip address.  The program is listed in
"Programs and Features" as an installed program.

What I was shooting for with "destroy/infect/... their OS" was
including their own data, but also that a user with an administrator
account could installed a malicious service that tracks and transmits
all user(s)'s online activity.

I still don't see it being the browser's responsibility.  The user can
execute the file outside the browser, and rendering this wanted
browser protection useless.  If you want a warning about a potentially
malicious DLL, a running third party service (Antivirus/Malware
software) or the OS should be the expected software to add this wanted
feature.

Stefan Kanthak, thanks for the response and giving me the opportunity
to make my statements more clear.  I enjoyed your "cant afford a
surname" comment.  I laughed pretty hard when I read it.  Lee is only
an alias, and does not have a real surname.  I am Curtis Lee Bolin.  I
have added CurtisLeeBolin@...il.com to the mailing list and will use
it for future emails.

-Lee

On Tue, Oct 6, 2015 at 10:29 AM, Stefan Kanthak <stefan.kanthak@...go.de> wrote:
> Lee "cant afford a surname" <curtlee2002@...il.com> wrote:
>
>> Haifei Li, changing the default behavior to open a window asking the
>> user where to save the file would change nothing.  A "normal user"
>> would just click the "save" button to save the file in the default
>> folder.  I also don't think it should be the browser's responsibility
>> to look for potential malicious DLLs in that directory.  This "normal
>> user" may not even use the browser to execute this executable file so
>> they never even see this warning.
>
> Correct so far.
>
>> If you really want to pursue this problem, I think the OS (MS Windows)
>> is where you should be looking for a solution.
>
> No, the OS is NOT the problem here.
> The problem are the morons who build *.EXE to install software (or just
> unpack some files) and hand these *.EXE to unsuspecting and unskilled
> users, expecting them to actually EXECUTE them.
> This really nasty behaviour of almost all developers/companies out
> there trained users to execute almost anything they get their hands on.
>
> The solution for this is simple:
>
> * package your software in the platforms native format.
>   For Windows this is *.MSI for applications, *.INF/*.CAB for drivers.
>   Other (older) OS have *.pkg, their newer variants *.deb, *.rpm, *.apk,
>   *.dmg, ...
>
> * distribute your files in the platforms native format.
>   For Windows this is *.CAB. Other OS's have their own, and most of
>   them understand *.ZIP.
>
>> MS Windows has an "Open File - Security Warning" window before
>> executing untrusted files.
>
> Please define "untrusted file".
> Windows resp. some applications (Internet Explorer, Outlook *, Windows
> Live Mail, ...) add a "zone identifier" (as NTFS alternate data stream)
> to files downloaded from the internet resp. untrusted locations.
>
>> Again, a "normal user" just clicks "Run" on that window without reading
>> the warning, but this could be expanded to also warn about potential
>> malicious DLLs.  Example Image: http://i.imgur.com/3dxQJCB.png
>
> SAFER a.k.a. software restriction policies exist for more than 14 years
> now and can prevent normal users from running executable files.
> Cf. <http://mechbgon.com/srp> or http://home.arcor.de/skanthak/SAFER.html
>
>> As long as a "normal user" is given enough privileges to
>> destroy/infect/... their OS, they will continue to be careless.
>
> Normal user have enough privileges to destroy/infect their OWN files.
> This is worse than just loosing the OS: the latter can be reinstalled.
>
>> You will never be able to protect these people from themselves.
>
> But you can help protect themselves from accidential (or unwanted)
> execution of files.
>
> stay tuned
> Stefan
>
>> On Fri, Oct 2, 2015 at 6:43 PM, Haifei Li <haifei-non-reply@...look.com> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>> This is a copied version of my blog post, original version
> http://justhaifei1.blogspot.com/2015/10/watch-your-downloads-risk-of-auto.html.Probably it's commonly known that when you try to
> download something on your modern browser e.g. Google Chrome or Microsoft Edge, the file will be downloaded automatically to your
> local system with just a simple clicking - no need for additional confirmations. With default settings, the file will be downloaded
> to your "Downloads" folder ("C:\Users\<username>\Downloads").
>>> Personally, I have worried about this feature quite some times, now I finally got some time on highlighting this. (Please tell me
> if there's someone already talked about this, I quickly googled around and wasn't able to find an appropriate one, I think it should
> be known by many ppl).
>>>
>>> The "auto-download" feature is good from "user experience" perspective, but obviously it's not good for security, as the
> downloading could also be started by Javascript (<iframe src="url">). The attacker may just place a malicious DLL with a specific
> name into the "Downloads" folder when the victim visits a webpage he/she controls. In future, when the victim tries to
> download/install good programs (executables) from legitimate websites - of course, the good executable will be downloaded, and will
> be launched from the "Downloads" folder as well - then the installation/execution progress could be hijacked.
>>>
>>> This is because that in the real world, most executables replying dlls. Anyway, the "application directory" is the very first
> place in the search order when searching/loading for a dll (yoy may want to check this paper I released years ago). So, probably,
> most of dlls even the system dlls could be hijacked when you place a same-named dll in the executable's directory, and that's not
> for the situation that the searching dll is not in anywhere of your system.
>>>
>>> Usually, the "Downloads" folder is a place with massive downloaded files, so the victim probably never get a change to realize
> there is a malicious DLL sitting in his/her "Downloads" folder. I'd also doubt that even a normal user notices a strange dll in
> his/her "Downloads" folder, does he/she will really delete it immediately? DLLs won't be executed by themselves anyway, right?
>>>
>>> Anyway, in the real world, for most people, who really check their "Downloads" folder every time when they try to install
> something from internet? Instead, most people just click the "Run" button directly when installing something (see following figure).
>>>
>>>
>>>
>>>
>>> I have quickly made a video showing this risk. The test environment is Windows 10 Pro, with Microsoft Edge and Google Chrome,
> fully updated as of Oct 2nd, 2015, all with default settings. Check it out here.
>>>
>>>
>>> As you may have noted, a modified "VERSION.DLL" will be dropped into the "Downloads" folder when visiting the webpage
> https://dl.dropboxusercontent.com/u/14747595/auto_download_test/test.html. Then, when the user tries to install Adobe Reader from
> the official adobe.com website, the installation process of Adobe Reader will be hijacked - the modified "VERSION.DLL" will be
> loaded and my shellcode will be executed.
>>>
>>> There's one small thing, the code execution should be run out of the browser sandbox, but unluckily the tested shellcode I copied
> from internet runs calc.exe, and because there's no calc.exe anymore on Windows 10, what you've seen it's just a Calculator App
> which runs within the App Container sandbox. Other shellcode, for example, running notepad.exe, will be run out of the App Container
> sandbox and give the attacker control of your system. #BringTheLovelyCalcBackMicrosoft!
>>>
>>> Also note that with default setting, the Microsoft Edge will promote a warning dialog saying the DLL is dangerous, offering the
> user an option to delete the file.
>>>
>>>
>>>
>>>
>>> But:
>>> 1) Anyway, the DLL has been already dropped into the "Downloads" folder, if the user chooses not to delete the file or just do
> nothing, future execution will still be hijacked.2) I also guess this Microsoft Edge warning could be bypassed if the DLL is a
> signed DLL, but I don't have a certificate to test.
>>> On Google Chrome, as you have seen, there's no warning at all.
>>> Thanks,Haifei
>

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ