Closed GoogleCodeExporter closed 9 years ago
Original comment by fors...@google.com
on 18 Dec 2014 at 9:08
[deleted comment]
Correspondence Date: 20 Jan 2015
> Microsoft asked if we'd considered Extended Protection for Authentication
when disclosing the issue. They state that for SMB the issue can be remove but
to quote: "The only complication is that, due to application compatibility
concerns (i.e., trying not to break the universe) the features need to be
enabled and are not on by default." They provided links to documents from
2009/2010 discussing how to enable this. They also state that "Absent arguments
to the contrary we are inclined to consider the issue already addressed by the
existing materials."
< We informed Microsoft that yes this had been considered and the original
write-up makes reference to SMB signing etc as a mitigation and that there
seems to be extended protection but that doesn't seem to mitigate in the
default case. The references provided were consulted but they refer
specifically to XP/2003/Vista which didn't have EPA available, and even then it
wasn't enabled by default. As this issue affects Windows 7 and 8 where EPA
should be on by default then specific SMB settings not liked in the documents
would need to be considered to mitigate the issue. These are internal policy
settings which could be deployed easily in a enterprise environment but not
really for average consumers. Asked for clarification on their final statement
regarding it being already addressed. Did this mean that even though a local
system elevation exists in a default installation of Windows that they would
not provide a fix but just request end users change the defaults?
Original comment by fors...@google.com
on 11 Mar 2015 at 3:58
Correspondence Date: 10 Mar 2015
< Asked Microsoft if any further progress had been made on this case
considering the 90 day deadline expires on the 18th March.
Original comment by fors...@google.com
on 11 Mar 2015 at 3:59
Correspondence Date: 18 Mar 2015
> Microsoft indicated that they felt their previous response indicated they
would not be servicing this issue with a bulletin due to application
compatibility concerns. Enabling SMB signing or SPN validation settings
mitigates the issue and they might consider making it the default going
forward.
Original comment by fors...@google.com
on 18 Mar 2015 at 7:23
As this is a known issue Microsoft have provided some links to advisories and
Knowledge Base articles which discuss how to deploy mitigations.
Security Advisory: https://technet.microsoft.com/library/security/973811
KB Article: http://support.microsoft.com/kb/973811
SMB EPA KB article http://support.microsoft.com/kb/2345886
Additionally you can also disable the Webclient service which makes it more
difficult to elevate to local system. This doesn't necessarily mitigate against
other local attacks (such as sandbox escapes) which only require user level
permissions.
Original comment by fors...@google.com
on 18 Mar 2015 at 8:51
Marking as WontFix and opening the issue to the public.
Original comment by fors...@google.com
on 18 Mar 2015 at 11:37
Why the anti-reflection check isn't effective in the cross-protocol scenerio?
Original comment by davidson...@gmail.com
on 19 Mar 2015 at 7:56
@davidson.shahar
The anti-reflection check added in MS08-068 is explicitly per-service and
opt-in, no doubt for compatibility reasons. The typical scenario is causing an
SMB connection outbound (such as a boobytrapped web page) and reflecting the
credentials back to the same place. This is achievable cross-protocol by using
NTLM auth over HTTP but due to default security policies this is usually only
possible to do in domain joined machines in the victim machines Intranet which
limits the impact. Of course from what I can find no-one has publicly
documented the case where this is abused locally where many different security
restrictions (such as blocking admin shares) seems to not be in force.
Original comment by fors...@google.com
on 20 Mar 2015 at 4:49
> Start the WebClient service, this could be done in many ways from a normal
user
How could this be performed by a normal user? Would an admin not need to give
that normal user access to start/stop services? I don't see any way an
unprivileged user could start this service.
Original comment by petebark...@gmail.com
on 26 Mar 2015 at 2:34
The simplest way from a normal user is to force explorer to navigate to a
webdav share which will eventually force the service triggers which will bring
the service up. You could do this easily programmatically but easier to
demonstrate this way. Bring up the run dialog (using Win+R) and open
\\live.sysinternals.com\tools. Once the explorer window appears for this server
you'll find the webclient service is now running.
Original comment by fors...@google.com
on 26 Mar 2015 at 7:04
have any ways to start the webclient service ?
Original comment by wangdean...@gmail.com
on 27 Mar 2015 at 7:21
Here is a link that explains how to start the webclient service:
http://tyranidslair.blogspot.sg/2015/03/starting-webclient-service.html
Original comment by thierry....@9online.fr
on 27 Mar 2015 at 12:36
Video of poc.jar running on Windows 8.1 x64 fully up-to-date:
https://www.youtube.com/watch?v=wZusd2BmoPk
Original comment by nicolas....@gmail.com
on 30 Mar 2015 at 3:01
Original issue reported on code.google.com by
fors...@google.com
on 18 Dec 2014 at 3:53Attachments: