Monday, September 26, 2016

Status of Submitted Vulnerabilities To MSRC

This list is intended to give vague information about submitted bugs, but important information about communication process and timeline.

Bug Title: Microsoft Local Security Authority Subsystem Service (LSASS) Remote Memory Corruption.

  • Affected software: Microsoft Local Security Authority Subsystem Service (LSASS)
  • Type: Memory Corruption.
  • Submitted: 15/09/2016
  • Coordinated disclosure agreement expiration: 15/12/2016.
  • Notes and updates:
    -Proof of concept code was sent on 17/09/2016, no confirmations or real updates were received since then.
    - 28/09/2016: Issue confirmed by MSRC, they are planning on releasing a patch on each affected platform.
    - MSRC informed the bug submitter that they are planning to release a patch on November 8, 2016, that is a full month in advance of the 3 months deadline.

Bug Title: SMBv2 Remote Memory Corruption.

  • Affected software: Microsoft SMBv2.
  • Type: Memory Corruption.
  • Submitted: 25/09/2016. 
  • Coordinated disclosure agreement expiration: 25/12/2016.
  • Notes and updates:
    - MSRC is currently investigating the issue.
    - Microsoft confirmed the issue on 28/09/2016.
    - Bug submitter extended his coordinated disclosure agreement to 1 more month, due to certain circumstances around this issue.

Bug Title: Microsoft Active Directory PDC Remote Code Execution.

  • Affected software: Microsoft Active Directory
  • Type: Protocol Abuse
  • Submitted: 09/12/2016
  • Bug status: Implemented in Responder v2.3.2.2
  • Notes and updates:
    - Proof of concept code was sent on 12/09/2016, Microsoft is planning to release a security fix "over the next few months".
    - Additional proof of concept provided on 02/10/2016 leading to privilege escalation.

Reporting Vulnerability Policy

After several years of actively reporting security bugs to various vendors I came to the following conclusion:
  • A vendor will usually sit on a critical bug as long as he can. Response teams like MSRC, are particularly good at it. I've seen cases where a critical RCE took more than a year before a patch came out.
  • While they usually pretend to care about end-users, most of the time a security patch is released when timing is opportunistic. For example, Server side bugs (RDP, AD/SMB, Lync) month is usually June at MSRC:
  • We only see how long a vendor took to fix a vulnerability when there's an actual advisory with a timeline. Usually the average time is 7-9 months.
  • Taking even 6 months to fix a simple length check is simply not acceptable. It doesn't show in any way a commitment for the security of their users.
Although I must say that I had the opportunity to work with productive vendors in the past for the same kind of bugs I submitted to MSRC. For example, with Samba's Security team, a technical answer was usually sent within 2 hours after submitting a security bug and was fixed across all their branches within 1 week at most.

After some constructive discussions with MSRC lately I decided that I don't want to somehow contribute to this scheme and that things need to change.

Starting today, vulnerabilities already submitted to MSRC will be announced publicly (vuln title, criticity, vuln type) on this blog, but no technical details will be provided to the general public until a patch is out or until my vulnerability disclosure policy agreement has been breached (taking more than x months, for example). Users will be able to track the time it takes them to patch a critical issue and will pressure them if they feel the timeline is unfair. Communities are great for that.

NAC, IDS, IPS vendors might receive ready to go signature for a fairly low price on a case by case review, I don't want any of this ending in any gov's hands before a patch is out. Therefore, selected security vendors will be able to protect their users from critical 0day attacks several months before Microsoft finally decide to protect them by releasing the actual patch.

I invite any frequent MSRC submitter to join me, if they feel like MSFT or any other high profile vendor is sitting on their bugs, it can also be hosted here or published in the same way on their websites.

Users win, you win, I win.

GPG public key: AD0D 60A7 FDAE 1443 F439 D6B1 8DA2 BA12 402E 6A77

Sunday, September 11, 2016

Introducing Proxy Auth on Responder 2.3.2

Few days ago mubix submitted a feature request on Responder repository
I liked the idea and I started working on it. The concept was to force authentication while a victim would use the WPAD proxy server, but then comes the question: Why would you auth someone on the proxy while you used the option -F to force authentication for wpad.dat file retrieval?

Why not letting anyone get that wpad.dat configuration file for free, no authentication and then use another proxy server (not the wpad server) to force authentication, so Responder doesn't send an HTTP 401 response, but a 407 Proxy Authentication Required and then ditch the connection.

Thanks to PAC files, you can set fail-over proxy servers:

function FindProxyForURL(url, host)
if ((host == "localhost") || shExpMatch(host, "localhost.*") ||(host == "") || isPlainHostName(host))
   return "DIRECT";

if (dnsDomainIs(host, "RespProxySrv")||shExpMatch(host, "(*.RespProxySrv|RespProxySrv)"))
   return "DIRECT";


The last line means: 

If the proxy server fails, then use this one: and if both fails, use a direct connection to the intranet or internet.

Using this functionality, we can make sure the WPAD server is not working -by not using the -w option- then any workstation using our PAC file will:
  • Connect to and send a request with URL, cookies, headers.
  • The Auth-Proxy module will respond with a 407 and request credentials.
  • The workstation will transparently send its encrypted NTLMv1/NTLMv2 credentials and will get a TCP Reset from the proxy server right after that.
  • This is done by using SO_LINGER which will send a RST as soon as close() is called, faking a proxy server failure.
  • The workstation will then attempt the second proxy server which is offline.
  • Finally the workstation will connect to the internet directly.

The user behind his desk using Internet Explorer has seen nothing and has internet access, we get his NTLM credentials.

This attack is highly effective and is included in the latest version 2.3.2:

This video demonstrates the concept on a 2012R2 PDC with default settings, someone simply open IE, Responder gets the credentials transparently, no password prompt: