"KINGSTON CATS"

Thursday, January 18, 2024

PHASES OF HACKING

What is the process of hacking or phases of hacking?
Hacking is broken up into six phases:The more you get close to all phases,the more stealth will be your attack.

1-Reconnaissance-This is the primary phase of hacking where hacker tries to collect as much as information as possible about the target.It includes identifying the target,domain name registration records of the target, mail server records,DNS records.The tools that are widely used in the process is NMAP,Hping,Maltego, and Google Dorks.

2-Scanning-This makes up the base of hacking! This is where planning for attack actually begins! The tools used in this process are Nessus,Nexpose,and NMAP. After reconnaissance the attacker scans the target for services running,open ports,firewall detection,finding out vulnerabilities,operating system detection.

3-Gaining Access-In this process the attacker executes the attack based on vulnerabilities which were identified during scanning! After the successful, he get access to the target network or enter in to the system.The primary tools that is used in this process is Metasploit.

4-Maintaining Access-It is the process where the hacker has already gained access in to a system. After gaining access the hacker, the hacker installs some backdoors in order to enter in to the system when he needs access in this owned system in future. Metasploit is the preffered toll in this process.

5-Clearning track or Covering track-To avoid getting traced and caught,hacker clears all the tracks by clearing all kinds of logs and deleted the uploaded backdoor and anything in this process related stuff which may later reflect his presence!

6-Reporting-Reporting is the last step of finishing the ethical hacking process.Here the Ethical Hacker compiles a report with his findings and the job that was done such as the tools used,the success rate,vulnerabilities found,and the exploit process.

Related word

Security And Privacy Of Social Logins (III): Privacy In Single Sign-On Protocols

This post is the second out of three blog posts summarizing my (Louis Jannett) research on the design, security, and privacy of real-world Single Sign-On (SSO) implementations. It is based on my master's thesis that I wrote between April and October 2020 at the Chair for Network and Data Security.

We structured this blog post series into three parts according to the research questions of my master's thesis: Single Sign-On Protocols in the Wild, PostMessage Security in Single Sign-On, and Privacy in Single Sign-On Protocols.

Overview

Part I: Single Sign-On Protocols in the Wild

Although previous work uncovered various security flaws in SSO, it did not work out uniform protocol descriptions of real-world SSO implementations. We summarize our in-depth analyses of Apple, Google, and Facebook SSO. We also refer to the sections of the thesis that provide more detailed insights into the protocol flows and messages.

Part II: PostMessage Security in Single Sign-On

It turned out that the postMessage API is commonly used in real-world SSO implementations. We introduce the reasons for this and propose security best practices on how to implement postMessage in SSO. Further, we present vulnerabilities on top-visited websites that caused DOM-based XSS and account takeovers due to insecure use of postMessage in SSO.

Part III: Privacy in Single Sign-On Protocols

Identity Providers (IdPs) use "zero-click" authentication flows to automatically sign in the user on the Service Provider (SP) once it is logged in on the IdP and has consented. We show that these flows can harm user privacy and enable new targeted deanonymization attacks of the user's identity.

Introduction to XS-Leaks in Single Sign-On
XS-Leaks in Single Sign-On: Account Leakage Attack
XS-Leaks in Single Sign-On: Identity Leakage Attack
Automatic Sign-In and Session Management Practices in the Wild

Introduction to XS-Leaks in Single Sign-On

Cross-site leak (XS-Leak) refers to a family of browser side-channel techniques that can be used to infer and gather information about users [...]. While the deanonymization capabilities of XS-Leak attacks are only just being realized, some researchers have said the technique will soon be in the OWASP Top 10.

Source: Latest cross-site leak (XS-Leak) news | The Daily Swig

In SSO setups, redirects can leak private information about the user. Thus, we focused on XS-Leaks that detect cross-origin redirects, i.e., whether a cross-origin request returns an `HTTP/200` or `HTTP/302` response. In this post, we present an XS-Leak that is based on the Fetch API and detects cross-origin redirects with 100% accuracy. The following method expects a URL, sends a GET request, and finally returns `true` if the response is a redirect or `false` if the response is no redirect:

// let is_redirect = await xs_leak_redirect("<URL>");  async function xs_leak_redirect(url) { 	let res = await fetch(url, { 		mode: "cors", 		credentials: "include", 		redirect: "manual" 	}).then( (response) => { 		if (response.type == "opaqueredirect") { 			return true; 		} 	}).catch( (error) => { 		return false; 	}); 	return res; }

More details are provided in Section 5.1.4.1 of the thesis.

