Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New malware abuses Microsoft IIS feature to establish backdoor

symantec-enterprise-blogs.security.com

Post reply on HN
Print view View original

51–60 of 62 posts

Re: New malware abuses Microsoft IIS feature to establish backdoor

#51

Post by rbanffy »

louthy wrote: post #40
alexjplant wrote: post #28

Earlier quoted context omitted.

It's snobbery to have an opinion? In terms of both static and application web servers I've personally administered nginx, Apache, IIS, Tomcat, Wildfly and Websphere and mention them here in descending order of preference with regard to capability and DX. As you can see IIS falls squarely in the middle of the pack and is actually a distant third in my opinion. The only compelling reason to use it a decade ago was to h…

> It's snobbery to have an opinion? Of course not and I didn't say any such thing. The original comment "People use IIS?" is clearly a passive-aggressive dig at MS, its tech, and those that use it (as is so often the case in tech circles). It's quite pathetic and childish. If I misunderstood that, then I apologise to the author, but I'd argue it still adds nothing to the discourse even if it was asked honestly. It do…

> "People use IIS?" is clearly a passive-aggressive dig at MS

Feels a bit snarky, but not too aggressive. Windows is not a popular choice for cloud platforms and those users seem to be overrepresented here. I can imagine someone being genuinely surprised it's used for more than serving documentation that's already on a Windows server.

That said, as I mentioned earlier, it's hard to find a use case where IIS (or Windows) is a better choice than any of the popular open source http servers and app platform runtimes.

There is a colossal corpus of .NET Framework code out there and I wouldn't be surprised it achieves the status of COBOL (but with a lot less charm) at some point in the future - where code on it is maintained ad infinitum even though almost nobody would deploy a greenfield app using it.

Re: New malware abuses Microsoft IIS feature to establish backdoor

#53

Post by AnIdiotOnTheNet »

the8472 wrote: post #42
jiggawatts wrote: post #31

Earlier quoted context omitted.

Conversely, from the perspective of people that started with computers in the 1990s, it's bizarre how Linux keeps failing to copy Windows. At one point something like 95% of PCs were Windows, and the rest were mostly Apple Macs. Similarly in the server space, you would be surprised to hear that the majority of servers were Windows for quite a while. Note that I didn't say web servers , because not all the world is HT…

> There is still no equivalent to Microsoft Exchange, Group Policy, Enterprise PKI, and a bunch of other things in the Linux world. Which also means fewer attack vectors.

Why yes, by leaving our computers off and not using them we are at significantly less risk than if we actually employed them to do meaningful work.

Re: New malware abuses Microsoft IIS feature to establish backdoor

#54

Post by DaiPlusPlus »

tombert wrote: post #16
sublinear wrote: post #2

People use IIS?

I used to work for a .NET shop (pre .NET Core) doing F#, and we used IIS. In the company Slack, I said something like "Serious question; is there something that IIS does better than something like Nginx or any other open source server?" One of the most senior engineers responded back with "crashing".

IIS can be configured by non-expert users easily, and without necessarily compromising security, thanks to the well-designed (I’m being serious) administration tools that MS has (thankfully) not butchered-up over the past 15 years.

It’s an “old-world” web-server (like Apache, etc) which defaults to “filesystem-first” which is great for quickly making a directory available on the web, and its architecture employing recyclable worker-processes (since IIS 6) with limited privileges gives it the performance benefits of in-proc code-execution (vs CGI/FastCGI) without the risk of a vuln compromising the entire web server. Oh, and HTTP.sys is pretty nice and fast too. I’ve never had reliability or crashing issues with IIS: if your worker-process goes down it means your application code has a crashing bug in it, not IIS.

Yeah, nginx is nice - but is also a relatively recent tool (since 2004, I didn’t start seeing people prefer it for projects until after NodeJS gave them a reason to use it - so around 10 years ago). While nginx supports Windows, there’s a big fat caution saying it’s performance is sub-par still: https://nginx.org/en/docs/windows.html

