all about Caffeine

Search Engineer

So you're eager to learn about pointers but unfortunately you got stuck because they seemed to you terrible in nature? That's not true I know, but many of the people get confused when they arrive at the topic of pointers. Well pointers are the most important tools in C programming and are the one that can make you fly (unless you don't know how to ride over them). In this article we're going to learn basics of pointers.

Pointers are the varaibles that store addresses of other variables. Easy ain't it?

So lets start with the decleration of a pointer, pointer is decreleared as:

data_type *var_name;
e,g
int *pt;

well the astrisk(*) before the variable name is the thing that makes variable a pointer. So far so good now what?
Now lets say we want to store address of a variable in our pointer variable that seems pretty complex..!

Let's do it:

int number = 100;
int *pt = &num;

Is it really complex..?
what we are doing here is that we are first declaring and initializing a integer variable (number) with value of 100 and then we declare and initialize a pointer variable (pt) with the address of number variable. Now pt (pointer variable) contains the address of number (integer varaible). So what? Now we can use this pointer variable to change the value of number variable. Is this some kind of Magic? Maybe. Lets' do it:

*pt = 200;

what we have done here is that we De-referencing the pt variable with the asterisk (*) and then assigned it the value of 200 now the number variable contains 200. Isn't it a magic? De-referencing is used for accessing the value of the variable towards which our pointer is pointing simple. So lets write a full program of what we have learned so far.

/*Pointer Basics: Creating and Using Pointers*/
#include<stdio.h>
int main(void){
int number = 100;
int *pt = &number;
printf("Value of 'number' is: %d", number);
printf("Address of 'number' is: %p", pt);
*pt = 200;
printf("New value of 'number' is: %d", number);
return 0;
}

What this whole program did was it created a integer variable and a pointer to integer variable and then printed out the value and address of the 'number' variable and after that we De-referenced the pointer variable so that we can access the value to which our pointer variable is pointing and changed the old 100 value with new 200 value and at last we printed that out. Easy isn't it?
But do you know that you can get the address of a variable even by using ampersand (&) operator? Lemme show you how. I'll declare and initialize a variable 'var' and then print it to screen using ampersand (&) operator:

int var = 10;
printf("Address of 'var' is %p\n", &var);

the last statement here will print out the address of 'var' not value so that means it is equal to this statement:

int *pt = &var;
printf("Address of 'var' is %p\n", pt);

here we first assigned the address of 'var' to pointer variable 'pt' and then printed out the address of 'var' using the pointer variable (pt).
So lets write another program that will wrap up this part of 'Pointer Basics':

/*Pointer Basics Part 1: Program 2*/
#include<stdio.h>
int main(void){
   int var = 10;
   int *pt = &var;
   printf("The Value of 'var' is: %d\n", var);
   printf("De-referencing: *pt = %d\n", *pt);
   printf("Ampersand: The Address of 'var' is %p\n", &var);
   printf("pt = %p\n", pt);
   return 0;
}

So that's the end of first part watch out for the next part in which we'll tighten our grip on pointers and get ready for some Advanced '*po(inter)-fo'.

Background:

Let's get started with a little bit background. Windows OSs have a User known as Administrator which is hidden by default. This user is there for security reasons (maybe it's the way around). Most of the users who use Windows are lame, sorry to say that but I'm not talking about you, they don't even know that such an invisible account exists so it is almost everytime without a password. But this Administrator user is a SU (Super User), that means you work wonders once you get access to this account. So our first task will be to make it visible and then we'll access it and using it's power privilages we'll remove password of other accounts (which is not really neccessary cuz you can access any user folder or file using Administrator Account).

Requirements:

1. Physical Access to the Victems computer.
2. A Live Bootable Kali/Backtrack Linux Pendrive or DVD.
(You can downoad Kali Linux here)

Steps:

1. Plug in the Live Bootable Pendrive/DVD into to victim's computer and then boot from it.

