Bugtraq mailing list archives

Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account

From: "Stefan Kanthak" <stefan.kanthak () nexgo de>
Date: Mon, 28 Jul 2014 16:26:10 +0200

"Michael Cramer" <mike.cramer () outlook com> wrote:

sudo make-me-a-sandwich.py


How is this different from any other temporary, per-process elevation system?


0. neither sudo nor make-me-a-sandwich.py nor the OS where these programs
   typically run have a CreateProcess*() system call which guesses which
   executable it should run in case of a command line with embedded spaces.

   Do you expect that your command line executes "sudo make-me-a-sandwich.py"
   in the absence of a file sudo or sudo.exe?


1. if you omit sudo from the command line, there is no elevation, not even
   an attempt for an elevation.

   On Windows, you dont need to use sudo, you just "open" for example
   REGEDIT.EXE or make-me-a-sandwich.reg: if you do this in a standard
   user account REGEDIT.EXE will run with standard user rights, without
   any prompt for elevation. But if you do this in an administrator account
   (except the builtin "Administrator"), Windows prompts for consent.

   And if you use one of the 70 Windows programs which Microsoft in their
   very finite wisdom granted auto-elevation, you wont see any elevation
   prompt at all!


2. on *x, your user account is an UNPRIVILEGED user account, and you have
   to use sudo explictly.

   On Windows, all user accounts created during setup are administrator
   accounts which show the above mentioned behaviour.


Is this enough of a difference?

Sent from my Surface Pro 3


ARGH!
I don't need any advertising!

Stefan

From: Stefan Kanthak
Sent: ?Monday?, ?July? ?28?, ?2014 ?06?:?08
To: Gynvael Coldwind
Cc: fulldisclosure, Brandon Perry, bugtraq () securityfocus com





Gynvael Coldwind wrote:

So reading the links you provided I semi-agree with you. I think the
problem boils down to this part of your initial e-mail:

PS: yes, it needs administrative privileges to write C:\Program.exe.
   BUT: all the user account(s) created during Windows setup have
   administrative privileges.


My point was (and it still stands) that if you have admin access, this
isn't a privilege escalation, as there is no "escalation" part here.


Correct.
If only Microsoft would educate its users to exercise STRICT user
separation and use different accounts for administration and daily work.

This is where and why UAC chimes in (which answers your question below):
Joe Average uses the administrative account created during Windows setup,
but UAC strips the administrator rights.
Microsoft "sells" UAC as "Joe Average works with standard user rights"
or "Joe Average is not an administrator any more", neglecting that Joe
will happily approve almost every request for administrative rights (or
isnt asked at all when one of the about 70 Windows executables which are
exempt from the elevation prompt are auto-elevated).

The links you provided use different wording, e.g.
(http://blogs.technet.com/b/srd/archive/2013/07/09/assessing-risk-for-the-july-2013-security-updates.aspx):
"To exploit the vulnerability addressed by this update, attacker must
have permission to create a new file at the root of the system drive.
(C:\malicious.exe)"

This makes of course more sense, though as I did mention above, it
does seem to require deliberate action from the administrator to
actually allow a non-admin user the WD (add file to directory)
privilege on C:\, which is rather rare I would say.


Correct.
This argument holds as long as strict user separation is exercised.
But with UAC, Joe Average is both user and administrator, and isnt
really aware of his split personality.

That being said, after thinking about it again I do see your point,
which I interpret at: even if an administrator grants all users WD/AD
on C:\, there should be no reason for him to worry, as there is no
reason to suspect files placed in C:\ are going to auto-execute on
certain events*.
* let's leave autoexec.bat/config.sys out of this, as that branch of
Windows is long dead and supported only FAT anyway

So let me change my initial e-mail to: Congratz on finding the bug :)

(BTW not sure why did you bring UAC into the discussion - did I miss
something? or was it just an argument you've heard before and wanted
to reply to it preventively?)

Cheers!


regards
Stefan

On Fri, Jul 25, 2014 at 2:50 PM, Stefan Kanthak <stefan.kanthak () nexgo de> wrote:

