Bash on Windows: a hidden Bitcoin goldmine? | Hacker News Reader

Bash on Windows: a hidden Bitcoin goldmine?

ma.ttias.be

81 pointsMojah47 comments

Hopefully this gets fixed, but to be fair, if an attacker can enable the subsystem, download the image, and run the commands to install a miner and run them, you're already beyond screwed.

Resolved already. https://github.com/Microsoft/BashOnWindows/issues/122

Edit: A comment how easy it would be to theoretically have this functionality accidentally enabled --

Note that the odds of Grandma 'accidentally' enabling Bash on Windows is more or less none. You have to 1: Associate your Win10 account with a MSDN account. 2: Enable Developer Mode from the Update Settings. 3: Sign into MSDN and click through a few pages to enable Insider features. 4: Finally, Go back to the Update settings and enable Insider updates along with the "Fast" feature-set. 5: Reboot. 6: Enable the "Server" Service (most users are just running "Workstation" on 10; 'Server' isn't even offered on non-Pro,Enterprise. (At least, I think)).

Only then will you be able to even have the option of installing the Bash feature (which isn't an "oops" situation - you have to be a power user to even get access to it with an Admin user [See: (1,2) for what's visible on a stock install of Windows, even to administrators - none of which offer the Feature selection.]

It's intentionally obscured for power users, just like the Group Policy, MMC, etc functionality. You can even tell by [3] ("Features") and the other Features in there (Active Directory, Hyper V, etc) that this functionality is clearly targeted to power-users (in fact, there's a large overlap between WinServer 2012's Feature screen & this).

TL;DR - This isn't something which will accidentally get turned on, and if Grandma is rooted, you can hide the process from Process Manager easily anyways. Even from Sysinternals' Procexp, with some ease.

[1] https://i.imgur.com/EPgcrrR.png Standard settings page [2] https://i.imgur.com/Lim8eFv.png Standard Control Panel [3] https://i.imgur.com/xDyQzHd.png Features

Very true, indeed. If Microsoft ever decides to activate Bash by default (ie: in a couple of years), this could present a real problem.

Right now, it's hopefully just an implementation detail that will get resolved soon.

It isn't worth CPU mining Bitcoin. Furthermore, even when it was botnet owners quickly saturated not just the CPU mining but the GPU mining as well. It wasn't until FPGA Bitcoin software and ASICs started coming out that this generally stopped.

One of the dark bits with people calling for a more democratic Proof of Work based cryptocurrency is that it will dramatically increase monetary flows to organized cyber criminals.

Replace "bitcoin mining" with "cryptocurrency mining".

Several cryptocurrencies use alternative Proof-of-Work that is more CPU friendly, e.g. by requiring several MB of memory and exploiting Intel CPU's AES-NI support for cryptographic operations.

It totally is if someone else is paying for the power.

You may be underestimating how wildly inefficient CPU mining is. Even if an attacker isn't paying for the hardware or the power, there's still a significant opportunity cost. (Especially given that Bitcoin mining is a rather conspicuous way to use an exploited computer; users are likely to notice the increase in fan noise.)

OS X gets this right. Activity Monitor, essentially the OS X equivalent to the Windows Task manager, shows all types of processes. Furthermore, OS X's "Apps Using Significant Energy" list will contain Terminal if an app running within it is eating CPU.

That isn't a fair comparison. OSX is itself a unix system and as such, there isn't any work involved in showing all processes equal (they _are_ equal). In Windows, the subsystem is probably running an entirely different and separate process model, regulated by the kernel. That's way harder to nicely unify in task manager or something like that. (Disclaimer: I know zilch of the new linux subsystem on windows, so please forgive any errors)

I don't know how bash is running processes, but I do know that there used to be a POSIX subsystem, and processes would show in the task manager.

IIRC the POSIX subsystem was impure and its apps also used user32.dll and such, which might explain why its processes showed up.

Actually, the POSIX subsystem is part of the user mode portion of Windows. It's classed as an environmental subsystem.

The portion of Windows that handles processes is in the kernel mode part of Windows, and is part of its executive subsystem - I believe Microsift call it the process manager.

Windows just ran POSIX compliant programs in a POSIX environment, so the process manager shouldn't have had any problems.

Edit: I researched this years ago whilst studying for the MCP, and documented it on Wikipedia [1] - I even drew a diagram in Word which has since been converted to SVG :-) Since then someone else has written an article about the POSIX subsystem of Windows and it notes:

"The runtime environment of the subsystem is provided by two files: psxss.exe and psxdll.dll. A POSIX application uses psxdll.dll to communicate with the subsystem while communicating with posix.exe to provide display capabilities on the Windows desktop." [2]

1. https://en.m.wikipedia.org/wiki/Architecture_of_Windows_NT

2. https://en.wikipedia.org/wiki/Microsoft_POSIX_subsystem

This isn't about cmd or Powershell. Bash on Windows is a whole different beast, and it is early days.

Can you explain what exactly OS X gets right - which other operating system ABIs are involved?