2. After accessing kali linux (I'm using Kali Linux) from victim's computer open a terminal.

3. Now we have to mount the drive on which the victim's OS is loaded. In my case it is sda2. So in order to mount that drive I'll type the command:
mount /dev/sda2 /media/temp

this means that I'm mounting the drive in folder /media/temp if you haven't created a temp folder in /media then you must create one by typing these command:
cd /
mkdir /media/temp

4. After mounting the OS we need to access the SAM file and make visible Administrator account using chntpw. It's so simple lemme show you how.
first we'll navigate to /media/temp/Windows/System32/config:
cd /media/temp/Windows/System32/config

now we display the list of users on our victim's computer:
chntpw SAM -l

You'll see an Administrator User there which is disabled. Now we'll enable that:
chntpw SAM -u Administrator

now type 4 and hit return

press 'y' to save changes to SAM file.

OK voila! the hard part is done.

5. Now restart your Computer and take out your Pendrive/DVD from your computer and boot into windows 8 OS. You should be able to see Administrator User on Logon screen now. If not then look for a backward pointing Arrow besides the user Login Picture. Click on that Arrow and you should see an Administrator User. Click on the Administrator Account and wait for a while until windows 8 sets it up.

6. After a while you get Access to the computer and you can access anything. Enjoy :)

7. What you want to remove the password? I don't think it's a stealth mode idea, is it? OK I'll tell you how to do that but It's not a good hacker way of doing.
Open up the command prompt, simple way to do it is:

Press Ctrl + 'x' and then Press 'a' and if prompted click yes.
After that Enter following commands:

net user
(This command will display all users on computer)

net user "User Name" newPassword
(This Command will change the Password of User Name user to newPassword).
OK you're done now logout and enter the new password. It will work for sure.

8. If you want to disable the Administrator Account again then type in command prompt:
net user Administrator /active:no

I tried it on Windows 8/8.1 all versions and it works. Guess what it works on all windows OSs.

Hope you enjoyed this tutorial. Don't forget to share it and yes always read the Disclaimer.

Related links

Search Engineer

Automating REST Security Part 3: Practical Tests for Real-World APIs

If you have read our two previous blogposts, you should now have a good grasp on the structural components used in REST APIs and where there are automation potentials for security analysis. You've also learned about REST-Attacker, the analysis tool we implemented as a framework for automated analysis.

In our final blogpost, we will dive deeper into practical testing by looking at some of the automated analysis tests implemented in REST-Attacker. Particularly, we will focus on three test categories that are well-suited for automation. Additionally, we will look at test results we acquired, when we ran these tests on the real-world API implementation of the services GitHub, Gitlab, Microsoft, Spotify, YouTube, and Zoom.

Author

Christoph Heine

Overview

Undocumented Operations

The first test that we are going to look at is the search for undocumented operations. These encompass all operations that accessible to API clients despite not being listed in the API documentation. For public-facing APIs, undocumented operations are a security risk because they can expose functionality of the service that clients are not supposed to access. Consequences can range from information leakage to extensive modification or even destruction of the resources managed by the underlying service.

A good example for an operation that should not be available is write access to the product information of a webshop API. While read operations on stock amounts, prices, etc. of a product are perfectly fine, you probably don't want to give clients the ability to change said information.

In HTTP-based REST, operations are represented by the HTTP methods used in the API request (as explained in Part 1 of the blog series). Remember that API requests are essentially HTTP requests which consist of HTTP method (operation), URI path (resource address) and optional header or body data.

GET /api/shop/items

We can use the fact that REST operations are components from the HTTP standard to our advantage. First of all, we know that the set of possible operations is the same for all HTTP-based REST APIs (no matter their service-specific context) since each operation should map to a standardized HTTP method. As a result, we also have a rough idea what each operation does when it's applied to a resource, since it's based on the assigned purpose of the HTTP method. For example, we can infer that the DELETE method performs a destructive action a resource or that GET provides a form of read access. It also helps that in practice most APIs only use the same 4 or 5 HTTP methods representing the CRUD operations: GET, POST, PUT, PATCH, and DELETE.

If we know a URI path to a resource in the API, we can thus enumerate all possible API requests, simply by combining the URI with all possible HTTP methods:

GET    /api/shop/items POST   /api/shop/items PUT    /api/shop/items PATCH  /api/shop/items DELETE /api/shop/items

REST-Attacker's test case undocumented.TestAllowedHTTPMethod uses the same approach to find undocumented operations. With an OpenAPI description, the generation of API requests is extremely to automate as the description lists all defined URI paths. Since the API description also documents the officially supported operations, we can slightly optimize the search by only generating API requests for operations not documented for a path (which basically are the candicates for undocumented operations).

