Gelatin again
Continuation of the history of the study of the "virus" of gelatin, aka Storm Worm, aka Peacomm, and so on. See the beginning in the last issue .
So, gelatin. Hm Again.
The first thing I encountered was the absence of any technical information about gelatin. Google, of course, sends straight to Wikipedia [WIKI]. Here we learn a little.
')
1. The virus includes infected machines in the botnet [WIKI1];
2. The gelatin network is a modification of the Overnet network.
A little history of gelatin in Russian is also contained in [KASP].
Understanding how Overnet works is the basis for further fights. Therefore, in this issue we will study this framework.
After going a few links, I found a description of the gelatin network [PPT]. Attempts to find ready-made sales of Overnet customers have also been crowned with success [KADC]. One glance at the KadC library was enough to recognize the vague features of the dismantled valentine malware code. Even with some changes, but the KadC code in the field can be a base for gelatin. Only this reason can explain the completely arrogant statement of McAffee specialists:
[MCAF] is also discussed in [CNET1] and [ASHIMMY]. I would very much like to draw the attention of comrades from McAffee that it would be nice for them to expand their view of the world by including the brave MIT scientists who developed Kademlia in the accusation.
One of the most valuable resources was [REC]. There you can take the original version of one of the very first gelatins. Then it was almost a normal :) encrypted executable file, traces of which were carefully conspired by the rootkit driver. The advantage of the first versions is that they do not create messages, and therefore wireshark will be able to decode them in edonkey format.
By the way, about the "obxoren" traffic. The fact is that the penultimate type of gelatin (and the latter, as we know, was distributed on the first of April), creates ordinary messages that are understandable to both past modifications and to Overnet customers, by the way. But before sending it is traversed by it xor, using a hard-coded table. The fact that only representatives of the “valentine strain” are able to process the traffic of their “brothers” indicates a decrease in the size of the botnet, which is based on this modification [HAC]. There were other, earlier data that Bonet was divided into several small [ZD].
Strictly speaking, gelatin and others like it ... er ... programs ... are not viruses. They do not infect files on local media, they do not commit destructive actions. They only :) spread themselves, spam, participate in dos-attacks and, probably, do something else [SCH]. Obviously, first of all you need to find out how individual instances of gelatin communicate with each other.
Gelatin uses the Overnet [WIKI2] network, which is a realization of the idea of Kademlia [WIKI3], a model of a distributed hash table developed at MIT, this is not good for you. The main combat unit of the network is the node, peer. The primary task of any conscious node is first of all to enter the network. For this, gelatin has a list of nodes to which it tries to connect first. In the first versions this list was hardcoded right in the body of the virus, in the last versions it was also hardcoded in the body, but it was extracted and stored in the ini file. Without it, - without a file, - by the way, valentine gelatin refuses to work. The addresses of the nodes of the "first circle" are written approximately as follows:
where the number before the sign is different - this is the OvernetID (oid), or the hash of the node, a 128-bit number that is generated as if randomly generated. In detail we will talk about it later. Following the sign are the IP address (BE56062A = BE.56.06.2A = 190.86.5.42), the port (5DC6 = 24006) and the last byte is the type of the node.
The first (and most frequently used) message that the new node sends to other nodes is “PUBLICIZE”. This is a kind of ping, with which the parties make sure that each other is available. This message is strongly referred to in some sources as “HELLO”. Inside it is sent the oid of the sending node, its IP address, port and type. In general, the same data as in the ini file.
After the new node has made sure that the addressee is available and responded (the “PUBLICIZE_ACK” message, two bytes long — the header and the message code), it sends a CONNECT request. The message structure is identical to the “PUBLICIZE” message. In response to this message, the receiving party
1. Sends a list of nodes known to him and
2. adds the sender to this list (and, accordingly, will send the “new” address in response to the new “CONNECT”).
The new node adds the addresses it received to its list of hosts. If you count on the fingers, the diperto.ini in the composition of the valentine gelatin contained the addresses of 823 nodes. And if at least half answered twenty addresses, then ... Fortunately, the gelatin is written "correctly." The size of the list of known nodes is limited to 1024 elements.
The next step is to find out what address our node looks like for the destination node. To do this, gelatin opens the tcp port and starts listening to it. He transmits the port in the IP_REQ message, to which the recipient receives this message responds with the IP_REQ_RES message with the address from which he received this message. This is done to bypass the limitations of NAT and firewalls.
This completes the process of connecting to the network, but the gelatin will continue to ping with great frequency the nodes from its list in order to promptly remove those that for some reason have become unavailable.
By the way, in order to stop the cycle of processing incoming messages, it is enough to send him the number 74BE2A5Dh. This is not a bug - he sends it to himself to complete the work. Perhaps, even for upgrading your executable code, but the fact is that gelatin works, but completely refuses to process incoming messages. Such a clumsy method can be tried to neutralize it on infected machines.
So, the following messaging followed (Z - Gelatin, H - host):
Z → PUBLICIZE → H
Z ← PUBLISIZE_ASK ← H
Z → CONNECT → H
Z ← CONNECT_RES ← H
Z → IP_REQ → H
Z ← IP_REQ_RES ← H
Now let's make a small lyrical digression on the subject of the main goal of the Overnet network as a distributed hash table. The main purpose of the network is to exchange files, or rather publish data about files and their location in such a way as to speed up the search. Simplified, this scheme looks like.
A host that needs to publish some data computes an MD4 hash of the file contents (or keywords, depending on what information is being published), then searches for the node whose OID is closest to that hash. (The degree of proximity is determined by the result of the XOR operation, which, as we know, returns zero for identical bits. That is, for absolutely identical hashes, we get zero). To do this, the publisher sends a SEARCH message that contains the desired hash to all hosts from its list. The nodes that received such a message find several (?) Addresses from their lists, in descending order of proximity, and send back this list with the message SEARCH_NEXT. The search ends if the node sends its own address inside SEARCH_NEXT. Meta-data and data about the site from which this file can be downloaded are published separately.
In the same way, but in the other direction, the search also occurs. The hash is calculated in a certain way, and then the exchange is SEARCH-SEARCH_NEXT, after which the TCP connection parameters are determined, after which the file is downloaded.
In the simplest version, the gelatin finds the right host, downloads a list of emails from it and starts spamming.
For example, like this:
a href = "mailto:" is not my invention, for some reason automatically substitutes (
About what specifically and how looking for gelatin in the network, let's talk in the next issue.
Literary.
So, gelatin. Hm Again.
The first thing I encountered was the absence of any technical information about gelatin. Google, of course, sends straight to Wikipedia [WIKI]. Here we learn a little.
')
1. The virus includes infected machines in the botnet [WIKI1];
2. The gelatin network is a modification of the Overnet network.
A little history of gelatin in Russian is also contained in [KASP].
Understanding how Overnet works is the basis for further fights. Therefore, in this issue we will study this framework.
After going a few links, I found a description of the gelatin network [PPT]. Attempts to find ready-made sales of Overnet customers have also been crowned with success [KADC]. One glance at the KadC library was enough to recognize the vague features of the dismantled valentine malware code. Even with some changes, but the KadC code in the field can be a base for gelatin. Only this reason can explain the completely arrogant statement of McAffee specialists:
"Bot technology is rapidly evolving, often aided and
abetted, unfortunately, by the open-source movement. ”
[MCAF] is also discussed in [CNET1] and [ASHIMMY]. I would very much like to draw the attention of comrades from McAffee that it would be nice for them to expand their view of the world by including the brave MIT scientists who developed Kademlia in the accusation.
One of the most valuable resources was [REC]. There you can take the original version of one of the very first gelatins. Then it was almost a normal :) encrypted executable file, traces of which were carefully conspired by the rootkit driver. The advantage of the first versions is that they do not create messages, and therefore wireshark will be able to decode them in edonkey format.
By the way, about the "obxoren" traffic. The fact is that the penultimate type of gelatin (and the latter, as we know, was distributed on the first of April), creates ordinary messages that are understandable to both past modifications and to Overnet customers, by the way. But before sending it is traversed by it xor, using a hard-coded table. The fact that only representatives of the “valentine strain” are able to process the traffic of their “brothers” indicates a decrease in the size of the botnet, which is based on this modification [HAC]. There were other, earlier data that Bonet was divided into several small [ZD].
Strictly speaking, gelatin and others like it ... er ... programs ... are not viruses. They do not infect files on local media, they do not commit destructive actions. They only :) spread themselves, spam, participate in dos-attacks and, probably, do something else [SCH]. Obviously, first of all you need to find out how individual instances of gelatin communicate with each other.
Gelatin uses the Overnet [WIKI2] network, which is a realization of the idea of Kademlia [WIKI3], a model of a distributed hash table developed at MIT, this is not good for you. The main combat unit of the network is the node, peer. The primary task of any conscious node is first of all to enter the network. For this, gelatin has a list of nodes to which it tries to connect first. In the first versions this list was hardcoded right in the body of the virus, in the last versions it was also hardcoded in the body, but it was extracted and stored in the ini file. Without it, - without a file, - by the way, valentine gelatin refuses to work. The addresses of the nodes of the "first circle" are written approximately as follows:
00003D6C8F338A3FDD3DF3648666F55C = BE56062A5DC600
0100A634122F3553A046EC451061927C = 4B6EB028151500
02007E238D780D25FD5511285E2E596E = 58E941B3100A00
where the number before the sign is different - this is the OvernetID (oid), or the hash of the node, a 128-bit number that is generated as if randomly generated. In detail we will talk about it later. Following the sign are the IP address (BE56062A = BE.56.06.2A = 190.86.5.42), the port (5DC6 = 24006) and the last byte is the type of the node.
The first (and most frequently used) message that the new node sends to other nodes is “PUBLICIZE”. This is a kind of ping, with which the parties make sure that each other is available. This message is strongly referred to in some sources as “HELLO”. Inside it is sent the oid of the sending node, its IP address, port and type. In general, the same data as in the ini file.
After the new node has made sure that the addressee is available and responded (the “PUBLICIZE_ACK” message, two bytes long — the header and the message code), it sends a CONNECT request. The message structure is identical to the “PUBLICIZE” message. In response to this message, the receiving party
1. Sends a list of nodes known to him and
2. adds the sender to this list (and, accordingly, will send the “new” address in response to the new “CONNECT”).
The new node adds the addresses it received to its list of hosts. If you count on the fingers, the diperto.ini in the composition of the valentine gelatin contained the addresses of 823 nodes. And if at least half answered twenty addresses, then ... Fortunately, the gelatin is written "correctly." The size of the list of known nodes is limited to 1024 elements.
The next step is to find out what address our node looks like for the destination node. To do this, gelatin opens the tcp port and starts listening to it. He transmits the port in the IP_REQ message, to which the recipient receives this message responds with the IP_REQ_RES message with the address from which he received this message. This is done to bypass the limitations of NAT and firewalls.
This completes the process of connecting to the network, but the gelatin will continue to ping with great frequency the nodes from its list in order to promptly remove those that for some reason have become unavailable.
By the way, in order to stop the cycle of processing incoming messages, it is enough to send him the number 74BE2A5Dh. This is not a bug - he sends it to himself to complete the work. Perhaps, even for upgrading your executable code, but the fact is that gelatin works, but completely refuses to process incoming messages. Such a clumsy method can be tried to neutralize it on infected machines.
So, the following messaging followed (Z - Gelatin, H - host):
Z → PUBLICIZE → H
Z ← PUBLISIZE_ASK ← H
Z → CONNECT → H
Z ← CONNECT_RES ← H
Z → IP_REQ → H
Z ← IP_REQ_RES ← H
Now let's make a small lyrical digression on the subject of the main goal of the Overnet network as a distributed hash table. The main purpose of the network is to exchange files, or rather publish data about files and their location in such a way as to speed up the search. Simplified, this scheme looks like.
A host that needs to publish some data computes an MD4 hash of the file contents (or keywords, depending on what information is being published), then searches for the node whose OID is closest to that hash. (The degree of proximity is determined by the result of the XOR operation, which, as we know, returns zero for identical bits. That is, for absolutely identical hashes, we get zero). To do this, the publisher sends a SEARCH message that contains the desired hash to all hosts from its list. The nodes that received such a message find several (?) Addresses from their lists, in descending order of proximity, and send back this list with the message SEARCH_NEXT. The search ends if the node sends its own address inside SEARCH_NEXT. Meta-data and data about the site from which this file can be downloaded are published separately.
In the same way, but in the other direction, the search also occurs. The hash is calculated in a certain way, and then the exchange is SEARCH-SEARCH_NEXT, after which the TCP connection parameters are determined, after which the file is downloaded.
In the simplest version, the gelatin finds the right host, downloads a list of emails from it and starts spamming.
For example, like this:
220 hnicpmaa01.vnn.vn ESMTP Service (7.3.118.8) ready HELO xxxx.xxx.xxxx.com 250 hnicpmaa01.vnn.vn MAIL From: pcec-vmi-onsite@aliceadsl.fr 250 MAIL FROM: pcec-vmi-onsite@aliceadsl.fr OK RCPT TO: dmchn@hn.vnn.vn 550 RCPT TO: dmchn@hn.vnn.vn User unknown Quit 221 hnicpmaa01.vnn.vn QUIT
a href = "mailto:" is not my invention, for some reason automatically substitutes (
About what specifically and how looking for gelatin in the network, let's talk in the next issue.
Literary.
Source: https://habr.com/ru/post/25026/
All Articles