text/plain

Attack Techniques: Encrypted Archives

Tricking a user into downloading and opening malware is a common attack technique, and defenders have introduced security scanners to many layers of the ecosystem in an attempt to combat the technique:

Web hosting providers may scan files served from their infrastructure.
Network gateways and proxies may scan files in transit from server to client.
Email web apps may scan files when received as attachments.
Client download managers scan files as they’re downloaded from the internet.
Client AV and OS security features scan downloaded files as they’re stored on disk or opened.

With all this scanning in place, attackers have great incentives to try to prevent their malicious code from detection up until the moment that a user is infected.

One technique attackers use to avoid getting blocked is delivering the malware inside an archive: for example, using a .zip, .rar, or .7z file. Unfortunately for attackers, defenders long ago caught on to this technique and enhanced scanners to peek inside archives. For example, if you download a .zip file in Chrome or Edge, the browser will decompress the archive file and scan the files within it using SafeBrowsing or SmartScreen. Client AV software will scan inside archives on disk, etc.

Attackers were forced to take another step — encrypting the archive using a password that they share with the user.

Requiring that the end-user type a password to get at the malicious content adds some friction– users might not understand how to do so, or might get suspicious if this isn’t something they’re used to doing. However, the tradeoff is that many of the security scanners (at the web host, gateway, and download manager) will not be able to peek inside the archive¹ to hunt out malicious content. Only security scanners run after the archive’s content is extracted will have the opportunity to block the malware.

This attack works best when the attacker has established some pretext for the file being encrypted; e.g. claiming that it contains private content like financial records, a “free trial” of a paid app, or other types of illegal programs like keygen/cracking software.

https://www.404media.co/a-network-of-ai-nudify-sites-are-a-front-for-notorious-russian-hackers-2/

This same encryption technique is sometimes used to hide URLs used in phishing attacks: The attacker sends the user a phishing link inside an encrypted PDF or ZIP file, and thereby scanners that would ordinarily block the phishing link are blinded.

What can a security administrator do to combat this threat vector?

First, help your users understand that encrypted archives are inherently more risky than average. Consider blocking or quarantining encrypted archives, or enable prompting the user for the password if your security software supports the option. Ensure that your users exclusively use archive extraction software that correctly propagates the Mark-of-the-Web, so that client security software is able to detect files extracted from archives that originated from untrusted sources.

Stay safe out there!

-Eric

¹ In rare cases, a security program might be able to decrypt the archive (if it uses an extremely common password, or if it’s configured to detect the password in an email message or download page) but this is, to the best of my knowledge, extremely uncommon.

Welcome to Fall, I guess?

Two months without a blog post? Sheesh. A lot has happened in two months, although perhaps nothing especially interesting.

I splurged on a new laptop, a Lenovo P1 Gen7 (22-core Ultra 9 185H and 64 gigs of memory). It’s big, heavy, and expensive, but it’s nice to have a PC that isn’t super-slow.

In July, the kids and I visited Maryland and went to Hershey Park and Tree Trekkers.

Coasters were ridden, Grandpa’s wallet was lightened

We then joined the family on a cruise to Bermuda and CocoCay. The boat was the older/smaller Vision of the Seas, but we splurged on Suites and it was pretty nice. Bermuda was beautiful and we had a nice time on the beach and snorkeling.

The Bahamas port call was a bit of a letdown, but the worst day on a beach in the Bahamas is better than most days anywhere else. The waterpark on CocoCay was a lot of fun; we took a ton of runs down Daredevils’ Peak, the tallest waterslide in North America. I look forward to going back around New Year’s.

After the cruise, we headed back to Texas. Noah started 6th grade and tackle football. We all were happy to reunite with our (bigger) no-longer-kittens.

At work, I switched from being a Group Product Manager to an Architect, and flew to Redmond for the Windows Ecosystem Security Summit. I’ll be heading back in November for another week.

Coming up? Mostly work, with some daydreaming about winter break mixed in. I’ll be running some races throughout the fall and winter — the 10K Daisy Dash, the 10 Mile Run for the Water, the Austin Half Marathon, and the Galveston Full (gulp!) Marathon.

Browser Features: Find in Page

For busy web users, the humble Find-in-Page feature in the browser is one of the most important features available. While Google or Bing can get you to the page you’re looking for faster than ever before, once you get to that page, you’ve got to find the information you’re looking for¹, and that’s where Find-in-Page comes into play.

Fortunately, with the death of Adobe Flash, Find-in-Page sometimes works better than it did fifteen years decade ago, because 3rd-party plugin content couldn’t participate in the browser’s Find-in-Page feature. (Chromium’s PDF viewer plugin does use the browser’s Find-in-Page).

Unfortunately, the value of Find-in-Page has been on the decline in recent years, largely due to three trends:

Breaking information out over multiple pages
Virtualized DOMs (Lazy-loading)
Non-DOM web applications

How it works

Conceptually, Find-in-Page is simple: simply gather the text of the page, and then search it, highlight the matches, and allow the user to navigate between each.

