Things You Should Know : Wireless Hacking Basics

No t e b o o k:

The Days Reading

A u t h o r:
T ag s:

EvilSaint616
CEH, comptia, Days Reading, linux, privilege escalation, security+

Cre at e d :
URL:

25/08/2016 01:33

Up d at e d :

25/08/2016 01:49

http://www.kalitutorials.net/2016/08/things-you-should-know -wireless-hacking.html

Table of Contents

SourceURL: file://Table%20of%20Contents/
Author: EvilSaint616
1.
2.
3.
4.
5.

Things You Should Know : Wireless Hacking Basics

Facial recognition can be tricked with Facebook photos
WordPress Mail Masta Plugin 1.0 - Local File Inclusion
Ethical Hacking for Beginners: CompTIA Security+ or EC-Council CEH | Phoenix TS
Privilege Escalation on Linux with Live examples - InfoSec Resources

Things You Should Know : Wireless Hacking

Basics

SourceURL: http://www.kalitutorials.net/2016/08/things-you-should-know-wireless-hacking.html

Things You Should Know : Wireless Hacking

Basics

This is the first post in a new series of posts that don't involve any real hacking (and hence don't require that you
have Kali installed on your system), but instead explain concepts in an interesting way (at least I hope so). If you
have tried getting started into the world of hacking, but failed despite your best attempts, then this series will get
you in a position where you'll find it easier to understand any tutorials you read in the future(on this site or any
other). Note that I might use some technical jargon at some places, but would usually try to use laymen terms.
Also, this guide is an oversimplification and hence factual precision is not it's strong suit, ease of understanding is.

Pre-requisites
You should know-

Nothing really.

Post-reading
You will know -

What are the different flavors of wireless networks you'll encounter and how difficult it is to hack each of
them.
What are hidden networks, and whether they offer a real challenge to a hacker.
You'll have a very rough idea how each of the various 'flavors' of wireless networks is actually hacked.

(The last point would be covered in details in the next post)

Wireless Security Levels

Below is a (bad but hopefully helpful) analogue I'm using to explain various possible security implementations that
a wireless network may have.
Suppose you are the owner of a club. There can be many possible scenarios as far as entry to the club is
concerned :-

Open Entry

Open networks- They don't require passwords to

connect to the wireless router (access point).
1. Open entry and unrestricted usage - Anyone can walk right in. They have unrestricted access
to the dance floor, free beer, etc.
This is open network. This is only used in public places (restaurants, etc.) which offer free Internet
access to it's users (WiFi hotspots) . It's fairly uncommon to find such networks.
2. Open entry but restricted usage - Anyone can walk right in, but have to pay for drinks. For the
router's security purposes, this is also an open network. However, connecting to the wireless router
(entering the club) doesn't guarantee you unlimited access to the internet. There is another layer of
authentication. These are seen in public places (airports, restaurants, fast food joints, shopping
malls) where they let you connect to the wireless network without any password, but after that you
have an additional layer between you and the internet. This layer usually restricts your ability to
access the internet (either by bandwidth or by time). This layer can be used to charge you for the
amount of data you use.

The point to note in the discussion above is that wireless hacking usually refers to cracking the router's
password. The additional layer which might be present between you and the internet after you login is something
you'll have to deal with separately, and is not covered under wireless hacking. So, from wifi hacking perspective,
both the networks above are the same, "open", and do not require any hacking.

Stupidly Guarded Entry (WEP)

ISPs may require users to login to

their accounts to access the internet.
1. Password at door and unrestricted access - The member of the club pay a certain amount
every month, and get access to free drinks. They have to say the password at the shady looking
entrance to the club. Unfortunately, it's quite easy for anyone to overhear the password and get in.
This is WEP protected network. For a person who has Kali Linux installed on his machine, hacking
this kind of wireless network is a matter of minutes. These are easy targets. However, nowadays
it's fairly uncommon to find WEP protected networks, because of the ease with which they can be
hacked into. WPA and WPA-2 are more common.
2. Password at door but restricted access - Only members can enter, but they still have to pay
for their drinks. This is the case when the network has password and an additional layer to get
access to the internet. This is common in two cases 3.

