A blog for Confluence group.

Wednesday 31 May 2023

WHY WE DO HACKING?

Purpose of Hacking?
. Just for fun
.Show-off
.Steal important information 
.Damaging the system
.Hampering Privacy
.Money Extortion 
.System Security Testing
.To break policy compliance etc

More information


Why (I Believe) WADA Was Not Hacked By The Russians

Disclaimer: This is my personal opinion. I am not an expert in attribution. But as it turns out, not many people in the world are good at attribution. I know this post lacks real evidence and is mostly based on speculation.



Let's start with the main facts we know about the WADA hack, in chronological order:


1. Some point in time (August - September 2016), the WADA database has been hacked and exfiltrated
2. August 15th, "WADA has alerted their stakeholders that email phishing scams are being reported in connection with WADA and therefore asks its recipients to be careful"  https://m.paralympic.org/news/wada-warns-stakeholders-phishing-scams
3. September 1st, the fancybear.net domain has been registered
   Domain Name: FANCYBEAR.NET    ...    Updated Date: 18-sep-2016    Creation Date: 01-sep-2016
 
4. The content of the WADA hack has been published on the website
5. The @FancyBears and @FancyBearsHT Twitter accounts have been created and started to tweet on 12th September, reaching out to journalists
6. 12th September, Western media started headlines "Russia hacked WADA"
7. The leaked documents have been altered, states WADA https://www.wada-ama.org/en/media/news/2016-10/cyber-security-update-wadas-incident-response


The Threatconnect analysis

The only technical analysis on why Russia was behind the hack, can be read here: https://www.threatconnect.com/blog/fancy-bear-anti-doping-agency-phishing/

After reading this, I was able to collect the following main points:

  1. It is Russia because Russian APT groups are capable of phishing
  2. It is Russia because the phishing site "wada-awa[.]org was registered and uses a name server from ITitch[.]com, a domain registrar that FANCY BEAR actors recently used"
  3. It is Russia because "Wada-arna[.]org and tas-cass[.]org were registered through and use name servers from Domains4bitcoins[.]com, a registrar that has also been associated with FANCY BEAR activity."
  4. It is Russia, because "The registration of these domains on August 3rd and 8th, 2016 are consistent with the timeline in which the WADA recommended banning all Russian athletes from the Olympic and Paralympic games."
  5. It is Russia, because "The use of 1&1 mail.com webmail addresses to register domains matches a TTP we previously identified for FANCY BEAR actors."

There is an interesting side-track in the article, the case of the @anpoland account. Let me deal with this at the end of this post.

My problem with the above points is that all five flag was publicly accessible to anyone as TTP's for Fancy Bear. And meanwhile, all five is weak evidence. Any script kittie in the world is capable of both hacking WADA and planting these false-flags.

A stronger than these weak pieces of evidence would be:

  • Malware sharing same code attributed to Fancy Bear (where the code is not publicly available or circulating on hackforums)
  • Private servers sharing the IP address with previous attacks attributed to Fancy Bear (where the server is not a hacked server or a proxy used by multiple parties)
  • E-mail addresses used to register the domain attributed to Fancy Bear
  • Many other things
For me, it is quite strange that after such great analysis on Guccifer 2.0, the Threatconnect guys came up with this low-value post. 


The fancybear website

It is quite unfortunate that the analysis was not updated after the documents have been leaked. But let's just have a look at the fancybear . net website, shall we?

Now the question is, if you are a Russian state-sponsored hacker group, and you are already accused of the hack itself, do you create a website with tons of bears on the website, and do you choose the same name (Fancy Bear) for your "Hack team" that is already used by Crowdstrike to refer to a Russian state-sponsored hacker group? Well, for me, it makes no sense. Now I can hear people screaming: "The Russians changed tactics to confuse us". Again, it makes no sense to change tactics on this, while keeping tactics on the "evidence" found by Threatconnect.

It makes sense that a Russian state-sponsored group creates a fake persona, names it Guccifer 2.0, pretends Guccifer 2.0 is from Romania, but in the end it turns out Guccifer 2.0 isn't a native Romanian speaker. That really makes sense.

What happens when someone creates this fancybear website for leaking the docs, and from the Twitter account reaches out to the media? Journalists check the website, they see it was done by Fancy Bear, they Bing Google this name, and clearly see it is a Russian state-sponsored hacker group. Some journalists also found the Threatconnect report, which seems very convincing for the first read. I mean, it is a work of experts, right? So you can write in the headlines that the hack was done by the Russians.

Just imagine an expert in the USA or Canada writing in report for WADA:
"the hack was done by non-Russian, but state-sponsored actors, who planted a lot of false-flags to accuse the Russians and to destroy confidence in past and future leaks". Well, I am sure this is not a popular opinion, and whoever tries this, risks his career. Experts are human, subject to all kinds of bias.

The Guardian

The only other source I was able to find is from The Guardian, where not just one side (it was Russia) was represented in the article. It is quite unfortunate that both experts are from Russia - so people from USA will call them being not objective on the matter. But the fact that they are Russian experts does not mean they are not true ...

https://www.theguardian.com/sport/2016/sep/15/fancy-bears-hackers--russia-wada-tues-leaks

Sergei Nikitin:
"We don't have this in the case of the DNC and Wada hacks, so it's not clear on what basis conclusions are being drawn that Russian hackers or special services were involved. It's done on the basis of the website design, which is absurd," he said, referring to the depiction of symbolically Russian animals, brown and white bears, on the "Fancy Bears' Hack Team" website.

I don't agree with the DNC part, but this is not the topic of conversation here.

Alexander Baranov:
"the hackers were most likely amateurs who published a "semi-finished product" rather than truly compromising information. "They could have done this more harshly and suddenly," he said. "If it was [state-sponsored] hackers, they would have dug deeper. Since it's enthusiasts, amateurs, they got what they got and went public with it.""

The @anpoland side-track

First please check the tas-cas.org hack https://www.youtube.com/watch?v=day5Aq0bHsA  , I will be here when you finished it. This is a website for "Court of Arbitration for Sport's", and referring to the Threatconnect post, "CAS is the highest international tribunal that was established to settle disputes related to sport through arbitration. Starting in 2016, an anti-doping division of CAS began judging doping cases at the Olympic Games, replacing the IOC disciplinary commission." Now you can see why this attack is also discussed here.


  • My bet is that this machine was set-up for these @anpoland videos only. Whether google.ru is a false flag or it is real, hard to decide. It is interesting to see that there is no google search done via google.ru, it is used only once. 
  • The creator of the video can't double click. Is it because he has a malfunctioning mouse? Is it because he uses a virtualization console, which is near-perfect OPSEC to hide your real identity? My personal experience is that using virtualization consoles remotely (e.g. RDP) has very similar effects to what we can see on the video. 
  • The timeline of the Twitter account is quite strange, registered in 2010
  • I agree with the Threatconnect analysis that this @anpoland account is probably a faketivist, and not an activist. But who is behind it, remains a mystery. 
  • Either the "activist" is using a whonix-like setup for remaining anonymous, or a TOR router (something like this), or does not care about privacy at all. Looking at the response times (SQLmap, web browser), I doubt this "activist" is behind anything related to TOR. Which makes no sense for an activist, who publishes his hack on Youtube. People are stupid for sure, but this does not add up. It makes sense that this was a server (paid by bitcoins or stolen credit cards or whatever) rather than a home computer.
For me, this whole @anpoland thing makes no sense, and I think it is just loosely connected to the WADA hack. 

The mysterious Korean characters in the HTML source

There is another interesting flag in the whole story, which actually makes no sense. When the website was published, there were Korean characters in HTML comments. 



When someone pointed this out on Twitter, these Korean HTML comments disappeared:
These HTML comments look like generated HTML comments, from a WYSIWYG editor, which is using the Korean language. Let me know if you can identify the editor.

The Russians are denying it

Well, what choice they have? It does not matter if they did this or not, they will deny it. And they can't deny this differently. Just imagine a spokesperson: "Previously we have falsely denied the DCC and DNC hacks, but this time please believe us, this wasn't Russia." Sounds plausible ...

Attribution

Let me sum up what we know:

It makes sense that the WADA hack was done by Russia, because:

  1. Russia being almost banned from the Olympics due to doping scandal, it made sense to discredit WADA and US Olympians
  2. There are multiple(weak) pieces of evidence which point to Russia
