此前，我对“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从内部修复了代码运行机制，消除了异常处理的响应内容，堵塞了漏洞。

PoC视频

*参考来源：amolbaikar，clouds编译，转载请注明来自FreeBuf.COM