Hacking & Computer Science stuff

How direct APEX execution can lead to SSRF, data enumeration, XSS, phishing and more.

Salesforce Lightning exploitation through direct APEX execution


*Disclaimer: this article is not intended to be exhaustive and is the result of my own research and understanding of this quiet complex and vast subject.*

## About mounting

Operating systems implement many interoperable features in order to read, write or execute files from file systems. Some of them are based on standards: CIFS SMB, NFS, ... 

On Linux, `mount` is a **privileged system call** to attach a filesystem specified by a **source** related to a **type** with **options**.

> Note: `mount` program is different than `mount` system call: the first one does not need specific privileges by default, unless you use it to effectively mount a filesystem. You can spot `mount` program calling `mount` syscall by using `strace mount` for a real mount attempt. By default, without arguments, `mount` program will read informative system files like `/proc/self/mountinfo` readable by standard users.

### Mount privileges

You could tell that the usage of `root` user (EUID 0) is mandatory, but I will answer you that only `CAP_SYS_ADMIN` effective capability is needed (*Read [page 2 of mount manual](https://man7.org/linux/man-pages/man2/mount.2.html))*.

By default, that should be enabled in the **initial user namespace**, it does not apply to a child user namespace except if the requested filesystem especially accept it through a `fs_flag` containing `FS_USERNS_MOUNT`. Fast preview from a `grep` in Linux source code shows that OverlayFS could be mount by a non-privileged user in their initial user namespace:

`fs/overlayfs/super.c:1480:	.fs_flags		= FS_USERNS_MOUNT,`

> So, given a [mount (MNT) namespace](https://man7.org/linux/man-pages/man7/mount_namespaces.7.html) and [user (USR) namespace]([aa](https://man7.org/linux/man-pages/man7/user_namespaces.7.html)) combined with `CAP_SYS_ADMIN` capability could offer you a privileged access to local devices sharing this namespace.  
> Required and obtained privileges are also dependent of each filesystem module implementation. The [**GameOver(lay) vulnerability (CVE-2023-2640 and CVE-2023-32629)**](https://www.wiz.io/blog/ubuntu-overlayfs-vulnerability) exploits a defect in the OverlayFS module in the security management of mounting this filesystem for non-privileged user.

*Additionally, `mount` could also be gated through [seccomp](https://man7.org/linux/man-pages/man2/seccomp.2.html) or [AppArmor](https://en.wikipedia.org/wiki/AppArmor).*

### Mount types

As explained in the [page 8 of mount manual](https://man7.org/linux/man-pages/man8/mount.8.html), the mount type matches the compatible filesystem to be attached to your current context.

Mount types can be found in folder `/lib/modules/$(uname -r)/kernel/fs`. In my case:

```bash
❯  find /lib/modules/$(uname -r)/kernel/fs/ -type d | cut -d '/' -f7 | sort | uniq
```

- `9p`
- `adfs`
- `affs`
- `afs`
- `autofs`
- `befs`
- `bfs`
- `btrfs`
- `cachefiles`
- `ceph`
- `cifs`
- `coda`
- `configfs`
- `dlm`
- `ecryptfs`
- `efivarfs`
- `efs`
- `erofs`
- `exfat`
- `ext4`
- `f2fs`
- `fat`
- `freevxfs`
- `fscache`
- `fuse`
- `gfs2`
- `hfs`
- `hfsplus`
- `hpfs`
- `isofs`
- `jbd2`
- `jffs2`
- `jfs`
- `ksmbd`
- `lockd`
- `minix`
- `netfs`
- `nfs`
- `nfs_common`
- `nfsd`
- `nilfs2`
- `nls`
- `ocfs2`
- `omfs`
- `orangefs`
- `overlayfs`
- `pstore`
- `qnx4`
- `qnx6`
- `quota`
- `reiserfs`
- `romfs`
- `smbfs_common`
- `squashfs`
- `sysv`
- `ubifs`
- `udf`
- `ufs`
- `vboxsf`
- `xfs`
- `zonefs`

### Mount options

The manual also specifies that filesystem mounting *can* be done with following options:

- `async`
- `atime`
- `auto`
- `context=context`
- `defaults`
- `defcontext=context`
- `dev`
- `diratime`
- `dirsync`
- `exec`
- `fscontext=context`
- `group`
- `iversion`
- `lazytime`
- `loud`
- `mand`
- `_netdev`
- `noatime`
- `noauto`
- `nodev`
- `nodiratime`
- `noexec`
- `nofail`
- `noiversion`
- `nolazytime`
- `nomand`
- `norelatime`
- `nostrictatime`
- `nosuid`
- `nosymfollow`
- `nouser`
- `owner`
- `relatime`
- `remount`
- `ro`
- `rootcontext=context`
- `rw`
- `silent`
- `strictatime`
- `suid`
- `sync`
- `user`
- `users`
- `x-*`
- `X-*`
- `X-mount.auto-fstypes=list`
- `X-mount.group=group|GID`
- `X-mount.idmap=id-type:id-mount:id-host:id-range`
- `X-mount.mkdir[=mode]`
- `X-mount.mode=mode`
- `X-mount.owner=username|UID`
- `X-mount.subdir=directory`

**All these options are not compatible / implemented for every filesystem / OS / context.**

The options have an effect on the attached filesystem behavior, and sometimes on general security.

*I did not find a clear compatibility matrix between mount types and options. You are welcome to share one!*

### Mounting operations and udisks

Although `mount` system call needs privileges, hopefully a standard user does not always directly needs them by default to get a filesystem mount.

For an easy example, in non-hardened systems, an unprivileged user should have the capability to use an USB flash drive without having administrator rights.

**How do we manage unprivileged mounts (without messing up with kernel)?**

Auto-mount handling is managed by external programs.  

First, in my case, GNOME is responsible of this feature:

```bash
❯ gsettings get org.gnome.desktop.media-handling automount
true
```

Second, though I did not dig into GNOME code, it is probably interacting with **[`udisks`](https://github.com/storaged-project/udisks)** (*Or `udisks2`*) interface, dedicated to mount USB flash drives without high privileges.  
> You can try with `udisksctl mount -b /dev/sda1` (*If `/dev/sda1` is the target partition of your USB flash drive*), then you will get your UDisk mounted at `/media/user/xyz`.

**That's sound crazy at first sight: how this device get *mounted* in so far `mount` syscall needs `CAP_SYS_ADMIN` privileges ?**

<center>![arthur](/images/arthur_think.png)</center>

Because `udisks` is asynchronous: it works via polling and jobs thanks to its autonomous daemon, and not direct user action. It can be seen with `udiskctl monitor`. *Example after a direct USB flash drive plug-in*:

```bash
19:53:05.489: Added /org/freedesktop/UDisks2/block_devices/sda
  org.freedesktop.UDisks2.Block:
    Configuration:              []
    CryptoBackingDevice:        '/'
    Device:                     /dev/sda
    DeviceNumber:               2048
    Drive:                      '/org/freedesktop/UDisks2/drives/General_UDisk_General_UDisk_0_3a0'
    HintAuto:                   true
    HintIconName:               
    HintIgnore:                 false
    HintName:                   
    HintPartitionable:          true
    HintSymbolicIconName:       
    HintSystem:                 false
    Id:                         
    IdLabel:                    
    IdType:                     
    IdUUID:                     
    IdUsage:                    
    IdVersion:                  
    MDRaid:                     '/'
    MDRaidMember:               '/'
    PreferredDevice:            /dev/sda
    ReadOnly:                   false
    Size:                       8054112256
    Symlinks:                   /dev/disk/by-diskseq/27
                                /dev/disk/by-id/usb-General_UDisk-0:0
                                /dev/disk/by-path/pci-0000:06:00.4-usb-0:2:1.0-scsi-0:0:0:0
    UserspaceMountOptions:      
  org.freedesktop.UDisks2.PartitionTable:
    Partitions:         
    Type:               dos
19:53:05.553: Added /org/freedesktop/UDisks2/block_devices/sda1
  org.freedesktop.UDisks2.Block:
    Configuration:              []
    CryptoBackingDevice:        '/'
    Device:                     /dev/sda1
    DeviceNumber:               2049
    Drive:                      '/org/freedesktop/UDisks2/drives/General_UDisk_General_UDisk_0_3a0'
    HintAuto:                   true
    HintIconName:               
    HintIgnore:                 false
    HintName:                   
    HintPartitionable:          true
    HintSymbolicIconName:       
    HintSystem:                 false
    Id:                         by-uuid-5B67C7955E71E727
    IdLabel:                    usb1
    IdType:                     ntfs
    IdUUID:                     5B67C7955E71E727
    IdUsage:                    filesystem
    IdVersion:                  
    MDRaid:                     '/'
    MDRaidMember:               '/'
    PreferredDevice:            /dev/sda1
    ReadOnly:                   false
    Size:                       8053063680
    Symlinks:                   /dev/disk/by-id/usb-General_UDisk-0:0-part1
                                /dev/disk/by-label/usb1
                                /dev/disk/by-partuuid/a100c314-01
                                /dev/disk/by-path/pci-0000:06:00.4-usb-0:2:1.0-scsi-0:0:0:0-part1
                                /dev/disk/by-uuid/5B67C7955E71E727
    UserspaceMountOptions:      
  org.freedesktop.UDisks2.Filesystem:
    MountPoints:        
    Size:               0
  org.freedesktop.UDisks2.Partition:
    Flags:              0
    IsContained:        false
    IsContainer:        false
    Name:               
    Number:             1
    Offset:             1048576
    Size:               8053063680
    Table:              '/org/freedesktop/UDisks2/block_devices/sda'
    Type:               0x07
    UUID:               a100c314-01
19:53:05.553: /org/freedesktop/UDisks2/block_devices/sda: org.freedesktop.UDisks2.PartitionTable: Properties Changed
  Partitions:           /org/freedesktop/UDisks2/block_devices/sda1
19:53:05.617: Added /org/freedesktop/UDisks2/jobs/14
  org.freedesktop.UDisks2.Job:
    Bytes:              0
    Cancelable:         true
    ExpectedEndTime:    0
    Objects:            /org/freedesktop/UDisks2/block_devices/sda1
    Operation:          filesystem-mount
    Progress:           0.0
    ProgressValid:      false
    Rate:               0
    StartTime:          1692813185616440
    StartedByUID:       0
19:53:05.668: /org/freedesktop/UDisks2/jobs/14: org.freedesktop.UDisks2.Job::Completed (true, '')
19:53:05.669: Removed /org/freedesktop/UDisks2/jobs/14
19:53:05.669: /org/freedesktop/UDisks2/block_devices/sda1: org.freedesktop.UDisks2.Filesystem: Properties Changed
  MountPoints:          /media/seb/usb1
19:53:05.673: /org/freedesktop/UDisks2/block_devices/sda1: org.freedesktop.UDisks2.Block: Properties Changed
  UserspaceMountOptions:        uhelper=udisks2
```

`udisks` security can be configured with (*Not exhaustive*):

- **`polkit` rules** (Check `/usr/share/polkit-1/*` and `/etc/polkit-1/*`).
- **Options** from `/etc/udisks2/mount_options.conf`.
- **Hardcoded configuration**. As the manual of `udisks2` is pretty good, you can refer to [http://storaged.org/doc/udisks2-api/latest/mount_options.html](http://storaged.org/doc/udisks2-api/latest/mount_options.html). It is particularly written: 

> Apart from the final computed options UDisks always adds the following options due to security concerns: `nodev, nosuid, uhelper=udisks2` no matter if included in _allow or not. These are hardcoded and can't be changed.

**That said, we can go deeper in the mount option `nodev` and why it is important for system security.** 

## The `nodev` option

### From the Linux manual

Sure it could be very interesting to enumerate all security impacts for all other options for each filesystem, but **I will just explain the security risk about `nodev` option**.

**What does the manual tell us about `nodev` ?**

> Do not interpret character or block special devices on the filesystem.

It could be unclear about real effects of this option on the attached filesystem and security, especially for a Linux neophyte. Some knowledges are prerequisites about Linux file types before understanding the impacts.

Let me tell you how I discovered the **security risk about NOT using the `nodev` option** ...

### Security risk

#### The case

I was analysing the security of two devices, where first one **(A)** had an automatic CIFS SMB mount of a share from the other one **(B)**.

I have limited privileges on the device **(A)**.  
I have high privileges on the share of the device **(B)**.

#### About file types

I was aware that every file you see on a filesystem could not be *a regular file*. In fact, we can distinguish following file types (*Brought by POSIX standard, read [https://en.wikipedia.org/wiki/Unix_file_types](https://en.wikipedia.org/wiki/Unix_file_types)*):

- **Regular file**
- **Directory file**
- **Symbolic link** (*Or symlink*)
- **FIFO** (*Or named pipe*)
- **Socket**
- **Device file** (*Divided in character or block types*)

**Synthesis with needed capabilities for creating these files:**

|File type|[Macro name](https://www.gnu.org/software/libc/manual/html_node/Testing-File-Type.html) (`S_IFMT`)|File type attribute flag|Needed [capabilities](https://man7.org/linux/man-pages/man7/capabilities.7.html)|Example of file creation|
|-|-|-|-|-|
|Regular|`S_IFREG`|-|-|`touch myfile`|
|Directory|`S_IFDIR`|`d`|-|`mkdir mydirectory`|
|Symbolic link|`S_IFLNK`|`l`|-|`ln -s mysymlink`|
|FIFO|`S_IFIFO`|`p`|-|`mknod myfifo p`|
|Socket|`S_IFSOCK`|`s`|-|`socat UNIX-LISTEN:my.socket -`|
|Device (block)|`S_IFBLK`|`b`|Capability `CAP_MKNOD`|`mknod myblockdevice b 1 2`|
|Device (character)|`S_IFCHR`|`c`|Capability `CAP_MKNOD`|`mknod mychardevice c 3 4`|

A block device is using two identifiers to point a real device like a disk. You can list them with `lsblk`. For example, on the device **(A)**, we have:

```bash
nvme1n1     259:5    0 931,5G  0 disk 
└─nvme1n1p1 259:6    0 931,5G  0 part /
```

So the partition `nvme1n1p1` have identifiers `259` and `6`.

The matching block device file can also be found at `/dev/nvme1n1p1`:

```bash
❯ ls -l /dev/nvme1n1p1
brw-rw---- 1 root disk 259, 6 23 août  20:25 /dev/nvme1n1p1
```

**If I create a block device somewhere else with those identifiers, it will refer to the same partition.**

#### Experiment

I was curious how device files (which needs high privileges) were interpreted through SMB mount ...

On the device **(B)**, I can create a block device matching the partition from the device **(A)**:

```bash
# In the SMB share from device (B) - Creation of block device pointing to the partition present in device (A)
sudo mknod mypartition b 259 6
```

Go back in the device **(A)**, with standard user:

```bash
# Go into the SMB share mounted path
❯ cd /mnt/shared
# List
❯ ls -l
brwxrwxrwx  1 root  root  259, 6 22 août  20:30  mypartition
# Try to display the block device
❯ head mypartition
# (...) Raw bytes here (...)
```

#### Consequences

**I can have now a full raw access to the main partition as a standard user, through the mounted block device.**

Why it is permitted ? For this case, it is mainly **because `nodev` was not set in the options of the CIFS SMB share mount.**
If `nodev` were set (`mount -t cifs -o nodev (...)`), I would had an error of type `EACCES`, **even with `root` user**, which is very efficient.

*You can reproduce it with a single USB flash drive containing a block device, without using `udisk`. Simply mount it with `mount -t auto /dev/sda1 /mnt/usb` (Of course you need `CAP_SYS_ADMIN`)*

**So, next times, be aware of mount without options impacting security like `nodev` ;)**

Brief summary about mount security principles, Linux file types and risk about this specific option.

The nodev mount option


## Salesforce Lightning first approach

You maybe encountered Salesforce assets in security researchs. The approach to test these kind of environment can be kinda hard, due to lack or complexity of documentation or tools.

First, I can recommend you these links if do not know the context:

- [https://infosecwriteups.com/in-simple-words-pen-testing-salesforce-saas-application-part-1-the-essentials-ffae632a00e5](https://infosecwriteups.com/in-simple-words-pen-testing-salesforce-saas-application-part-1-the-essentials-ffae632a00e5)
- [https://www.varonis.com/de/blog/abusing-salesforce-communities](https://www.varonis.com/de/blog/abusing-salesforce-communities)

And tool [**sret**](https://github.com/Ophion-Security/sret) and its [first blog post](https://www.reconstation.io/blog/salesforce-recon-and-exploitation-toolkit-sret). I have a waiting PR to enhance its features.

Globally, even if I do not know all the Salesforce technical behaviors, you can interact with it through it **Aura** endpoint, which can be recon with `/sf/aura` for example. A [nuclei template](https://github.com/projectdiscovery/nuclei-templates/blob/master/misconfiguration/salesforce-aura.yaml) exists for this part.

You can send a `message` which specify the **action** you want to execute, related to a **controller**.

For authenticated requests, you need an Aura token `aura.token` and `sid` cookie. At least, on the assets I have tested. 

*Example:*

```bash
POST /s/sfsites/aura HTTP/2
Host: HOST
Cookie: sid=00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;
Content-Length: 1145
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8

message=%7b%22actions%22%3a%5b%7b%22id%22%3a%2286%3ba%22%2c%22descriptor%22%3a%22aura%3a%2f%2fRecordUiController%2fACTION%24getRecordWithFields%22%2c%22callingDescriptor%22%3a%22UNKNOWN%22%2c%22params%22%3a%7b%22recordId%22%3a%22XXXXXXXXXXXXXXX%22%2c%22fields%22%3a%5b%22Account.Id%22%5d%7d%7d%5d%7d&aura.context=XXXXXXXXXXXXXXXXXX&aura.pageURI=%2Fs%2F&aura.token=eyXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
```

- Here, the message is (URL-encoded): `{"actions":[{"id":"86;a","descriptor":"aura://RecordUiController/ACTION$getRecordWithFields","callingDescriptor":"UNKNOWN","params":{"recordId":"XXXXXXXXXXXXXXX","fields":["Account.Id"]}}]}`.
- The controller and action is `aura://RecordUiController/ACTION$getRecordWithFields`.
- The parameters of the action are:
  - The impacted record ID (The primary key in Salesforce environment) is `XXXXXXXXXXXXXXX`, always 15 characters long.
  - The fields `"fields":["Account.Id"]`, coherent with the action and the record type (`Account`).

*Salesforce can add security measures against a large context: object name, object fields, role of the user, scope ...*

## Get more info with debug mode

The debug mode can be enabled on the `User` through its field `UserPreferencesUserDebugModePref` ([Salesforce documentation](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_user.htm)).

*In a context of best security practice, this attribute should not be modifiable by the current user, but by an administrator. But it not always the case.*

> The debug mode can provide (depend on the controller, the actions, the parameters ...) for example :
>
>- Debug messages
>- Stacktraces, with backend code extract


Modifying the field of a record can be done with the action `aura://RecordUiController/ACTION$updateRecord`.

*Example of request:*

```bash
POST /s/sfsites/aura HTTP/2
Host: HOST
Cookie: sid=00XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;
Content-Length: 1145
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8

message=%7b%22actions%22%3a%20%5b%7b%22id%22%3a%20%22123%3ba%22%2c%20%22descriptor%22%3a%20%22aura%3a%2f%2fRecordUiController%2fACTION%24updateRecord%22%2c%20%22callingDescriptor%22%3a%20%22UNKNOWN%22%2c%20%22params%22%3a%20%7b%22apiName%22%3a%20%22User%22%2c%20%22recordId%22%3a%22YYYYYYYYYYYYYYY%22%2c%22recordInput%22%3a%20%7b%22fields%22%3a%20%7b%22UserPreferencesUserDebugModePref%22%3atrue%7d%7d%7d%7d%5d%7d&aura.context=XXXXXXXXXXXXXXXXXX&aura.pageURI=%2Fs%2F&aura.token=eyXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
```

**Then, you will see delicious stacktraces popping with a new context (`PRODDEBUG`) in HTTP response:**

![sfdebug](/images/sf_debug.png)

**Happy hacking!**

Bug bounty tip: enable debug mode for current user

Salesforce Lightning debug mode


## The characters

### The history with introduction to security

#### Representation

Make the experience, open a file `textbook.txt`, write this content:

```bash
This is my wonderful textbook!
```

Save it then display it: `cat textbook.txt`. You should see your text, nothing exceptional.

Some explanations: as you may know, in most of the cases, all characters are 8-bits single bytes that can be represented as hexadecimal.  
You can display the hexadecimal representation of your file with `xxd`:

```bash
❯ xxd textbook.txt 
00000000: 5468 6973 2069 7320 6d79 2077 6f6e 6465  This is my wonde
00000010: 7266 756c 2074 6578 7462 6f6f 6b21 0a    rful textbook!.
```

*The `T` is represented by `54`. The *end-of-line* (Or `LF`, Line Feed) is represented by `0A`.*

> *Yes, in the jungle of encoding schemes, you could encounter some outliers like characters encoded on 7-bits bytes (Original ASCII) or two bytes or more (For special characters, emoji, ...) ... Let's keep it simple today.*

Here are the 128 first characters in ASCII table:

|Hexadecimal|Character|
|-|-|
|00|NUL|
|01|SOH|
|02|STX|
|03|ETX|
|04|EOT|
|05|ENQ|
|06|ACK|
|07|BEL|
|08|BS|
|09|HT|
|0A|LF|
|0B|VT|
|0C|FF|
|0D|CR|
|0E|SO|
|0F|SI|
|10|DLE|
|11|DC1|
|12|DC2|
|13|DC3|
|14|DC4|
|15|NAK|
|16|SYN|
|17|ETB|
|18|CAN|
|19|EM|
|1A|SUB|
|1B|ESC|
|1C|FS|
|1D|GS|
|1E|RS|
|1F|US|
|20|SP|
|21|!|
|22|"|
|23|#|
|24|$|
|25|%|
|26|&|
|27|'|
|28|(|
|29|)|
|2A|*|
|2B|+|
|2C|,|
|2D|-|
|2E|.|
|2F|/|
|30|0|
|31|1|
|32|2|
|33|3|
|34|4|
|35|5|
|36|6|
|37|7|
|38|8|
|39|9|
|3A|:|
|3B|;|
|3C|\<|
|3D|=|
|3E|>|
|3F|?|
|40|@|
|41|A|
|42|B|
|43|C|
|44|D|
|45|E|
|46|F|
|47|G|
|48|H|
|49|I|
|4A|J|
|4B|K|
|4C|L|
|4D|M|
|4E|N|
|4F|O|
|50|P|
|51|Q|
|52|R|
|53|S|
|54|T|
|55|U|
|56|V|
|57|W|
|58|X|
|59|Y|
|5A|Z|
|5B|[|
|5C|\|
|5D|]|
|5E|^|
|5F|_|
|60|`|
|61|a|
|62|b|
|63|c|
|64|d|
|65|e|
|66|f|
|67|g|
|68|h|
|69|i|
|6A|j|
|6B|k|
|6C|l|
|6D|m|
|6E|n|
|6F|o|
|70|p|
|71|q|
|72|r|
|73|s|
|74|t|
|75|u|
|76|v|
|77|w|
|78|x|
|79|y|
|7A|z|
|7B|\{|
|7C|\||
|7D|\}|
|7E|~|
|7F|DEL|

#### The unprintable

You can notice there are two kind of *categories*:

- **Printable characters**: *a, B, 1, 2, !, etc.*
- **Unprintable characters**: *NUL, BEL, ACK, BS, TAB, ...*

Where do the **unprintable characters come from?**.
Most of these characters come from older times, where old computers and teletypes were the kings and queens (or [Teleprinter](https://en.wikipedia.org/wiki/Teleprinter)).

<center>![teleprinter](https://upload.wikimedia.org/wikipedia/commons/8/89/WACsOperateTeletype.jpg)</center>

These characters instruct the interpreter for special behavior, like the good old typewriter for "Ring a bell" or "Return to the beginning of the text". They are also called **[Control characters](https://en.wikipedia.org/wiki/Control_character)**.
All of them also can be represented by **[Caret notation](https://en.wikipedia.org/wiki/Caret_notation)**, and some may be represented using **[C escape sequence](https://en.wikipedia.org/wiki/Escape_sequences_in_C)**:

|Hexadecimal|Character|Caret notation|C escape sequence|
|-|-|-|-|
|00|NUL|^@|\0|
|01|SOH|^A||
|02|STX|^B||
|03|ETX|^C||
|04|EOT|^D||
|05|ENQ|^E||
|06|ACK|^F||
|07|BEL|^G|\a|
|08|BS|^H|\b|
|09|HT|^I|\t|
|0A|LF|^J|\n|
|0B|VT|^K|\v|
|0C|FF|^L|\f|
|0D|CR|^M|\r|
|0E|SO|^N||
|0F|SI|^O||
|10|DLE|^P||
|11|DC1|^Q||
|12|DC2|^R||
|13|DC3|^S||
|14|DC4|^T||
|15|NAK|^U||
|16|SYN|^V||
|17|ETB|^W||
|18|CAN|^X||
|19|EM|^Y||
|1A|SUB|^Z||
|1B|ESC|^[|\e|
|1C|FS|^\||
|1D|GS|^]||
|1E|RS|^^||
|1F|US|^_||
|7F|DEL|^?||

The **[ASCII page on Wikipedia](https://en.wikipedia.org/wiki/ASCII)** is a gold mine about this.

**These characters have been used for more than 50 years, and are still fully used today in all basic I/O communication at low level.** 

> *We may one day talk about (pseudo)TTY behaviors, you can refer to this excellent article from Guillaume Quéré about [The oldest privesc: injecting careless administrators' terminals using TTY pushback](https://www.errno.fr/TTYPushback.html) and Linus Akesson about [The TTY demystified](https://www.linusakesson.net/programming/tty/).*

#### Managing the unprintable characters

When **text processing** comes in, everything breaks. We need **exceptions**, ***awful* if/else**, **whitelisting**, **regex** (*they do not hurt, stay here*), ... to **manage control characters** (block, replace, etc.). Beyond this, some characters may even have a double meaning (*ex: control character `09` for text tabulation*).

Without countermeasures, here some winners in cybersecurity:

- **[Null Byte Injection](http://projects.webappsec.org/w/page/13246949/Null%20Byte%20Injection)**
- **[CRLF injection](https://cwe.mitre.org/data/definitions/93.html)**
- **[Embedded tab evasion](https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html#embedded-encoded-tab)**
- And a *lot* more.

![bomb](/images/bomb.jpg)


**What a nightmare uh?** Because these characters are not *natural*, they are sometimes ignored by developers, thinking control characters are actually well-managed at low-level states which is not always the case (*by purpose, by mistake or by ignorance*).

**A lot of security holes come from missing character management.** We are only talking about 1 or 2 bytes. That is beautiful. That is also why I like cybersecurity.

### About character testing

I will not especially cover specific injection types like the CRLF one. I think you got it after reading that first part: **in fact, all control characters, and by extension unprintable characters, are candidates for injection during text processing.** Some of them are more special than others, because they are more prevalent (*NUL for strings, LF for lines, ...*).

It is always interesting to inject these control characters during critical text processing (Authentication, user management, session management, text editor, etc.). 

> Some ideas and methods:
> 
> - **For HTTP(S)**, I like to use the **Intruder** from **[Burp Pro](https://portswigger.net/burp/pro)** with numbers or [hex list](https://github.com/danielmiessler/SecLists/blob/master/Fuzzing/URI-hex.txt).
> - **For serial or specific TCP**, I like to run my own **[boofuzz](https://github.com/jtpereyda/boofuzz)** template or specific library if necessary ([scapy](https://scapy.net/), ...).
> - **For RPC / IPC**, I like implementing my own callers (C, shell, python, ...) but you can also use standard [fuzzers](https://en.wikipedia.org/wiki/Fuzzing) ([AFLplusplus](https://github.com/AFLplusplus/AFLplusplus), [syzkaller](https://github.com/google/syzkaller), ...). **[msfvenom](https://docs.metasploit.com/docs/using-metasploit/basics/how-to-use-msfvenom.html)** mixed with [badchars generator](https://github.com/cytopia/badchars) can also be used for payloads generation, but it is very context-dependent.

<center>![catgun](/images/catgun.png)</center>

## The case

### The security test

I was testing the security of a **user management feature**.  
An HTTP endpoint permits adding a user to the system, which involves editing the `/etc/passwd` file (*found after some reverse engineering*).  
Here the general steps of the current implementation:

1. API endpoint callable with HTTP POST with parameters like the username, the password, the groups and the user-friendly name ([GECOS](https://en.wikipedia.org/wiki/Gecos_field)).
2. Its implementation calls an internal function which ends up invoking `putpwent` from **glibc** ([man](https://man7.org/linux/man-pages/man3/putpwent.3.html)), in order to edit `/etc/passwd`.

A vulnerability may be discovered in two ways:

- Try to find a vulnerability regarding the workflow between (1) and (2).
- Try to find an exploit regarding directly `putpwent` to target the system. *This where I identified some parameters "not well controlled" by the caller.*

I like the last way, and I also wanted to understand how the `putpwent` function works.

### The Results

Within the well-prepared environment, create a simple caller:

```c
#include <stdio.h>
#include <pwd.h>

int main() {
    FILE *passwdFile = fopen("./etc_passwd", "a");
    if (passwdFile == NULL) {
        perror("Error on reading file");
        return 1;
    }

    struct passwd userEntry;

    userEntry.pw_name = "standard";
    userEntry.pw_passwd = "userpw";
    userEntry.pw_uid = 1001;
    userEntry.pw_gid = 1001;
    userEntry.pw_gecos = "Simple user";
    userEntry.pw_dir = "/home/user1";
    userEntry.pw_shell = "/bin/sh";

    putpwent(&userEntry, passwdFile);

    fclose(passwdFile);

    return 0;
}
```

After executing the previous code, the file `etc_passwd` will contain:  

```bash
standard:userpw:1001:1001:Simple user:/home/user1:/bin/sh
```

Fine. **Nominal case**.

Now, let's try to inject some **control characters** and `:` as it acts as a separator.

- The function is not executed for `\n`:

```c
    userEntry.pw_name = "stand\nard";
```

- `:` is replaced by a space in the final file:

```c
    userEntry.pw_gecos = "Simple:user";
```

- For `\r` (CR):

```c
    userEntry.pw_gecos = "Simple\ruser";
```

I got:

```bash
❯ cat etc_passwd 
user:/home/user1:/bin/sh1:Simple
```

Hm. What? A possible vulnerability in glibc for password entry write function ? I could not believe it (and I feel like I shouldn’t; this is too easy).

<center>![deeper](/images/deeper.jpg)</center>

Let's dive in glibc source code. In fact, there is effectively just a "simple" filter on semi-colon and LF characters around `nss/valid_field.c`:

```c
#include <nss.h>
#include <string.h>

const char __nss_invalid_field_characters[] = NSS_INVALID_FIELD_CHARACTERS;

/* Check that VALUE is either NULL or a NUL-terminated string which
   does not contain characters not permitted in NSS database
   fields.  */
_Bool
__nss_valid_field (const char *value)
{
  return value == NULL
    || strpbrk (value, __nss_invalid_field_characters) == NULL;
}
```

Where `NSS_INVALID_FIELD_CHARACTERS` is `# define NSS_INVALID_FIELD_CHARACTERS ":\n"`.

Sure, the vulnerability could only be fully exploited if the password entry function accepts that format (Like `getpwent`).

I have managed to create a special `passwd` file from a *possible bad* usage of `putpwent` function resulting in `abcd:mypwd:88:0:random`.  
It could potentially be used as a local privilege escalation vector.

If I create a `/etc/passwd` file based with this result: it works (*`sudo -u abcd id` gives me the IDs of the user*), but I use the full chain exploit attempt, it does not (*real editing of `/etc/password` file through `putpwent` then `sudo -u abcd id`. The user does not exist.*).

**WHY?**

<center>![questions](/images/questions.png)</center>

### The failure

I just forgot to **avoid to mixing up text processing programs with pure I/O programs**.

Let’s go back to our last generated `passwd` file:

```bash
❯ cat etc_passwd 
user:/home/user1:/bin/sh1:Simple
```

Display with `-A`:

```bash
❯ cat -A etc_passwd
standard:userpw:1001:1001:Simple^Muser:/home/user1:/bin/sh$
```

**I was stunned**. Just tricked by (my own) `^M` character.

<center>![cry](/images/cry.png)</center>

Keep in mind that the historical job of that control character is to do a [carriage return](https://en.wikipedia.org/wiki/Carriage_return).

So, with default options, `cat` produces a good output, by only showing "printable" characters and process control characters in conformity with your tty. For this case:

- Write `standard:userpw:1001:1001:Simple`
- Process `^M`: go back to the beginning of the buffer (*or return to the beginning of the line like a [typewriter](https://en.wikipedia.org/wiki/Typewriter)*).
- Write `user:/home/user1:/bin/sh`
- We got the final string: `user:/home/user1:/bin/sh1:Simple`.

> **It is also a good reminder that `printf` should be preferred to `echo` for I/O**. `echo` is dedicated to text ([man](https://linux.die.net/man/1/echo)), and an LF control character is automatically appended by default (this behavior can be disabled if you pass the option `-n`). It could mess up some of your scripts. Example:
> ```bash
> # Incorrect
> ❯ echo "wonderful" | base64
> d29uZGVyZnVsCg==
> # Correct
> ❯ printf "wonderful" | base64
> d29uZGVyZnVs
> ```

## Conclusion and learnings

**Do not mix pure I/O and text processing programs or functions. For the security of your programs and your peace of mind.**

Ultimately, prefer checking and comparing function output with agnostic format (Hexadecimal (**xxd**)) combined with checksum (**sha256sum**).

This little experience is kind of *human* proof-of-concept that, even with **technical knowledge** about characters management, errors (*(bad) usage, (mis)understanding*) about text processing, it can sometimes lead to strange outputs, followed by hasty conclusions, and associated bugs. What a waste of time.
**Now *multiply* that situation by `N` where `N` is the amount of people, langages, programs, fixes, errors, standards that have been around for 50 years.**

Character management, an infinite source of work for developer & cybersecurity. 


I encountered a strange behaviour by testing text input processing functions, where I thought I found a vulnerability. Some feedback and history about characters management.

The carriage return (CR) case


## What will you expect here ?

**As the title says: hacking & computer science stuff.** *Thoughts, discoveries, curiosities, anecdotes, ...*

Posts will come from time to time, when I want & when I have something interesting to tell. **[Stay tuned](/rss.xml).**

## Who I am ?

Just check the [about](/about) page. :)
Maybe I will add more details about me in the future ...

## How to reach me ?

You didn't check the [about](/about) page. :)


Salesforce Lightning exploitation through direct APEX execution

The nodev mount option

Salesforce Lightning debug mode

The carriage return (CR) case

Welcome