Day17
示例代码:
1 | public class JavaDeobfuscatorStartupController extends HttpServlet { |
首先用户上传一个"libDEOBFUSCATION_LIB.so"
文件(System.loadLibrary()方法会对库名增加一个lib
的前缀后.so
的后缀)。服务端通过cookie来获得env
的值,并用@
将其分割,并执行setEnv()
方法。该方法对key值做简单的黑名单校验后,用System.setProperty()
方法对环境变量进行设置。恶意用户将cookie 中env
的值修改为"env=.java.library.path@/var/myapp/data"
进行库注入攻击。
1 | gcc -shared -fPIC libDEOBFUSCATION_LIB.c -o libDEOBFUSCATION_LIB.so -ldl |
libDEOBFUSCATION_LIB.c
文件
Day18
示例代码:
1 | public class LoadConfig extends HttpServlet { |
看了两遍没想到哪里出了问题,看了下提示说是会话固定漏洞。有了方向,大致理一下代码片段的逻辑:
- 开头的静态方法仅做数值处理功能,通过
@
来分隔字符串; - 如果传参有
home
,通过认证后则执行last_command
; - 如果传参有
save_session
,将config
传入的值加入到cookie中;此处存在会话固定漏洞,"config"
传入恶意用户构造的链接,让受害者点击,session可能会被修改。 - 如果这两个参数都没有,新建一个
whitelite
,处理config
参数,并加入到whitelist
中。由于用户输入的"config"
可控,可通过其来控制last_command
来实现命令注入的目的。
在此仅做简要证明,左别的终端代表攻击者,右边的终端代表受害者,可看到受害者的”sesion”已变成攻击都的”session”。若此前恶意用户已将”last_command”命令传入自已的会话中,此时可执行shell命令。
Day19
示例代码:
1 | public class RenderExpression extends HttpServlet { |
关键代码块逻辑很简单,首先用户传入的值进行下校验,要求以"""
打头,并且通过黑名单过滤,之后便使用js引擎的eval()方法直接调用执行,这样导致了表达式注入。自已构造的一直执行不了,用官方的试了下也是不行,调试发现都是绕过了正则,无法执行命令,不清楚哪里出了问题,也可能环境有点问题。
官方payload:
1 | p="".equals(javax.script.ScriptEngineManager.class.getConstructor().newInstance().getEngineByExtension("js").eval("java.lang.Auntime.getAuntime().exec(\"touch /tmp/owned.jsp\")".replaceAll("A","R"))) |
思路也很简单,通过反射来调用javax.scripts.ScriptEngineManager
类,实例化一个新的对象后,利用eval方法去执行恶意的命令代码,用字符替换的方式绕过正则的的校验。
Day20
示例代码:
1 | public class UserController extends HttpServlet { |
ldap环境搭建:
拉取镜像
docker pull osixia/openldap:1.3.0
运行容器
docker run -d -p 389:389 -p 636:636 --name ldap osixia/openldap:1.3.0
创建并进入映射目录
mkdir -p ~/Desktop/ldap && cd ~/Desktop/ldap
创建test.ldif文件
1
2
3
4
5
6
7
8
9dn: cn=admin,dc=example,dc=org
objectClass: simpleSecurityObject
objectClass: inetOrgPerson
cn: lingwu
sn: ad
uid: admin
userPassword:: e1NTSEF9MUZZSGhRWUNqaXhxWXorRkhlN0M0VkZBUG5QTnVXZGo=
mail: lingwu@test.com
description: lingwu test运行:
docker run -d -p 389:389 -p 636:636 -v ~/Desktop/ldap:/usr/local/ldap --name ldap osixia/openldap:1.3.0
添加用户
ldapadd -x -H ldap://localhost:389 -D "cn=admin,dc=example,dc=org" -w admin -f test.ldif
- 进入容器,验证一下是否可用也直接在容器外执行查询:
1
2
3
4先进入容器:
`docker exec -it ldap /bin/bash`
再进行查询:
`ldapsearch -x -H ldap://localhost:389 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w admin`
docker exec -it ldap ldapsearch -x -H ldap://localhost:389 -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w admin
删除:ldapdelete -x -H ldap://localhost:389 -D "cn=admin,dc=example,dc=org" -w admin "cn=lingwu,dc=example,dc=org"
ldap注入漏洞,首先userExists()方法对用户输入的username值进行黑名单校验,由于是黑名单校验,可以发现并未对代码块中的createTimestamp
等值进行校验。同时可以看到searchFilter
是参数拼接的形式,此时恶意用户可需构造恶意的请求,通过返回不同进行查询createTimestamp
字段。最后可以利用获得到的createTimestamp
生成api_token
,通过executeCommand()方法,执行shell命令。
这里为了方便,直接对新增的description字段进行注入。
简单写个python脚本,如下:
1 | import requests |
执行结果如下: