Updates php/challenge-89.md

Auto commit by GitBook Editor

Author: CHYbeta

php/challenge-80.md

@@ -1,9 +1,44 @@
 # Challenge
 ```php 
+class FTP {
+    public $sock;
 
+    public function __construct($host, $port, $user, $pass) {
+        $this->sock = fsockopen($host, $port);
+
+        $this->login($user, $pass);
+        $this->cleanInput();
+        $this->mode($_REQUEST['mode']);
+        $this->send($_FILES['file']);
+    }
+
+    private function cleanInput() {
+        $_GET = array_map('intval', $_GET);
+        $_POST = array_map('intval', $_POST);
+        $_COOKIE = array_map('intval', $_COOKIE);
+    }
+
+    public function login($username, $password) {
+        fwrite($this->sock, "USER " . $username . "\n");
+        fwrite($this->sock, "PASS " . $password . "\n");
+    }
+
+    public function mode($mode) {
+        if ($mode == 1 || $mode == 2 || $mode == 3) {
+            fputs($this->sock, "MODE $mode\n");
+        }
+    }
+
+    public function send($data) {
+        fputs($this->sock, $data);
+    }
+}
 ```
 
 # Solution
+This challenge contains two bugs that can be used together to inject data into the open FTP connection. The first bug is the usage of $_REQUEST in line 9 while only sanitizing $_GET and $_POST in lines 14 to 16. $_REQUEST is the combination of $_GET, $_POST, and $_COOKIE but it is only a copy of the values, not a reference. Therefore the sanitization of $_GET, $_POST, and $_COOKIE alone is not sufficient. A real world example of a vulnerability that is caused by a similar confusion can be found in our blog.
+
+The second bug is the usage of the type-unsafe comparison == instead of === in line 25. This enables an attacker to inject and execute new commands in the existing connection, for example a delete command with the query string ?mode=1%0a%0dDELETE%20test.file.
 
 # Refference
-+ php-security-calendar-2017 
++ php-security-calendar-2017 Day 16 - Poem

php/challenge-81.md

@@ -1,9 +1,45 @@
 # Challenge
 ```php 
+class RealSecureLoginManager {
+    private $em;
+    private $user;
+    private $password;
 
+    public function __construct($user, $password) {
+        $this->em = DoctrineManager::getEntityManager();
+        $this->user = $user;
+        $this->password = $password;
+    }
+
+    public function isValid() {
+        $pass = md5($this->password, true);
+        $user = $this->sanitizeInput($this->user);
+
+        $queryBuilder = $this->em->createQueryBuilder()
+            ->select("COUNT(p)")
+            ->from("User", "u")
+            ->where("password = '$pass' AND user = '$user'");
+        $query = $queryBuilder->getQuery();
+        return boolval($query->getSingleScalarResult());
+    }
+
+    public function sanitizeInput($input) {
+        return addslashes($input);
+    }
+}
+
+$auth = new RealSecureLoginManager(
+    $_POST['user'],
+    $_POST['passwd']
+);
+if (!$auth->isValid()) {
+    exit;
+}
 ```
 
 # Solution
+This challenge is supposed to be a fixed version of day 13 but it introduces new vulnerabilities instead. The author tried to fix the DQL injection by applying addslashes() without substr() on the user name, and by hashing the password in line 13 using md5(). Besides the fact that md5 should not be used to hash passwords and that password hashes should not be compared this way, the second parameter is set to true. This returns the hash in binary format. The binary hash can contain ASCII characters that are interpreted by Doctrine. In this case an attacker could use the value 128 as the password, resulting in v�an���l���q��\ as hash. With the backslash at the end the single quote gets escaped leading to an injection. A possible payload could be ?user=%20OR%201=1-&passwd=128.
+To avoid DQL injections always use bound parameters for dynamic conditions. Never try to secure a DQL query with addslashes() or similar functions. Additionally, the password should be stored in a secure hashing format, for example BCrypt.
 
 # Refference
