Linux Privilege Escalation (PE)

What does Privilege Escalation mean?

At it’s core, Privilege Escalation usually involves going from a lower permission to a higher permission. More technically, it’s the exploitation of a vulnerability, design flaw or configuration oversight in an operating system or application to gain unauthorized access to resources that are usually restricted from the users.

Why is it important?

Rarely when doing a CTF or real-world penetration test, will you be able to gain a foothold ( initial access ) that affords you admin role access. PE is important cause it help you gain to system admin levels. This allow you to do many things, including:

  • Reset password.
  • Bypass access control to compromise protected data.
  • Edit software configurations.
  • Enable persistence, so you can access the machine again later.
  • Change privilege of users.

As well as any other administrator or super user commands that you desire

Privilege Tree:

There are two main PE types:

Horizontal PE: This is where you expand your reach over the compromised system by taking over a different user who is on the same PE level as you. For instance, a normal user hijacking another normal user ( rather than elevating to root user ). This allows you to inherit whatever files and access that user has. This can be used, for instance, to gain access to another normal privilege user, that happen to have an SUID file attached to their home directory which can then be used to get root user access.

Vertical PE (privilege elevation): This is where you attempt to gain higher privilege or access, with exist account that you have already promised. For the local PE attacks this might mean hijacking an account with admin or root privilege.

TAKE EXAMPLE

when you are in the machine, but you are only normal user level. You can not do anything with this user, you want to get root user. Let’s follow some below step:

Enumeration

To enum the security hold in linux system. you can search on the internet. there are a lots of tool and github code custom. But the best one with me is LinEnum.

What is LinEnum?

LinEnum is a simple bash script that performs common commands related to PE, saving time and allowing more effort to be put toward getting root. It is important to understand what commands LinEnum executes, so that you are able to manually enumerate PE vulnerabilities in a situation where you’re unable to use LinEnum or other like scripts

Where to get LinEnum?

You can download a local copy of LinEnum from:

https://github.com/rebootuser/LinEnum/blob/master/LinEnum.sh

It’s worth keeping this somewhere you’ll remember, because LinEnum is an invaluable tool.

How do I get LinEnum on the target machine?

There are two ways to get LinEnum on the target machine. The first way, is to go to the directory that you have your local copy of LinEnum stored in, and start a Python web server using “python -m SimpleHTTPServer 8000” [1]. Then using “wget” on the target machine, and your local IP, you can grab the file from your local machine [2]. Then make the file executable using the command “chmod +x FILENAME.sh”.

image–

Other Methods

In case you’re unable to transport the file, you can also, if you have sufficient permissions, copy the raw LinEnum code from your local machine [1] and paste it into a new file on the target, using Vi or Nano [2]. Once you’ve done this, you can save the file with the “.sh” extension. Then make the file executable using the command “chmod +x FILENAME.sh”. You now have now made your own executable copy of the LinEnum script on the target machine!

–iamge

Running LinEnum

LinEnum can be run the same way you run any bash script, go to the directory where LinEnum is and run the command “./LinEnum.sh”.

Understanding LinEnum Output

The LinEnum output is broken down into different sections, these are the main sections that we will focus on:

Kernel Kernel information is shown here. There is most likely a kernel exploit available for this machine.

Can we read/write sensitive files: The world-writable files are shown below. These are the files that any authenticated user can read and write to. By looking at the permissions of these sensitive files, we can see where there is misconfiguration that allows users who shouldn’t usually be able to, to be able to write to sensitive files.

SUID Files: The output for SUID files is shown here. There are a few interesting items that we will definitely look into as a way to escalate privileges. SUID (Set owner User ID up on execution) is a special type of file permissions given to a file. It allows the file to run with permissions of whoever the owner is. If this is root, it runs with root permissions. It can allow us to escalate privileges. 

Crontab Contents: The scheduled cron jobs are shown below. Cron is used to schedule commands at a specific time. These scheduled commands or tasks are known as “cron jobs”. Related to this is the crontab command which creates a crontab file containing commands and instructions for the cron daemon to execute. There is certainly enough information to warrant attempting to exploit Cronjobs here

XXE Attack

What is XXE attack?

An XML External Entity (XXE) attack is a vulnerability that abuses features of XML parsers/data. It often allows an attacker to interact with any backend or external systems that the application itself can access and can allow the attacker to read the file on that system. They can also cause Denial of Service (DoS) attack or could use XXE to perform Server-Side Request Forgery (SSRF) inducing the web application to make requests to other applications. XXE may even enable port scanning and lead to remote code execution

There are two types of XXE attacks: in-band and out-of-band (OOB-XXE).
1) An in-band XXE attack is the one in which the attacker can receive an immediate response to the XXE payload.

2) out-of-band XXE attacks (also called blind XXE), there is no immediate response from the web application and attacker has to reflect the output of their XXE payload to some other file or their own server.

What is the application vulnerable?

