Re: [Linux-users] shell shock, one more time..
On Sat, Sep 27, 2014 at 11:38 AM, Volker Kuhlmann list0...@paradise.net.nz wrote: Anything your router exposes to the Internet is a valid attack surface. You are at the whim of the router's firmware, too often proven to be insecure and non-patchable (vendors don't give a toss). Just because you can't see anything easily on the outside of your router doesn't convince me, there are substantial access methods there for use by the telco. Devices provided by the Telco itself are usually exposing management interfaces back to them - I know that this is a pervasive problem in places like the US, but I have no specific data about NZ practices, and to be honest I've never used any device the ISP has delivered to me, except for diagnostics. That'll probably change when I get fibre installed -( I have a separate SSID for family visitors to use, for example. Is this separate SSID provided by the same wifi AP? Different AP, different subnet, routed to the Internet directly. If you started adding manual routes you could get through to the other internal network, I think. I originally wanted to do it all off the same kit and VLAN the traffc, but at the time my pfSense was old and not playing well. These days I'd rather have duplicate devices than a complex software setup - it means I have less to remember :-) -jim ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
On Fri, 2014-09-26 at 10:01 +1200, Derek Smithies wrote: Chris, thankyou for stating what can be achieved with minimal effort.. So - is my ADSL box exploitable - which has linux inside it? presumably not - my ADSL box refuses html and ssh login access from the wild. Won't your ADSL box be running busybox, not bash? -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
Another gotcha to note, which I've picked up from this one because I look after a lot of cloud stuff these days.. Rackspace repo mirrors are lagging behind, AWS ones are OK for Centos and RH and Debian but Ubuntu not so much. linode were quick with the first one but this latest is not there yet for RH el6.4 or Debian. The moral: Use the distribution primary mirrors for security updates. Another interesting one of interest, which might be AWS specific. I couldn't get a group of servers at AWS Sydney datacenter to update from the ipv4 addresses of the debian repo. IPv6 was fine. I'm sure that's just the thin end of the wedge there, and will be a growing trend. (I look after six clusters now that are IPv6 only, so if you've not already, read up on icmpv6 firewalling and neighbour dicovery, it's the new pain. :-) ) And, in case anyone is interested: Joyent (Illuminos/smartos) are 24 hours behind as usual. Solaris if you've not paid up support you wont get it for a few days, or have to go from source. BSD are smugly keeping up to date as usual. :-) Cheers, Chris H. On 26/09/14 10:06, C. Falconer wrote: Chris Hellyar wrote, On 26/09/14 09:42: 0918 this morning Debian released a patch for the patch. :-) For those not watching this is great viewing. A gotcha - its not (yet) listed in debian Jessie or Sid. So you have to manually get the older version and install it. http://security.debian.org/debian-security/pool/updates/main/b/bash/bash_4.2+dfsg-0.1+deb7u1_amd64.deb -- CF ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
Hi, thanks Chris for the explanation. That does help. Cheers, Derek. On 26/09/14 10:36, Chris Hellyar wrote: Per what Steve said... Bash would be pretty uncommon on embedded devices, they tend to use busybox. The current published/known exploit/vector from this is via apache, with cgi enabled and a cgi script using bash as it's interpreter. so... a2dismod cgi on your deb/ubuntu boxes with apache, and whatever the equiv. is on RH, can't think of it for the mo.. That will fix that vector. Or just not having any CGI scripts that use bash of course. (easier said than done if you run one of the hosting console tools like plesk etc per the other comments yesterday. At this stage there doesn't appear to be another vector and it's useless as a local exploit anyway as it doesn't give you privilege escalation which is what you're looking for if you've already got access to a machine. What it does do is allow you to remotely force the download of an arbitrary binary / script which can then have it's merry way with your box. There is chat on one of the darker shaded IRC channels about delivering the spike ddos toolkit via shellshock, which if you were of that persuasion might not be a had way to go. Cheers, Chris H. On 26/09/14 10:01, Derek Smithies wrote: Chris, thankyou for stating what can be achieved with minimal effort.. So - is my ADSL box exploitable - which has linux inside it? presumably not - my ADSL box refuses html and ssh login access from the wild. Yes - it might be, if someone inside my network does html access to the box and somehow gets to a shell with some buffer overrun attack. So - does this mean that any web server (which is subject to buffer overrun attacks) that eventually leads to shell access is vulnerable? However, in these days ofbetter code/ standard string types that don't have overrun issues/ python servers/how much is overrun a problem? Noone on this list is involved in hacking to destroy a remote web server, but we do have an interest in getting our servers secure. So when testing a server, what are the things (in the light of this exploit) that one could do to get into the box? Since one knows how to get in, one knows how to secure it. == My problem is that I read reviews on the net, and wonder a)how factual it is b)how much the author is hyping the reports to get a higher page hit rate and get more dollars from the advertisers c)how much the author hates unix/linux. Thanks, Derek. On 26/09/14 09:42, Chris Hellyar wrote: 0918 this morning Debian released a patch for the patch. :-) For those not watching this is great viewing. It's also quite scary how easy it was to build an exploit for this one. It took me about 15 minutes last night to build a shell script that could exploit a bash script on a remote server to download and execute arbitrary script/executable on the target machine. The last few major ones it's taken at least a few hours hunting around for source and preconditioning / setup would normally take multiple scripts. This one is single script, no set up required. Cheers, Chris H. ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users -- Sent from my Ubuntu computer ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
On Fri 26 Sep 2014 10:01:52 NZST +1200, Derek Smithies wrote: So - is my ADSL box exploitable - which has linux inside it? presumably not - my ADSL box refuses html and ssh login access from the wild. Oops. Presumably yes. http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/ Robert Graham of Errata Security, [...] However, everything else probably is. Scan your network for things like Telnet, FTP, and old versions of Apache (masscan is extremely useful for this). Anything that responds is probably an old device needing a bash patch. And, since most of them can't be patched, you are likely screwed. A lot of wireless routers shell out to ping and traceroute – these are all likely vulnerable. However, in these days ofbetter code/ standard string types that don't have overrun issues/ python servers/how much is overrun a problem? On your server, as much/little as ever. On your little turn-key boxes, you are likely screwed. Will Bruce Schneier rate this an 11 again, on a scale from 1 to 10? So when testing a server, what are the things (in the light of this exploit) that one could do to get into the box? Since one knows how to get in, one knows how to secure it. Nope. You might find out how to get in to your ADSL/wifi//whatnot, but that still doesn't tell you how to secure it (other than by taking the whole box to the dump). This is the main reason why all this consumer shite couldn't be further away from being a security device, whatever else it may be, like a splendidly easy MITM facilitator. I know only one company that supplies updates for their modems in a timely fashion - AVM for their Fritzboxes. The rest doesn't even understand the word update, never mind timely. Borrowing from an old saying about some other company: The only secure consumer electronics product is the one still shrink-wrapped on the shelf. Volker -- Volker Kuhlmann http://volker.top.geek.nz/ Please do not CC list postings to me. ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
Jim, You have me here. You wrote:: Beware of rogue DHCP responses on your local networks, too - most Linux runs the shell as part of dhclient. https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ The proof of concept above seems a little strange. The person running the dhcp server puts some illegal code into one of the configuration areas. Seems like the admin person was out to attack his own network. Wow. However, is this proof of concept saying that if the non admin person can get to the configuration area of a DHCP server and then do some nefarious things? really? Surely, if a non admin person can get to the config area of a DHCP server, you have bigger issues than shell shock. So - this leaves a bit perplexed as to how someone outside my home network can take advantage of the fact that my adsl box runs busybox (well, it is probable, and that is the considered advise of this list). Presumably - they get in via a corrupted email on a windows/linux box and then do whatever. But that attack vector has never changed. The adsl box at my house has no outside web page, or ssh/sftp/ftp/telnet service. So what am I missing. I guess what I am trying to work out is why is the advise of some on this list that my adsl box is a security issue with this shell shock thing. Cheers, Derek. === On 26/09/14 11:10, Jim Cheetham wrote: On Fri, Sep 26, 2014 at 10:36 AM, Chris Hellyar ch...@trash.co.nz mailto:ch...@trash.co.nz wrote: The current published/known exploit/vector from this is via apache, with cgi enabled and a cgi script using bash as it's interpreter. Or any execution environment (mod_perl, PHP, etc) that runs code that uses the shell to run a command, e.g. `cmd` or system(cmd) - if /bin/sh points to /bin/bash you are potentially vulnerable, or if the code explicitly runs bash. Debian doesn't do this, they point the default shell to dash instead. RedHat does point to bash, and you can't trivially change it. Beware of rogue DHCP responses on your local networks, too - most Linux runs the shell as part of dhclient. https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/ I don't yet know of Android or iOS are vulnerable to DHCP shellshock. -jim ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users -- Sent from my Ubuntu computer ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
On 26/09/14 11:22, Steve Holdoway wrote: so... a2dismod cgi on your deb/ubuntu boxes with apache, and whatever the equiv. is on RH, can't think of it for the mo.. That will fix that vector. Or just upgrade to nginx... well, there is that... :-) I was a bit resistant but I'm warming to it. There is some definite conversion pain for some apps/sites but for general hosting stuff it's been good to me so far. Touch wood. ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
On Fri, 2014-09-26 at 11:53 +1200, Chris Hellyar wrote: On 26/09/14 11:22, Steve Holdoway wrote: so... a2dismod cgi on your deb/ubuntu boxes with apache, and whatever the equiv. is on RH, can't think of it for the mo.. That will fix that vector. Or just upgrade to nginx... well, there is that... :-) I was a bit resistant but I'm warming to it. There is some definite conversion pain for some apps/sites but for general hosting stuff it's been good to me so far. Touch wood. Total convert here. Apart from anything else, you can analyse and tune the web server and server side processing separately ( if PHP, then you can properly use APC as well, which is even better ). And, as a free bonus, the devs can fiddle with .htaccess to their hearts delight, but it's not going to make any difference (: Steve -- Steve Holdoway BSc(Hons) MIITP http://www.greengecko.co.nz Linkedin: http://www.linkedin.com/in/steveholdoway Skype: sholdowa ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
On 26 September 2014 12:06, Chris Hellyar ch...@trash.co.nz wrote: While I don't disagree with the statement that any execution environment can be used to get the result from the flawed version of bash, the remote exploit is via apache/cgi at this stage and exploiting it via php/pearl/python would be of little value to attacker as it would be a low value secondary vector. As long as any of those calls 'system()' and system is implemented in terms of 'sh -c' and 'sh' is a symlink to bash, ( a very common arrangement ), env based exploits will still work here as soon as a bash instance is fired. Because ENV is implicitly inherited by those languages, and passed on to their children during fork+exec , ENV becomes an open conduit for malicious code and the intermediate languages of any kind simply work as naive carriers unless they explicitly filter out ENV they inherit. So all you need is a top level somewhere that stores user specified values in any ENV field. And that may not even require CGI binaries in some cases, but it is the most likely way you'll see it. ( ie: Hypothetically, if Apache simply inflated arbitrary ENV keys from HTTP requests within the Apache process itself, and then subsequently called bash inside the same process for any reason in such a way those ENV was inherited, your pooch is screwed ) And worse, this can all take place *prior* to authentication taking place, as authentication may requires the authentication tokens to be passed via ENV. SSH is a harder target because the vulnerability doesn't trigger until the channel is activated and authorised and then the ENV leaks over the connection once established. There may be some hype to this, but given we don't know a lot about the reality of this problem, considering we just discovered it after it being out there for well over 20 years, I think its better to err on the side of caution and assume vulnerability until some kind of confidence is offered to the contrary. ( You can never prove something invulnerable, and you cant ever make anything completely invulnerable ) -- Kent *KENTNL* - https://metacpan.org/author/KENTNL ___ Linux-users mailing list Linux-users@lists.canterbury.ac.nz http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
Re: [Linux-users] shell shock, one more time..
(Sorry long post. :-) Hmmm, You're not wrong, but polluting the environment before the webserver starts or after it's running is a different proposition from injecting into the environment in a single pass with predictable results. What makes the cgi vs shellshock exploit viable is that that cgi module sets a chunk of the environment from the get/post request. A quick reasoning: php code, run on debian/apache/php, called from my desktop with chrome: ? system(bash -c set); ? gives the following: - APACHE_LOCK_DIR=/var/lock/apache2 APACHE_LOG_DIR=/var/log/apache2 APACHE_PID_FILE=/var/run/apache2.pid APACHE_RUN_DIR=/var/run/apache2 APACHE_RUN_GROUP=www-data APACHE_RUN_USER=www-data BASH=/bin/bash BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() BASH_EXECUTION_STRING=set BASH_LINENO=() BASH_SOURCE=() BASH_VERSINFO=([0]=4 [1]=2 [2]=37 [3]=1 [4]=release [5]=i486-pc-linux-gnu) BASH_VERSION='4.2.37(1)-release' DIRSTACK=() EUID=33 GROUPS=() HOSTNAME=localweb HOSTTYPE=i486 IFS=$' \t\n' LANG=C MACHTYPE=i486-pc-linux-gnu OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/local/bin:/usr/bin:/bin PPID=3179 PS4='+ ' PWD=/data/www SHELL=/bin/sh SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 TERM=dumb UID=33 _=/bin/bash - But if we run: #!/bin/bash echo Content-type: text/html echo set using the cgi module on the same box we get: -- BASH=/bin/bash BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interactive_comments:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() BASH_LINENO=([0]=0) BASH_SOURCE=([0]=/usr/lib/cgi-bin/test.sh) BASH_VERSINFO=([0]=4 [1]=2 [2]=37 [3]=1 [4]=release [5]=i486-pc-linux-gnu) BASH_VERSION='4.2.37(1)-release' DIRSTACK=() DOCUMENT_ROOT=/data/www/abh.tips EUID=33 GATEWAY_INTERFACE=CGI/1.1 GROUPS=() HOSTNAME=localweb HOSTTYPE=i486 HTTP_ACCEPT='text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' HTTP_ACCEPT_ENCODING=gzip,deflate,sdch HTTP_ACCEPT_LANGUAGE='en-GB,en;q=0.8,en-US;q=0.6,da;q=0.4,th;q=0.2,es;q=0.2' HTTP_CONNECTION=keep-alive HTTP_COOKIE=ci_session=a%3A5%3A%7Bs%3A10%3A%22session_id%22%3Bs%3A32%3A%22356aa658fa2fdd81040e78f71578c9a9%22%3Bs%3A10%3A%22ip_address%22%3Bs%3A10%3A%2210.86.1.20%22%3Bs%3A10%3A%22user_agent%22%3Bs%3A105%3A%22Mozilla%2F5.0+%28X11%3B+Linux+x86_64%29+AppleWebKit%2F537.36+%28KHTML%2C+like+Gecko%29+Chrome%2F37.0.2062.120+Safari%2F537.36%22%3Bs%3A13%3A%22last_activity%22%3Bi%3A1411707427%3Bs%3A9%3A%22user_data%22%3Bs%3A0%3A%22%22%3B%7D32a5dc82bfef3aa2e944df2d060e56e7 HTTP_HOST=10.86.1.114 HTTP_USER_AGENT='Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.120 Safari/537.36' IFS=$' \t\n' MACHTYPE=i486-pc-linux-gnu OPTERR=1 OPTIND=1 OSTYPE=linux-gnu PATH=/usr/local/bin:/usr/bin:/bin PIPESTATUS=([0]=0) PPID=2104 PS4='+ ' PWD=/usr/lib/cgi-bin QUERY_STRING= REMOTE_ADDR=10.86.1.20 REMOTE_PORT=35052 REQUEST_METHOD=GET REQUEST_URI=/cgi-bin/test.sh SCRIPT_FILENAME=/usr/lib/cgi-bin/test.sh SCRIPT_NAME=/cgi-bin/test.sh SERVER_ADDR=10.86.1.114 SERVER_ADMIN=webmaster@localhost SERVER_NAME=10.86.1.114 SERVER_PORT=80 SERVER_PROTOCOL=HTTP/1.1 SERVER_SIGNATURE=$' Apache/2.2.22 (Debian) Server at 10.86.1.114 Port 80 \n' SERVER_SOFTWARE='Apache/2.2.22 (Debian)' SHELL=/bin/sh SHELLOPTS=braceexpand:hashall:interactive-comments SHLVL=1 TERM=dumb UID=33 _=echo Now we have the inclusion of all the direct-from-web stuff... including my agent string for chrome on Linux. So you replace the agent string with a valid bash function and when the CGI call passes to bash with that in the environment it executes. Directly injected from the web. While it's possible to do a proof of concept by creating the environment prior to starting apache or before the system() call in PHP (Same goes for perl etc) that would require exploited/malicious code on the server to achieve the desired result. If you've already got access to the box to put the malicious code there so there's no point in using a bash environment exploit as a secondary vector. You'd be running a discovery script/toolkit on the box and deciding if you'll harvest or farm, then getting out of there. Piddling about with secondary exploits is possible, but in 99.99% of cases is not going to happen. It leaves artifacts that will reduce the amount of time the attacker has have to play after a script/bot has found the targets for them. Me thinks you need to think like a hacker, of the nefarious kind, rather than a hacker of the developer kind to see my point of view though. :-) Cheers, Chris H. On 26/09/14 16:06, Kent Fredric wrote: On 26 September 2014 12:06, Chris Hellyar ch...@trash.co.nz mailto:ch...@trash.co.nz wrote: While I don't disagree with the statement that any execution environment can