So if you’re on Windows - because you’re a (non-Linux) .NET shop, or want/need to run on on-prem Windows Server boxes (especially SMB scenarios) it just makes sense to use IIS: it’s already there and certainly is not an underperforming, insecure, or otherwise “bad” web-server.

Re: New malware abuses Microsoft IIS feature to establish backdoor

#55

Post by dhx »

jimbobimbo wrote: post #5

FTA: "In order to use this technique, an attacker needs to gain access to the Windows system running the IIS server by some other means. In this particular case, it is unclear how this access was achieved." See also "It rather involved being on the other side of this airtight hatchway" series by Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20181219-00/?p=10... https://devblogs.microsoft.com/oldnewthing/20…

I don't think "airtight hatchway" applies here because what is to say the entry point isn't exploiting w3wp.exe remotely and executing code from the stack. Then let's say a memory page containing FREB code has permission PAGE_EXECUTE_READWRITE set (a plausible possibility for JIT compiling akin to eBPF), providing a convenient (and plausibly deniable) location for an extended amount of malicious code to be stored and executed from. Or w3wp.exe has permission to create a new memory page with PAGE_EXECUTE_READWRITE set and again this is plausibly deniable because FREB may need to do similar for JIT compiling. It it were almost any other process, a memory page set to PAGE_EXECUTE_READWRITE would sound alarm bells (or at least it should).

The second aspect is how well is w3wp.exe isolated? Can and does it use "AppContainer" (or equivalent) isolation and is it strict? For example, could code executed by w3wp.exe create a new network socket, execute another process, write to a file in any path even though it shouldn't have a need to do so? Perhaps a different process sample123.exe is compromised, which by itself isn't too much of a problem due to its high degree of isolation. However, sample123.exe has permission to write to a pipe shared with w3wp.exe and can use this permission to exploit a bug in w3wp.exe (not exposed remotely) to allow code to execute with different/higher permissions of w3wp.exe, or using a plausibly deniable PAGE_EXECUTE_READWRITE memory page of w3wp.exe to store and execute code from without immediately sounding alarm bells.

_If_ strong process isolation was in place and working for w3wp.exe and/or sample123.exe, the "airtight hatchway" may not have been breached because whilst malicious code may have been executable from a stack, the malicious code wouldn't have been able to achieve much or anything of concern (can't read files from disk, can't access memory of other processes, can't login to a SQL database and start pulling data of other users, etc, etc).

