分类目录归档:信息安全

A security flaw in the SQLite Editor application

In some of security conferences last and this year, I’ve said that, if any Android utility tool with root permission has security vulnerability, this may lead to gaining privilege-escalation like ability. In last year, I’ve posted a component exposing vulnerability in a MIUI’s custom application which will leaks system information. Here I’ll introduce another case I discovered recently.

The SQLite Editor is an Android local SQLite database file viewer developed by the Speed Software. In Google Play, it has been purchased and downloaded in more than 50,000 times. Most of its users are introduced by another famous application — the Root Explorer — which is also developed by the Speed Software.

When users give SQLite Editor a root permission by tools like superuser, and then open SQLite files in other applications’ private directories, for example, a file named example.db, according to SuperSU Pro’s log, SQLite Editor will uses its root persmission to change the ‘other’ permission of this file and its related files (include may existings example.db-shm, example.db-wal and example.db-journal) to readable and writeable, and then read or write it by normal permission. After its operations finish, it will restore the ‘other’ permission of example.db to its original value (normally, unreadable and unwriteable). But, it forget to restore example.db-journal’s permission! Thus, the last file will keep readable and writeable by ‘other’ Linux users, which means, it can be read or wrote by other normal applications.

In the Android system, files like example.db-journal are transparently created by the SQLite library, and used for transaction roll back. By our analysis, we found that these files will contain huge content which belong to the ‘example.db’ files, include users’ account password, login token and sensitive privacy data. For example, we all know that the Email in Android and the Browser in old versions’ Android will plaintextly store users’ account and password. In other banking or payment applications’ databases, there’ll be login token and other information. These data should be protected by Android’s security mechanisms. However, this flaw of SQLite Editor will lead these cache of password or data to be read by other applications.

Of course, attack surface of this flaw isn’t wide. It need many pre-requirements to exploit it. But it’s enough to be a typical case to reminder root permission tools developers and system customization developers to more strictly check the security of their code.

A .db-journal file becomes world readable and writeable

A .db-journal file becomes world readable and writeable

SuperSU Pro's log of SQLite Editor's root operations

SuperSU Pro’s log of SQLite Editor’s root operations

Android中webview缓存密码带来的问题

乌云上发布了一个漏洞,称微信记录了用户微博账号的密码。地址是:

http://www.wooyun.org/bugs/wooyun-2013-020246

这个问题的产生原因并不复杂:微信使用webview加载微博的OAuth登录和认证页面,并采用了webview的默认设置。这种情况下,用户输入账户和密码登陆微博时,系统会弹出提示询问是否保存密码。如果用户选择了是,密码就会保存在这个应用私有目录的databases/webview.db中。

同样地问题还出现在许多流行的应用软件中。在我的手机里,至少小米、腾讯、百度等公司的产品都有发现。

危险性如何?由于密码保存在了/data/data/com.package.name/databases/webview.db中,至少这个软件是可以随便读取的。但我审计过上面这些软件的代码,没有发现实际读取和回传这一密码的情况。另一方面,其他应用需要root权限才能读取——至少在Google的安全模型假设里,系统是不应该被root的。不少恶意代码会利用漏洞提权,因此有获得这些密码的可能,但目前还没有这样的案例。

责任在谁?Google曾回信称,这是webview的一个特性,开发者应在具体使用时自己考虑安全性。在这个案例中,腾讯也把责任推给了webview。我的观点是,Android、软件开发商、用户三方都有责任。Android的错误在于,给webview的默认设置是提示用户是否保存密码,而不是默认不保存,以及对天下无root的假设也毫不实际;软件开发商的错误在于,没有更改这个默认设置,将选择权留给了用户,并事实上造成了第三方密码被明文存储(虽然并非主观故意);用户的不当在于选择了保存——但这其实真的不能怪用户,不能要求大家理解这样一个会话界面的背后带来的诸多影响:

webview让用户选择是否保存密码

怎么修复?很简单,开发者在初始化webview实例后,加上一行代码:

theWebView.getSettings().setSavePassword(false);

就将其设置为不保存密码了。用户没有选择,也就避免了后面的问题。

最近关于secmobi的事

两个月前,我决定建设secmobi.com这个移动安全的专题站点,于是这两个月的业余时间,包括十一假期,就都搭进去了。主要做了这样几件事:

基础设施。域名是此前花了一周的时间挑选注册的,站点部署在了原来的虚拟主机上。九月份又购买了专门的VPS,自己从头开始搭服务器,做安全加固,然后将站点和数据做了迁移。还对主题做了很多定制,十一又换成了wordpress还没发布的官方主题twentytwelve,再次定制(我对PHP和CSS真的不熟啊啊啊)。

框架内容。包括站点框架、栏目设计、简介等,做了三次大的更改。其实站点定位和关注的主题也有多次变动。主要经验是,1. 逐渐才能找到感觉;2. 范围不断地缩小,最后收敛,太散了一是没重点,二是顾不过来。目前的定位是,通过这个站点汇集和分享Android和iOS上关于软件安全、反病毒、软件保护、设备取证的资讯、资源和知识。

博客。这个是最初的主体,一开始的设想是即时地发布相关新闻、进展,以及我积累的大量资源。然后迅速地发现时间绝对不够,新闻是海量的,筛选、阅读、分析,书写、翻译(对的,这个网站是中英文双语的),需要的时间太多。于是改为一周统一发布一次。但现在也有些心力不足。anyway,这个一定会坚持。博客的地址是:http://www.secmobi.com/blog/