To find out whether an undocumented operation exist, we have to determine if the generated API requests are successful. Here, we can again rely on a standard HTTP components that are used across REST APIs. By checking the HTTP response code of the API, we can see whether the API request was rejected or accepted. Since the response codes are standardized like the HTTP methods, we can also make general assumptions based on the response code received. If the operation in the API request is not available, we would expect to get the dedicated response code 405 - Method Not Allowed in the response. Other 4XX response codes can also indicate that the API request was unsuccessful for other reasons. If the operation is accepted, we would expect the API response to contain a 2XX response code.

Using the same approach, we let REST-Attacker search for undocumented operations in all 6 APIs we tested. None of them exposed undocumented operations that could be identified by the tool, which means they would be considered safe in regards to this test. However, it's interesting to see that the APIs could responded very differently to the API requests sent by the tool, especially when considering the response codes.

API	Response Codes
GitHub	`401`, `404`
Gitlab	`400`, `404`
MS Graph	`400`, `401`, `403`, `404`
Spotify	`405`
YouTube	`404`
Zoom	`400`, `401`, `403`, `404`, `405`

Spotify's API was the only one that used the 405 response code consistently. Other APIs returned 400, 401, 403, or 404, sometimes depending on the path used in the the API request. It should be noted that the APIs returned 401 - Unauthorized or 403 - Forbidden response codes even when supplying credentials with the highest possible level of authorization. An explanation for this behaviour could be that the internal access checks of the APIs work differently. Instead of checking whether an operation on a resource is allowed, they may check whether the client sending the request is authorized to access the resource.

Credentials Exposure

Excessive Data Exposure from OWASP's Top 10 API Security Issues is concerned with harmful "verbosity" of APIs. In other words, it describes a problem where API responses contain more information than they should return (hence excessive exposure). Examples for excessive data exposure include leaks of private user data, confidential data about the underlying service, or security parameters of the API. What counts as excessive exposure can also depend on the application context of the underlying service.

Since the definition of excessive data exposure is very broad, we will focus on a particular type of data for our practical test: Credentials. Not only do credentials exist in some form for almost any service, their exposure would also have a significant impact on the security of the API and its underlying service. Exposed credentials may be used to gain higher privileges or even account takeovers. Therefore, they are a lucrative target for attacks.

There are several credential types that can be interesting for attackers. Generally, they fit into these categories:

long-term credentials (e.g., passwords)
short-term credentials (e.g., session IDs, OAuth2 tokens)
service-specific credentials for user content (e.g., passwords for files on a file-hosting service)

Long- and short-term credentials should probably never be returned under any circumstances. Service-specific credentials may be less problematic in some specific circumstances, but should still be handled with care as they could be used to access resources that would otherwise be inaccessible to an API client.

The question is: Where can we start looking for exposed credentials? Since they would be part of the API responses, we could scrape the parameters in the response content. However, we may not actually need to look at any response values. Instead, we can examine the parameter names and check for association with credentials. For example, a parameter names "password" would likely contain a type of credential. The reason this can work is that parameter names in APIs are generally descriptive and human-readable, a side effect of APIs often being intended to be used by (third-party) developers.

In REST-Attacker, credentials parameter search is implemented by the resources.FindSecurityParameters test case. The test case actually only implements an offline search using the OpenAPI description, as the response parameter names can also be found there. The implementation iterates through the response parameter names of each API endpoint and matches them to keywords associated with credentials such as "pass", "auth" or "token". This naive approach is not very accurate and can produce a number of false-positives, so the resulting list of parameters has to be manually checked. However, the number of candidates is usually small enough to be searched in a small amount of time, even if the API defines thousands of unique response parameters.

API	Parameter Count	Candidates	service-specific
GitHub	2110	39	0
Gitlab	1291	0	0
MS Graph	32199	117	0
Spotify	290	6	0
YouTube	703	6	0
Zoom	800	96	2

5 out of 6 APIs we tested had no problems with exposed credentials.

