正文

前言

这里应急需要知道mysql提权的一些姿势，还有能够提权成功的前提。5金币就当复习一下了。

• 这里考察的是mysql应急响应，我们应该是根据找flag的需求去就行，但是我做了之后发现没啥用，他这个找的flag顺序其实有问题。我自己就捋顺了一遍后，发现下面这种思路比较适合（新手）：
  服务器疑似被入侵，日志中发现有告警，所以我们去分析日志，得到一些信息后，发现黑客可能上传或者写入了websehll，同时在日志中发现黑客还进行了一系列的查询语句，并且发现能够执行系统命令，到这里就要怀疑是否进行了mysql的提权了。
  我的思路就是：
• 查webshell木马
• 同时一边分析日志
• 然后mysql应急

简介

mysql应急响应 ssh账号 root 密码 xjmysql
ssh root@env.xj.edisec.net -p 端口号
1.黑客第一次写入的shell flag{关键字符串}
2.黑客反弹shell的ip flag{ip}
3.黑客提权文件的完整路径 md5 flag{md5} 注 /xxx/xxx/xxx/xxx/xxx.xx
4.黑客获取的权限 flag{whoami后的值}

应急开始

准备工作

• 这里由于需要知道黑客写入的webshell，其实题目中写的不明白不清楚，如果是问：找出黑客写入的webshell，其中藏着flag的内容。
  如果是这问的话比较清楚需求一点。

• 就当他问题问的比较清楚，那我们就需要准备webshell查杀工具。D盾扫一下导出来的web站点文件。
  

• 其次我们需要了解mysql在Linux中提权知识点
  mysql提权其实很容易就想到udf提权，所以这里可以提前准备好路径：/usr/lib/mysql/plugin/，这个目录下就是一些mysql给用户准备的，放udf文件的目录，将你写好的功能文件进来，就能够像查询语句一样使用你写好的一些功能函数了，这里就是黑客经常用来提权的地方。
  注意，Linux下的udf提权文件后缀名一般是.so结尾，而在windows中的话一般是dll结尾文件。

日志分析

这里我加一个日志分析
首先导出apache的日志：/var/llog/apache2/access.log，

• 使用360星图进行分析
  
  发现攻击ip是192.168.200.2(其实全是这个ip的日志)
• 过滤192.168.200.2的日志，由于日志量不是很大，我这里就一条一条得看了，结果发现黑客大概在做：
  • 进行sql注入
  • 执行系统命令
  • 写入反弹shell（这里就是base64解码后发现是反弹shell，反弹的黑客ip也知道了）
    
    

步骤 1

1.黑客第一次写入的shell flag{关键字符串}

• 我们通过D盾扫描出来的sh.php这个webshell中进行查看即可发现关键字符串。
  

• flag为：
  flag{ccfda79e-7aa1-4275-bc26-a6189eb9a20b}

步骤 2

2.黑客反弹shell的ip flag{ip}

• 反弹shell，这里在日志分析中其实就看出来了，黑客通过mysql提权后，使用函数执行系统命令，写入反弹shell，写入到1.sh文件中。
  我们要么直接查看1.sh就可以看到黑客ip，要么就是日志中将base64内容进行解码即可。

  • 日志信息为：
    
    
    
  • 1.sh内容为：
    
    

• flag为：
  flag{192.168.100.13}

步骤 3

3.黑客提权文件的完整路径 md5 flag{md5} 注 /xxx/xxx/xxx/xxx/xxx.xx

• 提权文件，前面提到过，按照正常逻辑的话，到这里的时候其实就是已经发现黑客可能有通过mysql连接上来，然后进行提权了，所以就要进行mysql应急响应。首要的提权方式就是通过写入udf文件。
• 直接进入目录：cd /usr/lib/mysql/plugin/
  在这个目录中，我们有可能看不懂哪些是有用哪些是没用，这时候就是问运营了，我们安全人员不可能一个一个的给你分析，这样的话黑客早到处撒尿了，不过一般这里也不会有很多的udf文件。
