holynix

问题解决：找不到ip

综合一些参考文章以及这台靶机官方页面的评论，表明这台靶机是有问题的，把mac地址写死了，因此扫描不到它的ip，最终解决成功如下： 首先，kali和靶机的网络都设置为NAT（注意不是自定义中的VMnet8），然后选中靶机的网卡高级设置： 2024-10-02-18-43-22 将该mac地址修改为00:0C:29:BC:05:DE，注意是关机状态下再设置。

nmap四扫结果

  • tcp全端口扫：
1
2
3
4
5
6
Nmap scan report for 192.168.59.151 (192.168.59.151)
Host is up (0.0025s latency).
Not shown: 65534 closed tcp ports (conn-refused)
PORT   STATE SERVICE
80/tcp open  http
MAC Address: 00:0C:29:BC:05:DE (VMware)

只有一个80端口，无需考虑优先级。

  • tcp详细扫：
1
2
3
4
5
6
7
8
9
10
11
12
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch)
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.12 with Suhosin-Patch
MAC Address: 00:0C:29:BC:05:DE (VMware)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose|specialized|WAP|router|phone|switch
Running (JUST GUESSING): Linux 2.6.X|4.X (98%), Kronos embedded (92%), ipTIME embedded (92%), Linksys embedded (91%), Suga embedded (91%), Google Android 4.0.X (91%), Extreme Networks ExtremeXOS 15.X (91%)
OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:4.4 cpe:/h:iptime:pro_54g cpe:/h:linksys:rv042 cpe:/h:linksys:wrv54g cpe:/o:google:android:4.0.4 cpe:/o:extremenetworks:extremexos:15.3
Aggressive OS guesses: Linux 2.6.24 - 2.6.25 (98%), Linux 2.6.35 (95%), Linux 2.6.22 (SPARC) (95%), Linux 2.6.18 - 2.6.24 (93%), Linux 2.6.9 - 2.6.33 (93%), Linux 4.4 (92%), Kronos InTouch timeclock (92%), ipTIME PRO 54G WAP (92%), Linux 2.6.18 - 2.6.32 (92%), Linux 2.6.22 (embedded, ARM) (92%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

扫描出了目标的banner与版本信息

  • tcp漏扫：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
PORT   STATE SERVICE                                                        
80/tcp open  http                                                            
|_http-trace: TRACE is enabled                                              
| http-csrf:                                                                 
| Spidering limited to: maxdepth=3; maxpagecount=20; withinhost=192.168.59.151                                     
|   Found the following possible CSRF vulnerabilities:                        
|                                                          
|     Path: http://192.168.59.151:80/?page=login.php                                                                  
|     Form id:                                             
|     Form action: /index.php?page=login.php               
|                                                          
|     Path: http://192.168.59.151:80/index.php?page=login.php                                                         
|     Form id:                                             
|_    Form action: /index.php?page=login.php               
| http-slowloris-check:                                    
|   VULNERABLE:                                            
|   Slowloris DOS attack                                   
|     State: LIKELY VULNERABLE                             
|     IDs:  CVE:CVE-2007-6750                              
|       Slowloris tries to keep many connections to the target web server open and hold                               
|       them open as long as possible.  It accomplishes this by opening connections to                                
|       the target web server and sending a partial request. By doing so, it starves                                  
|       the http server's resources causing Denial Of Service.                                                        
|                                                          
|     Disclosure date: 2009-09-17                          
|     References:                                          
|       https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-6750                                                  
|_      http://ha.ckers.org/slowloris/                     
| http-sql-injection:                                      
|   Possible sqli for queries:                             
|     http://192.168.59.151:80/?page=login.php%27%20OR%20sqlspider                                                    
|     http://192.168.59.151:80/index.php?page=login.php%27%20OR%20sqlspider                                           
|     http://192.168.59.151:80/?page=login.php%27%20OR%20sqlspider                                                    
|     http://192.168.59.151:80/?page=login.php%27%20OR%20sqlspider                                                    
|     http://192.168.59.151:80/index.php?page=login.php%27%20OR%20sqlspider                                           
|_    http://192.168.59.151:80/?page=login.php%27%20OR%20sqlspider                                                    
|_http-vuln-cve2017-1001000: ERROR: Script execution failed (use -d to debug)                                         
|_http-dombased-xss: Couldn't find any DOM based XSS.                                                                 
|_http-stored-xss: Couldn't find any stored XSS vulnerabilities.                                                      
| http-enum:                                               
|   /login.php: Possible admin folder                      
|   /login/: Login page                          S          
|   /home/: Potentially interesting folder                 
|   /icons/: Potentially interesting folder w/ directory listing                                                      
|   /img/: Potentially interesting folder                  
|   /index/: Potentially interesting folder                
|   /misc/: Potentially interesting folder                 
|   /transfer/: Potentially interesting folder             
|_  /upload/: Potentially interesting folder

web初探

首先验证nmap的tcp漏扫结果，排除其他相对无价值信息，尝试验证sql注入。 点击Login跳转到一个很简陋的登录表单，都输入'，观察页面回显’ 2024-10-08-16-08-25 说明被带入执行了，并且可能是报错注入。

sql注入万能密码登录

尝试万能密码1' or 1=1--+后不行，但是把+直接替换成空格后，发现直接登录成功了。 2024-10-08-17-36-23 该功能点可尝试上传文件： 2024-10-09-14-26-28 然而上传后提示当前用户受限。

评估功能点价值

Directory可能隐藏着一些有价值的与用户凭据相关信息，尤其是筛选时字段为Department: Administration的角色，暂时放在一边；

Message Board中的留言信息暴露了开发人员在开发运维的生产活动中做了一些备份、计划任务、针对频繁的ssh暴力攻击采取的配置等动作，这对于我们来说会非常感兴趣，推测当提权时能利用上；

Calender中则是近期的一些日程安排，很有可能一些凭据线索也能从中提取，尤其是时间、人名、地名；

最后，Security中通过不同的选项，会显示对应的不同内容，从该展示效果就可以初步推测可能存在文件包含漏洞，通过查看源码进一步加深这种可能性： 2024-10-09-15-00-50 因为不同复选框选项对应展示不同文件内容， 通过尝试路径遍历虽没成功但也暴露出与文件包含相关线索： 2024-10-09-15-02-52 另外观察url的特点，和文件包含的payload一样： 2024-10-09-15-09-21 【来源库】

(失败尝试)fuzz本地文件包含

既然page参数存在利用可能性，可以尝试fuzz对应的payload，因为目标可能做了过滤措施： 2024-10-09-15-19-29 结合nmap操作系统扫描结果，因此尝试适用于类unix的字典。 利用burp的Intruder模块： 2024-10-09-15-24-29 2024-10-09-15-25-58 尝试后，根据响应情况来看并没啥收获。

(根据返回提示做进一步尝试)文件上传用户枚举

回顾前面失败的文件上传尝试，重新用burp捕获POST请求包时发现，cookie值是对应uid的，结合返回提示，自然可以联想到对该处的id进行枚举: 2024-10-09-16-28-20 尝试后，根据响应长度快速枚举出了能够成功实现文件上传的uid： 2024-10-09-16-29-46 并能成功上传哥斯拉webshell： 2024-10-09-17-02-56 但很可惜，即使通过目录爆破(Cookie指定uid=2)试图寻找更多其他有趣的目录，并没有找到webshell被上传到的路径，放弃。

(视频提示)修改前端成功实现本地文件包含

反思前面的失败尝试，发现尝试中fuzz的对象搞错了，因为一开始怀疑存在漏洞的位置是在前端复选框中，而不是在url，虽然两者效果很相似。修改其中一个包含的文件名： 2024-10-09-17-21-54 无法读取到/etc/shadow，但显然只是该用户无权限访问，而前面通过sql注入万能密码登录进一个默认账户，这不是唯一选择，还有一些来自于/etc/passwd暴露出的非功能性用户名可以尝试。

(视频提示)进一步尝试sql注入登录高权限用户

自己尝试的时候用了很多payload都无效，看了视频发现可以这样精心构造逻辑： 2024-10-10-14-02-51 尝试换一个用户，账号密码都输入相同的payload，发现登陆进去依然还是默认的alamo用户；尝试用户名保持不变，密码随意输入，则提示了错误用户名或密码： 2024-10-10-14-05-14 说明存在注入点的位置可能并不在用户名处，而是密码处。用户名保持不变，密码尝试直接输入'，发现产生了语法报错，说明被成功带入执行了： 2024-10-10-14-08-38 根据报错重新构造payload：

1
2
cvestonesec
' or username='etenenbaum'--

SELECT * FROM accounts WHERE username='cvestonesec' AND password='' or username='etenenbaum'-- ' 仔细观察拼接后的sql语句会发现原来的逻辑都相当于无效了，即0 AND 0 or 我们控制的真逻辑部分，整体的结果就为1，所以直接绕过了，此时如果数据库中存在该用户名，不需要输入正确密码就可以实现登录，该新用户依然无权限访问： 2024-10-10-14-26-32 尝试后，所有用户都无法访问到(包括admin和administrator)

***(视频提示)反思欠考虑的点、通过标题含义猜测上传路径

观看视频演示，发现在测试本地文件包含时我遗漏了一个点未考虑到，即前端表单通过文件包含查看指定文件内容时，还可以通过在url表单上添加对应参数查看： 2024-10-10-14-50-31 另外前面文件上传时，还遗漏了对上传路径的猜测，实际上通过标题的含义可以做推测： 2024-10-10-14-52-28 因为这个功能名叫家目录上传器，自然要想到上传的路径与家目录相关，因此推测路径为：http://192.168.59.151/~etenenbaum/： 2024-10-10-14-57-59 发现之前上传成功的webshell就上传在此处！果然细节决定成败。但这里的文件大小却是0，显得很奇怪，无法成功解析，依旧是权限或其他未知问题： 2024-10-10-15-01-09

(视频提示)通过文件包含尝试获取源码内容

既然之前文件包含都能够读取系统级文件，也不要忽略了网站源码，因为上面利用文件上传漏洞受阻，故优先考虑查看与之相关的： 2024-10-10-15-17-12 !!2024-10-10-15-18-07 注意到这里包含的源码中有部分还是直接被解析了，所以可以利用php伪协议来实现将源码base64编码保证源码的完整和可读性： http://192.168.59.151/index.php?page=ssp.php&&text_file_name=php://filter/read=convert.base64-encode/resource=transfer.php 对结果解码后：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
<?php 
if ( $auth == 0 ) {
        echo "<center><h2>Content Restricted</h2></center>";
} else {
	if ( $upload == 1 )
	{
		$homedir = "/home/".$logged_in_user. "/";
		$uploaddir = "upload/";
		$target = $uploaddir . basename( $_FILES['uploaded']['name']) ;
		$uploaded_type = $_FILES['uploaded']['type'];
		$command=0;
		$ok=1;

		if ( $uploaded_type =="application/gzip" && $_POST['autoextract'] == 'true' ) {	$command = 1; }

		if ($ok==0)
		{
			echo "Sorry your file was not uploaded";
			echo "<a href='?index.php?page=upload.php' >Back to upload page</a>";
		} else {
        		if(move_uploaded_file($_FILES['uploaded']['tmp_name'], $target))
			{
				echo "<h3>The file '" .$_FILES['uploaded']['name']. "' has been uploaded.</h3><br />";
				echo "The ownership of the uploaded file(s) have been changed accordingly.";
				echo "<br /><a href='?page=upload.php' >Back to upload page</a>";
				if ( $command == 1 )
				{
					exec("sudo tar xzf " .$target. " -C " .$homedir);
					exec("rm " .$target);
				} else {
					exec("sudo mv " .$target. " " .$homedir . $_FILES['uploaded']['name']);
				}
				exec("/var/apache2/htdocs/update_own");
        		} else {
				echo "Sorry, there was a problem uploading your file.<br />";
				echo "<br /><a href='?page=upload.php' >Back to upload page</a>";
			}
		}
	} else { echo "<br /><br /><h3>Home directory uploading disabled for user " .$logged_in_user. "</h3>"; }
}

分析关键逻辑，$command代表是否要执行解压等操作，当上传文件的mime类型为application/gzip且解压按钮激活，此时将$command置1，同时并未对上传文件的类型做黑白名单限制，然后关键在于置1后，先用tar对上传的临时文件打包到当前用户对应home目录下，然后删除临时文件；不解压则是直接移动。最后，执行脚本/var/apache2/htdocs/update_own，那么显然之前文件上传失败很可能就与该脚本有关系，因为当时并没有勾选解压，脚本未执行。同样用文件包含查看脚本内容： 2024-10-10-17-27-24 更新各个用户家目录权限所有者，那么这很可能就与之前访问webshell的报错有关系。所以重新将webshell用tar打包再上传，激活自动解压按钮。但发现上传成功了却没有在家目录看到解压过后的新webshell。 猜测是mime类型出了问题，尝试用burp拦截： 2024-10-10-19-39-01 mime类型符合源代码中的条件判断，但依然还是同样的问题。

到这一步就卡住了不知道为什么上传了却未出现解压后的文件，以及即使出现了却无法访问成功webshell。（已解决）

(视频补充部分)kali自带的可自定义php反弹shell

2024-10-09-14-33-00 注意这里要修改成攻击机器的： 2024-10-09-14-33-51

获取到立足点

后来重置了靶机后，重新尝试上述步骤，成功： 2024-10-11-10-14-32 发现尝试提升交互体验的shell没有完全生效，但同样还可以用python，查看目标软件包中是否安装了它： 2024-10-22-14-39-59 所以： 2024-10-22-14-42-40 先进入刚才网站根目录查看是否有一些感兴趣文件： 2024-10-22-14-43-37 暴露了数据库凭据，但无法实现root连接。

(视频提示)权限提升

提权这里卡了有点久，主要是积累的少，对原理没有深入理解透。 结合上面的suid文件与当前用户可执行的root命令来看，提权的思路很明确，因为当前用户可以执行root的/bin/mv，这就给了我们很大权限用于覆盖文件从而实现一些特殊操作，尤其是权限提升时很实用。由于最终目的是要弹出root的shell，而首先想到/bin/bash，但它不是suid文件，翻看suid列表中显然只有/bin/su的功能符合，但如果直接它，会提示我们输入当前用户密码，对应返回的shell也是普通用户，而它欠缺的条件正好又是sudo -l中的文件具有的，而mv覆盖前后发现权限与所有组也没有发生变化，那么此时自然就会想到给/bin/su附加上能够以root用户来执行这个条件，而像这样高权限的文件也必须具有高权限命令才能编辑，/bin/mv正好满足，因此： 2024-10-22-14-56-58 其中覆盖掉sudo -l结果中任何一个文件都可以实现。

复盘总结

学到的