Mystery - Chapter 2 Log Analysis - mysql Emergency Response

preamble

Here emergency need to know some posture of mysql lifting power, and the prerequisite to be able to lift power successfully. 5 gold coins just as a review.

---

• Here is the examination of the mysql emergency response, we should be based on the need to find the flag to go on the line, but I did and found that there is no use, he is looking for the order of the flag is actually a problem. I smoothed out the whole thing myself, and found that the following ideas are more suitable (novice):
  The server is suspected of being invaded, the logs found in the alarm, so we went to analyze the logs, get some information, found that the hacker may have uploaded or written websehll, at the same time in the logs found that the hacker also carried out a series of query statements, and found that the ability to execute the system commands, up to this point, we have to suspect that whether or not to carry out the mysql power up.
  My thought process is this:
• Check Webshell * Horse
• While analyzing the logs.
• Then mysql emergency

---

synopsis

mysql emergency response ssh account root password xjmysql
ssh root@ -p port number
1. The first time the hacker writes the shell flag {key string}
2. Hacking the ip flag of the bounce shell {ip}
3. The full path of the hacker's lifted file md5 flag{md5} Note /xxx/xxx/xxx/xxx/xxx/
4. Hacker-acquired permissions flag{value after whoami}

Emergency response begins

preliminary

• Here due to the need to know the webshell written by the hacker, in fact, it is not clear what is written in the title is not clear if it is asked:Find out what the hacker wrote to the webshell that hid the flags。
  If that's what's being asked it's a little clearer about the need.

• Let's assume that he asked a clearer question. then we need to prepare the webshell checking tool. the D-shield sweeps the exported web site files.
  

• Secondly, we need to know about mysql privileges in Linux.
  mysql lift is actually very easy to think of udf lift, so here you can prepare the path in advance:/usr/lib/mysql/plugin/This directory is some mysql to the user to prepare, put the udf file directory, will you write a good function file in, you will be able to query the statement as well as the use of some of the functions you have written a good function, here is the hacker is often used to lift the power of the place.
  Note that the udf privilege files under Linux usually end in .so, whereas in windows they usually end in dll.

log analysis

I'll add a log analysis here
First export the apache logs: /var/llog/apache2/.

• Analyze using the 360 Star Chart
  
  Found the attack ip is 192.168.200.2 (actually all the logs from this ip)
• Filtering the logs for 192.168.200.2, which I've had to go through one by one here since it's not a huge amount of logs, turned out to be what the hacker was probably doing:
  • Perform sql injection
  • Execute system commands
  • Write the bounce shell (here is where the base64 decoding reveals it to be a bounce shell, and the bounce hacker ip is known)
    
    

Step 1

1. The first time the hacker writes the shell flag {key string}

• We can find the key strings by looking in this webshell scanned by D-Shield.
  

• Flag for:
  flag{ccfda79e-7aa1-4275-bc26-a6189eb9a20b}

Step 2

2. hack the ip flag of the bounce shell {ip}

• Bounce shell, here in theLog analysis in progressIn fact, it becomes clear that the hacker, having been authorized by mysql, uses a function to execute a system command that writes theBounce shell, write to file。
  We can either view it directly to see the hacker ip, or just decode the base64 content in the log.

  • The log message is:
    
    
    
  • Content for:
    
    

• Flag for:
  flag{192.168.100.13}

Step 3

3. The full path of the hacker's lifted file md5 flag{md5} Note /xxx/xxx/xxx/xxx/xxx/

• The power lifting file, mentioned earlier, according to normal logic, to here when in fact is already found that the hacker may have to connect up through mysql, and then power lifting, so it is necessary to carry out mysql emergency response. The first way to lift the right is by writing udf files.
• Go directly to the catalog:cd /usr/lib/mysql/plugin/
  In this directory, it is possible that we can not read what is useful and what is not useful, this is the time to ask the operation, our security personnel can not give you one by one to analyze, in this case, the hacker early pissed everywhere, but generally there will not be a lot of udf files here.
• The hacker's lifting files are, here you try them one by one, because I didn't specialize in them, and all you dawgs can see it straight away if you know what you're doing.
  
• flag is: md5(/usr/lib/mysql/plugin/)
  flag{b1818bde4e310f3d23f1005185b973e7}

Step 4

4. Hacker-acquired permissions flag{value after whoami}

First of all, we have to understand that if the hacker is lifting the power, he must know the connection account and password, so we have to guess how he knows it, and we have to go to see if there is something to leak the password.

• Finding out that the password was compromised in the middle, it's only natural that the hacker was able to connect to the database and then dutifully lift the power.
  User name: root
  Password: 334cc35b3c704593
  Connected database name: cms
  

Here is simple, because we know the hacker is through that file to lift the power, and udf file is through the file to write some function function, and then use the function can be lifted, and even lifted to root, so we with the hacker as the use of the function can be.
And the name of that function we find in theThe log can also directly see that the hacker is through the function function directly executed whoami and a series of system commands. Or you are able to query what functions are available directly through mysql.

• Viewing command: select * from ;
  

• It is also possible to know in the logs what functions the hacker used for system command execution.
  

• Flag for:
  flag{mysql}
  

summarize

---

Results:
flag{ccfda79e-7aa1-4275-bc26-a6189eb9a20b}

flag{192.168.100.13}

flag{/usr/lib/mysql/plugin/}
flag{b1818bde4e310f3d23f1005185b973e7}

flag{mysql}

---

replenishment

Here's something to add: the /var/log/mysql/ log in mysql can be very useful in an emergency.
With this question, I reviewed again mysql lift, udf file customization function function, and one that we didn't pay attention to and only found out by looking at someone else's wp.
GPT answered as follows:（My question is what type of error does uploading a file size and name fall under?）
Uploaded file logs appear in MySQL either because the application writes to these log entries, or the file upload process involves a database operation that triggers logging. These log entries are helpful in debugging and diagnosing problems with the file upload process. To determine the exact cause, you need to examine the application's code and logging configuration.
exist Log files that record the size and name of uploaded files usually belong to theerror messagemaybewarning messageCategory. Such log entries can be triggered by the following reasons:

1. Upload file error: When errors occur during file uploads (e.g., files that are too large, incorrectly formatted, permissions issues, etc.), MySQL may log these error messages.
2. safety warning: If an uploaded file triggers a security check or violates a security policy, MySQL may log these warning messages to the Center.
3. Diagnostic information: In some cases, MySQL may log detailed diagnostic information to help administrators investigate and resolve issues related to file uploads.

Although MySQL's Primarily used for logging database-related errors and events, but some applications or stored procedures may pass error or warning messages about file upload activity to MySQL to be logged in the Center.

If you see log entries related to file uploads, the specific category may depend on the specific error or warning context. The following is a sample log entry showing information about a file upload error:

2024-07-10T12:34:56.789012Z 1 [ERROR] [MY-012345] [Server] File upload failed: File size exceeds limit. File name: '', File size: 10485760 bytes.

In this example, the log entry shows an error (ERROR), indicates why the file upload failed (file size exceeded the limit), and provides information about the file name and file size.

• Reasons for recording information about uploaded files
  • error message: Indicates that an error occurred during the upload process that needs to be noted and resolved by the administrator.
  • warning message: Alert administrators that there may be potential problems, such as uploading files that are close to the size limit.
  • Diagnostic information: Provides detailed information to help administrators diagnose and resolve file upload related issues.

To analyze this information in detail, it is often necessary to look at the content and context of specific log entries to determine the exact cause and category.
Through the file can also locate the file of this bounce shell, here also able to find some traces of hackers, so do not forget to emergency mysql in the future, here is another tip.