This article is from WeChat official account:Big Data Digest (ID: BigDataDigest), original title “three months, five hackers to find vulnerabilities Apple 55, earned more than $ 50,000, also wrote a blog about the whole”, author: Liu Junhuan, Branch Zhu Jin, lin , The title picture comes from: Visual China
Yesterday, the eagerly anticipated iPhone12 finally came out. Whether it is returning to the classic box design or launching the small-screen mini version for the first time, Apple players are hooked.
However, before this year’s special press conference, Apple, known for its security, was suddenly exposed to 55 vulnerabilities.
Friends who want to chop their hands can relax, because these vulnerabilities have been reported to Apple by 5 hackers, and they have made a small profit and received a reward of $50,000.
This is how it is. Apple has always had a tradition of providing financial rewards to bug reporters, and gave this project a cool name-Apple Bug Bounty Program. In July of this year, Brett Buerhaus, a senior technology practitioner, saw on Twitter that a colleague was rewarded with $100,000 from Apple for discovering Apple’s authentication bypass bug. He was very excited and called 4 hackers. Together with friends, study the entire basic program of Apple. After three months of research and analysis on Apple’s online services, 55 vulnerabilities were found, some of which are still very dangerous.
For example, an unsuspecting person can use these vulnerabilities to create a worm that automatically steals all photos, videos, and documents in someone’s iCloud account, and can even perform the same attack on the victim’s contacts.
Sounds too scary, the digest bacteria gripped the broken iPhone…
Fortunately, after discovering these vulnerabilities, these five hackers have already reported to Apple, and Apple has fixed these errors immediately.
Brett Buerhaus then also recorded the process and all the vulnerabilities on his blog in the form of self-report.
The first step in hacking Apple is to figure out what the actual goal is. Both Ben and Tanner are experts here, so they started to figure out all the Apple content we can access. All the results of their scans are indexed in the dashboard, which includes HTTP status codes, headers, response bodies, and screenshots of web servers accessible under various domains owned by Apple, which we will refer to during the participation process These ones.
In short: Apple’s infrastructure is huge.
They have the entire 17.0.0.0/8 IP range, including 25,000 web servers, of which apple.com has 10,000 web servers, another 7,000 unique domains, and most importantly, they have their own TLD(click the apple). Our time is mainly spent on the 17.0.0.0/8 IP range, .apple.com and .icloud.com, because that is where the interesting features are.
After listing all the web servers, we start to run the directory on more interesting serversBrute force.
Blog address: https://samcurry.net/hacking-apple/
This blog quickly attracted the attention of overseas media and many netizens.
Shortly after the foreign media vice reported on the incident, one of the hackers, Sam Curry, said on his personal Twitter that Apple told them that they still had a chance to receive a total of 288,500 US dollars in rewards, because before Apple only They paid for some vulnerabilities, and now they are ready to add 28 additional vulnerabilities.
50 thousand bonus, is it more or less?
Speaking of this project, Sam Curry said in his blog post, “I didn’t expect it would take us more than 3 months.”
“This was originally a subsidiary project. We will work on it every once in a while. However, under the influence of the new crown epidemic, we have a lot of extra free time. In the end, it accumulates and everyone puts in on average Hundreds of hours.“
>
However, in this incident, people are more interested in the amount of bonuses given by Apple than the loopholes discovered by hackers.
Let’s do a little math. Five hackers spent “hundreds of hours” researching Apple’s online services. They found 55 vulnerabilities in three months. Apple rewarded them with $50,000. If you count this, each person is worth about each vulnerability. $250, or the “salary” per person per month is $17,171.
Dan Tentler, founder of the security company Phobos, lamented that it was “very low.”
Tentler told Motherboard in an online meeting: “In my opinion, a security assessment of two to four weeks is worth about $50k, regardless of what the 5 hackers found The question itself is actually more valuable.”
“Imagine if any criminals threatening national security discover and exploit these vulnerabilities, the damage would be great. However, Apple told them and the public that all this is only worth 50,000, which makes me It is inexplicable, and it runs counter to their claim that privacy and security issues will be taken seriously.”
However, according to Katie Moussouris, a well-known bug bounty expert, the amount given by Apple may be fair.
Moussouris said: “The skills required to find network-based vulnerabilities are easier than mobile or iOS.”
“Logically, Apple will pay higher amounts for those who can hack into its core operating system. This may also be why Apple is willing to pay for system vulnerabilities such as iCloud data breaches.”
Moussouris concluded: “The real problem is that Apple can provide documentation to professional penetration testers so that they can find more vulnerabilities in less time instead of wasting time on black box inspections, especially considering The price of the two will not differ too much.”
There is a gimmick, but the bonus is too small, and no one wants to report the bug to Apple
After the hackers reported the discovered vulnerabilities to Apple, an Apple spokesperson said, “We value cooperation with security researchers to help ensure the safety of users. Thanks to the team’s assistance, we willReward them in the curity Bounty program”.
Apple Security Bounty is a program announced by Apple in 2016. Ivan Krstic, the head of Apple’s security engineering and architecture at the time, announced on Black Hat that Apple will start to provide A cash prize of up to 200,000 USD.
The establishment of Apple Security Bounty aims to eliminate certain secrets of the security architecture and is open to hackers, researchers and cryptographers who are willing to help improve Apple’s security. This includes HomeKit, AutoUnlock and iCloud keychains. security function.
However, in the past four years, although Apple has slowly started to award rewards to some researchers, in general, this plan has not achieved its original purpose. Because for most security researchers, participating in this program may not be cost-effective, they need to invest a lot of energy, and the final income cannot possibly justify the initial time investment.
A former Apple employee complained on Twitter, “Bonus is the best labor.”
In 2017, Motherboard interviewed some security researchers, they all said that iOS vulnerabilities are very valuable, but in contrast, Apple gives too little bonus, because even if they find vulnerabilities, they will not report to Apple, These vulnerabilities It can be sold at higher prices on the black market.
Zimperium security researcher Nikias Bassen said: “Selling vulnerabilities to others can get a higher price. For those who make a living, they will definitely not choose to report the vulnerabilities directly to Apple.”
However, there is no doubt that these five people will earn more income in the next few months.
“I think Apple might pay the same amount of money as these discoveries. To be fair, we solved a large number of problems in a short time, but the process of dealing with these problems is much more difficult than reporting 1 or 2 problems .”
Nevertheless, this is just another example of what many experts in the error expert bounty industry consider to be a big problem. As the network security consulting company Trail of Bits wrote in a blog post last year, “Trying to make a living as a programmer by participating in bug rewards is like convincing yourself to be good enough in Texas and you can live a normal life when you quit your job.” .
What Apple vulnerabilities did hackers find?
Presumably by now, everyone is still very curious about which vulnerabilities in Apple have been discovered by these hackers.
Don’t worry, on the blog, Brett Buerhaus disclosed the 55 vulnerabilities they found. Here, I have selected two of them, and let everyone have an eye addiction.
Blog link: https://samcurry.net/hacking-apple/
By bypassing authentication and authorization, the Apple Outstanding Educator Program was completely breached
One of the first servers we spent time hacking was the “Apple Distinguished Educator” website. This is an invitation-only Jive forum where users can use their Apple account for authentication. The interesting thing about this forum is that some of the core Jive functions of registered applications are transplanted through custom middleware pages established by Apple, so that their authentication system (IDMSA) is connected to the underlying Jive forum using username/password authentication.
The purpose of this is to allow users to easily use their existing Apple account to verify their identity without the need to create an additional user account. You only need to use “Login with Apple” to log in to the forum.
The login page of users who are not allowed to enter the forum is an application portal. You provide your own information, and the forum moderator will evaluate and approve it.
When you submit an application to use the forum, just as you normally register for the Jive forum, you provide almost all of your account information. This allows Jive forums to know who you are based on your IDMSA cookie, because it binds the email address of your Apple account to the forum.
On the application registration page, there is a hidden information field “password” with a value of “##INvALID#%! 3”. When you submit an application including username, name, email address and employer, you are also submitting a “password” value, which is secretly bound to yours from a hidden input field on the page On the account.
...After observing this hidden default password field, we immediately thought of a way to manually authenticate the application and access the approved account of the forum instead of trying to log in with the “Log in with Apple” system. We adopt this method because each of us has the same password when registering separately.
If someone uses this system to apply, and there is a function of manual authentication, you can simply log in to their account with the default password, completely bypassing the “Login with Apple” login.
On the surface, it seems that you can’t authenticate manually, but after searching on Google, we found a “cs_login” endpoint, which is used to log in to the Jive application with a username and password. When we manually made a test HTTP request to verify the Apple Distinguished Developer app, we found that it tried to verify us by displaying the password error. When we used the account we applied for before, the application did not allow us to authenticate because we had not been approved yet. If we want to perform identity verification, we must find the usernames of approved members.
At this time, we load the HTTP request into Burp Suite’s intruder, and try to forcibly enter a user name of 1 to 3 characters by logging in and the default password.
About two minutes later, we received a 302 response, indicating that the default password was used to successfully log in to the userThe account name “erb”. We succeeded! Now, our next goal is to authenticate the identity of people with high authority. We took a screenshot of a few access records, and click on the “Users” list to see which users are administrators. We logged in to the first administrator account we saw in the list, trying to prove that we can achieve remote code execution through management functions, but we encountered some obstacles.
When we tried to browse “/admin/”(Jive Administrator Console) as an administrator account, the application redirected to login The page looks like we have not passed the certification yet. This is strange because this is just the behavior of the Jive application, and we have not observed this before. Our guess is that Apple restricted the management console based on the IP address to ensure that the application was never completely compromised.
The first thing we tried was to use X-Forwarded-For to bypass the limits we guessed, but unfortunately, this failed. The next thing we tried is to load different forms of “/admin/” in case the application has a blacklist of specific paths to access the administrator console.
After just a few HTTP requests, we found that “GET /admin;/” allows the attacker to access the management console. We set up a Burp Suite rule to automatically change the “GET/POST /admin/” in the HTTP request to “GET/POST /admin;/” to achieve automatic bypass.
When we finally found and loaded the management console, the obstacle appeared again. We can’t use general functions to demonstrate remote code execution (no templates, plug-in uploads, and no standard management and debugging functions).
At this time, we stopped and thought about our own problems and realized that the account we authenticated might not be the “core” administrator of the application. We continued to authenticate 2~3 accounts, and finally authenticated as the core administrator, and realized the function of remote code execution.
The attacker can (1) bypass the authentication manually by using the hidden default login function, then (2) access the management console by sending the modified HTTP path in the request, and finally (3) upload by using a plug-in, One of many RCE functions such as template or file management can completely destroy the application.
In general, this will enable an attacker to do the following:
Execute arbitrary commands on the ade.apple.com website server;
Access the internal LDAP service to manage user accounts;
Access most of Apple’s internal networks.
Storage cross-site scripting vulnerability: allows attackers to steal iCloud data by modifying emails
One of the core parts of Apple’s infrastructure is their iCloud platform. This website serves as an automatic storage mechanism for Apple product photos, videos, documents and app-related data. In addition, the platform also provides services such as mail and find my iPhone.
Mail service is a complete email platform, users can send and receive emails, similar to Gmail and Yahoo. In addition, there is a mail application installed by default on both iOS and Mac. The mail service is hosted on “www.icloud.com” together with other services such as file and document storage.
This means that from an attacker’s point of view, any cross-site scripting vulnerability will allow the attacker to retrieve any information they want from the iCloud service. At this point we started looking for any cross-site scripting issues.
The working method of the mail application is very simple and straightforward. When the service receives an email and the user opens it, the data is processed into a JSON blob, filtered, cleaned and decomposed by JavaScript, and then displayed to the user.
This means that as far as content filtering is concerned, there is no server side to process emails, and all the actual functions of rendering and processing the body of the email are in the JavaScript done on the client side. This is not necessarily a bad thing, by understanding we need to be in the source codeWhat can be destroyed in the process can simplify the process of identifying XSS.
XSS stored based on Style tag confusion
When testing this feature, one thing I finally encountered was the “
” tag. This means that if we write “
The email popped up in my inbox. I clicked it. There is an alert! It worked!
The DOM of the page includes the following:
Because the mail application is hosted on "www.icloud.com", this means that we have browser permission to retrieve the HTTP response of the corresponding API of the iCloud service.(If we can dive into JavaScript to contact them).
The explanation of the above payload is as follows:
At this point, we think the coolest proof of concept would be to steal all the victim’s personal information(photos, calendar information and files), and then forward the same exploit to all its contacts.
We built a simple PoC that will return the photo URL from the iCloud API, paste it into the image tag, and append the contact list of the user account below it. This shows that these values can be retrieved, but to infiltrate them, we must bypass the CSP, which means that in addition to ".apOutside of ple.com" and several other domains, there is no other simple outbound HTTP request.
Fortunately for us, the service is a mail client. We can simply use JavaScript to send an email to ourselves, attach the iCloud photo URL and contact, and then send the victim's signed iCloud photo and file URL.
The following video shows proof of a concept in which a photo of a victim was stolen. In a fully exploited scenario performed by a malicious party, the attacker can steal all the photos, videos, and documents of the victim quietly, and then forward the modified email to the victim’s contact list, and implement cross-cutting of the iCloud mail service. Site script payload worm attack.
XSS based on hyperlink obfuscation storage
Later, I discovered a second cross-site scripting vulnerability that affected mail in a similar way.
For such semi-HTML applications, one thing I always check is how they handle hyperlinks. Automatically converting unmarked URLs into hyperlinks seems intuitive, but if it is not properly cleaned up or combined with other functions, it can become very confusing. This is a common place to find XSS because it relies on regex, innerHTML, and all acceptable elements that can be added next to the URL.
The second interesting feature of this XSS is to completely remove certain tags, such as "https://domain.com/abc
After sending the above content through the email itself, the content analysis is as follows:
This is very interesting at the beginning, but it can be a bit difficult to use. It is easy to define attributes in tags (such as src, onmouseover, onclick, etc.), but providing values is very difficult because we still need to match the URL regex, so that it will not escape the function of automatic hyperlinks. The payload that finally works without sending single quotes, double quotes, brackets, spaces or backquotes is as follows:
https://www.icloud.com/mail/#https://www.icloud.com/onmouseover=location=/javascript:alert%28document. domain%29/.source;//The payload generates the following content in the DOM:
https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//And give us this beautiful warning:
This payload comes from a CTF solution by @Blaklis_. I initially thought that it might be unavailable XSS, but there always seems to be somewhere that can solve XSS in border cases.
My best explanation is (1) When loading the initial URL, the characters in "" are acceptable during the automatic hyperlink process and do not break it, then (2) delete The script tag creates a blank or some type of void, which resets the automatic hyperlink function without turning off the initial hyperlink function. Finally (3), the second hyperlink adds extra quotation marks. The quotes are used to break the href and create the onmouseover event handler.
The effect of the second XSS is the same as the first XSS, except that the user must trigger onmouse by placing the mouse at a certain position in the body of the emailOver event handler, but you can simplify this part by making a hyperlink to the entire email to make it easier to trigger.
In general, attackers may abuse this information to:
Create a worm virus that can silently leak/modify iCloud account information (including photos and videos);
Silent execution of arbitrary HTML and JavaScript in the victim’s browser.
At the end, do you think Apple has given less than $50,000? Welcome to discuss~
Related reports:
https://www.vice.com/en/article/v7g5ea/hackers-found-55-bugs-in-apple-productsmade-dollar51500 p>
https://techcrunch.com/2016/08/04/apple-announces-long-awaited-bug-bounty-program/
This article is from WeChat official account:Big Data Digest (ID: BigDataDigest) author: Liu Junhuan, Zhu Jin Branch, li