Colleges often allocate student's IDs and

passwords using which students can access
Internet facilities offered by the institute.
1. ISP requires login - Many ISP's require users to login to their account to access the internet.
Often logging in provides an interface which lets the users see their bandwidth usage, details
of their network plan, etc.
2. Colleges/ Schools/ Offices - Many institutes provide users accounts which they use to access
the institutes' network.

Again, from the wireless hacking perspective,both the networks above are "WEP protected", and are rather simple
to hack into.

Well Guarded Entry

As far as the bifurcation into whether or not another layer of authentication is present once you have the
wireless network password is concerned, WEP and WPA cases are the same. The only difference is that
the college wireless routers have WPA instead of WEP (as a matter of fact, the two images in the section
above are from my home network tikona and my college network, and both are WPA protected. Of course
the login screen would be no different if the router was configured to be WEP protected, as these are two
independent authentication steps, and so I included those images in WEP section). Thus, this doesn't merit
further discussion. However, there's another subcategory in this that we will discuss.
1. Fingerprint and retinal scan for entry - The entry to this club is secure enough for most
purposes. Getting past this level of security takes a lot of time and efforts. Theoretically, if you're
willing to do what it takes, you may still get it. But a heist (if I may call it that) of this magnitude will
take a lot of planning, and even then, a lot depends on sheer luck. This is WPA secure network. The
only way to crack this network with dictionary or bruteforce attacks. Bruteforce attacks may take
forever (literally) depending on the length of the password, and dictionary attacks too will take
days/weeks depending on size of dictionary, and still may fail (if the password is not in the
dictionary). [More on this later]. So if you want to crack the password of a WPA network... get a
new hobby.
2. Fingerprint and retinal scan for entry, and a card which you can quickly swipe to avoid
standing in a queue since the aforementioned scans take some time - By introducing this
card the club created an alternate path for entry. While this saves time for the legitimate users, the
card can be stolen. While it's not as easy as overhearing the password (WEP), or walking right in
(open), pickpocketing a member is much easier than murder and mutilation (you really want to
enter that club if you're going that far). This is WPA with WPS enabled. WPS has a vulnerability
which allows a hacker to get a password in around 3 hours (can be more sometimes, up to 10-12
hours, but that figure is nothing compared to WPA). Just like WEP, WPS is now a well known weak
point and new routers have either disabled WEP or added some measures (like rate limiting) which
make it really hard to, well, pickpocket the members.

Bonus : Hidden entry

Any of the above clubs could have a secret entrance. Sounds cool, right? This is somewhat similar to what
we call "Security Through Obscurity". How we you get in if you don't know where the club's entrance is?
Well, while you don't know where the club entrance is, you know where the club is. You have two options1. Passive method - You go to the roof of a nearby building, take your binoculars out, and try to find
out how people enter the building. In wireless terms, you wait till a client connects to the network.
This may take a lot of time, but it's relatively safer from a forensic viewpoint (by not doing anything,
just watching patiently, you ensure that you don't leave any clues behind which may later be used to
catch you).
2. Active method - You cut off the electric/water supply to the building, or maybe somehow trigger
the fire alarm. One way or the other, force the members to get out of the club. Once they find out
that everything is fine, they'll swarm back in. You will know where the gate is. In wireless terms,
you can de-authenticate the clients (you'll be doing this often, whether you're hacking a WEP
network, or getting a WPA handshake [again, more on this later]). Off course, this method results in
you leaving behind some traces, but at least you don't have to wait for hours.

Summary