It makes sense that the WADA hack was not done by  Russia, because: 
  1. By instantly attributing the hack to the Russians, the story was more about to discredit Russia than discrediting WADA or US Olympians.
  2. In reality, there was no gain for Russia for disclosing the documents. Nothing happened, nothing changed, no discredit for WADA. Not a single case turned out to be illegal or unethical.
  3. Altering the leaked documents makes no sense if it was Russia (see update at the end). Altering the leaked documents makes a lot of sense if it was not Russia. Because from now on, people can always state "these leaks cannot be trusted, so it is not true what is written there". It is quite cozy for any US organization, who has been hacked or will be hacked. If you are interested in the "Russians forging leaked documents" debate, I highly recommend to start with this The Intercept article
  4. If the Korean characters were false flags planted by the Russians, why would they remove it? If it had been Russian characters, I would understand removing it.
  5. All evidence against Russia is weak, can be easily forged by even any script kittie.

I don't like guessing, but here is my guess. This WADA hack was an operation of a (non-professional) hackers-for-hire service, paid by an enemy of Russia. The goal was to hack WADA, leak the documents, modify some contents in the documents, and blame it all on the Russians ...

Questions and answers

  • Was Russia capable of doing this WADA hack? Yes.
  • Was Russia hacking WADA? Maybe yes, maybe not.
  • Was this leak done by a Russian state-sponsored hacker group? I highly doubt that.
  • Is it possible to buy an attribution-dice where all six-side is Russia? No, it is sold-out. 

To quote Patrick Gray: "Russia is the new China, and the Russians ate my homework."©

Let me know what you think about this, and please comment. 

Related links


Security And Privacy Of Social Logins (I): Single Sign-On Protocols In The Wild

This post is the first 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.
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 (coming soon)

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.

Single Sign-On Protocols in the Wild

We presume basic knowledge of the SSO protocols OAuth 2.0 and OpenID Connect 1.0
Also, you should be familiar with the postMessage API and the general concept of frames and popups in web browsers. Chapter 2 of the thesis introduces all basics.

To understand real-world SSO implementations, we selected three frequently used IdPs for detailed protocol analyses: Apple, Google, and Facebook. You can find an overview of all Authentication Request/Response and Token Request/Response messages in Appendix A.1 of the thesis.

Identity Provider: Apple

Sign in with Apple is intended for user authentication only, whereas the authorization part is reserved for future use. Besides native libraries for iOS, macOS, tvOS, and watchOS, REST endpoints provide SSO functionality to third-party native apps. Websites can integrate the JavaScript SDK that is based on these endpoints. Although the Authentication and Token Endpoints perform standard-compliant OpenID Connect Code and Hybrid flows (`response_type=code[&id_token]`, `response_mode=query|fragment|form_post|web_message`), there are some features in the authentication & consent part worth mentioning:
  • The native libraries are tightly integrated into the OS using the existing authentication on the device. Thus, biometric user authentication is possible.
  • Apple does not maintain an authenticated session at the IdP. Thus, each (web) SSO flow requires reauthentication.
  • The user authentication is protected with 2FA by default. If the 2FA succeeds, users can choose to trust the browser, which stores a cookie that supersedes future 2FA.
  • The scope is limited to the name, which can be modified, and email.
  • Users can choose to share their real email with the SP or request Apple to generate an anonymous random email that acts as a proxy between the SP and the user's email account.
More details are provided in Section 3.2 of the thesis.

Identity Provider: Google

The Google Identity Platform provides several identity tools, including:
  • Google OAuth 2.0 and OpenID Connect 1.0: Certified OpenID Connect endpoints enable user authentication and authorization for Google APIs (i.e., Calendar, Drive, and more).
  • Google Sign-In: Custom authentication SDK based on the OAuth 2.0 IDP-IFrame-based Implicit Flow and available for Android, iOS, and the web. The web SDK embeds a hidden proxy iframe on the SP website and uses the postMessage API to communicate between Google and the SP. Since the proxy iframe is same-origin with Google, it has access to the session, receives the Authentication Response, and forwards it to the SP utilizing the postMessage API.
  • Google One Tap Sign-In and Sign-Up: SDK for Android and the web that introduces the account creation process on websites with a single tap on a button. The web SDK presumes an active session on Google, embeds the consent page in an iframe on the SP website, and uses the Channel Messaging API for communication between the SP and Google. Therefore, the web SDK on the SP generates a new `MessageChannel` with two ports and transfers `port2` to the consent page iframe with postMessage. Henceforth, the consent page iframe sends messages (i.e., the `id_token`) to `port2` while the web SDK receives them on `port1` and vice versa.