-+ php-security-calendar-2017 
++ php-security-calendar-2017 Day 17 - Mistletoe

php/challenge-82.md

@@ -1,9 +1,21 @@
 # Challenge
 ```php 
+class JWT {
+    public function verifyToken($data, $signature) {
+        $pub = openssl_pkey_get_public("file://pub_key.pem");
+        $signature = base64_decode($signature);
+        if (openssl_verify($data, $signature, $pub)) {
+            $object = json_decode(base64_decode($data));
+            $this->loginAsUser($object);
+        }
+    }
+}
 
+(new JWT())->verifyToken($_GET['d'], $_GET['s']);
 ```
 
 # Solution
+This challenge contains a bug in the usage of the openssl_verify() function in line 5 that leads to an authentication bypass in line 7. The function has three return values: 1 if the signature is correct, 0 if the signature verification failed, and -1 if there was an error while performing the verification. So if an attacker generates a valid signature for the data using another algorithm than the one pub_key.pem is using, the openssl_verify() function returns -1 which is casted to true automatically. To avoid this problem use the type-safe comparison === to validate the return value of openssl_verify(), or consider using a different library for cryptography.
 
 # Refference
-+ php-security-calendar-2017 
++ php-security-calendar-2017 Day 18 - Sign

php/challenge-83.md

@@ -1,9 +1,36 @@
 # Challenge
 ```php 
+class ImageViewer {
+    private $file;
 
+    function __construct($file) {
+        $this->file = "images/$file";
+        $this->createThumbnail();
+    }
+
+    function createThumbnail() {
+        $e = stripcslashes(
+            preg_replace(
+                '/[^0-9\\\]/',
+                '',
+                isset($_GET['size']) ? $_GET['size'] : '25'
+            )
+        );
+        system("/usr/bin/convert {$this->file} --resize $e
+                ./thumbs/{$this->file}");
+    }
+
+    function __toString() {
+        return "<a href={$this->file}>
+                <img src=./thumbs/{$this->file}></a>";
+    }
+}
+
+echo (new ImageViewer("image.png"));
 ```
 
 # Solution
+The ImageViewer class is prone to remote command execution through the size parameter in line 17. The preg_replace() call will purge almost any non-digit characters. This is not sufficient though because the function stripcslashes() will not only strip slashes but it will also replace C literal escape sequences with their actual byte representation. The backslash character is untouched by the preg_replace() call allowing an attacker to inject an octal byte escape sequence similar to 0\073\163\154\145\145\160\0405\073. The stripcslashes() function will evaluate this input to 0;sleep 5; which is concatenated into the system command and finally executed in the attackers favor.
 
 # Refference
-+ php-security-calendar-2017 
++ php-security-calendar-2017 Day 19 - Birch

php/challenge-85.md

@@ -1,9 +1,39 @@
 # Challenge
 ```php 
+set_error_handler(function ($no, $str, $file, $line) {
+    throw new ErrorException($str, 0, $no, $file, $line);
+}, E_ALL);
 
+class ImageLoader
+{
+    public function getResult($uri)
+    {
+        if (!filter_var($uri, FILTER_VALIDATE_URL)) {
+            return '<p>Please enter valid uri</p>';
+        }
+
+        try {
+            $image = file_get_contents($uri);
+            $path = "./images/" . uniqid() . '.jpg';
+            file_put_contents($path, $image);
+            if (mime_content_type($path) !== 'image/jpeg') {
+                unlink($path);
+                return '<p>Only .jpg files allowed</p>';
+            }
+        } catch (Exception $e) {
+            return '<p>There was an error: ' .
+                $e->getMessage() . '</p>';
+        }
+
+        return '<img src="' . $path . '" width="100"/>';
+    }
+}
+
+echo (new ImageLoader())->getResult($_GET['img']);
 ```
 
 # Solution