As a browser developer, the UX simplicity is a facade over a complicated set of conditions:

Pages may be made up of multiple frames; some of those frames may be running in other processes, requiring cross-process, asynchronous communication
Pages are dynamic: their contents can change, and frames can be added/removed/modified at any time, including in the middle of a Find operation. A user can invoke a Find operation as the page loads, or as it’s navigating away.
Providing the user with feedback like a Match Count or playing a “ding” sound when no more matches are found gets quite complicated.
Moving the search bubble so that it doesn’t cover up the highlighted search result may be tricky.
Figuring out how search should behave for invisible, or collapsed elements requires thought.

In Edge, things get even more complicated, with its AI-powered “Find Related” feature making network calls and hunting for related terms:

Beyond all of these complexities, the nature of the modern web makes it harder for Find-in-Page to function as well that users hope it would.

Problem: Paging

The problem with paging is pretty simple– many sites serve ads on each page, and the simplest way to increase page views is to split content out over multiple pages so that the user must navigate to new pages to get all of their content. If the user hits CTRL+F on a page, only the content of that current page is searched. If the content you’re looking for appears on a later page, you won’t find it until you visit that later page.

There’s no easy answer here… many problems in software are the direct result of economics, and this one is no different.

Problem: Virtualized DOMs

In other cases, a page might load content dynamically for performance reasons — loading tons of content “below the fold” might result in wasting the user’s memory or bandwidth for things they’ll never see. Returning more content into the page might put additional load onto the server, so it might use Intersection Observer or other techniques to figure out what content should be visible and not add invisible content to the DOM.

New features like content-visibility aim to allow web developers to get the performance benefits of virtual DOMs while solving some problems like Find-in-Page.

Problem: Non-DOM Pages

On Google Docs, if you invoke the browser’s native Find experience from the … menu, you get this surprising outcome where most instances of what you’re searching for aren’t found even while they’re literally in bold text in the middle of the visible page:

You can see a similar effect in Microsoft’s Web version of Excel:

If you use the Developer Tools, it’s easy to see what’s going on here: The entire content area of the document and spreadsheet are HTML5 Canvas elements, meaning that there’s no DOM to search at all:

To address these problems, web applications may take over the CTRL+F keystroke to pop up their own Find experience, like the Find UX in Google Docs:

Security / Privacy Implications

Most Web users may expect that websites cannot determine what they’re searching for within a web page. That expectation is faulty– there are a number of tricks a website can use to determine what the user is searching for, ranging from detecting how the browser scrolls to matches, to replacing the Find UX entirely with a lookalike (since the Find box is below the Line-of-Death).

¹Unless the search engine takes advantage of a new web platform feature called Scroll-to-Text-Fragment, which deserves a blog post all its own given its usefulness and subtle security implications.

Memento Mori – Farewells

A sad part of getting older is losing friends along the way. But it’s an important reminder that every day is a gift, and no tomorrow has been promised.

Last week brought the sad news that David Ross has passed away.

David was a giant and a pioneer in the new field of web application security. David graduated from my alma mater (U. Md College Park) the year after I arrived, beating to me to Microsoft by a few years. David was originally recruited by Microsoft after discovering and reporting several serious bugs in early versions of Internet Explorer that could allow attackers to run native code on victims’ PCs.

I first met David in 2004 when I joined Internet Explorer to work on Trust features; David was even by then a longstanding expert in the browser security space. Originally, David was focused purely on security feature work, finding and addressing security vulnerabilities in Internet Explorer and related products. Over time, he moved into security design work, driving the design and adoption of important security features that have had an industry-wide impact (e.g. HttpOnly cookies).

David’s most significant impact at Microsoft was the invention, prototyping, evangelization, and evaluation of the XSS Filter feature of Internet Explorer. This achievement required both high levels of technical and interpersonal skill. David’s research showed the prevalent and growing exploitation of XSS attacks and he knew that if Microsoft wanted to significantly move the needle on security, we had to have an answer for XSS attacks. David generated some proposals for what the browser might do to address this, and himself built a proof-of-concept plugin demonstrating his best proposal. He refined the prototype and improved its effectiveness and performance, and built test code to verify its impact and ensure that false-positives were minimized. He understood this space end-to-end better than almost anyone in the world. However, David needed to, and did, go beyond that. Getting this feature “out of the lab” required a huge amount of interpersonal skill as the Internet Explorer team at the time was very reluctant to take on major features to address a threat space which was “forward looking.”

David managed to build alliances, address concerns, refine his prototypes, win over skeptics (myself included) and eventually drive the approval to ship this feature in IE8. He worked closely with IE’s development team to refine the plugin prototype to fit within Internet Explorer’s architecture.

