joana&pedro

joana&pedro

This post is going to be a rather strange post compared to previous ones. But bear with me, in the middle of the post you will see why this post fits the IT security topic.

I'm also terribly sorry for not posting recently, but I was busy with my SPSE and SLAE certification. Both are recommended for Python and Assembly noobs like me. But back to this post.

A little bit of history

Cheating in games started as help for game testers. By using invincibility or infinite ammo testers were able to test the game quicker, which meant less money spent on testing. I personally use cheat codes in games, depending on my mood. Sometimes it feels good to slash all the opponents while I'm invincible, sometimes it is more fun to play the game without cheats. One can argue whether cheating in games is OK or not, but I believe it depends, there is no black or white. But one thing is for sure, it is part of the gaming industry. There is huge demand for cheats. There were even cheat books printed on paper...

The different types of cheats (on PC)

There are different types of cheats in PC gaming. Following is a noncomplete list of these cheats:

Cheat codes

The good old IDDQD type of cheats. These are left in the game by the developers intentionally. Nothing interesting here.

Edit memory

This is my favorite. I will talk about this at the end of the post. Whenever a user launches a new program, the program's whole memory is accessible (read/write) to every other program launched by the user. And since the memory stores the current game state (health, ammo, armor, etc.), these values can be changed easily. In the good old times, there were POKE commands to do this cheats, and the memory address to write into was published by people who found where the game stores the most critical states about the game.

Code injection

This is like patching the game code. For example, one can change the "DEC (pointer to your current health)" instruction with NOP (do nothing), thus becoming invincible. In multi-player cheats, there is the aimbot to help you aim at enemies, wallhack to see through the wall, increase hitbox of the enemy for smoother hit, or in MMORPGs, one can write macros to collect items while the player is not online. I would say the so-called "trainers" more or less fit into this category and the previous one.

Saved game editor

The first time a kid meets a hex-editor (just like the co-author of this blog did with SIM City when he was 10 years old - David). It can teach a lot about file structures, the hexadecimal numeral system, etc. Fun times.

Hacking game server

Not very common, but even more fun. Warning: endless trolling possibilities in multi-player games ahead :) How to hack a game server? Well, I think this might deserve another full blog post ...

Network traffic hacking

One last necessary type of cheating is to modify network traffic between the client and the game server. AFAIK SSL is not universal in gaming, so stunnel is not needed for this hack, but ettercap can help in changing the communication.

Why cheating becomes more critical (and challenging)?

Now in the age of in-app-payments, the game creators are no longer thinking about cheats as funny things but something to be destroyed to the ground. Because cheating decreases its revenue. Or not. At least they think it does. To quote Wikipedia here, "cheating in such games is nonetheless a legal grey area because there are no laws against modifying software which is already owned, as detailed in the Digital Millennium Copyright Act."

A lot of online games include anti-cheating components like PunkBuster, nProtect GameGuard, or Valve Anti-Cheat. This whole cheating/anti-cheating industry is the same as the virus/anti-virus industry. A cat and mouse game.

Freemium games

If you have not played with "freemium" games, you should watch South Park season 18, episode 6. - "Freemium Isn't Free." If you did play with freemium games, you definitely have to watch it :) There are many problems with freemium games. It is free to install, free to play. The first 3-4 hours might be fun to play. But after that, it turns out it is impossible to advance in the game without paying money for it. And by spending cash, I mean spending a LOT! Let's have a look at today's example, an arcade racing video game.

For 99.99 USD, you can get 3 000 000 credit. For almost double the price of a new PC game, you can get these credits. In this particular game, I estimate one have to play ~6-24 hours constantly to get this amount of credit. But by playing ~6 hours, I mean 6 hours without progress in the game! Kind of boring. And what do you get from 3 000 000 credit? You can buy one of the most expensive cars, but can't tune them fully. You have to play more (without progress) or buy more. But guess what, there are more cars you can't buy by only playing the game. Those are only available via in-app-purchase.

Even though the player has 58 765 533 credits, it is not possible to buy this car. Only available through real money.

So, what are your possibilities? You are either Richie Rich, and can afford the money to buy these. Or you can be insane, and try to play the game without in-app-purchase. Or give up the game and try another freemium ... Or, you can try to hack the game!

