Intel Outside: Hacking every Intel employee and various internal websites

Eaton •

Key Points / Summary

Intel needs no introduction. The storied chipmaker is a mainstay in modern computing and an Intel chip has been inside basically every computer I have ever owned. They’ve had their fair share of security vulnerabilities, from Meltdown and Spectre to side channel attacks and more. There have been many hardware security vulnerabilities over the years, but what about Intel websites? You never hear about vulnerabilities there. Probably because hardware vulnerabilities are worth up to $100k while website bugs are basically relegated to a black-hole inbox (more on that later). I managed to find some very serious issues in several internal Intel websites. Please note that all tokens and credentials shown below are now expired/rotated and can no longer be used.

Business cards for everyone!

Intel India Operations (IIO) maintained a website where employees in India could order their business cards. It had a vulnerability that allowed me to download the entire, worldwide employee/HR database. Let’s dig in!

When you visit the site, you are redirected to this corporate Azure login screen:

I’m starting to think the fancier the background, the more ineffective the login page will be.

Pretty typical. It turns out this is an Angular app and you can find the JavaScript files by viewing the source:

The JavaScript is what does the redirect when it detects no logged in user. It uses the Microsoft Authentication Library (MSAL) for JS and It is often possible to trick an application into thinking a valid user is logged in by modifying the getAllAccounts function to return a non-empty array. This worked perfectly for this app and allowed it to load past the login.

The intended purpose of the website is for an Intel India employee to find their name in the employee list and then form their business card based on the data. What surprised me was the long list of employees it would return from a search, and you could search for employees worldwide (not just in India).

Looking at network traffic behind the scenes, it utilized an authenticated API to return employee information. It got the authentication token for that API in the request before it:

What stood out was the fact that this all worked just fine without me actually being logged in. The reason is because the getAccessToken API was unauthenticated. You could request the token as an anonymous user and then use it in authenticated API requests. Looking inside the token, it seemed to give a lot of access as well:

Looking at the “worker” API now, it returned a huge amount of details about the target employee. Way more than this simple website would ever need. Intel’s APIs are very generous!

Being able to get this information about an employee was already a pretty big vulnerability, but it gets worse. If you look closely at the URL, you will see a filter. This narrowed down the employee search to what the user is looking for. I tried removing the filter to see what would happen and found that it kept crashing Fiddler. I wasn’t sure what was wrong, so I tried Postman instead and got a different error:

It seemed that the API was responding with more data than these apps can handle. I tried curl instead and it gave me a nearly 1 GB JSON file. This file contained the details of every Intel employee. Through 1 API request, I just exfiltrated a wealth of detailed information:

The data included fields like the person’s name, role, manager, phone number, and mailbox address, but nothing overly sensitive like salary or social security number. The full schema can be viewed here.

Hierarchy of hacks

The second Intel website I came across was the “Hierarchy Management” website. The purpose of this appears to be to help organize product groups and ownership within Intel. Like the business card website, it required an Intel login to get anywhere. Looking at the underlying ReactJS source code revealed some very interesting things.

The first thing I noticed is that this app also used the worker API, but the method of getting an access token was different. There was an actual OAuth flow utilizing a username and password. The password is encrypted so you can’t just copy it out and use it:

This encryption is 100% pointless and here is why. It’s all done client-side, meaning the client has the key, so it is possible to decrypt the password! Worse still, the AES key they used is… less than secure. They even give you a link to a website that can be used to decrypt the data – how nice!

Encryption as easy as 123!

With the password decrypted, the Basic auth header can be formed to successfully get an access token to pull down the worker data once more:

I also found some hardcoded admin credentials for the backend service in the form of Basic auth headers. It would, on the client-side, check if you are an admin and choose either the standard user credentials or admin credentials depending on your role:

Source map reconstruction
Raw

You could use this Basic auth to make authenticated API calls:

There are two more places that had hardcoded API credentials. First, there were credentials for the “PIM” API that used the same weak encryption:

Source map reconstruction
Raw

Second, there were Basic auth credentials in plaintext for the “PIM Microservices” API. The username and password were… not the best:

Source map reconstruction
Raw. The next time you want to create a strong password, ask yourself
“What would Intel do?” and then do the opposite.

Now to get into the site, a modification to the JavaScript is necessary. Specifically, I had to override the isAuthenticated boolean value to always be true at startup. When done, it would think you are logged in and skip the SSO redirect:

The unmodified startup code.
Login bypass applied to set isAuthenticated = true.

