Malwarebytes How security updates can cause malicious software to be incorrectly identified

Recently, April 15, the Malwarebytes forum began to appear on the issue of malware detection. It seems that suddenly it treats some parts of the OS file and itself as malware.

C:windowssystem32sessenv.dll (Trojan.Downloader.ED)-> No action taken. [2c3c895fbbb0b97dfa37ff68d42fc63a]

C:windowssystem32upnphost.dll (Trojan.Downloader.ED)-> No action taken. [f1772bbd0a61f343e64b0463e3206898]

C:windowssystem32wcncsvc.dll (Trojan.Downloader.ED)-> No action taken. [35339a4ef07b2b0b6dc48dda8a79b749]

C:windowssystem32webclnt.dll (Trojan.Downloader.ED)-> No action taken. [3a2e0adea3c82016c46d4720f21122de]

C:windowssystem32wsmsvc.dll (Trojan.Downloader.ED)-> No action taken. [E7815F897DEE56E036FBF374E91AF60A]

Why it began to detect itself as malware, an explanation of the cause of what has been a very serious error.

C:Program Files (x86) Malwarebytes ' Anti-malwarembam.exe (Trojan.Downloader.ED)-> No action taken. [0365915779f2d16560d1a6c139cabf41]

C:Program Files (x86) Malwarebytes ' Anti-malwarembamscheduler.exe (Trojan.Downloader.ED)-> No action taken. [D29647a1b2b9b18573be363108fb42be]

C:Program Files (x86) Malwarebytes ' Anti-malwarembamservice.exe (Trojan.Downloader.ED)-> No action taken. [1e4ad612fc6f0a2c3af7ce9941c2ab55]

As you can see in the topic for http://forums.malwarebytes.org/index.php?showtopic=125127, it starts to think that some of the running processes, registry keys, and files stored on the hard disk are part of the malicious software.

But Malwarebytes developers soon released an update to fix the problem, and even provided a tool to fix the problem. As Marcin Krekinsky posted on Malwarebytes's blog, the problem was fixed in minutes-"We can get updates from our servers in less than 8 minutes."

So what's the problem? To be able to understand why, we have to figure out how the update system works to find the right malware definition file that we need. A clue comes from when the wrong signature was added and when the fix's definition file was released. From a post by a user named "Catscomputer", I found that it seemed to be an update to version "v2013.04.15.12", destroying the operating system. The update to fix the problem is "v2013.04.15.13", according to a Malwarebytes employee, named Morris Senegal, who said on the forum.

To find out what Malwarebytes did during the update, I turned on wireshark for a scratch analysis (I was writing this blog). The first thing it does is check whether the program is the latest version, and then see if there is any news (I think so, but not completely ok). All requests for updates are sent to "data-cdn.mbamupdates.com". Finally what it does is we are interested in the part that updates the definition file. It begins to request the latest definition file: Get/v1/database/rules/version.chk http/1.1.

At that time, the returned version number is "v2013.06.27.09", this version of the database I do not locally (the purpose is to ensure that my own is expired, so that the process can display the update). Using this new version information, it starts to request the information file for this definition file, which is a YAML format file that describes the size of the definition file, the hash value of the checksum after downloading, and some other metadata. The request is as follows:

Get/v1/database/rules/data/rules.v2013.06.27.09.ref.yaml http/1.1

Subsequently, the response from the update server is as follows:

Filename:rules.v2013.06.27.09.ref

Version

previous:v2013.06.27.08

current:v2013.06.27.09

Date:thu, June 2013 16:32:13 GMT

Package

size:6616865

md5:cc8b2b2ace236d10eb833d9d3b46e23a

Format:legacydb

Content

size:26780341

Md5:318dd700ef1ac0b26b2eb2cf38d90cd4

Format:legacydb

Metadata

size:323

At the time, it looked like it was doing an incremental update for this day, and its request was as follows:

Get/v1/database/rules/data/rules.v2013.06.27.08_v2013.06.27.07.ref.inc http/1.1.

I got a binary data file, like its definition file. What I want to add is that an administrator who is managing the Malwarebytes update server added some extra "x forward headers" to the response:

http/1.1 OK

Accept-ranges:bytes

cache-control:max-age=7200

content-md5:ttzbrprw2mtl+uyheyzmvw==

Content-type:text/plain

Date:thu, June 2013 16:51:37 GMT

ETag: "8b6-4e02516192100"

Expires:thu, June 2013 18:51:37 GMT

Last-modified:thu, June 2013 16:16:36 GMT

SERVER:ECACC (ams/489a)

X-ADMIN:TEDIVM was here.

X-cache:hit

X-shameless-plug:looking for a dev job? Send your resume to jobs@malwarebytes.org

content-length:2230

Connection:close

I think TEDIVM is the name of the administrator, so it fits well with the "X-shameless-plug" head.

Now, based on these updated files, we know how it works, and for the two versions of the definition files that we need, respectively, "v2013.04.15.12" and "v2013.04.15.13," we can get the following:

Get/v1/database/rules/data/rules.v2013.04.15.12.ref http/1.1

Get/v1/database/rules/data/rules.v2013.04.15.13.ref http/1.1

We got two binary data files, one size is 6294406 bytes, one size is 6294350 bytes, there's no big change in both, but it does delete something. There is a problem with these update files and they are already encrypted. I'm not going to tell you how to decrypt them, but I did some reverse-engineering analysis with a buddy with the help of a ollydbg tool, and finally we figured out how to decrypt the files. The following are the differences between the decrypted files:

Voffset=trojan.downloader.ed, 74433, 1, 6,

687474703a2f2f36342e36342e32302e35302f32373753457236372e657865, NS

Voffset=trojan.downloader.ed, 74485, 1, 14

687474703a2f2f6674702e74636d6c732e6f72672f7172415165562e657865, NS

The descriptive information here "Trojan.Downloader.ED" is the description of the problem that was previously described in the forum post. Despite the precise workings of these rules, I can't say I'm 100% sure how it's done, but that's what I understand so far:

Voffset: Some kind of offset for byte matching. Whatever it is after the equals sign is the description

74433 and 74485 seem to be digital signature identifiers,

1,6 and 1.14 seem to be some sort of range, and I'll come back and see them later.

is the binary encoding of a URI related to a malicious software on Vt.

is the binary encoding format for URIs related to Polyloader malware loader

NS: There's no clue about what this is.

I think there is an offset error or misunderstanding when applying these rules. If you use the range in the rule as the string delimiter in the byte pattern match, the range 1-6 in the first rule means "http:" and the range 1-14 in the other rule represents "http://ftp.tc". I guess at the beginning. "http:" can match every place, possibly NS is a tag, to indicate that a partial match is also possible, who knows.

I did some checking on mbam detection of malware files by first executing the linux command "Strings-el " to print Unicode characters and then looking up the string "http:" Based on the byte encoding of its output, using the grep command. Coincidentally, all of the files I've received from previous posts in the forum that were mistakenly thought to be malware contain these strings, so I think the problem may be here.

It's an interesting thing to figure out the encryption method and the actual definition file itself. I even tried to put my own byte pattern into a custom rule file to see if it worked that way, and it turned out to be true. In addition, I would like to thank the friends I deprived of sleep, you at 4 o'clock in the morning for my system made a decryption tool, you know who you are.