XS-Leaks in Single Sign-On: Account Leakage Attack

With the account leakage attack, the attacker can determine whether the victim has an account on a targeted SP with a certain IdP. Specifically, the attacker checks whether the victim has granted consent to the targeted SP with the IdP. This attack is scalable: The attacker can test multiple (SP, IdP) pairs and check for which pair the victim has an account on the SP. The following prerequisites must hold:

The victim visits an attacker-controlled website.
The victim is signed-in on the IdP (i.e., in Google Chrome with its Google account).
The IdP supports the standardized `prompt=none` parameter.

The attack idea is simple: Let's assume the attacker wants to know whether the victim has an account on SP `sp.com` with the IdP `idp.com`. The attacker first tricks the victim into visiting its malicious website `attacker.com`. We further assume that the victim has an active session on the IdP. Then, the attacker constructs an Authentication Request URL, as shown in the figure below. Note that the SP `sp.com` has the `client_id=superSecretClient` on the IdP, the `redirect_uri` is set to `sp.com/redirect`, and the `prompt=none` parameter is set.

From the attacker's website, a cross-origin `Fetch` request is sent to that URL as shown before. If the `prompt=none` flow is requested with established consent on the SP, the IdP returns the Authentication Response as an `HTTP/302` redirect to the `redirect_uri`. If the victim has not granted the SP's consent, the IdP returns the consent page with an `HTTP/200` response and asks the user to grant the consent. Thus, based on whether the victim has or has not an account on `sp.com`, the IdP returns an `HTTP/302` redirect or an `HTTP/200` response. Although the Same Origin Policy prevents us from viewing the response from `idp.com`, we can use the XS-Leak to detect whether a redirect was performed or not. If a redirect was performed, the victim has an account on `sp.com` with the IdP. If no redirect was performed, the victim has no account.

We tested this attack with the Apple, Google, and Facebook IdP. It only works for Google and Facebook since Apple requires user interaction in each flow. A working PoC is provided on https://xsleak.sso.louisjannett.de. If the "Start" button is clicked, the website checks if you have an account on adobe.com, ebay.com, imdb.com, medium.com, or vimeo.com using either the Google or Facebook IdP. Make sure that you are signed in at Google and Facebook before testing and enable third-party cookies.

To circumvent this attack, the IdP must return an error as `HTTP/302` redirect if the `prompt=none` flow is requested, but no consent is given. This mitigation is described in the OpenID Connect specification, but as shown, not adopted by real-world IdPs.

More details are provided in Section 5.1 of the thesis.

XS-Leaks in Single Sign-On: Identity Leakage Attack

The identity leakage attack extends the account leakage attack by the `login_hint` parameter. The attacker can determine whether the victim has a certain identity on a targeted IdP. The attacker can use this information to check if a certain person is visiting its website. Therefore, all prerequisites of the account leakage attack must hold and the IdP must support the standardized `login_hint` parameter.

Once a victim visits the malicious website, the attacker must initially guess an (SP, IdP) pair that the victim most likely gave consent to, i.e., that causes the IdP in the `prompt=none` flow to return a redirect to `sp.com/redirect`. The attacker can use the account leakage attack to determine such a pair by testing the most-popular SPs and IdPs. Then, a new Authentication Request is created, and the `login_hint` parameter is set to the email address of the victim, i.e., `alice@example.com`. The attacker sends the Fetch request and determines whether the IdP returns an `HTTP/302` redirect or an `HTTP/200` response. If a redirect was performed, the attacker knows that the Authentication Request was valid, and thus the victim is `alice@example.com`. If no redirect was performed, the victim is not `alice@example.com`. The success of this attack depends on whether the attacker can guess (or eventually knows) an (SP, IdP) pair that the targeted victim gave consent to.

We tested this attack with the Apple, Google, and Facebook IdP. It only works for Google since Apple does not support the `prompt=none` flow, and Facebook does not support the `login_hint` parameter. We discovered that the `login_hint` parameter must contain a valid email address registered at Google. Otherwise, this parameter is ignored.

To mitigate this leakage, the IdP must return an error as `HTTP/302` redirect if a `login_hint` parameter is queried that the user does not own. We did not find any information about the `login_hint` parameter in the OpenID Connect specification that proposes guidelines for this scenario.

More details are provided in Sections 5.1 of the thesis.

Following the observations of the account leakage and identity leakage attacks, we analyzed "zero-click" SSO flows in terms of automatic sign-in features provided by the IdPs with their SDKs. We found that under certain assumptions, the SDKs can be configured to automatically sign in the user on the SP even though the user did not click on the sign-in button and may not notice the sign-in process.

