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: Mon, 12 Oct 2015 13:20:50 +0200
From: "Stefan Kanthak" <stefan.kanthak@...go.de>
To: "Lee" <curtlee2002@...il.com>
Cc: fulldisclosure@...lists.org
Subject: Re: [FD] Watch your Downloads: the risk of the "auto-download"
	feature on Microsoft Edge and Google Chrome

Lee "who still doesnt use his full name" <curtlee2002@...il.com> wrote:

> Stefan Kanthak, everything you said is true

Thanks. But I knew this already.-P

> but from the point of view of an enterprise with controlled user
> accounts.

Windows operates the same way in an enterprise and at home: its
loader searches DLLs and EXEs which are referenced with just their
simple filename instead of their absolute pathname in the "application
directory" first.
See <https://msdn.microsoft.com/en-us/library/ms682586.aspx>
and <https://capec.mitre.org/data/definitions/471.html>

In "other" OS $ORIGIN plus RPATH and LD_LIBRARY_PATH have the same
purpose.

> 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.

Right.
And that's why it's ABSOLUTELY necessary to educate EVERY Windows user:
DONT use the (now "protected") administrator account created during
Windows installation, but create your own "standard user" account(s)
for your daily work.

Point them to Microsoft's help and support pages:

<http://windows.microsoft.com/en-us/windows/user-accounts-faq>

| There are three types of accounts. Each type gives you a different
| level of control over the PC:
|
| * Administrator accounts provide the most control over a PC, and
|   should be used sparingly. You probably created this type of
|   account when you first started using your PC.
| * Standard accounts are for everyday use. If you're setting up
|   accounts for other people on your PC, it's a good idea to give
|   them standard accounts.
| * Child accounts are useful for parents who want to monitor or set
|   limits on their child's PC use, with the Family Safety settings
|   in Windows. For more info about Family Safety, see
|   Set up Family Safety.

JFTR: the default account type for user accounts created after setup
      is "standard user"!

<http://windows.microsoft.com/en-us/windows/change-users-account-type>

| When you set up Windows, you were required to create a user account.
| This account is an administrator account that allows you to set up
| your computer and install any programs that you'd like to use.
| Once you finish setting up your computer, we recommend that you
| create a standard account and use it for your everyday computing.
| If you create new user accounts, you should also make them standard
| accounts. Using standard accounts will help keep your computer more
| secure.

<https://support.microsoft.com/en-us/kb/2526083>

| One of the common misconceptions about UAC and about Same-desktop
| Elevation in particular is that it prevents malware from being
| installed or from gaining administrative rights. First, malware
| can be written not to require administrative rights, and malware
| can be written to write just to areas in the user's profile. More
| important, Same-desktop Elevation in UAC is not a security boundary
| and can be hijacked by unprivileged software that runs on the same
| desktop. Same-desktop Elevation should be considered a convenience
| feature, and from a security perspective, "Protected Administrator"
| should be considered the equivalent of "Administrator." By contrast,
| using Fast User Switching to log on to a different session by using
| an administrator account involves a security boundary between the
| administrator account and the standard user session.

Additionally let them read
<http://download.microsoft.com/download/0/e/9/0e922c03-8537-482f-b57c-aa385b3dee20/Security_Best_Practice_Guidance_for_Consumers.doc
>

| It's very important to remember that UAC prompts are not a security
| boundary - they don't offer direct protection.

<http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.aspx>

| It should be clear then, that neither UAC elevations nor Protected Mode IE
| define new Windows security boundaries. Microsoft has been communicating
| this but I want to make sure that the point is clearly heard.

And let them read
<https://technet.microsoft.com/en-us/magazine/2009.07.uac.aspx>,
<https://technet.microsoft.com/en-us/magazine/2007.09.securitywatch.aspx>,
<https://technet.microsoft.com/en-us/magazine/2007.06.uac.aspx> too!

> 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.