Gynvael Coldwind wrote:

Well it was discussed a couple of times recently on FD that this is a bug,
but it's not a privilege escalation.
If you are admin (and you did mention that it's a prerequisite) you can
execute code as other users anyway - so there's no *escalation* here.

Therefore it's not a security bug (unless you are using a super old version
of Windows with incorrect ACLs on c:\, which sounds like a bug in itself),
just a "normal" bug.
Not sure if FD is the right place for non-security bugs tbh.


If these bugs were no security bugs: why does Microsoft then publish fixes
for (at least some of) them via MSRC bulletins and Windows Update?

See <https://technet.microsoft.com/library/security/ms13-058.aspx>
or <https://technet.microsoft.com/library/security/ms13-034.aspx>

Or pulls drivers whose setup routines show these bugs from Windows Update?

See <http://seclists.org/fulldisclosure/2014/May/40>


Also try to see these bugs as a blended threat:

* during Windows setup Microsoft still creates all user accounts as
  administrators.

* Microsoft sells its unsuspecting users UAC as a security feature, but does
  NOT inform them (or at least does not inform Joe Average) that UAC is not
  a security boundary and they should better use a restricted^Wstandard user
  account instead of the administrator account created during setup.

* Joe Average will happily give consent to any program which presents an UAC
  prompt to him: he wants to get his work done, and this UAC prompt is just
  an annoyance. BTW: when Windows asks him for consent, this must be right?

regards
Stefan

Cheers,
On 25 Jul 2014 00:46, "Stefan Kanthak" <stefan.kanthak () nexgo de> wrote:

Brandon Perry wrote:

So, I am very curious how you are finding these? Have you automated this

or

is it manual hand work?


All my Windows installations have
<http://home.arcor.de/skanthak/download/SENTINEL.EXE> and
<http://home.arcor.de/skanthak/download/SENTINEL.DLL> preinstalled as
C:\Program.exe and C:\Program.dll, so I'm notified when some poorly written
program tries to execute them.
The sentinels call MessageBox() with "MB_SERVICE_NOTIFICATION", so the
messages are recorded in the event log too where I can find them later.

I also preinstall an APPINIT.DLL <https://support.microsoft.com/kb/197571>
which logs all command lines of programs linked to USER32.DLL to a file:
filtering for "C:\Program " at column 1 lists all the culprits.

My third source is a SAFER.Log <
https://technet.microsoft.com/cc786941.aspx>
where every execution attempt is logged, including the executables caller:
filtering this for "\program.exe" or "\program.dll" lists all the culprits.

So basically I just have to sit and wait...

In case one of my customers was hit, and this did not happen during an
installation, I have to interrogate them what they did... and hope they can
remember with sufficient detail.

But almost all hits occur during installations or the customization
following
an installation (here it was the import of existing mails into a new
account),
so these are not so difficult to reproduce.

regards
Stefan

PS: of course it helps if 8.3 names are disabled and "C:\Program Files\"
can't
    be aliased as C:\Progra~1\
    To achieve this just run FORMAT C: /FS:NTFS /S:Disable in Windows PE
    before you start the installation of Windows 7 and later.
    For Windows NT5.x you'll have to use \i386\MIGRATE.INF

On Wed, Jul 23, 2014 at 2:50 PM, Stefan Kanthak <stefan.kanthak () nexgo de

wrote:

Hi @ll,

the import function of Windows Mail executes a rogue program

C:\Program.exe

with the credentials of another account, resulting in a privilege
escalation!


[...]

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




-- 
Gynvael Coldwind

Current thread:

Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Stefan Kanthak (Jul 30)
- <Possible follow-ups>
- Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Stefan Kanthak (Jul 30)
  - Message not available
    - Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Stefan Kanthak (Jul 31)
    - Message not available
    - Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Stefan Kanthak (Jul 31)
    - RE: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Joe Souza (Jul 31)
    - Re: [FD] Beginner's error: import function of Windows Mail executes rogue program C:\Program.exe with credentials of other account Stefan Kanthak (Jul 31)