Multiple Vulnerabilities in ntpd (April 2015) Affecting Cisco Products(CVE-2015-1798分析)

CVE-2015-1798分析

Multiple Vulnerabilities in ntpd (April 2015) Affecting Cisco Products

漏洞链接:http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20150408-ntpd
从CISCO固件中提取c7200-adventerprisek9-mz.152-4.M8中提取C7200-AD.BIN文件,并把e_machine标记为0x08(MIPS指令)。
我们先看一下官方描述,可以知道是在NTP封包数据中处理中出现了问题。

1

我们首先找到我们要分析的关键函数ntp_receive,开始代码逆向。如果利用ntp.org的代码进行修改,整个过程就会变得事半功倍。尤其在数据结构方面,对代码逆向起到至关重要的作用。

2

逆向完成后,我们对比代码,发现主要区别在这个位置:

3

我们再来看一下汇编代码:

4

红色方框中的代码不相同,紫色方框中的代码的相同。

我们再来对比一下NTP.ORG的官方源代码(4.2.8p1和4.2.8p2):

5

当我们构造数据包的时候,把MAC数据去掉,也可以通过验证。

Fuzzing,从精通到重新入门 (一)

0、序
Fuzzing是一种成本低廉但高效的漏洞挖掘技术。这种技术最早来源于何处已不易考,但在最近几年应用的范围非常广泛,特别是随着一些成熟的自动化工具,例如grinder等的陆续开源,大量没有反汇编基础的脚本小子也陆续加入了漏洞发掘的大军中,并一跃成为所谓业界大牛。因为工作需要,上级领导交代下来了寻找漏洞的任务,笔者于是乎暂时抛开了手中的焊枪,试图通过实践和笔记的方式带你一起揭开国内外知名安全厂商华人大牛的成功之路。

1、目标与硬件
Fuzzing技术应用最广泛的领域往往也是测试门槛最低的领域,例如微软产品中,Internet Explorer(以下简称IE)和内核一向是CVE数量集中爆发点。鉴于内核的复杂程度远远不能比拟浏览器,笔者因此选择了IE作为浏览器作为测试目标。纵观各类浏览器,外部来看都是对HTML和JavaScript等的解析与支持,内部而言也都有建立DOM树和渲染等一整套机制,这方面的共性表明,一个合格的fuzzer应该涵盖不同的浏览器。综合以上原因,笔者同时选择了主流的四种浏览器作为fuzzing对象,它们分别是Internet Explorer,Chrome,Safari和FireFox。可能有人说FireFox已经死了,Safari脑子有问题的才用,笔者只能表示倘若放着浏览器不fuzz的话,除了诗和远方,连情怀都一并丢掉了。
除了浏览器,大规模杀伤性fuzzing的CVE中似乎还混进了些奇怪的东西,这就是漏洞辈出的Flash。为了保证fuzzing的多样性和完整性,作为浏览器的有益补充,笔者经过深思熟虑最终还是将Flash纳入了fuzzing的实践范围。
硬件系统而言,由于Safari的存在,最便宜的似乎只能选择MacMini,也就是最低配置3488软妹币一台……太贵了。一个创业公司,括号连凳子家具都是淘的二手那种,正确的选择必须是二手服务器。在经过多方论证后,笔者终于发现,多核服务器加上足够的内存可以完美运行各类虚拟机,这样硬件也决定下来,统统是PC服务器,型号配置一致还有一个好处,装windows可以不用每台机器都去激活,拷贝过来就能用。
IE、FF、Chrome、Safari加上不要钱的Flash,十台服务器,万事俱备。
还缺一个,服务器里的虚拟机可以挂,收集结果的服务器不能挂,另外买台二手台式机,配个GTX970前台玩屁股先锋,后台收集结果足够了。

2、虚拟机安装
废话笔者就不多说了,服务器上安装ubuntu并将QEMU/kvm更新到最新版本,辅助工具libvirt之类酌情安装。IE版本众多,XP对应IE8,Vista对应IE9,Win2012(注意不是r2)对应IE10,Win7对应IE11,Win7不小心升级后对应Edge(请忽略这个没人用的版本)。此外,Chrome不支持XP,所以请在Win7安装Chrome。FireFox不挑食,XP下运行顺利。Flash随便装哪里都可以。安装过程颇为乏味,打补丁更是慢得一比,诸君同笔者一样多多忍耐吧。
免费附送一些有用的命令行:

qemu-img create massivefuzzing00.img 2G
sudo qemu-system-x86_64 -hda ~/massivefuzzing00.img -m 2048 -vnc :1
sudo virt-install –name tigon00 –ram 2048 –vcpus=1 –disk path=massivefuzzing00.img –os-variant=winxp –accelerate –graphic vnc,listen=0.0.0.0,port=8888,password=1233211234567 –cdrom /dev/null –force