Hack all the freemium games!

Although I was not playing this racing game from day one, I was able to witness the evolution of the cheats against this game. The cheats which worked in one day was not working one month later. The game is continuously updated to defeat the newly published cheats.

Noob start

So, I want to hack this game, what is the first thing a noob like me does? ~~Bing it!~~ Google it!

From the first page result, let's check this tool:

While trying to download that, I just have to give my email address to spammers, or my mobile number will be subscribed to premium rate text messages. What fun.

Another "cheat" program will install malware/adware on your computer. Never ever try these programs. They are fake 99% of the time and after installing those you will have another problem, not just how to hack freemium games.

Beginners start - Cheat engine

When I first heard about hacking games in memory, I visualized hours of OllyDBG/ImmunityDBG/(insert your favorite Windows debugger here). It turned out, there are some specialized tools to help you with cheating the game. No assembly knowledge required. My favourite tool is CheatEngine. I highly recommend to download it and spend 10 minutes to get past the built-in tutorial levels to get a feeling about this tool. It's super duper awesome.

When I first tried to hack this game myself, I scanned the memory for my actual credit and tried to change that, no luck. Keep reading, you will see what happened.

The second cheat I tried with cheat engine was something like this:

Start the game, play the first level, and check how many credits is paid for winning the race. Pro tip: use dual display for full-screen game cheating.
Restart the same level, attach Cheat Engine to the game's process
Scan the memory for the same value at the beginning of the race
Scan the memory for the same value at the end of the game. The intersect of the first and second scan includes the real value where the credit is stored for winning the race.
Change the values (both the real one and some false positives) to something big
Watch the game to crash
Be amazed at the money you received

Nowadays, most of the cheats on YouTube does not work. Except for these kind of cheats. I don't want to recreate that tutorial, so you should watch it first then come back.

Are you back? Great. Do you have any idea what have you just seen? No? Well, in this case, don't try this at home. Copy-pasting assembly code from random internet posts and running on your computer is always a bad idea. It is precisely as risky as downloading free programs from random internet sites.

Although I have not seen people trolling others with this cheat engine type of shellcode, I think the time will come when these will be turned into something terrible. These shellcodes might work, or might harm your computer. The good news is, we can have a look at the code and analyze it.

When you open CheatEngine and try to define a new custom type, you are greeted with a skeleton assembly code. I don't want to detail what all the skeleton code does, let's just focus on the difference between the skeleton code and the code used in the video. This is the "decrypt function":

xor eax, 0baadf00d rol eax, 0e

What does it mean? The actual credit is encrypted in memory. If you want to scan it in memory, you won't be able to find it. But! The encryption is rotating the value to the right (ROR) with 0xE (14 in decimal), and after that, it is XOR-ed with 0xbaadf00d. Decrypting it is the inverse of the functions in reverse order (in this particular case, the order does not matter, but that's not the point). The inverse function of XOR is XOR, and the inverse function of ROR (rotate right) is ROL (rotate left). Now that we analyzed the assembly code, we can be sure that it is safe to execute. Just follow the video and see your coins falling from the sky. For free. In a freemium game. Have fun!

Encrypt memory - applications at financial institutions

Another exciting thing is that I don't recall any thick client applications in the financial industry encrypting the values in memory. And I agree, there are more significant problems with thick client applications than not encrypting the essential values in memory. But still, some thick client applications are regularly updated, maintained. Maybe it is a good idea to encrypt the values in memory. It will make attackers' life harder. Not impossible, but harder. Perhaps the developers of these applications should learn from the gaming industry (or from malware developers for that matter) because it is a shame that an arcade racing game or an FPS is protected better than an application responsible for transacting millions of dollars. Just think about the RAM scraping malware stealing millions of credit card data ...

Moral of the story

Cheating is part of the gaming history, and the freemium games are trying to take away the cheats from the gamers because they want money. Thanks to CheatEngine and some clever hacks, these programs can be still beaten. And guess what, there is CheatEngine for Android - although it did not work for me on the latest Android. And sometimes, hacking all kinds of applications can be more comfortable with CheatEngine, compared to traditional debuggers.