The analogue of hidden entry clubs are hidden networks. As long as the network has clients, it's quite easy
to find out the name of the network (SSID to be precise, setting the network to hidden basically stops the
access point from revealing it's SSID). However, when a client connects to the network, beacon frames
(date packets) with SSID (in clear-text, i.e. unencrypted) are transmitted, which you can capture and get
the SSID of the network. So, hidden networks don't really offer much protection to a network, and a WEP
protected hidden network just means that instead of 10 mins it will take 15 mins to get the password. For
a WPA network, making the SSID hidden doesn't really do a lot since WPA networks are practically
uncrackable and a person who has the time and processing power to get past WPA encryption won't be
stopped by the hidden SSID.
There can be additional authentication steps (logins) or other barriers between you and

internet even after you get access to the router. However, this is an entirely separate problem and
not too relevant to the discussion of wireless hacking. Still it's something you must be aware of.
Wireless hotspots or open networks don't have any encryption. They can be accessed by anyone.
Also, the data transmitted by you is not encrypted and can be read by anyone in the vicinity.
Anything which you send to the destination server in plain-text (say, to google), will be transmitted
from your machine to the wireless router in plain-text. Anyone in the vicinity can easily read it using
Wireshark or any other similar tool. Of course, sensitive data is rarely sent in plain-text, so don't sit
around wireless hotspots hoping to get someone's FB login credentials. However, lack of encryption
in open networks should be considered seriously. As far as wireless hacking is concerned, not a lot
to do here (other than sniffing at unencrypted data in the air).
WEP - This is where most of the stuff happens. Countless vulnerabilities, countless attacks,
countless research papers listing the issues, countless tools to get the passwords. It doesn't take
too much effort to learn how to hack these. If you are familiar with linux, then it takes practically no
efforts at all. Just some terminal commands, and you're done (with wifite you don't even have to
bother with that).
WPA - Don't want to mess with this guy. Theoretically there's a way to get in. Practically it will take
forever. Dictionary attacks and bruteforce are the methods to get in. Will cover all this in the
advanced version of this guide. PS: When I say WPA, I refer to both WPA and WPA-2. For the sake
of this post, they are the same (actually they have a lot of difference, the common thing is neither is
an easy target for hackers).
WPA with WPS - Tough guy with a weak spot. Hit him where it hurts and the 'it takes forever to
get in' becomes a matter of hours. Not as easy as WEP, but still do-able. Unfortunately, you might
encounter a guy who has a weak spot but has started learning his lessons and guards that spot
properly (WPS but with rate-limiting or some other security measure).

I hope you now have a general idea about the various flavors of wireless security. I have a few advanced guides
in mind too, which will touch the cryptographic specifics about these 'flavors', the vulnerabilities, and their
exploits. As far as the practical hacking process is concerned, there are plenty of tutorials here on this website
and elsewhere on the internet regarding that, so I am not covering that again. I hope that this time when you
read a guide you are aware of what's going on, and don't end up trying an attack that works on WEP targets on a
WPA network.

Facial recognition can be tricked with Facebook

photos
SourceURL: https://nakedsecurity.sophos.com/2016/08/23/facial-recognition-can-be-tricked-with-facebookphotos/

Facial recognition can be tricked with Facebook

photos

Heres a bit of irony: the vast array of photos collected on Facebook and crunched by its powerful facial
recognition technology can be used to trick facial recognition.

Its done by creating 3D facial models using just a handful of publicly available photos, such as those that people
post to Facebook and other social media accounts.

The news comes from researchers at the University of North Carolina whove been working on ways to get around
biometric authentication technologies such as facial recognition.
From a paper describing their technique, which incorporates virtual reality (VR):

Such VR-based spoofing attacks constitute a fundamentally new class of attacks that point to a
serious weakness in camera-based authentication systems.

Unless they incorporate other sources of verifiable data, systems relying on color image data and
camera motion are prone to attacks via virtual realism.

This is far from the first time weve seen facial recognition defeated.

Sophos Home

Free personal security software for all the family

Learn More