Since the One Tap SDK is quite different from traditional SSO flows, we will briefly outline its unique use of new web APIs. The project initially launched as Google YOLO (You Only Login Once) and had a significant drawback: the consent page iframe was vulnerable to clickjacking. This issue was reported in early 2018 and fixed with restricted API access to trusted websites. Later, Google redesigned the SDK with the new Intersection Observer API v2 that it announced in February 2019:
Intersection Observer v2 introduces the concept of tracking the actual "visibility" of a target element as a human being would define it. [...] A true value for isVisible is a strong guarantee from the underlying implementation that the target element is completely unoccluded by other content and has no visual effects applied that would alter or distort its display on screen. In contrast, a false value means that the implementation cannot make that guarantee. 

This new API enables the consent page iframe to check whether it is visible on the SP website. If it is not visible, the iframe can block the consent or start alternative flows. Unlike the `X-Frame-Options` and `frame-ancestors` directives, Intersection Observer v2 does not prohibit iframe embedding. Still, it prevents clickjacking, which is helpful for the SSO consent page.

Sidenote 1: OAuth 2.0 Assisted Token describes a new flow that similarly embeds the consent page in an iframe but uses `X-Frame-Options`, `frame-ancestors`, or JavaScript frame busting as clickjacking mitigation. Since the IdP knows the SP to which it serves the consent page, it whitelists the SP origin within the framing directives, i.e., `X-Frame-Options: allow-from https://sp.com`:
Due to the use of an iframe to host the assisted token endpoint, the authorization server MUST take precautions to ensure that only trusted origins are allowed to frame it. The authorization server MUST prevent any origin from framing the assisted token endpoint except ones that an administrator has explicitly allowed. 

However, these anti-framing techniques do not prevent the trusted origins from executing a clickjacking attack to obtain consent by fraud. Thus, the IdP must take any measures deemed appropriate to ensure that the SP is trusted to not execute any clickjacking attacks. This limitation causes problems to public IdPs (i.e., Google and Facebook) as they certainly cannot ensure the trustworthiness of their self-registered SPs. If the SP cannot be trusted, the consent page must be protected against framing (i.e., using `X-Frame-Options: deny`) and alternative flows may be started.

We are confident that the Intersection Observer v2 API provides a promising concept for future "one-tap" SSO flows because it allows framing the consent page (and thus entire SSO flows in iframes) without the risk of clickjacking. Currently, only Chromium-based browsers are compatible with Intersection Observer v2, but this might change in the future.

Sidenote 2: If you analyze the security of postMessage on websites, you probably use a browser extension that logs all messages exchanged via the postMessage API. We developed a Chrome extension that logs all messages sent via the Channel Messaging API to the console. If you conduct postMessage security analyses, we highly recommend checking the Channel Messaging API as well.

More details are provided in Section 3.3 of the thesis.

Identity Provider: Facebook

Facebook Login implements the OAuth 2.0 protocol for data access authorization and user authentication. Although OpenID Connect 1.0 defines the signed `id_token`, Facebook issues an `access_token` for user authentication. The `access_token` provides authorized access to Facebook's Token Debugging Endpoint, which returns the `app_id` of the SP that this token is intended for (`aud` claim), the `user_id` of the user that owns this token (`sub` claim), the validity, the expiration, the associated scopes, and more.

Also, Facebook issues a `signed_request`, which is a base64url-encoded and symmetrically integrity protected token. It is not a JWT – instead, it prepends the HMAC to the claims as follows: `<hmac_bytes>.{"user_id": "[...]", "code": "[...]", "algorithm": "HMAC-SHA256", "issued_at": 1577836800}`. Although the `signed_request` does not include an audience (`aud`) claim, it implicitly provides audience restriction with its symmetric HMAC that is generated with the `app_secret` of the appropriate SP. If the SP successfully verifies the HMAC, it can assume that it was issued by Facebook for itself. The SP uses the `user_id` and `code` claims to authenticate the user, i.e., it retrieves the user entry matching the `user_id` from its database or redeems the `code` in exchange for an `access_token`, which is finally sent to the Token Debugging Endpoint.

Facebook does not issue `refresh_tokens` but instead distinguishes between short-lived (approx. 60 minutes) and long-lived (approx. 60 days) `access_tokens`. Short-lived tokens are converted into long-lived tokens with `grant_type=fb_exchange_token` at the Token Endpoint. If long-lived tokens expire, the SP needs to restart the login flow from scratch to receive new short-lived `access_tokens`.