What is this "something not working how they want"?
Software which follows the MINIMUM requirements of the now 20 year old
"Designed for Windows" guidelines and is installed in %ProgramFiles%
works.
Only CRAPWARE which is NOT designed for their platform and tries to
load/execute files from %USERPROFILE% won't work. But EXACTLY this
is intended! It's the darn duty of EVERY developer to protects his
users too, and don't request anything stupid from them! Developers
should be smarter than the users of their software and don't let them
step on trapdoors...

JFTR: use <http://home.arcor.de/skanthak/download/NT6_SUPER.INF> for
      stubborn users^W"wannabee" administrators!

> 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.

Right, it's a REALLY bad and nasty habit, and Microsoft will apparently
newer change their twisted minds about that.
But there is PLENTY of advice, see above.
And it's "best (current) practice" for almost 50 years!

> 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.

The "zone identifier" is what (most) browsers, mailers etc. set, and is
the only one that doesn't need to alter a files content.
If you save a web page with Internet Explorer a "mark of the web" is added
to the HTML: see <https://msdn.microsoft.com/en-us/library/ms537628.aspx>
Some applications treat removable media generylly as untrusted.

For the "definition" of trust read Ken Thompsons ACM lecture
"Reflections on trusting trust".

> 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.

That's right.
The larger problem is to educate people and stop their "trigger happiness":
they must not click on any file just because they can, or because someone
asks them to do so.
They MUST finally but start to use their brains (unless they've alreade
met a zombie).

> 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.

A user with an administrator account can do ANYTHING, so its useless to
pick this up. Every UNPRIVILEGED user but can delete his own files, and
so can EVERY program started with his credentials, be it intended or by
accident.

> 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.

Correct.

> If you want a warning about a potentially malicious DLL, a running
> third party service (Antivirus/Malware software)

OUCH!
Antivirus is useless, it does NOT protect against new/unknown malware.
And the "quality" of most "security products" is LOWER than the quality
of normal products: almost all "security products" introduce more
weaknesses or possible attack vectors than they aim to extinguish.

If you need a proof (of concept): start IExpress.exe on your Windows,
use its wizard and the defaults offered, add an arbitrary file when
asked to, and specify the following command to be run:
CMD.EXE /K ERASE /S "%USERPROFILE%" (I omitted the /Q on purpose).

<http://home.arcor.de/skanthak/download/MALWARE.INF> automates this:
"installing" it will place a file "Don't use this at home, kids!.exe"
on your desktop.

JFTR: IExpress packages are "good" examples to demonstrate the risks
      of the "Downloads" folder:
      * on ALL versions of Windows they load DLLs from this folder,
        and they search the program to run there too;
      * on Windows Vista and above the security theatre known as UAC
        (more precise: its installed detection) will prompt the user
        for consent or an administrator password and run IExpress
        packages elevated, WITHOUT necessity.

> or the OS should be the expected software to add this wanted
> feature.

The OS in question here offers this feature since the last millennium:
it's called SAFER alias Software Restriction Policies or AppLocker.

Take a look at
<https://technet.microsoft.com/en-us/library/bb457006.aspx>
<https://technet.microsoft.com/en-us/library/cc786941.aspx>
<https://technet.microsoft.com/en-us/library/aa940985.aspx>

Also see <http://csrc.nist.gov/itsec/SP800-68r1.pdf>,
<https://www.nsa.gov/ia/_files/os/win2k/application_whitelisting_using_srp.pdf>
or <https://books.google.de/books?isbn=1437914926> and finally
<http://www.asd.gov.au/infosec/top35mitigationstrategies.htm>:

| At least 85% of the targeted cyber intrusions that the Australian
| Signals Directorate (ASD) responds to could be prevented by
| following the Top 4 mitigation strategies listed in our Strategies
| to Mitigate Targeted Cyber Intrusions:
| #1 use application whitelisting to help prevent malicious software
|    and unapproved programs from running

> 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.

That's OK.
I'm an old fart, I expect people to use their realname as display name.

stay tuned
Stefan

> 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