"分享" 标签

Java代码审计-铁人下载系统

作者: LandGrey ●   创建时间: 2018年3月11日 13:11 ●   标签:   #分享,   #代码审计

0x00: 简介初学java代码审计,跟着表哥们脚步,走一遍审计流程,就选了个没有使用Java框架的java系统,作为入门。 0x01: 目的熟悉代码审计流程,寻找漏洞的思路,入门记录。 0x02: 准备工作为了验证审计出的漏洞效果,还是要搭建起来系统,不然空说无凭。为了方便,使用JspStudy 2016一体化环境,选择tomcat 8.0,jdk 1.8搭建。查看代码使用IDEA,当然,也可以用jd-gui,反编译class,不过IDEA自动就反编译了,比较方便。 值得注意的是,使用系统自带的安装功能搭建后,打开页面报错,事后想起来可能是自动导入sql文件的路径程序中写死了,和自己部署时根目录位置不一样导致的。 再次通过install/index.html页面重新安装,则显示数据库已经安装。原因是WEB-INF/classes/liuxing_db.properties中的db_an=yes变成了db_an=no,表示数据库已经安装,不会再次安装。 最后发现使用安装提示里的第二种手工安装方法可以正常安装系统,人工导入数据库数据就行了。 为了审计代码时全局搜索方便,可以使用jad批量反编译class文件,使用命令如: jad -r -d /path/to/store/java -s java -8 /path/to/classes/files/**/*.class 最后,我将反编译出来的java文件,统一存放在了WEB-INF/java目录下,和class文件的原始目录WEB-INF/classes目录相对应。 0x03:发现漏洞非框架的代码审计,按照前台——后台,严重——低危,非交互——需交互,跟随代码流程尽量发现高危和易利用漏洞类型为主。 一:重安装漏洞像在0x02中说的一样,虽然我使用系统自带的安装功能失败了,但是db_an参数变成了no,虽然/install目录的重新安装页面没删除,但确实使用系统自带的安装功能不存在重新安装漏洞。 跟随/install/index.html页面,找到install.jsp文件,再根据form action,找到install_setup.jsp页面 再根据install_setup.jsp页面上的import语句 import="liuxing.util.Install,java.util.*" 找到安装的主要逻辑源码,在WEB-INF/java/liuxing/util/Install.java中,安装时会判断db_an的值,yes可以安装,no不安装;安装完后会把值置为no,虽然install页面没删除,但是已经不能够再次安装了。 所以,当使用系统自带的install页面安装系统时,不存在重安装漏洞;如果使用手工导入sql文件安装系统,自己又没有把db_an的值写成no,没删除install目录文件时,存在重安装漏洞。 二. SQL注入漏洞首先尝试搜索功能,进入so.jsp,发现将搜索的参数值传入Ruanjianguanli的so方法中 进入WEB-INF/java/liuxing/guanli/Ruanjianguanli.java文件中,找到so方法;发现是调用了ruanjianDao.so()函数, ruanjianDao是什么呢?在Ruanjianguanli类的构造函数里,可以找到,ruanjianDao是RuanjianMySQL的一个实例,那么再接着往下跟 然后打开WEB-INF/java/liuxing/dao/RuanjianMySQL.java文件,搜索so方法,并发现最终是采用预编译来执行数据库操作,这里不存在SQL注入漏洞。 public pageModel so(int pageNo, int pageSize, String tiaojian, int lei, String name) 可想而知,有一处用了预编译,说明就有很多处用了预编译方式来执行SQL语句,基本都没有SQL注入漏洞。然后全局搜索createStatement关键字,看看有没有用拼接的SQL语句的。 如上图,最后也发现几个可以注入的地方,但是都需要登录后台,在delete语句中,可以用时间盲注,比如: delete ...

更多 →

突破封闭Web系统的技巧之旁敲侧击

作者: LandGrey ●   创建时间: 2017年12月27日 22:50 ●   标签:   #分享,   #渗透测试,   #思考

前言:在互联网安全服务公司乙方工作的人或者进行SRC众测等相关渗透测试时,经常碰到客户只给一个"xxx信息管理系统"、"xxx平台"之类的一个Web登录界面的系统的链接地址,其它全凭自己造化,去找漏洞吧!我将上面讲的"需要认证后才能进入系统进行操作,但是当前没有认证凭证"的web系统统一称为"封闭的Web系统",本文认为阅读人员有一定的渗透测试经验,并将就如何突破封闭的Web系统,进行探讨。分享自己的思路与常用技巧,欢迎同道中人一起交流思路。 注:本文有一定的攻击性操作,仅为安全从业人员渗透测试思路交流,请在法律条规允许的范围内进行安全测试。一:文章脉络《突破封闭Web系统的技巧》由两篇文章组成。这是第二篇文章"旁敲侧击"。下面是本文的脉络:旁敲侧击 0x00: 扫端口扩范围 0x01: 寻找测试域名 0x02: 微信公众号与APP 0x03: 寻找蛛丝马迹 0x04: 何方CMS 0x05: 历史漏洞搜索 0x06: 大杀四方二:旁敲侧击经过我们的一阵自杀式……哦不对,字典式冲锋,发现我们将自己意淫成管理员企图从心里战胜"封闭系统"的想法失败了。进不去就是进不去啊,一个低危洞都没有,看来是这系统比较安全了。但是回头一瞟,隔壁座位上的老王喜笑颜开,3个高危已经轻松提交上去,还有2个中危都不屑一看…… 自己心里想着"我真菜",然后决定彻底放弃。直到某天,老王感觉亏欠你太多,向你娓娓道出他那天所施展的姿势……0x00:扫端口扩范围在正面冲锋失败后,我们应该暂时放弃"通过合法的凭证进入Web系统"这个想法,扩散思维,不再局限于Web系统,多关注操作系统、中间件的层面。端口扫描做为一项常用技术,可用nmap、masscan、zmap等工具进行端口探测和服务识别,不再赘述。值得注意的是:不要着急就只扫描TCP协议的端口,UDP协议的端口也不要放过。扫描到一些有趣的端口和服务,就可以尽情的去玩耍了。如果有较多有可能被拿下的服务端口开放,无形中我们直接拿下服务器的概率会大大增加。当别人还在"冲锋"时,我们可能早就通过某不知名端口部署的其它Web应用系统的中间件漏洞进入系统了~0x01:寻找测试域名有些厂商在开发其Web系统时,可能会先单独分配个测试域名来测试正在开发的系统,比如"testapi.land.com"。当系统开发完成后,厂商如愿以偿的将安全的系统部署在域名"api.land.com"上,但是确忘记关闭了"testapi.land.com"。然后,测试域名上仍然开放着N多端口,分别对应着不同版本的Web系统,俨然成为了一个天然的靶场。0x02:微信公众号与APPWeb系统进不去?去看看厂家的微信公众号吧。为了迎合客户和流量,有点规模的企业都会建立自己的微信公众号,而且安全保护的受重视程度通常远低于Web系统。Web系统可能有复杂的图片验证码,而微信公众号可能为了用户体验,并没有设置任何图形验证码;Web系统难以发现的接口可能在浏览微信公众号时的数据包中找到;同理,如果厂家的封闭Web系统是面向多业务员的,那么很可能存在某一或几款APP,存在同样的登录功能,而且也比Web系统要疏于保护。缺少验证码或可能找到一些请求接口和一些有意思的请求参数。除此之外,反编译APP获得其源码,梳理代码中所有敏感的请求接口、连接地址、关键认证逻辑,可能会有意外收获。另外,测试完安卓机上的APP后,如果APP有IOS版本,测下IOS版的APP,说不定有意外收获。0x03:寻找蛛丝马迹最好详细的记录下所有有关Web系统的相关信息。这些信息都有可能成为最后突破的方向,如服务器操作系统类型、使用的框架或组件、使用的容器、使用的CMS类型、服务器版本、开发语言、前端框架等信息。这部分的工具实在太多了,挑拣自己顺手的用就好,比如Firefox插件wapplayer、whatweb、云悉,其它不再赘述。搞不定的web系统,说不定一个Struts2 RCE、Weblogic RCE、Tomcat war包部署之类的漏洞,连服务器的权限都拿到了。另外,对于信息量极少的封闭系统,右击查看源码基本成了必须要做的事,最好把能接触到网页,全部右击查看一遍网站源码。仔细浏览一遍,看看有没有特殊的网页注释、特殊链接之类的,也许一条测试后台的ip地址链接、放置在json文件中的明文配置密码信息,就能让你进入未受保护的测试系统。最后,如果系统条件允许的话,最好用检测普通Web系统的手段对封闭的Web系统检测一遍。比如用主机漏洞扫描器Nessus、web漏洞扫描器 AWVS、Netsparker、Appscan等扫描下网站,防止遗漏重要的Web漏洞信息。0x04:何方CMS如果Web系统不是作为独苗被单独开发的话,那么很可能是由已知的CMS或框架写成的。知名的CMS在 0x03:寻找蛛丝马迹步骤就应该已经知道了。如果它是由没有开放源代码的商业化的CMS改造而成或者不知名的系统建成,我们还有以下几种方式得到它的名字或者源代码。1. 观察页面的特殊css命名规则、js方法名等资源特征,用搜索引擎搜索; 2. 将有特点的页面比如登录页面,截图后利用在线试图,比对相似的系统,或者发到某群中,问下有经验的师傅; 3. 在搜索引擎、文库、Github、百度云盘和其它代码托管、云存储平台上,搜索目标的系统类型名,如"企业印鉴管理系统",同类系统不多的话,很容易就可以搜索出来;如果开发者没有安全意识,极有可能会把源码托管或分享在任何人都可以访问到的平台上,只要不遗漏此步骤,说不定就可以拿到源码; 4. 在页面底部或者扫描到的REAMDE等文件里如果有外包公司等名称或首页,可以借此得知是哪个外包公司开发的什么系统,寻找类似的保护较脆弱的系统,拿到源码。0x05:历史漏洞搜索经过我们上面的工作,我们很可能已经得知系统的名字和版本。这时候,就可以去搜索引擎、wooyun漏洞镜像站、安全客的漏洞搜索、cvel漏洞库去搜索下CMS的历史漏洞,或者厂商以前曾暴露出来的漏洞,可能会发现许多有用的信息!有可能一个以前暴露出来的员工弱口令稍加变形或者xxxCMS 无条件getshell,封闭系统的大门就彻底向我们敞开了。0x06:大杀四方从上文所述,我们可以看出:所谓旁敲侧击的精华思想有两部分,一是规避安全措施做的很好的封闭Web系统,尝试从相关的弱点系统和人着手,间接突破封闭的Web系统;二是通过各种渠道,获得所使用系统的名字和源码,尝试使用历史漏洞或者审计源码,突破封闭的Web系统。最后,老王也缓缓说出了他快速提交漏洞的秘密:原来在N月前,老王在某次渗透测试时,就通过其它网站的wwwroot.rar备份文件。获得了和这个Web系统一样的源码,审计一波已经得到几个0day,0day才是大杀四方的利器啊!三:总结当尝试突破封闭的Web系统并且正面强攻不奏效的情况下,旁敲侧击往往具有强大的杀伤力。其中的技巧往往越猥琐、小众、另辟蹊径,效果越出彩,而且技巧也远远不止上面提到的一小部分。比如,针对性极强的邮件、网页钓鱼套出目标管理员的口令和密码;在所有思路全部中断时,去QQ群搜索下Web系统名或者机构名,编织个巧妙的不敢轻易拒绝的谎言,进去QQ群后,很可能系统源码、默认密码、测试帐号就全部都有了。