Static photos are easy to spoof by holding up a 2D picture to a camera. But even moving photos are spoofable.
Google recently filed a patent for Liveness Checks, but researchers using the most basic of photo editing tools
managed to fool it with just a few minutes of editing and animating photos to make them look like subjects were
fluttering their eyelashes.
None of this has stopped tech companies from exploring, and investing in, facial recognition as a method of
security authentication that could displace passwords: the oft-derided (but persistently popular) whipping boy in
the realm of authentication.
Advances in facial recognition technologies keep coming, and the money invested in this field keeps growing:
Gartner research estimated in 2014 that the overall market will grow to over $6.5 billion in 2018 (compared to
roughly $2 billion today).
Some of the fruits of that investment including Facebook tuning its systems to the point where it doesnt even

have to see your face to recognize you.

Microsoft, for its part, has been showing off technology that can decipher emotions from the facial expressions of
people who attend political rallies, recognize their genders and guesstimate their ages.
Facial recognition is everywhere.

Local law enforcement are using it in secret, a sports stadium used it to try to detect criminals at the Super Bowl,
retail stores are tracking us with it, and even churches are using it to track attendance.
Researchers recently demonstrated that algorithms can also be trained to identify people by matching previously
observed patterns around their heads and bodies, even when their faces are hidden.
And the money keeps coming:

In January, Apple picked up a startup called Emotient that uses artificial intelligence (AI) to read peoples emotions
by analyzing their facial expressions.
Google, for its part, last month acquired Moodstocks: a French company that develops AI-based image recognition
technology for mobile phones.
The UNC researchers demonstrated how their facial recognition workaround can defeat pretty much all of those
facial recognition checks be they based on recognizing 2D or 3D images or oriented at liveness checks at the
USENIX security conference earlier this month.
Their paper describes how the team took a handful of pictures of a target user from social media and created
realistic, textured, 3D facial models.

To trick liveness detection technologies into interpreting the images as a live human face, they used VR systems
to animate the photos, making it appear that the subject was moving: for example, raising an eyebrow or smiling.
The synthetic face of the user is displayed on the screen of the VR device, and as the device rotates
and translates in the real world, the 3D face moves accordingly. To an observing face authentication
system, the depth and motion cues of the display match what would be expected for a human face.

Using the 3D models, they were able to fool four out of five security systems 55% to 85% of the time.

Out of 20 participants, there were only 2 subjects whom the researchers couldnt spoof on any of the facial
recognition systems using the social media-based attack.

They really like moderate to high-resolution photos, as they lend substantial realism to the textured models, the
researchers said.
In particular, they just adore photos taken by professional photographers, such as wedding photos or family
portraits. These images not only lead to high-quality facial texturing, but such photos are also often posted by
users friends and made publicly available.
Hence theyre readily available for researchers (or anybody!) to pick up and spoof.

Whats more, the researchers noted that group photos provide consistent frontal views of individuals, albeit with
lower resolution. Even if such photos are low-resolution, the researchers found they got enough information from
the frontal view to accurately recover a users 3D facial structure.
Heres the million-dollar question: what are those two unspoofable users doing with their photos to foil these
types of social media attacks?
It wasnt necessarily that they posted fewer photos. Rather, they had few forward-facing photos and/or their
photos had insufficient resolution.
Maybe we should we all start taking bad photos!

WordPress Mail Masta Plugin 1.0 - Local File

Inclusion
SourceURL: https://www.exploit-db.com/exploits/40290/

WordPress Mail Masta Plugin 1.0

[+] Date: [23-8-2016]

[+] Autor Guillermo Garcia Marcos
[+] Vendor: https://downloads.wordpress.org/plugin/mail-masta.zip
[+] Title: Mail Masta WP Local File Inclusion
[+] info: Local File Inclusion
The File Inclusion vulnerability allows an attacker to include a file, usually
exploiting a "dynamic file inclusion" mechanisms implemented in the target
application. The vulnerability occurs due to the use of user-supplied input
without proper validation.
Source: /inc/campaign/count_of_send.php
Line 4: include($_GET['pl']);
Source: /inc/lists/csvexport.php:
Line 5: include($_GET['pl']);
Source: /inc/campaign/count_of_send.php
Line 4: include($_GET['pl']);
Source: /inc/lists/csvexport.php
Line 5: include($_GET['pl']);
Source: /inc/campaign/count_of_send.php
Line 4: include($_GET['pl']);
This looks as a perfect place to try for LFI. If an attacker is lucky enough, and
instead of selecting the appropriate page from the array by its name, the script
directly includes the input parameter, it is possible to include arbitrary files
on the server.
Typical proof-of-concept would be to load passwd file:
http://server/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?
pl=/etc/passwd

Ethical Hacking for Beginners: CompTIA

Security+ or EC-Council CEH | Phoenix TS

SourceURL: http://phoenixts.com/blog/ethical-hacking-for-beginners-comptia-security-plus-or-ec-council-ceh/

Ethical Hacking for Beginners: CompTIA

Security+ or EC-Council CEH
You are trying to decide between taking either EC-Councils CEH exam or CompTIAs Security+

course and you are trying to figure out which certification will benefit you the most. Welcome to the
club. Many people carry both certifications only to find out that even though the certifications fall under
an overarching cyber security umbrella, they belong to different discourse communities. Here is what
you need to know about each exam and certification.

SIMILARITIES BETWEEN EC-COUNCIL CEH & COMPTIA

SECURITY+

Even though these exams are meant for two different career paths, in order to take these exams both
EC-Council and CompTIA recommend that participants have similar experience within the field. Each
vendor advocates that before you partake in these exams, you should have a minimum of two years
of experience and knowledge of security concepts.
If you are already sold on one certification over another, view our CEH and Security+ course details
and/or take free assessments below.

COMPTIA SECURITY+ FOR NOVICE CYBER SECURITY

PROS
Along with two years of recommended cyber security experience, CompTIA advises potential
students hold a Network+ certification or an equivalent and knowledge.

It is important to know that even though CompTIA recommends that you have experience in the field
before taking a Security+ exam, it is still an entry level certification. This certification should be
considered a stepping stone that is needed to get your foot in the door of a cyber security career.

Security+ is not a certification that will earn you a managerial level position, but it is important that you
take the necessary steps that will get you to the place in your career that you want to be.

EC-COUNCIL CEH FOR BEGINNER ETHICAL HACKERS

AND PEN TESTERS

Just like CompTIA, two years of experience in IT security is recommended, but what sets this exam
apart from Security+ is the fact that EC-Council also recommends that potential students already
have their Security+ certification along with a strong understanding of TCP/IP.

This alone should show you that the Certified Ethical Hacker v9 certification is a tougher merit to
acquire than the Security+ certification. Apart from a Security+ certification, the only specifically
mentioned base of knowledge EC-Council recommends you have before the exam is TCP/IP, but our
instructors urge potential test takers to have experience in snort, nmap and hping.
This basic foundation of cyber security will not guarantee a passing score, especially when you
account for the recent change in CEH exams. EC-Council updated the exam from CEH v8 to v9.

PICK YOUR POISON

Even though the CEH exam is tougher than the Security+ exam, both IT security certifications hold
significant value.
CompTIAs Security+ exam is a certification for the novice IT security employee furthering their
knowledge of cyber security principles and networking protocols. On the other hand, if you already
maintain this certification and are looking to take on a career that is more along the lines of
penetration testing or incident response, CEH is more suited for you.

GET STARTED: FREE ASSESSMENTS AND COURSE

INFORMATION

Still unsure? Measure your skills and knowledge by taking either one of our free practice quizzes for
CEH and CompTIAs Security+ by filling out the form below.
Also, if you enjoyed this article and think a friend could use the info too, share it by clicking on the
button below.

Privilege Escalation on Linux with Live examples

- InfoSec Resources
SourceURL: http://resources.infosecinstitute.com/privilege-escalation-linux-live-examples/

Introduction
One of the most important phase during penetration testing or vulnerability assessment is
Privilege Escalation. During that step, hackers and security researchers attempt to find
out a way (exploit, bug, misconfiguration) to escalate between the system accounts. Of
course, vertical privilege escalation is the ultimate goal. For many security researchers,
this is a fascinating phase.

In the next lines, we will see together several real examples of privilege escalation. We will
use labs that are currently hosted at Vulnhub. Of course, we are not going to review the
whole exploitation procedure of each lab. Instead, we will suppose that we have already
gained access to the machine and, together, we will move from an unprivileged user into
the root.
We will perform all the privilege escalation techniques manually. This means that no
automatic tools will be used to escalate the privileges. Of course, though, tools and
papers will be given as reference at the end of the article. Before you begin reading the
next lines, I suggest you have a look at my personal Privilege Escalation Bible: G0tmi1k:
Basic Linux Privilege Escalation written by the very talented g0tmi1k.

The purpose of the article is to give you an idea of how privilege escalation looks and
works on real machines. We will not attempt to explain all the available techniques as this
would require several articles and at the same time, g0tmi1k and other people have done
this before, perfectly.

Lab 1: VulnOS 2
VulnOS version 2 is a very common boot to root lab available at Vulnhub. Once someone
manages to exploit the vulnerability and gain a shell, we will probably see something like
the following:

The things that we should do first are:

1.
2.
3.
4.

Check the OS Release of the vulnerable system

View its Kernel Version
Check the available users and the current user privileges
List the SUID files. Read more here: Common Linux Misconfigurations InfoSec
Resources InfoSec Institute
5. View the installed packages, programs and running services. Outdated versions
might be vulnerable.

Of course, each time we will be looking for other information but for now, the above will do
the job.
Lets try to view the OS Release of the lab machine. By executing:
$ lsb_release -a

We can see something like the following:

Moreover, by running:

$ uname -a

We can also see the Kernel Version:

During privilege escalation, we will find ourselves testing again and again. We will be
searching for possible techniques to escalate and each time one comes to our mind; we
will attempt to apply it. We will be testing exploits against the system, exploits against
services, we will brute force credentials and in general, we will be testing all the time.
Now that we know the OS Release Information, Ubuntu 14.04.4 LTS, and the Kernel
Version, 3.13.0-24-generic, the first thing we can try is the popular exploit called:
overlayfs. This exploit is supposed to work on Ubuntu 12.04/14.04/14.10/15.04 and
Linux Kernel after 3.13.0 and before 3.19. So, it should work fine. Lets test it.

We first move to the tmp directory which we will be able to create a file, paste the exploit
code and then compile it.
The commands we should run are:
$ cd /tmp

$ touch exploit.c
$ vim exploit.c

Then, we should paste the exploit code inside the file, save and exit. Now, we have to
compile the exploit. To do this we run:
$ gcc exploit.c -o exploit

And now we only have to execute the exploit file to see if our exploit works. By running:
$ ./exploit

We can see something like the following:

As you can see, the exploit has been executed successfully, and we have root access.
The python command you can see was used to get a proper shell. The command used:
$ python -c import pty; pty.spawn(/bin/bash)

Even if this wasnt a difficult lab to perform privilege escalation, the method used is one of
the most common techniques, and it applies to several systems. I personally suggest you
to always check if the overlayfs exploit works. Keep in mind that there are several
versions of this exploit which apply even to newer kernel versions. Have a look here:
1. Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) overlayfs Local
Root Shell
2. Linux Kernel 4.3.3 (Ubuntu 14.04/15.10) overlayfs Local Root Exploit
3. Linux Kernel 4.3.3 overlayfs Local Privilege Escalation

Make sure you use the proper one according to the kernel version!

Lab 2: Mr.Robot
Mr.Robot is another boot to root challenge and one of the authors most favorite. I
decided to show its privilege escalation part because it will help you understand the
importance of the SUID files. If you dont know what SUID files are, please have a look
here.
Once we manage to access the shell, we can see something like this:

Here, we have accessed an account with username daemon. Lets see how we will

manage to escalate from daemon to root.

This box is an Ubuntu 14.04 trusty with Linux Kernel version: 3.13.0-55-generic. All the
exploits against the OS and the Linux Kernel have failed.

