+```
+
+observing the hidden default password field leads to
+- find a way to manually authenticate to the application and access an approved account for the forum
+- instead of attempting to login using the “Sign In With Apple” system.
+
+We investigated this because the password was the same for each one of us on our separate registrations.
+
+If anyone had applied using this system and there existed functionality where you could manually authenticate, you could simply login to their account using the default password and completely bypass the "Sign In With Apple" login.
+
+From a quick glance, it did not appear that you could manually authenticate
+- after a few Google searches we identified a `“cs\_login”` endpoint which was meant for logging in with a username and password to Jive applications.
+ - manually formed the test HTTP request to authenticate to the `Apple Distinguished Developers application`,
+ - it attempted to authenticate us by displaying an incorrect password error.
+ - used our own accounts that we had previously applied with, the application errored out and did not allow us to authenticate as we were not yet approved.
+ - would have to find the username of an already approved member if we wanted to authenticate.
+
+
+
+
+
+At this point, we loaded the HTTP request into Burp Suite’s intruder and attempted to **brute force usernames** between 1 and 3 characters via the login and default password.
+- After about two minutes we received a 302 response indicating a successful login to a user with a 3 character username using the default password we found earlier.
+- We were in!
+
+
+next goal was to authenticate as someone with elevated permissions.
+- took a few screenshots of our access and clicked the “Users” list to view which users were administrators.
+- We logged into the first account we saw on the list in an attempt to prove we could achieve remote code execution via the administrative functionality, however, there were still a few roadblocks ahead.
+
+
+
+
+
+When attempting to browse to “/admin/” (the Jive administrator console) as the admin account
+- the application redirected to login as if we were not yet authenticated.
+- This was strange, as it was custom behavior for the Jive application and none of us had observed this before.
+- Our guess was that Apple had restricted the administration console based on IP address to make sure that there was never a full compromise of the application.
+
+One of the first things we tried was using the X-Forwarded-For header to bypass the hypothetical restriction, but sadly that failed.
+
+The next thing we tried was to load a different form of “/admin/” in-case the application had path specific blacklists for accessing the administrator console.
+
+After just a few more HTTP requests, we figured out that `“GET /admin;/”` would allow an attacker to access the administration console.
+- We automated this bypass by setting up a Burp Suite rule which automatically changed `“GET/POST /admin/”` to `“GET/POST /admin;/”` in our HTTP requests.
+
+
+
+When we finally navigated and loaded the administration console, it was immediately clear that something wasn’t right.
+- We did not have access to the normal functionality that would demonstrate remote code execution (there was no templating, plugin upload, nor the standard administrative debugging functionality).
+
+
+
+the account we authenticated to may not be the “core” administrator of the application.
+- We went ahead and authenticated to 2-3 more accounts before finally authenticating as the core administrator and seeing functionality that would allow for remote code execution.
+
+
+
+An attacker could
+1. bypass the authentication by manually authenticating using a hidden default login functionality,
+2. then access the administration console via sending a modified HTTP path in the request,
+3. and finally completely compromise the application by using the one of many “baked in RCE” functionalities like plugin upload, templating, or file management.
+
+Overall, this would've allowed an attacker to...
+
+* Execute arbitrary commands on the ade.apple.com webserver
+* Access the internal LDAP service for managing user accounts
+* Access the majority of Apple's internal network
+
+At this point, we finished the report and submitted everything.
+
+
+
+---
+
+
+
+### Full Compromise of DELMIA Apriso Application via Authentication Bypass
+
+any accessible services relating to the manufacturing and distribution of their products?
+- there was an application called "DELMIA Apriso" which was a third-party "Global Manufacturing Suite" which provided what appeared to be various warehouse solutions.
+
+
+
+Sadly, there did not appear to be much available interaction for the technology as you could only "login" and "reset password" from the available interfaces.
+
+
+
+find vulnerabilities on the limited number of pages
+- we were authenticated as a user called "Apple No Password User" based on a bar which appeared in the upper right portion of the site.
+- by clicking "Reset Password", we were temporarily authenticated as a user who had "Permission" to use the page.
+
+> The application's authentication model worked whereas users had specific permissions to use specific pages.
+> The "reset password" page counted as a page itself, so in order to let us use it, the application automatically logged us into an account that was capable of using the page.
+
+
+
+sent an HTTP request to an OAuth endpoint in an attempt to generate an authorization bearer that we could use to explore the API.
+- Our user account, even though its permissions were intended to be limited to authorization and resetting our password, could **generate a bearer** which had permission to access the API version of the application.
+
+
+
+now able to explore the API
+- found a list of API requests for the application.
+
+
+
+did not have access to the majority of the API calls,
+- but some sections like "Operations" disclosed a massive number of available functionalities.
+
+- hit the `"/Apriso/HttpServices/api/platform/1/Operations"` endpoint, it return a list of nearly 5,000 different API calls.
+ - None of these required authentication beyond the initial authorization bearer we initially sent.
+- The operations disclosed here included things like...
+ * Creating and modifying shipments
+ * Creating and modifying employee paydays
+ * Creating and modifying inventory information
+ * Validating employee badges
+ * Hundreds of warehouse related operations
+
+The one paid most attention to was `"APL\_CreateEmployee\_SO"`.
+- send a GET request to the specific operations and receive the expected parameters using the following format:
+
+```html
+GET /Apriso/HttpServices/api/platform/1/Operations/operation HTTP/1.1
+Host: colormasters.apple.com
+
+
+
+ {
+ "InputTypes": {
+ "OrderNo": "Char",
+ "OrderType": "Integer",
+ "OprSequenceNo": "Char",
+ "Comments": "Char",
+ "strStatus": "Char",
+ "UserName": "Char"
+ },
+ "OutputTypes": {},
+ "OperationCode": "APL_Redacted",
+ "OperationRevision": "APL.I.1.4"
+ }
+
+
+
+ {
+ "inputs": {
+ "param": "value"
+ }
+ }
+```
+
+The "create employee" function required various parameters that relied on UUIDs
+- but we were able to retrieve these via the other "Operations" and fill them in as we went along.
+- formed the following API request
+- After we sent this API call, we could now authenticate as a global administrator to the application.
+- This gave us full oversight to the warehouse management software and probably RCE via some accepted functionality.
+
+
+```html
+ POST /Apriso/HttpServices/api/platform/1/Operations/redacted HTTP/1.1
+ Host: colormasters.apple.com
+ Authorization: Bearer redacted
+ Connection: close
+ Content-Type: application/json
+ Content-Length: 380
+ {
+ "inputs": {
+ "Name": "Samuel Curry",
+ "EmployeeNo": "redacted",
+ "LoginName": "yourloginname123",
+ "Password": "yourpassword123",
+ "LanguageID": "redacted",
+ "AddressID": "redacted",
+ "ContactID": "redacted",
+ "DefaultFacility": "redacted",
+ "Department": "",
+ "DefaultMenuItemID": "redacted",
+ "RoleName": "redacted",
+ "WorkCenter": ""
+ }
+ }
+```
+
+
+
+There were hundreds of different functionalities that would've caused massive information disclosure and been capable of disrupting what appeared to be a somewhat crucial application used for inventory and warehouse management.
+
+
+---
+
+
+### Wormable Stored Cross-Site Scripting Vulnerabilities Allow Attacker to Steal iCloud Data through a Modified Email
+
+One of the core parts of Apple’s infrastructure is their iCloud platform.
+- This website works as an automatic storage mechanism for photos, videos, documents, and app related data for Apple products.
+- Additionally, this platform provides services like Mail and Find my iPhone.
+
+The mail service
+- a full email platform
+- users can send and receive emails similar to Gmail and Yahoo.
+- there is a mail app on both iOS and Mac which is installed by default on the products.
+- The mail service is hosted on “www.icloud.com” alongside all of the other services like file and document storage.
+
+from an attackers perspective
+- any cross-site scripting vulnerability would allow an attacker to retrieve whatever information they wanted to from the iCloud service.
+
+
+
+the mail application
+- When the service receives an email and a user opens it, the data is processed into a JSON blob which is sanitized and picked apart by JavaScript and then displayed to the user.
+- This means that there is no server side processing of the emails in terms of content sanitation, and that all of the actual functionality to render and process the mail body is within the JavaScript where it’s done client side.
+- This isn’t necessarily a bad thing, but simplifies the process of identifying XSS by understanding what specifically we’ll need to break within the source code.
+
+
+
+
+
+#### Stored XSS via Style Tag Confusion
+
+`“”` tag.
+- This means that if we wrote `“”` and it was fully rendered in the DOM,
+- there would be no alert prompt as the content of the tag is strictly CSS and the script tag was stuffed within the tag and not beyond the closing tag.
+
+From a sanitization perspective, the only things Apple would need to worry about here would be an ending style tag, or if there was sensitive information on the page, CSS injection via **import chaining**.
+
+- trying to break out of the style tag without Apple realizing it since it would be a very straightforward stored XSS if achievable.
+- trying various permutations and eventually observed
+ - when you had two style tags within the email, the contents of the style tags would be concatenated together into one style tag.
+ - This meant that if we could get `“”` into the second tag, it would be possible to trick the application into thinking our tag was still open when it really wasn’t.
+ - sent the following payload to test if it would work:
+
+```
+
+
+```
+
+An explanation of the above payload is as follows:
+
+
+
+
+
+The email popped up in my inbox.
+- clicked it.
+- There was an alert prompt!
+- It had worked!
+
+
+
+The DOM of the page included the following:
+
+```html
+
+```
+
+
+Since the mail application is hosted on “www.icloud.com”
+- this meant that we had browser permissions to retrieve the HTTP responses for the corresponding APIs for the iCloud service (if we could sneak in the JavaScript to reach out to them).
+
+
+**Goal**: steals all of the victim’s personal information (photos, calendar information, and documents) then forwards the same exploit to all of their contacts.
+- built a neat PoC which would return the photo URLs from the iCloud API, stick them into image tags, and then append a list of contacts for the user account underneath them.
+- This demonstrated that it was possible to retrieve the values, but in order to exfiltrate them we would have to bypass a CSP which meant no easy outbound HTTP requests to anything but “.apple.com” and a few other domains.
+
+Luckily for us, the service is a mail client. We can simply use JavaScript to invoke an email to ourselves, attach the iCloud photo URLs and contacts, then fire away all of the victim’s signed iCloud photo and document URLs.
+
+The following video demonstrates a proof of concept whereas a victim’s photos are stolen. In a full exploitation scenario performed by a malicious party, an attacker could silently steal all of the victim’s photos, videos, and documents, then forward the modified email to the victim’s contact list and worm the cross-site scripting payload against the iCloud mail service.
+
+### Stored XSS via Hyperlink Confusion
+
+Later on I found a second cross-site scripting vulnerability affecting mail in a similar fashion.
+
+One thing I’ll always check with these sorts of semi-HTML applications is how they handle hyperlinks. It seems intuitive to automatically turn an unmarked URL into a hyperlink, but it can get messy if it isn’t being sanitized properly or is combined with other functionalities. This is a common place to look for XSS due to the reliance on regex, innerHTML, and all of the accepted elements you can add alongside the URL.
+
+The second piece of interesting functionality for this XSS is the total removal of certain tags like “https://domain.com/abc
+
+After sending the above by itself within an email, the content was parsed to the following:
+
+
https://www.domain.com/abc
+
+This was very interesting to see initially, but exploiting it would be a bit harder. It is easy to define the attributes within the tag (e.g. src, onmouseover, onclick, etc.) but providing the values would be difficult as we still had to match the URL regex so it wouldn’t escape the automatic hyperlinking functionality. The payload that eventually worked without sending single quotes, double quotes, parenthesis, spaces, or backticks was the following:
+
+ https://www.icloud.com/mail/#https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//
+
+The payload produced this in the DOM:
+
+
https://www.icloud.com/onmouseover=location=/javascript:alert%28document.domain%29/.source;//
+
+And gave us this beautiful alert prompt:
+
+
+
+This payload was from a CTF solution by @Blaklis\_. I had originally thought it might be an unexploitable XSS, but there seems to always be a solution somewhere for edge case XSS.
+
+> ?age=19;location=/javascript:alert%25281%2529/.source; :>
+>
+> — Blaklis (@Blaklis\_) [May 7, 2019](https://twitter.com/Blaklis_/status/1125663871056928769?ref_src=twsrc%5Etfw)
+
+My best explanation here is that 1. when loading the initial URL the characters within the “” were acceptable within the automatic hyperlinking process and didn’t break it, then (2) the removal of the script tags created a space or some sort of void which reset the automatic hyperlinking functionality without closing the initial hyperlinking functionality, and lastly (3) the second hyperlink added the additional quote that was used to both break out of the href and create the onmouseover event handler.
+
+The impact for the second XSS was the same as the first one, except for this one the user would have to trigger the onmouseover event handler via putting their mouse somewhere within the email body, but this part could be simplified to trigger more easily by making the hyperlink of the entire email.
+
+Overall, an attacker could've abused this to...
+
+* Create a worm that has the capability to silently exfiltrate/modify iCloud account information including photos and videos
+* Silently execute arbitrary HTML and JavaScript within the victim's browser
+
+### Command Injection in Author’s ePublisher
+
+A major feature of Apple is the ability to upload and sell books, movies, tv shows, and songs. The files you upload get propagated to various Apple services such as iTunes where people can download or purchase them. This seemed like a good vector for customer XSS and blind XSS against employees.
+
+In order to upload files, we first had to apply for access to the service on iTunes Connect.
+
+We ran into an interesting problem where we did not have access to an iPad or iPhone, but we kept on looking for ways to use this service still. After some investigating, we discovered a tool called Transporter.
+
+[Transporter](https://help.apple.com/itc/transporteruserguide/#/) is a Java app that can be used to interact with a jsonrpc API for bulk uploading files utilizing a few different file services.
+
+At the same time, we were also looking through the iTunes Connect Book [help docs](https://itunespartner.apple.com/books/) and we found a page that explained a few different ways to upload books including an online web service: [https://itunespartner.apple.com/books/articles/submit-your-ebook-2717](https://itunespartner.apple.com/books/articles/submit-your-ebook-2717)
+
+This led us to the following service, [Apple Books for Authors](https://authors.apple.com/epub-upload).
+
+This service only has a couple of features:
+
+* Sign-in / Register
+* Upload images for book cover
+* Upload book ePub file
+* Upload book Sample ePub file
+
+The first thing we did was download sample epub files and upload them. Funny enough, the first epub file we grabbed was an epub version 1 format with invalid xhtml. The publish tool spit out a huge wall of text of errors to let us know why it failed to upload/validate.
+
+**HTTP Request:**
+
+ POST /api/v1/validate/epub HTTP/1.1
+ Host: authors.apple.com
+ {"epubKey":"2020_8_11/10f7f9ad-2a8a-44aa-9eec-8e48468de1d8_sample.epub","providerId":"BrettBuerhaus2096637541"}
+
+**HTTP Response:**
+
+ [2020-08-11 21:49:59 UTC]
DBG-X: parameter TransporterArguments = -m validateRawAssets -assetFile /tmp/10f7f9ad-2a8a-44aa-9eec-8e48468de1d8_sample.epub -dsToken **hidden value** -DDataCenters=contentdelivery.itunes.apple.com -Dtransporter.client=BooksPortal -Dcom.apple.transporter.updater.disable=true -verbose eXtreme -Dcom.transporter.client.version=1.0 -itc_provider BrettBuerhaus2096637541
+
+As you can probably guess at this point, all we had to do was a simple command injection on the provderId JSON value.
+
+We intercepted the request on the next upload and replaced it with:
+
+ "providerId":"BrettBuerhaus2096637541||test123"
+
+And we got the following output:
+
+ /bin/sh: 1: test123: not found
+
+The following is a screenshot showing the output of "_ls /_":
+
+
+
+Overall, an attacker could've abused this to...
+
+* Execute arbitrary commands on the authors.apple.com webserver
+* Access Apple's internal network
+
+This was a good exercise in making sure you fully explore what you are testing. A lot of the big names in recon research talk about creating mind maps and this is an example of that. We started with iTunes Connect, started exploring Books, and continued to branch out until we fully understood what services exist around that single feature.
+
+It also is a good reminder that you need to find as much information as possible before you start going down rabbit-holes while testing. Without exploring the help docs, you may have missed the web epub app entirely as it is a single link on one page.
+
+### Full Response SSRF on iCloud allows Attacker to Retrieve Apple Source Code
+
+The most elusive bug while hacking on Apple was full response SSRF. We found nearly a dozen blind or semi-blind SSRFs, but had a terribly hard time trying to find any way to retrieve the response. This was incredibly frustrating as during our recon process we found tons of references to what appeared to be awesome internal applications for source code management, user management, information lookup, and customer support.
+
+It wasn’t until the end of our engagement when we finally stumbled upon one which seemed to have a great deal of internal network access.
+
+During testing the iCloud application we noticed that you could open up certain attachments from the iCloud mail application in the iCloud pages application via the “Open in Pages” functionality. When you submitted the form to do this, it sent an HTTP request containing a URL parameter which included the URL of the mail file attachment in the request. If you attempted to modify this URL to something arbitrary, the request would fail and give a “400 Bad Request” error. The process would create a “job” where the response of the HTTP request was converted into an Apple Pages document, then opened in a new tab.
+
+
+
+It seemed to only allow URLs from the “p37-mailws.icloud.com” domain, would not convert pages with anything but a 200 OK HTTP response, and would additionally be a bit hard to test as the conversion process was done through multiple HTTP requests and a job queue.
+
+
+
+What worked to exploit this was appending “@ourdomain.com” after the white-listed domain which would point the request at our domain. The process would convert the raw HTML to an Apple pages file then display it to us in a new window. This was a bit annoying to fuzz with, so Brett ended up throwing together a python script to automate the process.
+
+[https://gist.github.com/samwcyo/f8387351ce9acb7cffce3f1dd94ce0d6](https://gist.github.com/samwcyo/f8387351ce9acb7cffce3f1dd94ce0d6)
+
+Our proof of concept for this report was demonstrating we could read and access Apple’s internal maven repository. We did not access any source code nor was this ever exploited by other actors.
+
+If the file was too large to be saved to a Pages file, it would instead be stored to the drive in a downloadable zip file which would allow us to extract large files like jars and zips.
+
+We had found the internal maven URL disclosed in a Github repository.
+
+
+
+There were many other internal applications we could’ve pulled from, but since we demonstrated access to the Maven repository with source code access we reported the issue right away.
+
+Overall, an attacker could've abused this to...
+
+* Read the various iOS source code files within the maven repository
+* Access anything else available within Apple's internal network
+* Fully compromise a victim's session via a cross-site scripting vulnerability due to the disclosed HTTP only cookies within the HTTP request
+
+The full process that had to be followed when scripting this is as follows:
+
+
+
+### Nova Admin Debug Panel Access via REST Error Leak
+
+While going through a list of all Apple subdomains one at a time, we discovered some interesting functionality from "concierge.apple.com", "s.apple.com", and "events.apple.com".
+
+With a little bit of Google dorking, we found that a specific request to "s.apple.com" would take you to "events.apple.com" with an authentication token.
+
+**HTTP Request:**
+
+ GET /dQ{REDACTED}fE HTTP/1.1
+ Host: s.apple.com
+
+**HTTP Response:**
+
+ HTTP/1.1 200
+ Server: Apple
+ Location: https://events.apple.com/content/events/retail_nso/ae/en/applecampathome.html?token=fh{REDACTED}VHUba&a=1&l=e
+
+Performing our standard recon techniques, we grabbed the JavaScript files and started looking for endpoints and API routes.
+
+
+
+Discovering a /services/public/account endpoint, we started to play around with it. We quickly discovered that passing in an invalid marketCode parameter resulted in the server returning a REST exception error.
+
+**HTTP Request:**
+
+
+
+**HTTP Response:**
+
+
+
+From the error message we can see the server is forwarding an API request to the following location:
+
+ https://nova-admin.corp.apple.com/services/locations/searchLocation?locationName=t&rtm=1
+
+We can also see that it leaked some request/response headers including a nova-admin cookie and an authorization token that the server is sending to make requests to nova-admin.corp.apple.com API requests.
+
+Also interesting is that the /services/ endpoint is similar to the /services/public/ API endpoints for the events app. We could not hit the endpoints on the event app and we did not have access to nova-admin.corp.apple.com. Going back to our recon data, we noticed that there is a nova.apple.com.
+
+Attempting to use the acquired auth token and cookie, we noted that the credentials were valid as we were no longer being redirected to idsmac auth, but it was still 403 forbidden.
+
+With a little bit of fuzzing, we discovered that we were able to hit /services/debug.func.php.
+
+Even though it was not a website with PHP extensions, it appeared adding any extension to the debug route would bypass the route restrictions they built since the authorization was separate from the functionality itself.
+
+**HTTP Request:**
+
+
+
+**HTTP Response:**
+
+
+
+This portal contained dozens of options, also contained several hundred configuration parameters and values.
+
+
+
+One of the values also contained an AWS secret key, another contained server crontabs. Having the ability to update these values was enough to prove command injection.
+
+
+
+Overall, an attacker could've abused this to...
+
+* Execute arbitrary commands on the nova.apple.com webserver
+* Access Apple's internal network
+
+At this point, we decided we had proven enough impact and stopped. The full flow from above is as follows:
+
+
+
+### AWS Secret Keys via PhantomJS iTune Banners and Book Title XSS
+
+We discovered the iTunes banner maker website a few weeks prior to finding this vulnerability. It was not until we added a book via iTunes Connect did we discover an interesting feature on the banner maker.
+
+[](https://banners.itunes.apple.com/us/catalog)
+
+There are multiple banner image formats based on the height and width specified. We discovered that the "300x250" banner image included the book name.
+
+We also noticed that it was vulnerable to Cross-Site Scripting because the book name was underlined with our injected "" element which we had set whilst registering the book on iTunes connect.
+
+
+
+Image URL:
+
+ https://banners.itunes.apple.com/bannerimages/banner.png?pr=itunes&t=catalog_black&c=us&l=en-US&id=1527342866&w=300&h=250&store=books&cache=false
+
+Earlier we had already discovered that there was path traversal and parameter injection in a few of the request parameters such as "pr". For example:
+
+ https://banners.itunes.apple.com/bannerimages/banner.png?pr=itunes/../../&t=catalog_black&c=us&l=en-US&id=1527342866&w=300&h=250&store=books&cache=false
+
+Results in a picture of the AWS S3 error page:
+
+
+
+From here we made the assumption that they were using a headerless browser client to take screenshots of HTML files inside of an S3 bucket. So the next step was to create a book with
+
+
+
+
+
+
+
- [**Live Demo** →][demo]
+