Differences

This shows you the differences between two versions of the page.

--- method_4_exploitation [2022/12/31 21:56] – [Tools] gman
+++ method_4_exploitation [2023/01/12 00:27] (current) – [Defaults] gman
@@ Line 49: / Line 49: @@
 ----
+====== Defaults ======
+Many folks leave many devices with factory defaults. You can quickly look up the default login creds here:
+  * https://www.defaultpassword.com/
+  * https://default-password.info/
+  * https://cirt.net/passwords
+  * [[https://www.google.com/search?q=default+passwords | Or just Google "default passwords"]]. There are a ton of sites.
+----
 ====== Tools ======
@@ Line 189: / Line 198: @@
   * It works with a variety of protocols.
   * It's a bit more difficult to use. The author says it's "less script kiddie friendly."
+----
+====== Injection Attacks ======
+===== Command =====
+**Command Injection Attacks:** These are attacks that attempt to send commands through a web app to the operating system.
+  * It would give you the ability to directly manipulate the o/s.
+  * On Linux, use the ''system()'' call to send commands to the o/s itself.
+**Example:** If an app asks for a username to set up an account (assuming the username dbag)
+  * When we create our account with the username "dbag," the back-end result sent to the o/s would be something like:
+    * ''system('mkdir /home/dbag')''
+  * Using command injection, you add commands to our user input:
+    * ''dbag & rm -rf /home''
+  * This would result in a command like this:
+    * ''system('mkdir /home/dbag & rm -rf /home')''
+  * And that's bad.
+===== SQLi =====
+**SQL Injection:** One quick way to check to see if the server is vulnerable to SQL injections, type the following into the query box.
+<code>
+' or '1'='1
+</code>
+==== Tool: SQLMap ====
+Automates SQLi enumeration and exploitation. Use it only after you have manually verified there is indeed an SQLi vulnerability on the target.
+==== Blind SQLi ====
+Blind SQL injection takes two forms: boolean-based (T/F) and timing-based.
+**Boolean-Based Blind SQLi:** Uses a boolean (T/F) SQL injection statement to test if the injected code gets through.
+  - Test for a standard SQL injection vulnerability by placing a boolean TRUE after valid input.
+    * If it is vulnerable it will match ALL results.
+    * If it is not vulnerable, you will get a normal result (as if you did not send the ''1=1'')
+  - Further test the vulnerability by sending it a boolean FALSE.
+    * Since 1 never equals 2, this should never return results.
+    * If it returns results on your valid input, there is no vulnerability
+    * If it returns no results, then the injection worked.
+<code>
+# 1. TRUE test example. Your input into target web app:
+[valid input]' OR 1=1;--
+# 2. FALSE test example. Your input into target web app:
+[valid input]' AND 1=2;--
+</code>
+**Timing-Based Blind SQLi:** relies on the amount of time required to process a query.
+  * If the app returns on the query immediately, it's probably not vulnerable.
+  * If there is a delay/pause (based on your query statement) before the return, the injection worked.
+  * Example:
+<code>[valid input]'; WAITFOR DELAY '00:00:15';--</code>
+**Tools:** Metasploit & SQLMap.
+  * They automate these timing-based attacks, making them fairly easy.
 ----
@@ Line 216: / Line 288: @@
 https://www.hackingtutorials.org/networking/hacking-netcat-part-2-bind-reverse-shells/  (scroll down)
-----
-====== SQLi ======
-**SQL Injection:** One quick way to check to see if the server is vulnerable to SQL injections, type the following into the query box.
-<code>
-' or '1'='1
-</code>
-===== Tool: SQLMap =====
-Automates SQLi enumeration and exploitation. Use it only after you have manually verified there is indeed an SQLi vulnerability on the target.
 ----