• 黑客的提权文件是udf.so，这里你就一个一个尝试了，因为我没专门学过，各位道友懂的话就直接看出来了。
  
• flag为：md5(/usr/lib/mysql/plugin/udf.so)
  flag{b1818bde4e310f3d23f1005185b973e7}

步骤 4

4.黑客获取的权限 flag{whoami后的值}

首先我们要明白黑客是提权的话，他肯定是知道连接账号和密码，所以我们就要猜他怎么知道的，我们就要去看是不是有东西泄露了密码。

• 发现在comment.php中泄露了密码，那黑客自然是能够连接上数据库然后尽心提权了。
  用户名：root
  密码：334cc35b3c704593
  连接的数据库名：cms
  

这里就简单了，因为我们知道了黑客是通过那个文件进行提权的，而udf文件是通过在文件中写入某些功能函数，然后使用该函数可以进行提权，甚至可以提权到root，所以我们跟黑客一样使用一下该函数即可。
而该函数的名字我们在日志中也能直接看到黑客是通过该功能函数直接执行了whoami等一系列系统命令， 或者你能够通过mysql中直接查询有哪些函数。

• 查看命令：select * from mysql.func;
  

• 在日志中也是能知道黑客使用了什么函数进行系统命令执行
  

• flag为：
  flag{mysql}
  

总结

成果：
flag{ccfda79e-7aa1-4275-bc26-a6189eb9a20b}

flag{192.168.100.13}

flag{/usr/lib/mysql/plugin/udf.so}
flag{b1818bde4e310f3d23f1005185b973e7}

flag{mysql}

补充erro.log

这里补充一下：mysql中的/var/log/mysql/erro.log日志，在应急中能发挥很好的作用。
通过本题，我又复习了一遍mysql提权，udf文件自定义功能函数，还有一个就是error.log我们没有注意，看别人wp才发现。
GPT回答如下：（我提问的是上传文件大小和名字属于什么错误类型）
上传文件的记录出现在 MySQL error.log 中，可能是由于应用程序将这些日志条目写入了 error.log，或者文件上传过程涉及数据库操作并触发了记录。这些日志条目有助于调试和诊断文件上传过程中的问题。要确定确切原因，需要检查应用程序的代码和日志配置。
在 error.log 日志文件中记录上传文件的大小和名字通常属于错误信息或警告信息类别。这种日志条目可能由以下原因触发：

1. 上传文件错误：当文件上传过程中出现错误（例如，文件太大、格式不正确、权限问题等），MySQL 可能会记录这些错误信息。
2. 安全警告：如果上传的文件触发了安全检查或违反了安全策略，MySQL 可能会将这些警告信息记录到 error.log 中。
3. 诊断信息：在某些情况下，MySQL 可能会记录详细的诊断信息以帮助管理员调查和解决与文件上传相关的问题。

尽管 MySQL 的 error.log 主要用于记录数据库相关的错误和事件，但某些应用程序或存储过程可能会将文件上传活动的错误或警告信息传递给 MySQL，从而记录在 error.log 中。

如果你看到与文件上传相关的日志条目，具体的类别可能取决于具体的错误或警告上下文。以下是一个示例日志条目，展示了文件上传错误的信息：

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

在这个示例中，日志条目显示了一个错误（ERROR），指出文件上传失败的原因（文件大小超过限制），并提供了文件名和文件大小的信息。

• 记录上传文件信息的原因
  • 错误信息：表示在上传过程中发生了错误，需要管理员注意和解决。
  • 警告信息：提醒管理员可能存在潜在的问题，例如上传的文件大小接近限制。
  • 诊断信息：提供详细信息以帮助管理员诊断和解决文件上传相关的问题。

要详细分析这些信息，通常需要查看具体的日志条目内容和上下文，以确定确切的原因和类别。
通过该文件也能定位到1.sh这个反弹shell的文件，这里也能够发现一些黑客的踪迹，所以以后应急mysql的时候不要忘记了，这里又是一个小技巧。