慢着,漏了个Safari哦。这个虚拟机安装略微复杂一些,限于篇幅这里就不多说了,需要安装的版本是10.9.5,因为10.10或者10.11目前装在虚拟机上会出现和女乔丹胸部一样大的问题.你需要做的是首先去百度OS X的镜像文件,接下来的安装过程耗费20G左右的虚拟磁盘,另外还要一个叫enoch_rev2795_boot的东西,当然软件更新也是必不可少的一步。总而言之这些都做完后,虚拟机就算是安装完毕了。将虚拟机激活,然后通过网络拷贝到不同的服务器上测试下是否正常运行。之所以说这句话是因为Ubuntu16下偶尔会出现各种想不到的问题,倘若Windows虚拟机无法正常使用,请换Ubuntu14下测试。
每台服务器都测试一下是必要的,随后的fuzzing可能会因为软件更新而频繁更新硬盘镜像文件,多余的时间一定不能耗费到兼容性与反复激活的琐事上。记住,人机分离十米自动报警,不不不,我是说,跑得快不一定赢,不跌跟头才是成功。

待续。待我把党章抄完,下次再补上osx虚拟机安装和启动的命令行。

Cisco IOS and IOS XE Software SSH Version 2 RSA-Based User Authentication Bypass Vulnerability CVE-2015-6280分析

CVE-2015-6280分析

Cisco IOS and IOS XE Software SSH Version 2 RSA-Based User Authentication Bypass Vulnerability

漏洞链接:�0�2CVE-2015-6280

从CISCO固件c880data-universalk9-mz.SPA.154-3.M2.bin中提取C880DATA.BIN文件,并把e_machine标记为0x14(PowerPC指令)。

我们从官方公告可以知道,想要成功利用这个漏洞,必须知道一个使用了RSA-base 私钥认证的SSHv2的正确用户名和Publickey,否则是不能利用成功。

为了更好的分析这个漏洞,我们先来看看SSHv2的验证过程:

SSHv2验证阶段 客户端 服务器端
密钥交换部分
用户认证部分 SSH2_MSG_SERVICE_REQUEST
用户认证部分 SSH2_MSG_SERVICE_ACCEPT
用户认证部分 SSH2_MSG_USERAUTH_REQUEST none
用户认证部分 SSH2_MSG_USERAUTH_FAILURE
用户认证部分 SSH2_MSG_USERAUTH_REQUEST publickey, have_sig=false
用户认证部分 SSH2_MSG_USERAUTH_PK_OK
用户认证部分 �0�2SSH2_MSG_USERAUTH_REQUEST�0�2 publickey, have_sig=true
SSH2_MSG_USERAUTH_SUCCESS
通道通讯部分

根据公告描述,攻击者必须有正确的用户名以及正确的公钥,可以推测问题出现在第二次(也就是最后一次签名部分)SSH2_MSG_USERAUTH_REQUEST。

接下来,我们去找来OpenSSH源代码和固件一起进行对比分析,这会让我们事半功倍。

 

1

 

我们跳过密钥交换部分(ssh_kex2),直接从验证部分开始分析(ssh_userauth2)。根据最后验证成功的条件,我们进行逆向推理,更容易找到问题,因此从SSH2_MSG_USERAUTH_SUCCESS这个成功封包开始逆向分析。我们从固件中看到如下代码:

 

2

 

 

我们可以看到这个地方就是验证通过后,最后的服务器数据封包。我们往上面回溯。

3

 

 

关键函数在do_pubkey函数, 只要这个函数返回1就可以验证通过。

 

4

 

这段代码对应openssh源代码的send_pubkey_test阶段:

 

 

5

 

在公告中,官方已经明确指出需要正确的用户名和对应的publickey。也就是_pubkey_verify这个函数必须通过。紧接着的部分就是响应服务器的SSH2_MSG_USERAUTH_PK_OK封包(客户端处理参考input_userauth_pk_ok函数),也就是带有签名的SSH2_MSG_USERAUTH_REQUEST,即sign_and_send_pubkey函数

 

6

 

7

 

看这两处的代码,service比较失败,会断开连接,并返回retcode=3; 但当method比较失败的时候,并没有改变retcode的值,也就是前面_publickey_verify的返回结果1,而且,服务器也不主动断开连接。问题就是出在这儿,我们继续看_Exit_with_Cleanup出的代码:

 

8

 

这儿我们就可以看到我们如果method方法不同,我们仍然可以返回1。

 

9

 

 

分析到这儿,就发现和我们最开始分析的对应起来了。我们就知道我们该如何构造我们的PoC代码了。
最后看一下利用成功后的调试信息:

10