Thus, we should come up with a new idea. As mentioned previously, we should always be
checking the SUID files available in the system. By running:
$ find / -perm -u=s -type f 2>/dev/null

We can see something like the following:

Here, we have listed all the SUID files. Can you notice something strange? Why would
Nmap have the SUID flags? Lets see.
First, we should run the following command to learn Nmaps version:
$ /usr/local/bin/nmap version
And the output is:

An outdated version of nmap is installed! But how can this help us escalate to a privileged
user?
Back in the day, Nmap supported an option called interactive. With this option, users
were able to execute shell commands by using a nmap shell (interactive shell). Many
times, security researchers were using this option to avoid logging their nmap commands

in the bash history log file. Here is how nmap interactive looks like:

As we can see, we can execute shell commands by typing ! followed by the command we
would like to execute.
Thus, the: !sh command should normally pop a shell. And as nmap has the SUID flags,
we should normally get a root shell.

And, we are in! We can now execute commands as root.

It is true that during your tests you will -probably- never find Nmap 3.48 with SUID flags
set. This example was demonstrated to make you understand how important is to check
for SUID in Linux. There are several labs at Vulnhub based on this technique. Every time,
different programs have been assigned with the SUID flags so that you can experiment
with them. Feel free to try them.

Lab 3: PwnLab-Init
Pwnlab is another lab hosted by Vulnhub. Again, one of the authors favorite challenges.
Once the attacker manages to get a shell (for several accounts but not root), he can see
something like this:

Currently, we are logged in as user kane. Unfortunately for us, the OS Release wasnt
vulnerable to any documented attack. At the same time, none of the kernel exploits
helped. Moreover, the SUID files were looking fine except a file located under Kanes
home directory named msgmike.

So, lets attempt to list the files under the home directory to see what we have.

From what we can see, we have an ELF 32-bit LSB executable. When executing the file,
we get the following error:

This let us know that the program is trying to call the cat command to view the contents of
a file called msg.txt available under the home directory of a user called mike. Moreover,
lets recall the the file is SUID. What should we do now?
There is a popular technique where attackers manage to manipulate the $PATH bash
environmental to escalate their privileges. Imagine what would happen if we edit the
$PATH variable and instead of the default value we put a new one, a simple dot (.).
Whenever a program (executable) is called, bash will look at the . directory for the
program instead of /usr/local/bin, /usr/bin and more. Lets see what this mean.
ETHICAL HACKING TRAINING RESOURCES (INFOSEC)

A normal PATH variable looks like this:

Whenever I call a program like cat bash will look for the above directories for it. Lets
make a file called cat with the following contents inside:

Of course, we must make it executable with the following command:

$ chmod +x cat

Now, lets change our PATH variable to .. This will make bash look at the . (current)
directory every time it needs to run a program.

Can you imagine what would happen if we execute the msgmike program again? As you
can recall, msgmike executes the cat command to view the contents of a file
(/home/mike/msg.txt). Now that we have changed the PATH variable, though, it will look
for the cat program inside the current directory. As we have created an executable file
called cat which pops a shell our cat file will be executed, and we should normally get
a shell as mike. Lets see!

As you can see, we have successfully logged in as mike! The real challenge doesnt stop
here, though. The next steps to log in as root are not hard, but we will not cover them as
they deal with Command Injection attacks something that is out of the scope of this article.

The reason we examined this lab-example is to understand that several times we should
think of non-common techniques to perform privilege escalation. It goes without saying
that we should first check for common ways to perform privilege escalation but several
times you will deal with machines like the previous one.

I hope you enjoyed this article as much as I did. If you have any questions, please, do not
hesitate to comment!

17
Share

AUTHOR

Nikos
Danopoulos

Nikos Danopoulos has worked as

Junior IT Security Researcher at
eLearnSecurity. Moreover he was
contributed on several projects such
as: HACKADEMIC - OWASP,
Hack.me and more. You can contact
him at danopoulosnikos@gmail.com
or you can find him on Twitter:
@nikosdanopoulos.