More significantly, David continued his evangelism, research, and ownership of this feature even after it shipped, working to update the feature to address new threats, even after the IE team was no longer actively working on it. Most impressively, David managed to keep the feature in IE for version 9, where features with performance impact (like the XSS Filter) were getting slashed and burned in order to boost performance of the browser. David did this in two ways: first, by helping to design and implement significant performance improvements in the feature itself. Next, by working with senior Internet Explorer and Windows management to ensure that they understood the value of the feature (both for security and competitive reasons) and would be willing to make the investments necessary to ship it with IE9 and future versions.

Beyond the XSS Filter, David was Microsoft’s “go to guy” for web security for over a decade. When the team encountered a difficult web security design problem, they would go to David, who consistently found a way to help. When Vice Presidents had questions about web security, they would ask: “Well, what does D-Ross think about this?” Unlike many experts at the top of their field, David was modest, easy to work with, and did not suffer from arrogance or impatience; he consistently got the job done while building successful long-term relationships.

The Windows 8 team relied upon David for security review of the critical Windows 8 HTML+JavaScript apps architecture, much as earlier Windows teams relied upon his work for the design of HTML-related features (Desktop Gadgets). He often shared his expertise in written form (publicly and internally) and via small internal presentations and rarely, public presentations, like this lecture at AppSec.eu. Beyond his own contributions, David recruited and directed several key security researchers for Microsoft, significantly strengthening the security team at the company.

At the end of 2013, David moved from Microsoft to Google (I would follow him to Google from Telerik two years later). As a part of his hiring, I had the honor of writing him a glowing letter of recommendation, despite the absurdity, like a high school JV QB writing a letter recommending a NFL team sign Tom Brady.

He was smart and patient and dauntless and I will miss him. Rest peacefully, David.

Earlier this year, we lost Richard Shupak. I met Richard when I started in Internet Explorer; he worked in Microsoft Research and had built tools that would audit products’ use of COM (“COMCheck”) and flag errors that could cause security or reliability problems. IE had a lot of these.

“Making a nuisance of myself is not officially part of my job description,” Richard said. “It’s more like a hobby.”

Unlike Google, Microsoft was pretty parsimonious about granting access to product source code (I joined the IE Team in large part to get access to its code), but rumor had it that Richard had permissions to all of the source at the company and spent his days looking for ways to improve it.

Even after he retired from Microsoft, Richard kept in touch and reported bugs he’d found and areas he planned to go research next.

Three years ago, we lost Dan Kaminsky. I’d first met Dan when he came to Microsoft as an external expert security reviewer, and we worked together on a variety of security topics for over a decade. He was brilliant, fun, and an optimist who had a huge impact on the security community. While Dan was just four months older than me, I want to be Dan when I grow up.

I could write a lot more about Dan, and maybe I will some day.

Four years ago, we lost Chris Jackson. Chris was a bright and funny and optimistic guy who helped customers succeed with Microsoft products. You couldn’t help but be friends with Chris.

Eleven years ago, we lost Ed Praitis. Coworkers for years, we were not especially close but he had a big impact on my outlook and my career, and his early death reminded me of the importance of both lifting others up and expressing your appreciation for those who do the same in timely fashion — you may not have a chance later.

Attack Techniques: Invoice Scams

Today in “Attack techniques so stupid, they can’t possibly succeed… except they do!” — we look at Invoice Scams.

PayPal and other sites allow anyone (an attacker) to send anyone (their victims) an invoice containing the text of the attacker’s choosing. In this attack technique, PayPal sends you an email suggesting that the attacker already has taken your money, and you should call the attacker-supplied telephone number if you have a problem with that.

Because PayPal is acting as a (clueless) accomplice in this scam, the email contains markers of legitimacy (including the “This message is from a trusted sender” notice):

If you call the attacker’s phone number, they will solicit enough information to actually rob you.

In the current version of the Microsoft Outlook web application, you can choose to report this phishing email. Because it really was PayPal that sent this phishing lure, choosing “Report and Block” will block all future email from PayPal, including any emails that aren’t scams, which may not be what you expected to happen.

Note that PayPal isn’t the only vendor with this issue; Square has recently started allowing the same scam, and attackers are abusing Calendly for the same thing:

Attackers are also conducting attacks using DocuSign to send fake invoices.

“Status” Messages Too

Pretty much any service that offers email notifications with attacker supplied text will get abused. For example, an attacker can configure Microsoft Azure to spam arbitrary email addresses with status alerts that have attacker-controlled text, like so:

Microsoft Azure-generated phone phishing lure

The advantage to an attacker here is that the email was sent by Microsoft’s legitimate email servers, being used as an unwitting accomplice to the fraud. The user can mark the email as fraudulent, but since it’s from a legitimate service, it’s unlikely that it will help much.

Best Practices

Software-as-a-Service vendors should take care not to allow attackers to abuse their services in this way. At the very minimum, every email sent on behalf of an untrusted party should have a Report Fraud link at the bottom to allow the vendor to learn when they’re behaving as a criminal accomplice.

If possible avoid sending emails to any address unless that address specifically opts-in to receiving messages (and ensure the opt-in prompt’s text is fully controlled by your service!).

Stay safe out there.

-Eric