Zoom's API was the only one which showed signs of problematic exposure of service-specific credentials by returning the default meeting password for meetings created via the API at an endpoint. It should be noted that this information was only available to approved clients and an required authorized API request. However, the credentials could be requested with few priviledges. Another problem was that Zoom did not notify users that this type of information was accessible to third-party clients.

Default Access Priviledges

The last test category that we are going to look at addresses the access control mechanisms of REST APIs. Modern access control methods such as OAuth2 allow APIs to decide what minimum priviledges they require for each endpoint, operation, or resource. In the same way, it gives them fine-grained control on what priviledges are assigned to API clients. However, for fine-grained control to be impactful, APIs need to carefully decide which priviledges they delegate to clients by default.

But why is it important that APIs assigned do not grant too many priviledges by default? The best practice for authorization is to operate on the so-called least priviledge principle. Basically, this means that a client or user should only get the minimum necessary priviledges required for the respective task they want to do. For default priviledges, the task is usually unspecified, so there are no necessary priviledges. In that case, we would expect an API to grant either no priviledges or the overall lowest functional priviledge level.

If the API uses OAuth2 as its access control method, we can easily test what the API considers default priviledges. In OAuth2, clients can request a specific level of priviledge via the scope parameter in the initial authorization request.

Including the scope parameter in the request is optional. If it's omitted, the API can deny the authorization request or - and that's what we are interested in - decide which scope it assigns to the authorization token returned to the client. By analyzing the default scope value, we can see whether the API adheres to the least priviledge principle.

REST-Attacker can automatically retrieve this information for configured OAuth2 clients with the scopes.TestTokenRequestScopeOmit test case. For every configured OAuth2 client, an authorization request without the scope parameter is sent to the OAuth2 authorzation endpoints of the API. The tool then extracts the scope that is assigned to the returned OAuth2 token. This scope value then has to be manually analyzed.

Out of the 6 APIs we tested, 2 (MS Graph and YouTube) denied requests without a scope parameter. The other 4 APIs (GitHub, Gitlab, Spotify, and Zoom) allowed omitting the scope parameter. Therefore, only the latter 4 APIs assigned default prviledges that could be analyzed.

API	Assigned Scope	Least Priviledge?
GitHub	`(none)`	Yes
Gitlab	`api`	No
Spotify	(default)	Yes*
Zoom	all approved	No

* OAuth2 scope with least priviledges

Interestingly, the extent to which a least priviledge principle was followed varied between APIs.

GitHub's API assigned the overall lowest possible priviledges by default via the (none) scope. With this scope, a client could only access API endpoints that were already publicly accessible (without providing authorization). While the scope does not grant more priviledges than a public client would get, the (none) scope had other benefits such as an increased rate limit.

In comparison, the Spotify API had no publicly accessible API endpoints and required authorization for every request. By default, tokens were assigned a "default" scope which was the OAuth2 scope with the lowest available priviledges and allowed clients to access several basic API endpoints.

Gitlab's and Zoom's API went into the opposite direction and assigned the highest priviledge to their clients by default. In Gitlab's case, this was the api scope which allowed read and write access to all API endpoints. Zoom required a pre-approval of scopes that the client wants to access during client registration. After registration, Zoom returned all approved scopes by default.

Conclusion

We've seen that while REST is not a clarly defined standard, this does not result in REST APIs being too complex for a generalized automated analysis. The usage of standardized HTTP components allows the design of simple yet effective tests that work across APIs. This also applies to other components that are used across APIs such as access control mechanisms like OAuth2. The practical tests we discussed worked on all APIs we tested, even if their underlying application contexts were different. However, we've also seen that most of the APIs were generally safe against these tests.

Tool-based automation could certainly play a much larger role in REST security, not only for finding security issues but also for filtering results and streamlining otherwise manual tasks. In the long run, this will hopefully also result in an increase in security.

Acknowledgement

The REST-Attacker project was developed as part of a master's thesis at the Chair of Network & Data Security of the Ruhr University Bochum. I would like to thank my supervisors Louis Jannett, Christian Mainka, Vladislav Mladenov, and Jörg Schwenk for their continued support during the development and review of the project.

all about Caffeine

Wednesday, May 31, 2023

Pointers Part 1: The Basics

Related articles

Removing Windows 8/8.1 Password With CHNTPW