On OS X, every process on the system is a Unix process and has a PID, and is visible from the Unix APIs that Activity Monitor uses. Even when OS X had more diversity in binary formats (the Classic environment, Carbon CFM apps, emulated PPC binaries), everything was still a Unix process.

I would say that OS X is just simpler, in that it doesn't use multiple subsystems which can each have totally separate process namespaces. What the Windows Task Manager should at least do is have a catch-all entry for a non-Win32 subsystem, so you can see that the Linux Subsystem is taking 100% CPU.

Clickbait.

100% agreed. Its really about Bash on Windows not showing up processes in the task manager.

There's no BTC goldmine here.

... because processes that run within Bash don't show in the task manager! So you can run Linux processes and they don't show up in normal Windows monitoring tools.

You don't think that's a problem or could be used to hide processes from the average sysadmin? I do!

It's a problem and could be used to hide processes from the average sysadmin, but Bitcoin mining is not a likely use of this exploit.

Possibly, but bitcoin mining is the reason for a fair bit of malware on the average PC/laptop.

BTC based malware is typically ransomware actually. Not actually BTC Mining.

Generally speaking, when virus writers write viruses, they don't like spinning up the CPU fans and literally allowing the user to hear the virus working. Pegging the CPU at 100% is the easiest damn way of getting caught.

Instead, Botnets seem to be more intent in stealing keyboard presses (credit card information, personal information), and launching DDOS attacks.

It's a beta release only available for insider subscribers. They also mention this issue in a channel9 video and are very well aware of the issue.

That's not the point I was responding to though. The OP was saying that bitcoin mining would be an unlikely motivation to exploit this, all I'm saying is that a lot of Windows malware is written precisely to steal CPU cycles in order to mine cryptocurrencies.

It's a loose assumption based on a chain of unlikely events, not a distinct outcome like the title suggests.

It's a ubuntu based subsystem. Apt-get probably uses their official repo and you would have to get your malware into that first and then make some windows beta-user install your new and unknown package.

Seriously, this is less useful than the headline. I wish people would stop exclaming "clickbait!" on any and all headlines.

Actually it tells us oh, garbage article, don't click it.

And yet, it wasn't garbage in any way. It was actually quite interesting.

Are bash processes entirely hidden from the task manager or just not shown by default (i.e. similar system services)?

There's an issue logged about this:

https://github.com/Microsoft/BashOnWindows/issues/122

Show processes from all users

Resource Monitor

Sysinternals Process Explorer

Run as administrator

Bash for Windows is still beta.

I wonder what Process Explorer shows. https://technet.microsoft.com/en-us/sysinternals/processexpl...

It correctly displays those processes, as does the tasklist.exe command line tool, and taskmgr.exe from earlier versions of Windows. Looks like this is just a bug in the Windows 10 Task Manager.

Those processes are weird compared to normal processes. The main place the user mode information about a process is tracked in a normal windows process is through the Process Environment Block (PEB). You get the list of modules and commandline and tons of other information by reading the PEB of a process.

The processes in the Linux subsystem does not interact with the usual usermode parts of Windows at all, so they don't need a PEB. Actually their PEB is mapped to address 0 which is reserved.

A lot of APIs for getting information about processes will try to read the PEB, and fail if they can't read that. So if you want useful information about those processes you can only use those APIs that queries the kernel about its information about the process.

The Task Manager probably just assumes that it can get all the information normally, and ignores the process if something fails. Maybe it's even the API it uses that's the issue, someone could check whether the ToolHelp32 API even returns those processes (I don't know whether the Task Manager uses the ToolHelp32 API or the lower level PSAPI).

Or maybe they forgot to show processes from all users.

There appears to be no option that will make these processes appear, even if you run the Task Manager as an administrator. It shows all the other processes on the system, just not the ones running in the Linux subsystem.

If my computer suddenly spins up the fans for no reason, I will check the task manager. If it is showing 99% CPU without being able to attribute it, it's way more suspicious than if it attributed to e.g. the browser.

Does this mean that the bash/root runs as Local System and not as admin (or the current admin user)? I am guessing, but it seems like a likely way this got missed.

If I remember correctly, it should show up in the details tab. At least the subsystem process that is.

Just tested this (and updated the article): no, does not show up.

The screenshots don't show the "Details" tab. Maybe the process can be seen there?

Hi! Author of the article here.

I've updated it, because that's a good remark: the list doesn't show the process's name either.

Ew. Reminds me of the infamous Sony toolkit...

bash is for bitcoin and android is for pirates?

This is actually the fault of the new Task Manager in Windows 10. If you click the "Details" tab, you should see all processes.

There are a lot of things that only show up in the "Details" tab. Any user who needs to kill a process in Windows (which is 70% of Windows users) will quickly learnt that the "Details" tab is the only one that matters.

Have you read the article? He accesses the Details tab and it's not there either.

Actually he updated the article after I read it and commented (he replied to another comment saying this). But if so, yeah, that's scary and hopefully something that will be fixed before general release.

Reply on news.ycombinator.com