更多 →

pydictor爆破字典生成指南

作者: LandGrey ●   创建时间: 2017年11月21日 00:17 ●   标签:   #分享,   #渗透测试,   #python

0x00:简介 pydictor是一个使用python语言开发,遵循GPLv3协议的开源命令行工具,主要用来帮助安全研究人员生成称心如意的暴力破解字典。 以功能强大、简洁实用、适用场景多、自定义程度强为开发目标。 开源地址:pydictor 0x01:特点与功能今天主要是讲pydictor如何结合渗透测试过程常见的场景使用,特点与功能REAME有详细讲解,下面只梳理一下大概脉络,方便下文的理解。 特点:1. 完全使用python的原生库写成,不需要额外安装其它任何的python模块; 2. 同时支持python 2.7+ 和python 3.4+版本,可在Windows、Linux和Mac平台上运行; 3. 可自定义化程度高,留出很多可配置规则的文件; 4. 爆破必备,新老皆宜. 功能:1. 基于三大字符集(d:数字 L:小写字母 c:大写字母)的基础字典; 2. 基于自定义字符集(包括特殊字符)的字典; 3. 排列组合字典(几个字符或字符串的所有排列可能); 4. 用配置文件或者符合pydictor字典语法的字符串直接生成字典; 5. 析取网页中可能有意义的原始单词字典; 6. 基于关键词生成针对性密码字典; 7. 基于性别生成中国公民身份证后4/6/8位字典; 8. 生成一段时间内的生日字典(自定义位数); 9. 用pydictor的handler功能润色下自己的字典; 10.基于个人信息和规则生成社会工程学字典(呃,蹭下知名度,本质还是基于关键词,重在密码规则模式) 11.一系列和字典的整个生命周期有关的内置工具; 包括字典合并、合并后去重、字典去重、单词频率统计、安全擦除字典; 12.一系列和生成优化字典有关的选项; 包括自定长度范围、字典加前缀、加后缀、编码或加密字典、用1337模式、控制字典所用规则的程度、根据数字、字符和特殊字符的个数或种类的多少来筛选字典、用正则表达式来筛选字典等。0x02:使用场景早期开发是为了让功能匹配使用场合,后期开发是让具体场景拥有对应的功能。01:字典合并 字典都不是凭空捏造或生成的,一般都会参考前辈们公布的字典。所以,先收集百八十个字典,放到一个目录下,把字典合并起来吧。1. 合并目录/网站路径爆破字典 2. 合并子域名字典 3. 合并用户名字典 4. 合并弱密码字典 5. ...

更多 →

Django安全编码与实践分享

作者: LandGrey ●   创建时间: 2017年5月17日 17:02 ●   标签:   #分享,   #python,   #django

主要分享关于 Django安全编码与实践 的文章,已经压缩成图片,方便查看。附件1: Django 安全最佳实践.png原文链接: Django 安全最佳实践附件2: 从Pwnhub诞生聊Django安全编码.png原文连接: 从Pwnhub诞生聊Django安全编码附件3: Python安全编码指南.png原文链接: Python安全编码指南

更多 →
<