puush hacked

[Beric]

Well we are talking about migration from Imageshack. 

[Gladz]

Detailed Analysis of Events (2015-03-30)

Spoiler

What happened?

If you were online and using the puush client for Windows on March 29 between 18:51-21:41 UTC, there is a chance that malware disguised as a puush update made its way to your computer. The Mac and iOS clients were not affected.

What should I do?

The latest version of puush cleans the malware (r100). If you wish to know whether you were affected, or have already uninstalled puush, you can use our stand-alone cleaner/checker to check whether you need to take further action.

If your PC was affected, treat any saved passwords on your system as compromised and change them immediately. This includes passwords saved in Mozilla Firefox, Mozilla SeaMonkey, Internet Explorer (including IE10/Windows 7 vault), Opera, Google Chrome, Windows Live Messenger, GAIM/Pidgin, Outlook and Mozilla Thunderbird. Note that if you had a master password set or used an external/plugin-based password manager, it is probable that your passwords are still safe.

How did this happen and what are you doing to prevent this from happening again?

Two primary failures occurred. Firstly, a web server was breached. As the investigation of the breach is still ongoing, we don’t wish to release further details until this is complete. However, we have since firewalled the affected servers and are building fresh replacements.

Secondly, the puush update system on Windows doesn’t verify the authenticity of the downloaded updates, which allowed a malicious version to be distributed. In a coming update, we will add a feature to verify the downloaded updates. An option to disable automatic updates will also be added.

Can you go into more detail?

On March 29 at 18:51 UTC, a puush web server was compromised and a malicious update to the Windows puush client (r94) was planted. This modified client was only altered to retrieve and execute malware, it otherwise behaved the same as puush. The malicious update was then distributed via puush’s auto-update system.

At the same time, a GeoIP-based redirect was put in place to forward users from Japan to the original, unmodified files. This was most likely in effort to hide the malware from us (as we are currently in Japan). As a side-effect, users in Japan were not affected.

At 21:41 UTC the breach was noticed and the affected web server was immediately shut down to cease distribution of the malicious update.

puush checks for updates when it runs. After this, the longer it’s open, the less frequently it checks (after 30 minutes, 1 hour, 2 hours, 4 hours, and then finally every 6 hours). Because of this, not all online users at the time were affected - only those that were unlucky enough to check within the ~3 hour window above. Therefore, if your pc was on and running puush for a long period of time, you were the least likely to be affected.

We investigated the malware in a sandboxed environment and wrote a cleaner to remove the malware, targeting the loader (puush.daemon.exe). We determined that this was sufficient to remove the malware and prevent it from reappearing.

At 01:13 UTC, we released an updated puush client with a built-in cleaner and also a stand-alone version of the cleaner. Due to how puush updates worked (as described above), the newly updated puush client would have been more frequently checking for updates. This meant that the earliest infected clients (potentially at 18:51 UTC) would have been replaced by the r100 cleanup build at 22:21 UTC.

Simultaneously, in the interest of ensuring the safety of our users, we reached out to @marcan42 for assistance in analyzing the malware’s payload. The malware was determined to be a variant of the popular NetWire RAT (a Remote Access Trojan), that is, software that gives the attacker control over your computer. Its distinctive feature seems to be the ability to steal passwords, though it can also perform other typical remote control operations on demand. Without input from its command and control server, the malware is effectively harmless and does nothing.

His detailed findings for those so inclined:

The malware loader is delivered as an EXE file (241664) with the following hashes:

SHA-1: 752c880c4c47581d97f6f5261146e22d0587b20f

MD5: b4e349c935914a62ea1c1ead0bf8271e

When installed, a one-byte modification is made to the EXE, yielding the following hashes:

SHA-1: 52ed84bff5b63a65e015e1762df27912c1e675df

MD5: e61335f59996598d1b5b7ea7e13222ce

The loader is an obfuscated VB6 application. As part of standard VB6 app startup functionality, it creates one temporary file in %TEMP%. This is unrelated to the malware functionality and can be safely ignored. The VB6 code calls further obfuscated code that deobfuscates the rest of itself in-place and then performs debugger checks. If a debugger is detected, or the Avast hook DLL (shnxhk.dll) is loaded into the process, it attempts to exit (but, due to a bug, will actually crash). The process will also attempt to exit, but crash, if the CPU does not support MMX instructions (users running puush on a 486 or original Pentium are safe from the malware).

When run, the obfuscated loader first copies itself into %APPDATA%\puush\puush.daemon.exe (on Windows XP, this will typically be C:\Documents and Settings\{username}\Application Data\puush\puush.daemon.exe, while on newer versions it will typically be C:\Users\{username}\AppData\Roaming\puush\puush.daemon.exe). Some users have reported an installation path in C:\Program Files, which may be the result of an uncommon APPDATA setting. The copy is slightly modified: one byte at offset 0x3AFF4 is changed from 0x00 to 0xCC (this appears to serve no purpose, as that byte is not checked). It then creates a registry key (HKCU\Software\Microsoft\Windows\CurrentVersion\Run\puush daemon) pointing to the installed exe, to start itself when Windows boots up, and then re-launches itself from the target location.

On launch from the target location, it deobfuscates its EXE payload in memory and uses a standard Windows process injection trick to run the payload from memory, avoiding writing it out to disk. To do so, it needs to spawn a dummy host process, for which it uses its own executable (puush.daemon.exe) (there is code present to use the system default web browser instead, but it is disabled). After launching its payload, the loader sticks around and attaches to it as a debugger, performing certain memory management duties. This appears to be simply a more sophisticated variant of the usual process injection trick, likely related to DEP functionality, and is otherwise unrelated to malicious functionality. The loader/debugger exits when the child exits.

The end result is that two processes are created: a parent named “puush.daemon.exe” and a child with the same name. The parent is the loader, and the child is the payload. Killing the child will make the loader exit, but the child will continue running if only the loader is killed. The removal tool will always kill both.

The payload EXE may be extracted from puush.daemon.exe with the following Python script:

#!/usr/bin/env python

d = open("puush.daemon.exe").read()

a = d.index("pw4k")

b = d.index("pw4k", a+4)

c = d.index("pw4k", b+4)

x, y = d[a+4:b], d[b+4:c]

with open("payload.exe","w") as fd:

fd.write("".join(chr(ord© ^ ord(x[i%len(x)]))

for i,c in enumerate(y)))

The payload is 83456 bytes long and has the following hashes:

SHA-1: f40a64efee732466a86d557c1309ea44f89adc3c

MD5: ef98164367c1ea47db15085d911b9793

This payload is a variant of the NetWire RAT (Remote Access Trojan). Since the loader is in charge of persistence, all of the built-in NetWire persistence features are disabled. The keylogging functionality is also disabled (and cannot be re-enabled remotely, other than by downloading a new version of the entire program). Most local persistence and data features (e.g.) log files are also permanently disabled.

NetWire is configured using the following settings (which are obfuscated using the RC4 cipher):

Command and control host: herd.suid.at:42069

Reconnect delay on connection error: 10 seconds

Connection mode: direct, no proxy

Host identifier: “sheep-%Rand%”

Mutex: disabled (“-”)

Persistence/local install: all disabled

Keylogger: disabled

Password/comms encryption key: “;wjg0-a29-fno23ty0b4b2”

Upon startup, due to a bug in the code, NetWire attempts to create a mutex named “-” (even though mutex functionality is disabled), but does not exit if it already exists. Next, it creates a single encrypted and hidden “.Identifier” file in the same directory as the executable, containing information about the machine and some random identification data.

Next, it goes into a loop that repeatedly tries to connect to the command and control server, retrying with a 10 second delay between failed connections. Upon a successful connection, it performs an encryption handshake and then starts handling commands received from the server.

The RAT commands can perform the following actions:

Initialize and register/report identification info to the server

Remove itself

Fetch files via HTTP to the local system

Execute files

Get information about available local drives

Read, write, create, copy, move, and delete local files and directories

Launch a remotely controlled shell (cmd.exe)

List the users logged in to the system

List processes and kill processes

List windows and control them (show/hide, send message, set window text)

Send virtual keypresses and mouse actions

Take a screenshot

Steal browser, e-mail, and IM credentials

Create a proxy connection to another host

Report MD5 checksums of local files and directory trees

List network connections (netstat)

Read and write the registry

The credential stealing functionality supports the following applications:

Mozilla passwords (signons.sqlite and logins.json) for:

Mozilla Firefox

Mozilla SeaMonkey

Mozilla Thunderbird (email credentials)

IE credentials:

HTTP BASIC authentication credentials via advapi Cred API

Autocomplete passwords/data for all sites that exist in the user’s history

IE10/Win7 Vault credentials

Opera credentials:

wand.dat for the default profile (for older versions of Opera)

“Login Data” database (for newer WebKit versions)

Google Chrome and Chromium credentials (“Login Data” DB for the Default profile only)

Windows Live Messenger credentials (via advapi Cred API)

libpurple (GAIM/Pidgin) accounts.xml credentials

Outlook credentials (POP3, IMAP, HTTP, SMTP settings, via registry)

 

The RAT directly accesses files and the registry (or the relevant Windows APIs), so if passwords are protected by a master password (e.g. in Firefox and Thunderbird if enabled) then they should remain safe if the password is strong, as it makes no attempt to dump any in-memory credentials. Passwords protected only by OS APIs (e.g. Google Chrome and IE) are always vulnerable.

An exhaustive list of implemented commands is available here.

A third-party tool to decrypt NetWire traffic is available, though we have not tested it with this variant.

Final Words

We thoroughly apologise for what has occurred. It could have been avoided had correct measures been taken. puush has always been a side-project for us, and thus we have not been able to give it the attention it deserves. The user count has consistently been increasing on its own; at the same time, we have not had the time or resources to improve and maintain the service to a level of high quality we ourselves expect.

Going forward we will do our best to ensure puush is a service you can continue to use in your daily life. We understand if you are no longer a user of the service (trust is hard to regain), and recommend ShareX as an alternative if you decide to stray from puush.

If you have any further questions, please reach out to us on twitter.

Sincerely,

the puush team

sauce: http://puushstatus.tumblr.com/post/115160990852/detailed-analysis-of-events-2015-03-30

 

Firefox wins again. I'm re-downloading.

Edited April 6, 2015 by Gladz

[Jake]

>muh runescape screenshots

[Gladz]

>muh runescape screenshots

ben tinkn bout u bae