More details are provided in Section 3.4 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
Related news

  1. Hacker Hardware Tools
  2. Beginner Hacker Tools
  3. Growth Hacker Tools
  4. Hacking Tools Windows
  5. Computer Hacker
  6. Hack Tools Download
  7. Hack Tools Mac
  8. Hacking Tools 2019
  9. Hacking App
  10. Pentest Tools Bluekeep
  11. Hacking Tools For Windows Free Download
  12. Hack Tools Pc
  13. Pentest Box Tools Download
  14. Game Hacking
  15. Hacking Tools For Windows Free Download
  16. Pentest Tools Website
  17. Hacker
  18. Hacking App
  19. Bluetooth Hacking Tools Kali
  20. Tools For Hacker
  21. Pentest Recon Tools
  22. Pentest Tools Website
  23. Hacking Tools For Windows Free Download
  24. Hacker Tools Software
  25. Best Hacking Tools 2019
  26. What Are Hacking Tools
  27. Pentest Tools Review
  28. Pentest Tools For Windows
  29. Hacking Tools Windows
  30. Hacker Tools List
  31. Hacker Tools Online
  32. Pentest Tools Android
  33. Ethical Hacker Tools
  34. Hacking Tools Github
  35. Hack Tools Mac
  36. Hacking Tools Hardware
  37. Kik Hack Tools
  38. Hacker Tools Windows
  39. Hacker Tools Windows
  40. Pentest Tools Download
  41. Android Hack Tools Github
  42. Hack Tool Apk No Root
  43. Pentest Tools Nmap
  44. Hack Tools For Windows
  45. Tools Used For Hacking
  46. Hack Tools Github
  47. Hack Apps
  48. Hack Tools Github
  49. Pentest Tools For Mac
  50. Hacking Tools For Windows
  51. Hacking Tools Windows
  52. Hack Tools For Ubuntu
  53. Hacker Tools Windows
  54. Usb Pentest Tools
  55. Hacker Tools For Windows
  56. Blackhat Hacker Tools
  57. Free Pentest Tools For Windows
  58. Pentest Tools For Ubuntu
  59. Hack Tools Download
  60. Best Hacking Tools 2019
  61. Beginner Hacker Tools
  62. Hacking Tools
  63. Pentest Tools Website Vulnerability
  64. Pentest Tools Tcp Port Scanner
  65. Kik Hack Tools
  66. Hacker Tools For Mac
  67. Tools 4 Hack
  68. Hack Tools Mac
  69. Hacker Techniques Tools And Incident Handling
  70. Hack Tools For Ubuntu
  71. Hacks And Tools
  72. Termux Hacking Tools 2019
  73. Hacker Tools Free
  74. World No 1 Hacker Software
  75. Hacking Tools Usb
  76. New Hack Tools
  77. Hacking Tools Mac
  78. Hacking Tools Name
  79. Hacker Tools For Pc
  80. Hacker Tools Online
  81. Hack Tool Apk No Root
  82. Hacking Tools For Windows
  83. Bluetooth Hacking Tools Kali
  84. Pentest Tools Review
  85. Hack Tools Online
  86. Hack Apps
  87. Pentest Automation Tools
  88. Hacker Tools Free Download
  89. Pentest Automation Tools
  90. Pentest Tools Port Scanner
  91. Hacker Tools Mac
  92. Pentest Tools For Mac
  93. Hacker Tools Apk
  94. Pentest Tools Github
  95. Beginner Hacker Tools
  96. Hacker Tools For Pc
  97. Hack Tools For Mac
  98. Hackrf Tools
  99. Install Pentest Tools Ubuntu
  100. Hack Tools Download
  101. Hack Tools For Mac
  102. Hak5 Tools
  103. Nsa Hack Tools Download
  104. Hack Tool Apk
  105. What Are Hacking Tools
  106. Game Hacking
  107. Game Hacking
  108. Top Pentest Tools
  109. Hacker Tools For Mac
  110. Pentest Tools Website Vulnerability
  111. What Are Hacking Tools
  112. Hack Tools Pc
  113. Hacker Hardware Tools
  114. Pentest Tools
  115. Tools Used For Hacking
  116. Hack Tools For Mac
  117. Hacking Tools Free Download
  118. Hacking Tools Software
  119. Pentest Tools For Windows
  120. Pentest Automation Tools
  121. Pentest Tools Online
  122. Nsa Hack Tools
  123. Hacker Search Tools
  124. Pentest Tools Download
  125. Hackrf Tools
  126. Pentest Reporting Tools
  127. Pentest Tools Alternative
  128. Pentest Tools For Android
  129. Computer Hacker
  130. Pentest Tools Framework
  131. Hacker Tools Free