标签：
有点像第二位演讲者玩命说的，"我给技术人员丢脸了"，不同之处在于他演讲是去打广告的，而我挂着技术人员的称号，实际上却不太懂技术。
因此，往下看之前请慎重考虑是否要继续点鼠标或下拉条。
0x1 内容
....
0x2 跨进程利益内核漏洞提升Android权限
演讲者是申迪 @retme，之前曾搞过Windows，现在关注Android安全。
在这篇演讲中，申迪提到Android的提权分为内核态和用态。内核漏洞的提权不可避免setuid(0)及setgid(0)，最终都要改写相关的结构体。用户态的提权可能由文件属性设置不当引起，可能出现跨进程执行代码，不过要实现权限提升还是得进入到内核层。Linux内核不会经常有这种漏洞，因此更通用的做法是从用户态的应用入手。当然，随着版本的升高，也会不断引入新的安全机制，如Selinux会限制访问内核设备驱动及危险操作如dlopen/mmap。Android > 4.4版本中，即便申请camera权限也无法访问相机设备(PPT中的文字是这么说的)。因此，很多时候虽然我们明知有一个驱动在那里，但就是无法碰到它。
在Android系统中，Application通过API和system_server交互，后者通过ioctl和Kernel交互。system_server在接下来的演讲中扮演了一个重要角色。
申迪以CVE-2014-7911作为案例进行说明，遗憾的是他讲的内容技术性比较强，而且由于幻灯片背景色的原因后面的内容台下基本看不清，只是断断续续记录了以下内容：
CVE-2014-7911和其他很多漏洞一样，由输入校验不足引起。
java.io.ObjectInputStream不校验输入的java对象是否是可序列化的
向system_server传入一个Java对象实例，实例中任何field的值可被恶意构造
上述两点为幻灯片中对该漏洞的说明，其他的没有听懂，随后便说到了堆喷射。Application运行于Dalvik虚拟机，Android和Windows一样存在堆喷射。申迪提到进行堆喷射要使用String对象，通过注册广播的方式反复调用API（system_server），随后将控制的堆内存交换到栈内存（ropgadget）。
正如我一开头提到的，自己不太懂技术，没能搞懂申迪所讲的内容。他提到的5.0不能调用system()及sync("/dev/pmtx")的内容我也无法将相关内容串联起来，最后记住了他所说的重点研究的内容: system_server, drmserver, surfaceflinger, keystore.vold, mediaserver。
0x3 打造移动金融核心程序安全流水线
玩命所讲的内容实际是推广娜伽的Android APP加壳保护方案，这种植入广告的方式有时候会让人很不爽，但作为一个不太懂技术的人，听他的演讲感觉要比retme的更好。如玩命说的，前者是高大上，自己是下里巴人，更加接地气，但这并不说明他的技术不行。
为了保护Android应用程序，尤其金融类应用程序被反编译、逆向或者进行二次打包，一种可行的解决方案是对程序进行加壳。国内做这方面的还有梆梆和爱加密，3BAT也有所研究。对这类应用程序进行加壳保护，除了要考虑脱壳外，加壳后的程序是否能健壮地运行则是一个更加需要重点考虑的因素。很多原声APP能正常运行，但加壳后出现不兼容或出现bug等现象，这些问题都需要解决，因此娜伽有270台真机用于测试。
广告到此为止，下面是玩命提到的一些技术性知识：
娜伽内部对每一款产品的命名方式是X－DOG（他们爱狗），直接说加固方案。Android APP的壳可以从两方面入手，DEX和so文件。
DEX篇——调用类加载器接口
对DEX进行整体加密，内存中进行整体解密
对DEX的类进行抽取加密，运行时分段解密
上面第一种是Android加壳最常用的也是技术含量比较低的方式，因此可以使用zDroid这样的工具轻易脱壳。第二种相对较复杂，技术含量更高，但相比之下兼容性也更差。曾经听梆梆的人说到过这两种方式，去年乌云峰会LBE张勇的paper里也都提到过，有需要的可以去了解下。
so篇
玩命说无论Windows还是Android的加壳和脱壳，了解编译器和链接器等相关知识都是有必要的。另外，谁要是说"不就是加个壳吗", 玩命的态度是you can you up，不要说得加壳很容易一样（Windows下做加壳有名的就那么几家，杀毒软件倒是很多）。
DIS原理－链接器
1. 读取Loader与被保护的符号表，字符串与重定位表
2. 按照Android的哈希规则重新组合Loader与目标文件中的符号表、字符串表
3. 将两个so的代码段合并到一起
4. 合并两个so的重定位表，并修复重定位到新的基地址
5. 修订动态段的符号表，字符串表及充定位表的指向
TDK： Android Native层的SDK，向开发者提供快捷方便的native层保护设计
SDK + (算法模块／保护模块)＋ 目标so ＝ 保护后的so
加的壳还要考虑反动态调试机制，但非root环境下能采取的措施并不多，如双进程反调试。针对双进程反调试，玩命指出双进程一般是一个父进程一个子进程，可以先找到父进程，然后找到子进程的PID，再然后我就不是很清楚了。反反反调试，玩命说他可能会在程序执行前fork() & fork()...总之怎么恶心人怎么弄
这个演讲中，同样提到了android_server，另外提到的两个是gdb和gdbserver，看到这里应该知道它们是干嘛的了
玩命在演讲中多次提到"不难"、"没多少技术含量"之类的话，不排除有扬长避短、为自己增添光环的嫌疑。但作为一个长期研究软件安全的人，的确很可能有很多事情在他眼里是很简单或没什么技术含量的。最后，他说的"破解与反破解，不是技术上的较量，而是耐心的较量”，个人觉得挺有道理，在攻防之路上，一切技术难题都可以交由时间来解决。
0x4 关于Office Word程序的漏洞发掘
演讲者张仁状是独立安全研究者，之前大概没有这种演讲的经验（演讲前的准备和对演讲时间的控制可说明）。
张仁状说，之前看捉虫日记时觉得这本书讲得挺好，但也有一个问题：书中所说的bug有了，但是怎么发现的它们呢？国内技术分享氛围不如国外不说，即便分享了我们也可能是‘知其然，不知所以然‘。
演讲者漏洞挖掘的思路首先来自Microsoft的CVE报告，他发现多数问题都出现在ActiveX相关的地方，这就为他提供了一个漏洞挖掘的方向。
"宏导致的攻击并没有灭绝"，张仁状在引用外部文章时说到，他的shellcoce是写在VBA中的。
通常来说，如果一个word文档中存在宏病毒，电脑上的杀毒软件是可以检测出来的，但是如果（1）VBA代码中没有宏病毒使用的API（2）office文档结构完好，漏洞由VBA自动化操作完成 杀毒软件也是无能为力
张仁状指出，安全软件对文件执行前的静态检查很难奏效，因为shellcode可以加密且分散存储，因此应该将更多精力放在行为检测方面（文件释放，本地操作行为，网络通信方面）。这方面，对服务器上Webshell的检测是否类似道理，则需要专业人士来说明了，但我个人觉得应该也是类似的。
现场演示的之前录下的demo中，加载有shellcode的稳定的确过了360安全卫士、趋势科技、卡巴斯基的检测。
当然，虽然可以绕过杀毒软件的检测，攻击者也不是每次都直接发送恶意的word文档给受害者双击打开的，他可能会：
1) 发送没有恶意代码的宏的a.doc给Bob；
2）发送包含恶意代码的宏的a.doc给Bob.
这样做，是因为要允许宏执行需要得到Bob的同意，他可能会交给安全软件检测；第二次将相同的文件名发给Bob时， 相关记录已经存在于注册表中，打开word会直接执行宏，从而恶意代码得到执行。因此，这里一方面先用无害文档获取受害者信任，另一方面也是为第二次恶意代码的执行创造条件。
虽然张仁状说现在那么多自动化测试工具能做的很有限，只能做一些简单的处理，但不表明自动化或Fuzz是无效的，因为他自己也在这么做。他使用popupkiller处理窗口弹出问题，在使用工具进行测试时触发一个奔溃问题可能就是一个潜在的漏洞，但程序奔溃时工具也会退出，该怎么记录呢？
1）调试器附加到目标进程上（_NO_DEBUG_HEAP）
2）Reflection反射测试控件内部对象（这一点应该不是用于记录奔溃时刻的）
最后，演讲者关于VBA Shellcode给我们提了个醒：
1）VBA shellcode以Unicode形式出现在内存中，要用到StrConv(shellcodeStr, vbFromUnicode)
2) VBA使用‘?‘表示不认识的符号
0x5 基于Binder调用攻击Android系统服务提权
龚广的演讲相比申迪有更多"干货"，他讲述了更多的技术细节，实际上他们的演讲内容也存在很多共同之处，比如通过Binder作为突破口（retme的演讲中也有提到）。
Android系统中有Binder机制，进程间可以通过IPC通信，而和Binder驱动（/dev/binder）之间则为ioctl，但它们之间的权限时不同的。系统服务进程的权限较高（system_server, surfaceflinger, mediaserver），应用进程的权限较低，二者之间存在交互，因此可能出现前面提到的跨进程攻击／提权。
可以使用adb shell service list查看运行中的service，列出来的服务越多自然就表示攻击面越广了。龚广指出，利用这些借口甚至有可能从Chrome沙箱中逃逸出来（技术细节可以上微博私信@oldfresher，不过从微博发布记录来看，龚君上微博较少），更重要的是Binder调用对参数校验较少，这就意味着有更多的利用机会（从低权限到高权限应用的交互有一个flatten过程，反之高权限系统服务进程会进行"unflatten"处理，类似于序列化与反序列化操作）。
龚广以cve-2015-1474为例讲解了堆喷(po)射(huai)中遇到的一些障碍和解决方法。他想控制Binder服务线程变为堆风水，但不同线程会分配相同大小的堆内存，位于不同chunk，线程太多没法堆风水。下面是障碍和解决方案的表：
| 障碍 | 解决方法 |
| 有n个Binder服务线程 | 挂起n-1个线程 |
| ASLR | 地址泄露 |
| 只能写连续地址 | 覆盖je_malloc元数据 |
| NX | ROP |
| Selinux限制不能夹在so | Load From Memory |
| execmem、execmod | ？ |
1）挂起n-1个线程
BufferQueue －－ IGraphicBufferProducer, IGraphicBufferConsumer
－－ system_server, surfaceflinger, mediaserver都会用到BufferQueue
2）堆内存泄漏 －－ IGraphicBufferProducer->requestBuffer native_handle
－－ 泄漏堆地址，多个模块地址，栈地址
3）泄漏栈基址 －－jemalloc pthread_internal_t
4）任意地址写入 －－覆盖指针表中某个值
5）Load From Memory
操作链：Rop code－>shellcode－>Load so from memory code>－>Shared library code>
龚广表示上面第六个问题他目前还没有有效解决方案，受到的限制使代码段即便可写也不可执行，应该是他接下来研究的重点。
0x6 社会工程学攻击的实例化
p0tt1认为网上流传的一些社会工程学案例大多给人一种神乎其神的感觉，而且通常不具备可复制性。在做过大量相关项目后积累了经验后，他试图将社会工程学实例化，即让它变得实际可行，有一定的操作步骤或规范之类的指南。
老实说，听这个议题时兴趣表现得比之前几个更大，一方面是因为这个更能听懂，另一方面也是因为与生活关联更加密切。
p0tt1案例中的两个渗透测试项目，苏宁和蘑菇街，与其说是渗透测试，实际更多的是使用社会工程学，因为无论通常的定义还是他自己的理解，社会工程学算不上技术手段。
社会工程有一个目标，假设叫做未知整体，那么这里未知主体分为两类：网站和个人，苏宁和蘑菇街纳入网站一类，而后面社工的对象王大锤则属于个人，结果都成功了。不论攻击对象是站点还是个人，收集信息都是必要的，比如使用搜索引擎：google，shodanhq，zoomeye，fofa.so，当然还有其他很多线上和线下的渠道。
一些网站，可能站点本身是外包开发的，可以从外包公司那里获取到合作单位列表等信息。还可以通过以下手段获取信息：
＊投诉与建议
＊破坏业务功能
＊伪装与诱骗
＊直接询问
另外，网站自身也看存在泄漏信息之处：
＊网站上一代遗留
＊管理员遗留文件
＊黑客留下后门
＊运维备份文件
如前面提到的，都是非技术上的技术，不再一一描述。
值得一提的是，社会工程学虽然不是技术手段，但是很多时候可以做到纯技术上没法实现的事情。一想到被社工，所有个人信息都在别人面前一览无余，实在是不寒而栗。一些政府事务系统如社保及体检中心等网站，里面包含了大量敏感个人信息，但由于网站存在诸多漏洞，使得我们的信息不可避免遭到泄漏，流入他人手中，包括但不限于：姓名，身份证号，手机号，社交账号，习惯，生活圈......技术改变了我们的生活，但始终是一个工具，虽然能够leverage，也取决于使用它的人在杠杠哪一头。信息系统中最脆弱的一环始终是人，无论习惯，心理还是技术，因此无论企业还是个人，这一点永远都不应轻视。
Day2 .......coming
updating......
标签：
原文地址：http://www.cnblogs.com/r00tgrok/p/4448751.html