I'm not sure what the equivalent of "systemd-analyze security" is for Windows, but it'd be well worthwhile for Windows system owners to demand similar easy-to-use tools for auditing the level of isolation of and required interfaces between applications (spoiler: just like a typical Linux system, the results will not be comforting, but seemingly with Windows you wouldn't know). Windows process isolation features introduced over the years are poorly documented, hard to use due to lack of tooling and often not used except for a few high profile applications such as Chromium and Adobe Acrobat. Chromium possibly has one of the best overviews of how sandboxing/process isolation can be achieved in Windows because they would have gone through a lot of pain in being amongst the first to figure it out[1].

[1] https://chromium.googlesource.com/chromium/src/+/HEAD/docs/d...

Re: New malware abuses Microsoft IIS feature to establish backdoor

#56

Post by Dylan16807 »

msm_ wrote: post #45
Dylan16807 wrote: post #33

Earlier quoted context omitted.

My desktop has a 20MB security log that goes back 16 days, which seems like enough. If anything, stop spamming tens to hundreds of duplicate messages when credentials are read or group membership is enumerated. System has 8 months, application has 10 months, and setup has 26 months.

It's absolutely not enough for APT investigation. Average attacks lengths are in months, infections sometimes span multiple years. Especially since we're talking about a backdoor (ransomware operators tend to move more quickly)

It's not enough for that, but that bar is too high. Unless the logs are very small, you should not be keeping years of them. I still say 20MB is enough for a desktop.

Re: New malware abuses Microsoft IIS feature to establish backdoor

#57

Post by CompuHacker »

rbanffy wrote: post #46
CompuHacker wrote: post #3

Earlier quoted context omitted.

Yeah! I run an unpatched IIS FTP server on Windows 10 from 2016. When FileZilla stopped connecting to it for reasons I can't even imagine, I enabled SSL using some slightly modified arcane commands I found on a forum post from 2011 to generate a self-signed certificate, convert it between two different formats, and finally use it to accept connections from only some of the still available FTP clients for Windows, whi…

I hope this is humor. I really do.

I wish it was, as well.

What should I be doing?

Re: New malware abuses Microsoft IIS feature to establish backdoor

#58

Post by gerdesj »

Dylan16807 wrote: post #33
gerdesj wrote: post #18

Earlier quoted context omitted.

"it is unclear how this access was achieved" Not a good line in a write up like this. Windows does write n store an awful lot of logs by default. However thanks to circular logging with log sizes from the 1990s on critical logs, you can easily lose information. I can't remember what the defaults are (connects to 2016 AD DC) ... 20Mb for %SystemRoot%\System32\Winevt\Logs\Security.evtx . On a tiddly setup like mine (20…

My desktop has a 20MB security log that goes back 16 days, which seems like enough. If anything, stop spamming tens to hundreds of duplicate messages when credentials are read or group membership is enumerated. System has 8 months, application has 10 months, and setup has 26 months.

Yes (20Mb), but so do AD DCs which is frankly lazy on MS dev's part. If a DC is such a big deal that it requires rather more cash to buy than a "workstation" edition of Windows, then I'd like to see more attention to detail.

By contrast a Linux box running systemd/journald by default will leave 10% disc space free when logging. That's enough to keep a filesystem honest!

20Mb on a DC - even one for a small site like mine will cycle quite often.

I really recommend that you extend your logs to cover six months or more. It will cost you maybe a gigabyte or 10. Very little these days (my first HD was 20MB, yes: megabytes). However if you need to get some details from the past - very handy.

Re: New malware abuses Microsoft IIS feature to establish backdoor

#59

Post by gerdesj »

Dylan16807 wrote: post #56
msm_ wrote: post #45

Earlier quoted context omitted.

It's absolutely not enough for APT investigation. Average attacks lengths are in months, infections sometimes span multiple years. Especially since we're talking about a backdoor (ransomware operators tend to move more quickly)

It's not enough for that, but that bar is too high. Unless the logs are very small, you should not be keeping years of them. I still say 20MB is enough for a desktop.

Depends on the desktop. Mine does quite a lot of stuff. /var/log is 8.3Gb and the journal is probably a monster.

Your use case is probably different to mine - I'm a security officer for my firm.

Re: New malware abuses Microsoft IIS feature to establish backdoor

#60

Post by gerdesj »

throwanem wrote: post #23
gerdesj wrote: post #15

Earlier quoted context omitted.

Nothing at all. It is an extremely capable webserver. In common with all web servers, advice found via search varies in quality and unfortunately, being Windows based: IIS really suffers. The GUI is pretty intimidating (IIS Manager - both of them) and there are things that can only be done via registry, config files and dark magic. IIS gets a lot of undeserved stick in my opinion.

You're not really making a strong case here for that "undeserved".

Fair enough. I'm an Apache, Caddy, nginx, HA Proxy "fan" and I generally only worry about IIS when it hoves into view - Exchange for example, or whatever weird and wonderful nonsense a customer comes up with.

I am almost perversely going to get into IIS but I probably won't. Following logs on Windows is a right old ballache. The bloody things don't seem to get written to disc for quite a while for those many systems that ignore the Windows Events system and dump to .log. I've tried various log viewers. Where the hell is lnav or even less for Windows?

My snags with Windows is opacity. I fire up a daemon on a Linux box and then in another tab/window or whatever, I follow logs - I can use less (is more) or something fancier like lnav. That workflow does not translate very well to Windows.

The taskmanager on Windows is much improved these days - you can now with a GUI work from a network port to a binary (PID) and even associate it with a particular service.

However, text logs are still second class citizens.

Post reply on HN