Google and Facebook support automatic sign-in with their SSO SDKs: Google Sign-In, Google One Tap, and Facebook Login. They follow a similar approach: The user visits the SP website that integrates and initializes the SDK with automatic sign-in enabled. Suppose the user has an active session on the IdP, valid consent for the SP, and third-party cookies enabled. In that case, the SDK first retrieves a logout state from browser storage to determine whether the user signed out previously using the SDK's sign-out method. If the logout state is set to false or does not exist, the SDK returns the Authentication Response to the SP website, i.e., to a registered callback. If it is set to true, the SDK does not proceed with the automatic sign-in and instead requires the user to click on the sign-in button. Thus, the execution of the automatic sign-in flow depends on the stored logout state. If the browser storage is cleared (i.e., cookies are deleted or a private window is opened), the logout state does not exist, and thus the automatic sign-in is enabled.

Note that the logout state is only a feature provided by the SDKs to stop unwanted sign-in operations on the SP. They do not prevent the SP from secretly receiving tokens from the IdP. If the SP does not use the SDK's sign-out method, the logout state will never be set to true. Alternatively, the SP may manually request the tokens from the IdP in the background without paying attention to any logout state. Note that this automatic sign-in flow is different than the standardized `prompt=none` flow because it returns the tokens in the background (i.e., via Fetch requests), whereas the `prompt=none` flow requires a redirect that is in some form visible to the user.

Google and Facebook use different approaches to receive the Authentication Response in the background. Google sends a `getTokenResponse` RPC from the SP website to its proxy iframe and receives the tokens with postMessage. Facebook issues a simple CORS request and receives the tokens in the CORS response.

For instance, SPs can send the following CORS request with the Fetch API to Facebook:

GET /x/oauth/status?client_id=<CLIENT_ID> HTTP/1.1 Host: www.facebook.com Origin: https://sp.com Cookie: c_user=REDACTED; xs=REDACTED;

If the user has an active session at Facebook (i.e., cookies are set) and valid consent, Facebook responds with a CORS response and explicitly allows the SP to read the `fb-ar` header that contains the tokens:

HTTP/1.1 200 OK Access-Control-Allow-Origin: https://sp.com Access-Control-Allow-Credentials: true Access-Control-Expose-Headers: fb-ar,fb-s fb-s: connected fb-ar: {"user_id": "REDACTED", "access_token": "REDACTED", "signed_request": "REDACTED"}

We tested the automatic sign-in on top-visited SPs and found that some of them implement it as expected. For instance, `change.org` supports automatic sign-in with Facebook: First, we open `change.org` without being logged in on Facebook. Thus, we are not signed-in automatically. Then, we log in on Facebook and reload `change.org`. As shown, `change.org` uses the CORS request to receive the tokens from Facebook and finally logs us in. The user interface does not indicate that we were just signed in. Only the small profile picture in the top right corner is added to the UI.

More details and examples of automatic sign-in flows are provided in Section 5.3 of the thesis.

Acknowledgments

My thesis was supervised by Christian Mainka, Vladislav Mladenov, and Jörg Schwenk. Huge "thank you" for your continuous support, advice, and dozens of helpful tips.

Also, special thanks to Lauritz for his feedback on this post and valuable discussions during the research. Check out his blog post series on Real-life OIDC Security as well.

Authors of this Post

Louis Jannett

More information

Wednesday, January 17, 2024

Hacking Freemium Games - The Evolution Of PC Game Cheating

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!

Thursday, January 18, 2024

PHASES OF HACKING

Related word

Security And Privacy Of Social Logins (III): Privacy In Single Sign-On Protocols

Overview

Part I: Single Sign-On Protocols in the Wild

Part II: PostMessage Security in Single Sign-On

Part III: Privacy in Single Sign-On Protocols

Introduction to XS-Leaks in Single Sign-On

XS-Leaks in Single Sign-On: Account Leakage Attack

XS-Leaks in Single Sign-On: Identity Leakage Attack

Automatic Sign-In and Session Management Practices in the Wild

Acknowledgments

Authors of this Post

More information

Wednesday, January 17, 2024

Hacking Freemium Games - The Evolution Of PC Game Cheating

A little bit of history

The different types of cheats (on PC)

Cheat codes

Edit memory

Code injection

Saved game editor

Hacking game server

Network traffic hacking

Why cheating becomes more critical (and challenging)?

Freemium games

Hack all the freemium games!

Noob start

Beginners start - Cheat engine

Encrypt memory - applications at financial institutions

Moral of the story

More information