Also, always check the code before executing it! And when you find something cool, publish it, so everyone could enjoy the games!

Related word

joana&pedro

An advanced persistent threat group with links to Iran has updated its malware toolset to include a novel PowerShell-based implant called PowerLess Backdoor, according to new research published by Cybereason.

The Boston-headquartered cybersecurity company attributed the malware to a hacking group known as Charming Kitten (aka Phosphorous, APT35, or TA453), while also calling out the backdoor's evasive PowerShell execution.

"The PowerShell code runs in the context of a .NET application, thus not launching 'powershell.exe' which enables it to evade security products," Daniel Frank, senior malware researcher at Cybereason, said. "The toolset analyzed includes extremely modular, multi-staged malware that decrypts and deploys additional payloads in several stages for the sake of both stealth and efficacy."

The threat actor, which is active since at least 2017, has been behind a series of campaigns in recent years, including those wherein the adversary posed as journalists and scholars to deceive targets into installing malware and stealing classified information.

Earlier this month, Check Point Research disclosed details of an espionage operation that involved the hacking group exploiting the Log4Shell vulnerabilities to deploy a modular backdoor dubbed CharmPower for follow-on attacks.

The latest refinements to its arsenal, as spotted by Cybereason, constitutes an entirely new toolset that encompasses the PowerLess Backdoor, which is capable of downloading and executing additional modules such as a browser info-stealer and a keylogger.

Also potentially linked to the same developer of the backdoor are a number of other malware artifacts, counting an audio recorder, an earlier variant of the information stealer, and what the researchers suspect to be an unfinished ransomware variant coded in .NET.

Furthermore, infrastructure overlaps have been identified between the Phosphorus group and a new ransomware strain called Memento, which first emerged in November 2021 and took the unusual step of locking files within password-protected archives, followed by encrypting the password and deleting the original files, after their attempts to encrypt the files directly were blocked by endpoint protection.

"The activity of Phosphorus with regard to ProxyShell took place in about the same time frame as Memento," Frank said. "Iranian threat actors were also reported to be turning to ransomware during that period, which strengthens the hypothesis that Memento is operated by an Iranian threat actor."

Facebook Plans To Launch Its Own Cryptocurrency

The social network giant, Facebook is going through a bad phase with lots of ups and down. The recent scandal with Cambridge Analytica has caused the world's largest social network giant Facebook to change its stance on user privacy and to be more transparent about its use of the data it collects.

Since then, some social networks based in Blockchain have been popularized, namely Sphere, Steemit, and Howdoo. However, recently, something unusual announcement is announced by the social network giant Facebook itself, in which Facebook stated that it is investing in a Blockchain-based solution development team, but, the purpose of the project is not yet known.

It was with a post on the Facebook page that David Marcus confirmed his departure from the Messenger team and the creation of a small group dedicated to finding solutions based on the potential of Blockchain technology for Facebook.

David Marcus has not given much detail on the work he will do with his new group, saying only that they will study Blockchain from scratch so that they can use this revolutionary technology for Facebook.

"I'm setting up a small group to explore how to leverage Blockchain across Facebook, starting from scratch," stated David Marcus.

Despite being connected to Facebook's Messenger since 2014, David Marcus is no novice in these financial issues related to money transfers. In addition to having introduced the possibility of P2P payments in Messenger itself, David Marcus was President of PayPal and CEO of Zong, a company dedicated to payments on mobile devices.

However, his experience in this segment does not allow us to conclude that Facebook will create or support a crypto coin, but, it also doesn't mean that it will launch or support any crypto coin of its own. Blockchain technology has become famous thanks to crypto-coins, especially Bitcoin, but its potential expands dramatically to other areas.

The potential of Blockchain goes from the crypto-coins to the creation of real ecosystems online, supported by the users of the network. Sharing and storing data is a legacy that Blockchain allows you to explore and maybe the fact that Facebook will use it in your favor.

The lead post in Messenger was then handed over to Stan Chudnovsky, who now heads one of the most widely used communication services around the world, alongside WhatsApp.

Rumors also point out that James Everingham and Kevin Weil, both from Instagram, will also join David Marcus in this new onslaught of Facebook to one of today's most acclaimed technologies.

More info

joana&pedro

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.