Adobe has patched a flaw that enabled attackers to slurp a user’s network authentication details – but not before someone else patched it first.
Security researcher Alex Inführ discovered a flaw in Adobe Reader which enabled a malicious PDF file to trigger a callback from the program. A compromised program would communicate with a server using Microsoft’s SMB protocol, sending it the user’s hashed authentication details.
The flaw stemmed from the XML Form Architecture (XFA), which is an XML structure inside a PDF that enables users to fill out forms. Loading a remote XML-based stylesheet relating to XFA with an insecure HTTPS-based URL prompts a file to ask for user confirmation before visiting that URL. By using a Universal Naming Convention (UNC) path, the attacker can stop that security dialog appearing. The result is that the infected file causes the user’s machine to send their NTML (NT Lan Manager) v2 hash to the attacker.
That’s pretty significant, because this hash is the digest of a password for the Windows NT Lan Manager authentication protocol. Various hackers have already detailed methods of cracking the NTLMv2 hash using automated tools.
Adobe released a patch for the flaw yesterday, 12 February 2019, labelling the vulnerability CVE 2019-7089 as a critical data leakage issue. However, security firm Acros Security beat the software vendor to the punch by releasing its own patch on Monday.
Acros’s 0patch service specialises in micropatches, which are applied in memory, rather than in an alteration to the program binary. Micropatches are keyhole surgery, designed to block a specific exploit from compromising a program.
These in-memory patches don’t replace regular software patches, which can make more fundamental structural changes to fix program errors, they’re there to act as a sticking plaster until the vendor applies its own fix. Vendors usually roll up patches into bundles that they release all at once, making it easier for administrators to handle all of the software fixes in one go. Yesterday, on one of its regular patch Tuesdays, Adobe fixed 71 vulnerabilities across a range of products.
Acros applied its own micropatch over two weeks after a vulnerability was published and one day before the vendor released its own official fix. The timing makes the benefits of such an in-memory patch questionable for handling zero-days (vulnerabilities for which there are no patches).
Acros co-founder Mitja Kolsek told Naked Security that the company is currently moving its product out of beta, which accounts for the delay in releasing a patch. However, he added that handling zero-days is a side benefit, rather than the focus of his business. He told us:
Patch administrators (our main target market) are justifiably more concerned about N-days, i.e., vulnerabilities that already have official patches but for one reason or another can’t be applied, and often for a very long time. This is the gap we want to close.
Accepting third party patches brings its own risks. Vendors may be reluctant to support customers who experience problems after applying third party patches, and a willingness to accept third party patches could create new opportunities for supply chain attacks.
Tim Boddington
This reminds me that c.50 years ago operating systems were not at all reliable and micro-patches were the order of the day (and night). I recall many a night working out a bug, writing a correction, converting it to octal, and keying it in word by word to the operational running system through the operator’s console. Change control? Never ‘eard of it! (Univac 1100)