All-Python malware nasty bites Windows victims in Poland Malware authors have put together a strain of malicious code written entirely in Python, in what may turn out to be an experiment in creating a new type of cross-platform nasty. PWOBot is written entirely in Python, and compiled via PyInstaller to generate a Microsoft Windows executable. The malware has already infected a …
I fail to see the particular seriousness of the threat in this case. Wouldn't it be easier to detect since the generated code will be more predictable with all the known python optimization and libraries involved? Any environment where someone can install a payload created with whatever set of tools or in whatever language would have major problems in the first place. Or do I miss something here?
This is what it can do :
PWOLauncher : Download/execute file, or execute local file
PWOHTTPD : Spawn a HTTP server on the victim machine
PWOKeyLogger : Log keystrokes on the victim machine
PWOMiner : Mine bitcoins using the victim CPU/GPU
PWOPyExec : Execute Python code
PWOQuery : Query remote URL and return results
This list basically means that are in remote control of infected PCs. They can detect passwords, launch whatever they want and generally benefit from all the resources of the machine.
I rank that as rather serious. I certainly hope it can be detected and blocked by my current AV solution, although I must admit that I tend to not download its targeted carriers (Quick PDF to Word, XoristDecryptor, Easy Barcode Creator, Kingston Format Utility and the others are really not in my interest zone).
Expect some nasty cryptolocking ransomware written in Python sooner or later... ne'er-do-wells just seems to keep themselves busy these days...
Solution would be to code a default-deny OS - where nothing will run without authorization from the user. Granted, it will be a major PITA (especially after application upgrades)...
Yes, but dot and source only work for scripts written in the same language as the shell.
You cannot execute a script written in Python that way, nor a compiled executable. The script can embed a script in another language, but it has to manually execute the interpreter and pipe the data to it for that to work.
True, but /usr/bin/python or %WINDOWS%/Program Files/python/python.exe isn't exactly hard to guess.
What we want is a jailed browser process by default, and a prohibition on launching any executable (mime/extension recognition?) from disk areas the browser has write access to. I'd settle for a ramdisk with all the executables in it which gets copied and deleted after use. The browser is a high-risk interface - we know that. From a security pov, you should be able to completely compromise it and still not be able to compromise the user's general files, install persistent threats or compromise the system as a whole. i.e. (pun intended) the browser is an app controlled by the OS, not part of the OS. If you want a high-privileged (what we normally get now) browser, that should be a launch-time option, not the default.
This isn't a windows only problem - I want this for linux too. A chroot without all those interpreters (python, bash, cmd.exe, screen saver config, word.exe, excel.exe) would be a good start. The option of a non-kernel (slow but safe) display system would also be good, even if it were a boot-only option.
Linux is free - it is hard to complain about a lack of features. Windows has no excuse.
Removing execute permissions for the /home partition, /tmp, etc, where users can write to helps a lot, but not as you say for a particularly determined user and/or program. For the really gullible Linux user you can also deny them a command shell so they can be tempted to type in crap.
However, for more serious blocking of tricks like you mention you can use tools like apparmor to deny execution of bash, python, etc, in user-writeable areas to further piss off malware authors.
Incidentally Windows supports no-execute as a ACL setting, you can do the same to block execution in all user-writeable areas stop a lot of Trojans from being able to run even if the user is dumb enough to try some random download. Of course, you end up with complaints of other crap they need also being broken...
Python is very, very, good at being cross platform. However, as you said, hooking into platform specific features is inherently not cross platform.
I suspect that the main reason that Python was used in this application was to reduce the cost and time to write the software. It typically takes far fewer lines of code to do something in Python than it does to do it in something like C++, Java, or C#. The language also permits a development process consisting of rapid, short, iterative cycles (write a small stand alone bit of code, test it, write another small bit of code, test it, etc.). This lets someone get their virus out "onto the market" in less time, with less manpower, and with lower overall investment.
In other words, it's the same reason why Python is so popular in many legitimate fields of endeavour.
The executable was not Python code but a Winbloat executable written in Python. Outside of a few developers, I would be surprised if Python was ever installed on a Winbloat box. I suspect this is true of a Mac also.
What this seems to be is someone writing malware in Python (the language is actually unimportant) and compiling it into a platform specific executable (this case Winbloat). Other than Python being used, this is not much different than many of the other malware that are Winbloat/Mac/Linux executables.
From what I can tell, it compromises Windows when a user installs an application that they downloaded from the Internet. I assume that traditional methods of containing this type of threat will continue to be as effective as they have been in the past I.e. Restricting admin rights, up-to-date AV software, user education
As for the Python element? I can't recall a scripting language (compiled or otherwise) ever being used to install software...
Will it require 2.7 or 3.3? If I get a request to update python should I look closer? Clearly just because a language is cross enviroment doesn't mean a compiled executable is. Look at the so called UWP.
No matter what the source, most infections still rely on the "I Agree" click.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