Applications and in particular XML-based web services or downstream integrations might be vulnerable to attack if:

  • The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.
  • Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled. As the exact mechanism for disabling DTD processing varies by processor, it is good practice to consult a reference such as the OWASP Cheat Sheet ‘XXE Prevention’.
  • If your application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable.
  • If the application uses SOAP prior to version 1.2, it is likely susceptible to XXE attacks if XML entities are being passed to the SOAP framework.
  • Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack.

Before we move on to learn about XXE exploitation we’ll have to understand XML properly.

What is XML?

XML (eXtensible Markup Language) is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. It is a markup language used for storing and transporting data.

Why we use XML?

  • XML is platform-independent and programing language independent, thus it can be used on any system and supports the technology change when that happens.
  • The  data stored and transported using XML can be changed at any point in the time without affecting the data presentation.
  • XML allows validation using DTD and Schema. This validation ensures that the XML document is free form any syntax error.
  • XML simplifies data sharing between various systems because of its platform-independent nature. XML data doesn’t require any conversion when transferred between different systems

What are XML entities?

XML entities are a way of representing an item of data within an XML document, instead of using the data itself. Various entities are built in to the specification of the XML language. For example, the entities &lt; and &gt; represent the characters < and >. These are metacharacters used to denote XML tags, and so must generally be represented using their entities when they appear within data.

What is document type definition?

The XML document type definition (DTD) contains declarations that can define the structure of an XML document, the types of data values it can contain, and other items. The DTD is declared within the optional DOCTYPE element at the start of the XML document. The DTD can be fully self-contained within the document itself (known as an “internal DTD”) or can be loaded from elsewhere (known as an “external DTD”) or can be hybrid of the two.

What are XML custom entities?

XML allows custom entities to be defined within the DTD. For example:

<!DOCTYPE foo [ <!ENTITY myentity “my entity value” > ]>

This definition means that any usage of the entity reference &myentity; within the XML document will be replaced with the defined value: “my entity value”.

What are XML external entities?

XML external entities are a type of custom entity whose definition is located outside of the DTD where they are declared.

The declaration of an external entity uses the SYSTEM keyword and must specify a URL from which the value of the entity should be loaded. For example:

<!DOCTYPE foo [ <!ENTITY ext SYSTEM “http://normal-website.com&#8221; > ]>

The URL can use the file:// protocol, and so external entities can be loaded from file. For example:

<!DOCTYPE foo [ <!ENTITY ext SYSTEM “file:///path/to/file” > ]>

XML external entities provide the primary means by which XML external entity attacks arise.

Exploiting XXE

To perform an XXE injection attack that retrieves an arbitrary file from the server’s filesystem, you need to modify the submitted XML in two ways:

  • Introduce (or edit) a DOCTYPE element that defines an external entity containing the path to the file.
  • Edit a data value in the XML that is returned in the application’s response, to make use of the defined external entity.

For example, suppose a shopping application checks for the stock level of a product by submitting the following XML to the server:

<?xml version=”1.0″ encoding=”UTF-8″?>
<userinfor><name>Leiz</name></userinfor>

The application performs no particular defenses against XXE attacks, so you can exploit the XXE vulnerability to retrieve the /etc/passwd file by submitting the following XXE payload:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM “file:///etc/passwd”> ]>
<userinfor><name>&xxe;</name></userinfor>

This XXE payload defines an external entity &xxe; whose value is the contents of the /etc/passwd file and uses the entity within the productId value. This causes the application’s response to include the contents of the file:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin

NOTE:

With real-world XXE vulnerabilities, there will often be a large number of data values within the submitted XML, any one of which might be used within the application’s response. To test systematically for XXE vulnerabilities, you will generally need to test each data node in the XML individually, by making use of your defined entity and seeing whether it appears within the response.

How to find and test for XXE vulnerabilities?

The vast majority of XXE vulnerabilities can be found quickly and reliably using Burp Suite’s web vulnerability scanner.

Manually testing for XXE vulnerabilities generally involves:

  • Testing for file retrieval by defining an external entity based on a well-known operating system file and using that entity in data that is returned in the application’s response.
  • Testing for blind XXE vulnerabilities by defining an external entity based on a URL to a system that you control, and monitoring for interactions with that system. Burp Collaborator client is perfect for this purpose.
  • Testing for vulnerable inclusion of user-supplied non-XML data within a server-side XML document by using an XInclude attack to try to retrieve a well-known operating system file.

How to prevent XXE vulnerabilities?

preventing XXE requires:

  • Whenever possible, use less complex data formats such as JSON, and avoiding serialization of sensitive data.
  • Patch or upgrade all XML processors and libraries in use by the application or on the underlying operating system. Use dependency checkers. Update SOAP to SOAP 1.2 or higher.
  • Disable XML external entity and DTD processing in all XML parsers in the application, as per the OWASP Cheat Sheet ‘XXE Prevention’.
  • Implement positive (“whitelisting”) server-side input validation, filtering, or sanitization to prevent hostile data within XML documents, headers, or nodes.
  • Verify that XML or XSL file upload functionality validates incoming XML using XSD validation or similar.
  • SAST tools can help detect XXE in source code, although manual code review is the best alternative in large, complex applications with many integrations.

Practice

With the lab you can create the account and try it by yourself.

https://portswigger.net/web-security/xxe

————-Have nice day guys—–

Website supports HTTP/2

What is http/2

HTTP/2 (originally named HTTP/2.0) is a major revision of the HTTP network protocol used by the World Wide Web.

Since about 1997, the web has been mostly powered by HTTP/1.1. Back in the 90’s, the web had other needs than we have today. The new protocl version, HTTP version 2 or in short HTTP/2, has some much needed improvements in terms of speed, reliability and security.

I would strongly recommend you to upgrade your webserver to also support the HTTP/2 protocol.

Differences from HTTP1.1

Similar to SPDY, using HTTP/2 does not require any changes to how web applications currently work however, applications are able to take advantage of the optimization features to increase page load speed. According to the HTTP/2 home page, the high-level differences between the HTTP1.1. and HTTP/2 protocol include the following:

  • HTTP/2 is binary, instead of textual
  • It is fully multiplexed, instead of ordered and blocking
  • It can use one connection for parallelism
  • It uses header compression to reduce overhead
  • It allows servers to “push” responses proactively into client caches instead of waiting for a new request for each resource

Overall, HTTP/2 means the server load will go down and the loading times for the end-user will go down drastically as well. And, since it results in a better user experience, it may be advantageous for SEO as well.

Comparison of SPDY3.1 and HTTP/2

Although SPDY and HTTP/2 both have the same goal in mind, there are key variations that exist between them. The following table outlines a few of the high-level differences between SPDY3.1 and HTTP/2

SPDY3.1
HTTP/2
To use the SPDY protocol and take advantage of its features, SSL is required.SSL isn’t required, however encrypted websites will see a boost in performance over today’s encrypted sites.
Multiplexing happens on one host at a time, known as single host multiplexing.Multiplexing happens on different hosts at the same time, known as multi-host multiplexing.
SPDY’s stream-based compression method leaves a slight opening to protocol vulnerabilities.Uses a fixed Huffman code-based header compression algorithm to further prevent attacks and shorten headers.
SPDY’s encrypted connections are fast however they do not use the ALPN extension.

Uses the ALPN extension which allows for faster encrypted connections by letting browsers and servers to decide which application protocol to use initially.

HTTP/2 Support

Most major browsers fully support the use of HTTP/2. This means that if the website you are trying to access runs on an HTTP/2 supported server, your browser will be able to utilize its features. However, although the working group did not require the use of encryption for the new protocol, currently all major browsers only support HTTP/2 over HTTPS.

A more detailed history of browser versions that do support HTTP/2 can be found here.

BrowserSupported
ChromeYes
FirefoxYes
Microsoft EdgeYes
SafariSupport limited to OSX 10.11+
OperaYes
iOS SafariYes
IESupported in version 11, but only for Windows 10.
Android BrowserNo

How to check HTTP/2 support

Test HTTP/2 via command line

1— Using the command line, you can easily check if a website is using the newest HTTP/2 protocol. Using cURL, execute the following command:

curl –http2 https://fallinlove.home.blog

curl -sI domain -o/dev/null -w ‘%{http_version}\n’ => this will show which is current version.

Online HTTP/2 test tools

2There are quite some tools available on the internet that let you enter the website and will show you if this site is using HTTP/2.
KeyCDN: a free HTTP/2 online test tool to Verify HTTP/2.0 Support
Akamai: test if your browser support HTTP/2. They also have a demo to compare the pageload time of a HTTP/1.1 versus the HTTP/2 version.
CloudFlare: for a long time, CloudFlare is one of my favourite companies in terms of innovation and technology. They have a special subdomain to access their site in full HTTP/2 mode.

HTTP/2 browser extension

3If you regularly want to get information about HTTP/2 of website you visit, it might be worth installing a browser plug-in. The HTTP/2 and SPDY indicator plug-in for Google Chrome is an excellent tool to visually indicate if the website you are currently using supports HTTP/2 or SPDY.

Conclusion

HTTP/2 is without a doubt the direction the web is moving towards in terms of networking protocol that is able to handle the resource needs of today’s websites. While SPDY was a great step forward in improving HTTP1.1, HTTP/2 has since further improved the HTTP protocol that has served the web for many years.

Given you have a server that supports the HTTP/2 protocol, you can start serving content over this protocol to users that are accessing your content through a supported browser. For browsers that do not support HTTP/2, they will continue to be delivered content through the old protocol. Using the HTTP/2 protocol will help make websites faster and overall will improve the web’s user experience.