More work is required. The site calls out to the Microsoft Graph API to see what roles you have:

This fails, so another modification is needed. First, I had to find the names/values of the roles. Pretty straightforward:

Then, I had to comment out the entire graph API call to be a no-op, and fill in the roles array. Doing so stops the API call and ensures all roles are always applied (even the admin role):

With both modifications in place, the site loads and you can access some interesting information, some of which may include unreleased products:

CCB Request History (Admin)
Hierarchy Owners
Hierarchy Owners (Admin)

Product Onboarding

The third website vulnerable to attack was the “Product Onboarding” site, which is presumably used to upload products to Intel ARK. This one is the worst offender in terms of leaked/hardcoded credentials.

First up, we have a similar story of being able to access the worker API through hardcoded secrets:

Then there’s this with a hardcoded token and username/password in the code comments:

Three more hardcoded credentials for various APIs, one of which uses the same weak encryption as Hierarchy Management:

One more hardcoded credential: a GitHub personal access token. They tried encrypting it to keep it safe. This kicks off an “L4 Create” process in an internal GitHub repository. It’s possible you could have created a rogue product on Intel ARK using this, but I decided not to test this one.

That’s it for the leaked/hardcoded credentials!

This site shares a very similar codebase to the Hierarchy Management site. In fact, the same process to bypass the login works here. The only difference were the roles you had to fill the array with. This site has a lot more roles. Only the “SPARK Product Management System Admin” was required to gain full access:

Fortunately for Intel, most of the critical functions were behind their VPN and some parts of this site would not work as a result. Here’s a few screenshots of the site – this is presumably what Intel uses internally to onboard new products onto the ARK site:

SEIMS

The fourth website is SEIMS – Intel’s supplier site (Supplier EHS IP Management System). The description on the site gives a good overview: Welcome to the Supplier Environmental Health and Safety (EHS) Information Management System. This site provides Intel and its suppliers the ability to securely exchange, manage, and store EHS intellectual property.

This is another site protected by Intel’s corporate login. It is built using Angular. Here is how I was able to bypass the login:

One of the first things that happens when you load the site is this API call to retrieve a JWT. Since there is no valid SSO session, it fails as expected:

I looked for the code that handles this response and found it. It explicitly checked if the token value was “Not Autorized” (yes, that is a typo). If it was that value, the login failed, and you get redirected to the SSO login. To bypass it, I modified the code to skip the check:

mapToken just saves data.token to local storage.

That was step 1 and the website proceeded with the next API call:

Another fail response. In a normal flow, EnterpriseID would have your employee ID, and IsAuth would be true. The next step was to try and find a valid employee ID that might have access to this site. I found some APIs to fetch users:

These APIs are supposed to use the JWT returned from the first API. The server doesn’t check it, so you could put in any value and it would be accepted. Oops!

I found one employee. The active=false flag didn’t matter as it looked like they still had their admin roles:

And now for the 4th and final method to obtain all Intel employee information. I found this API that would return some sensitive information. It was vulnerable to enumeration and since Intel’s employee IDs are sequential, it would be trivial to get everyone’s details. No Authorization header required!

The final step to get into SEIMS was to make another modification to override the response of the svc/auth API to include the employee ID just discovered and set the auth flag to true:

Then the site would load and I had admin access:

Product & document reports:

And the companies. If you looked at the response data for the companies, you could see details about the NDA they signed:

The APIs that provide the above information make use of the JWT token. If you look in the last screenshot, you’ll notice how the Bearer token is literally “Not Autorized” as a result of the modifications. Server-side validation seems to be completely broken to allow this “token” to be accepted.

Intel also uses Azure for some backend operations and they just give away a Bearer token for free to anyone that asks nicely:

Intel’s Response and Timeline

Intel’s bug bounty program has been around a while and is well-known. There are some great rewards too – up to $100k. After discovering multiple critical website vulnerabilities, I was excited about the potential rewards I would get. Then I read the fine print:

Obviously disappointing, but the right thing to do was to still report the vulnerabilities, and that is what I did.

When you send an email to external.security.research@intel.com, you get this auto-response:

That is the only official correspondence I ever received from Intel. The good news is that everything was fixed, so while the email inbox was essentially a one-way black hole, at least the reports got to the right people eventually.

The full timeline:

The good news is that Intel has recently expanded their bug bounty coverage to include services. Hopefully they will include blanket coverage for *.intel.com in the future for bug bounty rewards.

Subscribe to new posts

Get an email notification every time something new is published.
📧