维基。源于自己积累了大量资源,乱糟糟地没有整理过。终于决定用wiki来管理,考虑了很久,决定完全公开出来。在两种系统中选择了dokuwiki,然后又做了大量设置、优化和界面调整(完美主义真是坏习惯)。然后花了将近两周的时间来完善内容,现在还在进行中。也请大家一期建设,目前注册和编辑都是完全开放的。wiki的地址是:http://wiki.secmobi.com/

服务。VPS很贵,建设和维护这个站点又已经占用我的几乎全部业余时间(并且可以预见将来也会是),因此考虑在公益地提供博客、维基之余,能否获得一定的回报。选择有很多,但从我几年前选择独立空间+独立域名开始,就不考虑广告了(虽然这确实是最方便最稳定的),而在国内要求donation又不靠谱,于是只能选择做服务。能为其他人提供价值的项目,选择了很久,最后定为Android逆向技术和软件安全方面的培训,以及软件安全测试。目前已经上线,可以看:http://www.secmobi.com/services/,也希望大家能支持。

另外,正在准备做的事情还包括:1. 整理以往各种对外报告的幻灯片,打算陆续发布出来;2. 正在写原创的技术白皮书,保证都是充满干货的,不说废话,让读者有收获,白皮书也会发布出来。

这就是最近主要做的事情。另外的事情是,准备和参加各种会议、交流、沙龙,以及写稿子。这些事情加起来,已经把工作之余的所有时间占满,非常充实,也有些累。继续努力。

(我会告诉你们这是个广告软文么?)

两个会议回视

这周去xkungfoo和xcon,是第一次参加国内的安全方向纯技术会议。其实只去了三天,只认真听了一天,所以没法谈对具体议题的看法了。

与我想象中相同的是,xcon的主要用处果然是大家来聚一聚了。不过并不适合新人来拓展业内关系,主要还是已经在线上结识的或者以前就见过的人再次聚会。老实说,如果一个新人想要融入国内的这个圈子,感觉还是蛮难的。

技术上来看,依然是大部分人关注Web安全和软件安全,少数移动安全和支付安全。对新的趋势、新的领域、新的方法,还是老外更积极(比如Chengyun Chu的Windows 8安全,Stefan Esser的iOS堆利用,Paul Craig的受限环境)。Antiy做的计时器攻击也许算是个例外,我觉得demo部分的水平差不多够BlackHat了。

整的来看,水分还是有,不一定比得上台湾的HITCON议题有趣。我的猜测是,首先,国内的老牌高手很可能都不屑于跑出来讲了,这一点倒是和国内整个IT界气氛蛮像,十年以上的老程序员很少见,而国外正是这些人支撑起Microsoft、Google的核心团队;另一方面,独特的商业环境也可能导致封闭的企业文化;最后,关于漏洞上报流程和方法以及由此产生的争议,正体现出国内企业对安全的认识和态度依然存在问题。

另外比较诧异的是国内同行在英语方面的水平低于我的想象(虽然我自己的英文也一般)。这是我对产业最大的担忧之一。

由于在xkungfoo有做分享,得以见到业内许多前辈,也和很多朋友“相认”或者有交流。特别感谢热情的黑哥。

最大的收获是,发现自己的问题还是蛮多的,一是技术不够实践(比如对我分享内容的一些质疑),二是了解得不够深。另外,许多人在这个领域有多年的积累,真的让我很难再有自满的感觉。我的知识面也不够广,即便是做移动app安全,还是不可避免地会涉及web安全、网络安全等,每次遇到与此相关的,我都会很囧。

这几天我一直在想,怎么样可以建立良好的技术交流平台。这个事情非常困难。与kanxue的聊天也能感受到他的一些无奈。最后一天有幸听到Jeffery Moss的演讲,这确实是一个有领袖气质的人,他关注整个产业的动态和趋势,有自己的思考,并且会去传播他的理念。这也许会是值得学习的方向。

anyway,接下来需要做到的是:低调、严谨、继续努力、保持视野。

介绍几个Android分析工具

1. otertool

动态分析的瑞士军刀,功能包括:logcat筛选、文件系统diff、apk->smali及搜索、java->smali、app data browser(以及内嵌的text/hex/sqlite viewer)、smali编辑并一键build apk(可以签名)、一键安装apk、安装证书等。

地址是:https://github.com/wuntee/otertool,支持Linux和Mac OS。

如果你坚持用手机而不是模拟器分析,并且版本在4.0.3以上,otertool会有问题。可以用我的patch版本:https://github.com/secmobi/otertool

2. 010 Editor

文本和十六进制编辑器,主要好用的是,用拓展语言写文件格式解析模板,这是我一直想做的事情,果然已经被实现了。官方提供了多种文件格式的模板,包括DEX。(其他SWF、PDF、PE的也不错)

地址是:http://www.sweetscape.com/010editor/,支持Windows和Mac OS。售价50刀。不要问我买没买,你懂的。

3. Charles Proxy
HTTP/HTTPS Proxy。在Android/iOS中导入根证书后,可以将流量通过代理方式转给Charles开启的本地转发服务,它相当于中间人,负责与目标服务器通信,并自动生成同名的证书与客户端通信。这样,就可以看到HTTPS流量的所有内容了。

地址是:http://www.charlesproxy.com,支持Windows、Linux和Mac OS。售价也是50刀。

4. CocoaPacketAnalyzer
Mac OS下的抓包、包解析软件,功能没有wireshark强大。唯一的优点是,它是原生的,界面比较好看。而wireshark基于x11——mountain lion对x11的那个支持真是无语。

地址是http://www.tastycocoabytes.com/cpa/