+This challenge contains a server-side request forgery vulnerability. It allows an attacker to perform requests on behalf of the attacked web server. Thus, servers can be reached that would otherwise be not reachable for an external attacker. For example, this can be abused to perform a port scan and to grab banners (e.g., version of the server) on an internal network that the web server is part of. The exploitable parts are the usage of file_get_contents() with unfiltered user input in line 14 and the printing of the error message to the user in line 23. An attacker can request an internal URI like ?img=http://internal:22 and would get a response such as failed to open stream: HTTP request failed! SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.2 if OpenSSH is running. Information like this can be used to prepare further attacks. Another popular exploit scenario is the retrieval of sensitive AWS credentials when attacking an AWS cloud instance. Besides that, filter_var() also accepts file:// URLs, enabling an attacker to load local files.
 
 # Refference
-+ php-security-calendar-2017 
++ php-security-calendar-2017 Day 20 - Stocking

php/challenge-86.md

@@ -1,9 +1,42 @@
 # Challenge
 ```php 
+declare(strict_types=1);
 
+class ParamExtractor {
+    private $validIndices = [];
+
+    private function indices($input) {
+        $validate = function (int $value, $key) {
+            if ($value > 0) {
+                $this->validIndices[] = $key;
+            }
+        };
+
+        try {
+            array_walk($input, $validate, 0);
+        } catch (TypeError $error) {
+            echo "Only numbers are allowed as input";
+        }
+
+        return $this->validIndices;
+    }
+
+    public function getCommand($parameters) {
+        $indices = $this->indices($parameters);
+        $params = [];
+        foreach ($indices as $index) {
+            $params[] = $parameters[$index];
+        }
+        return implode($params, ' ');
+    }
+}
+
+$cmd = (new ParamExtractor())->getCommand($_GET['p']);
+system('resizeImg image.png ' . $cmd);
 ```
 
 # Solution
+This challenge contains a command injection vulnerability in line 33. The developer declared strict_types=1 in line 1 to ensure the the type hint in the validate function in line 7 throws a TypeError exception if a non-int is passed to the class. Even with strict types enabled there is an bug with the usage of array_walk() which ignores the strict typing and uses the default weak typing of PHP instead. An attacker can therefore just append a command to the last parameter that is executed in the system call. A possible payload could look like ?p[1]=1&p[2]=2;%20ls%20-la.
 
 # Refference
-+ php-security-calendar-2017 
++ php-security-calendar-2017 Day 21 - Gift Wrap

php/challenge-87.md

@@ -1,9 +1,27 @@
 # Challenge
 ```php 
+if (isset($_POST['password'])) {
+    setcookie('hash', md5($_POST['password']));
+    header("Refresh: 0");
+    exit;
+}
 
+$password = '0e836584205638841937695747769655';
+if (!isset($_COOKIE['hash'])) {
+    echo '<form><input type="password" name="password" />'
+       . '<input type="submit" value="Login" ></form >';
+    exit;
+} elseif (md5($_COOKIE['hash']) == $password) {
+    echo 'Login succeeded';
+} else {
+    echo 'Login failed';
+}
 ```
 
 # Solution
+The code snippet suffers from 4 vulnerabilities. First, the type-unsafe comparison operator is used in line 12 to compare the hashed password to a string. The string has the form of the scientific notation and as a result it is interpreted as “zero to the power of X”, which is zero. So if we are able to generate a zero-string for the hashed user input as well, the check compares zero to zero and succeeds. This hashes are called “Magic Hashes” and a Google search reveals that the MD5 hash of the value 240610708 results in the desired properties. The code snippet calculates the MD5 hash of the password twice though, so it is not possible to directly submit the value. Instead you have to exploit the second vulnerability: the first hash is calculated on the server side but stored in a cookie on the client side. Thus the value 240610708 simply has to be directly injected into the password cookie.
+
+There are two more vulnerabilities but they are not relevant for this challenge. First, the comparison of the hashes is vulnerable to timing attacks. To prevent this issue, the PHP function hash_equals() should be used for comparison. Second, the PHP function md5() is used to hash the password. The MD5 algorithm is considered broken and it was not designed for password hashing. Instead a secure password hashing algorithm like BCrypt should be used. It should be noted that passwords also should not be hard coded but separated into a configuration file.
 
 # Refference
-+ php-security-calendar-2017 
++ php-security-calendar-2017 Day 22 - Chimney

php/challenge-88.md

@@ -1,9 +1,47 @@
 # Challenge
 ```php 
+class LDAPAuthenticator {
+    public $conn;
+    public $host;
 
+    function __construct($host = "localhost") {
+        $this->host = $host;
+    }
+
+    function authenticate($user, $pass) {
+        $result = [];
+        $this->conn = ldap_connect($this->host);    
+        ldap_set_option(
+            $this->conn,
+            LDAP_OPT_PROTOCOL_VERSION,
+            3
+        );
+        if (!@ldap_bind($this->conn))
+            return -1;
+        $user = ldap_escape($user, null, LDAP_ESCAPE_DN);
+        $pass = ldap_escape($pass, null, LDAP_ESCAPE_DN);
+        $result = ldap_search(
+            $this->conn,
+            "",
+            "(&(uid=$user)(userPassword=$pass))"
+        );
+        $result = ldap_get_entries($this->conn, $result);
+        return ($result["count"] > 0 ? 1 : 0);
+    }
+}
+
+if(isset($_GET["u"]) && isset($_GET["p"])) {
+    $ldap = new LDAPAuthenticator();
+    if ($ldap->authenticate($_GET["u"], $_GET["p"])) {
+        echo "You are now logged in!";
+    } else {
+        echo "Username or password unknown!";
+    }
+}
 ```
 
 # Solution
+The LDAPAuthenticator class is prone to an LDAP injection in line 24. By injecting special characters into the username it is possible to alternate the result set of the LDAP query. Although the ldap_escape() function is used to sanitize the input in lines 19 and 20, a wrong flag has been passed to the sanitize-calls resulting in insufficient/incorrect sanitization. Therefore, in this particular example, the LDAP injection results in an unauthenticated adversary bypassing the authentication mechanism by injecting the asterisk-wildcard * character as username and password to successfully login as an arbitrary user.
 
 # Refference
-+ php-security-calendar-2017 
++ php-security-calendar-2017 Day 23 - Cookies

php/challenge-89.md

@@ -1,9 +1,18 @@
 # Challenge
 ```php 
-
+@$GLOBALS=$GLOBALS{next}=next($GLOBALS{'GLOBALS'})
+[$GLOBALS['next']['next']=next($GLOBALS)['GLOBALS']]
+[$next['GLOBALS']=next($GLOBALS[GLOBALS]['GLOBALS'])
+[$next['next']]][$next['GLOBALS']=next($next['GLOBALS'])]
+[$GLOBALS[next]['next']($GLOBALS['next']{'GLOBALS'})]=
+next(neXt(${'next'}['next']));
 ```
 
 # Solution
+This challenge consists of a code snippet that was created by one of our team members for the Hack.lu CTF Tournament. It makes heavy use of the next() function and the $GLOBALS array. The next() function moves the internal array pointer up by one. Combined with the $GLOBALS array this allows us to execute arbitrary code.
+The payload has to be split up into 2 segments: First, a PHP function to execute, passed in via $_COOKIE[‘GLOBALS’]. Second, parameters for the injected function, passed in via the file type of a sent file with the same name as the called PHP function. A more detailed write-up of the solution can be found here.
+
+https://github.com/ctfs/write-ups-2014/tree/master/hack-lu-ctf-2014/next-global-backdoor
 
 # Refference
 + php-security-calendar-2017