diff --git a/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/README.md b/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/README.md index 4ab69bca0..b5ce7fb98 100644 --- a/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/README.md +++ b/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/README.md @@ -396,7 +396,7 @@ bash -p #From non priv inside mounted folder ### Privilege Escalation with 2 shells -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.f-secure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/).\ +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.\ @@ -519,7 +519,7 @@ cat /proc/self/status | grep CapEff ### User namespace abuse via symlink -The second technique explained in the post [https://labs.f-secure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/](https://labs.f-secure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/) indicates how you can abuse bind mounts with user namespaces, to affect files inside the host (in that specific case, delete files). +The second technique explained in the post [https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/](https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/) indicates how you can abuse bind mounts with user namespaces, to affect files inside the host (in that specific case, delete files).
diff --git a/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md b/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md index 46862a821..e62f88b46 100644 --- a/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md +++ b/mobile-pentesting/android-app-pentesting/bypass-biometric-authentication-android.md @@ -16,7 +16,7 @@ These methods were copied from [https://securitycafe.ro/2022/09/05/mobile-pentes ## **Method 1 – When the crypto object is not used** -The authentication implementation relies on the callback _**onAuthenticationSucceded** _ being called. The researchers from F-Secure developed a [**Frida script**](https://github.com/FSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass.js) that can be used to **bypass** the NULL _**CryptoObject** _ in _**onAuthenticationSucceeded(…)**_. The script will automatically bypass the fingerprint when the aforementioned method is called. Here is a short example that shows the bypass for the Android Fingerprint. The complete application can be downloaded from my [GitHub](https://github.com/St3v3nsS/InsecureBanking). +The authentication implementation relies on the callback _**onAuthenticationSucceded** _ being called. The researchers from WithSecure developed a [**Frida script**](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass.js) that can be used to **bypass** the NULL _**CryptoObject** _ in _**onAuthenticationSucceeded(…)**_. The script will automatically bypass the fingerprint when the aforementioned method is called. Here is a short example that shows the bypass for the Android Fingerprint. The complete application can be downloaded from my [GitHub](https://github.com/St3v3nsS/InsecureBanking). ```javascript biometricPrompt = new BiometricPrompt(this, executor, new BiometricPrompt.AuthenticationCallback() { @@ -33,7 +33,7 @@ frida -U -f com.st3v3nss.insecurebankingfingerprint --no-pause -l fingerprint-by ### **Method 2 – Exception Handling** -This [**Frida script**](https://github.com/FSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass-via-exception-handling.js) developed by F-Secure can be used to bypass the insecure usage of the crypto object. All the script needs to do is manually call the _**onAuthenticationSucceded**_ with a **non-authorized** (not unlocked by fingerprint) _**CryptoObject**_ stored in the Keystore. The catch is if the application will attempt to use another cipher object, then an **exception will be thrown**. This script will attempt to call _**onAuthenticationSucceded** _ and catch the exception _**javax.crypto.IllegalBlockSizeException**_ in _Cipher_ class. From now on, **any objects the application uses will be encrypted using this new key**. +This [**Frida script**](https://github.com/WithSecureLABS/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass-via-exception-handling.js) developed by WithSecure can be used to bypass the insecure usage of the crypto object. All the script needs to do is manually call the _**onAuthenticationSucceded**_ with a **non-authorized** (not unlocked by fingerprint) _**CryptoObject**_ stored in the Keystore. The catch is if the application will attempt to use another cipher object, then an **exception will be thrown**. This script will attempt to call _**onAuthenticationSucceded** _ and catch the exception _**javax.crypto.IllegalBlockSizeException**_ in _Cipher_ class. From now on, **any objects the application uses will be encrypted using this new key**. ``` frida -U -f com.st3v3nss.insecurebankingfingerprint --no-pause -l fingerprint-bypass-via-exception-handling.js diff --git a/mobile-pentesting/android-app-pentesting/webview-attacks.md b/mobile-pentesting/android-app-pentesting/webview-attacks.md index 1155565fd..305b93b85 100644 --- a/mobile-pentesting/android-app-pentesting/webview-attacks.md +++ b/mobile-pentesting/android-app-pentesting/webview-attacks.md @@ -133,7 +133,7 @@ If `addJavascriptInterface` is necessary, take the following considerations: ### Javascript Bridge to RCE via Reflection -As noted in [**this research** ](https://labs.f-secure.com/archive/webview-addjavascriptinterface-remote-code-execution/)(_check it for ideas in case you obtain RCE_) once you found a JavascriptBridge it may be possible to obtain **RCE** via **Reflection** using a payload like the following one: +As noted in [**this research** ](https://labs.withsecure.com/archive/webview-addjavascriptinterface-remote-code-execution/)(_check it for ideas in case you obtain RCE_) once you found a JavascriptBridge it may be possible to obtain **RCE** via **Reflection** using a payload like the following one: ```markup diff --git a/network-services-pentesting/pentesting-web/laravel.md b/network-services-pentesting/pentesting-web/laravel.md index 99e4a216c..0b109c57a 100644 --- a/network-services-pentesting/pentesting-web/laravel.md +++ b/network-services-pentesting/pentesting-web/laravel.md @@ -96,7 +96,7 @@ encrypt(b'{"data":"a:6:{s:6:\\"_token\\";s:40:\\"RYB6adMfWWTSNXaDfEw74ADcfMGIFC2 Vulnerable versions: 5.5.40 and 5.6.x through 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/)) -Here you can find information about the deserialization vulnerability here: [https://labs.f-secure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.f-secure.com/archive/laravel-cookie-forgery-decryption-and-rce/) +Here you can find information about the deserialization vulnerability here: [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/) You can test and exploit it using [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133)\ Or you can also exploit it with metasploit: `use unix/http/laravel_token_unserialize_exec`