Yandex Mail. Preventing hakostrofy

In November last year, Yandex held a competition on the topic of searching for vulnerabilities in its service. I was lucky to find a couple of holes there and get second place for it. Since I haven’t published any details in these six months (except at the Defcon-Russia meeting, but this was orally for a narrow circle of visitors), I decided to fill this gap now. So there will be a story about one of the holes, which was discovered in the framework of the competition and promptly closed by Yandex. I believe that the competition fully justified itself and allowed to prevent the terrible consequences, so the idea is clearly successful, some advantages. Actually, the story will be about the banal absence of verification of authorization in one of the scripts, which could lead to a partial compromise of more than a billion letters only on one node ...

Start

When the competition was announced, I, as the head of the audit department at Digital Security, did not want to participate in it (I’m afraid of competitions in general, and the heads have other important things - an order to give someone or report to demand ... 8)), but , curiosity and thirst for profit dictated their terms. I decided to look for something interesting and fun, so I decided not to waste time searching for vulnerabilities such as XSS and CSRF. First, they are found automatically when examining any script (in fact, a pair of XSS was found right away). Secondly - uninteresting (although dangerous, as shown by kyprizel in the same competition ). In addition, since the competition area (scope) was gigantic, I decided to confine myself to the most interesting service for me - mail. At the same time, I decided not to spend more than one working day in order not to be distracted from work. This allowed me not to worry that I would not find anything, because there is no time (self-justification, aha!), And to look for something really carbon-fueled. In any case, for the beginning it was necessary to simply study the structure and logic of the web interface. This was done tritely - with the help of BurpSuite and the developer interface built into Google Chrome.





Anton Karpov aka toxa ( tokza ) tells how the found bugs will be assessed.

FrontEnd

')

The main script for delivering mail content is some handlers.jsx. It is noteworthy that the developers themselves willingly share information on the mail architecture, so we know that in this case we are dealing with server-side JavaScript . However, I didn’t need all these subtleties, since the very first vulnerability found there turned out to be so classic that the implementation details are not so significant. But first, the general details:

• A request to handlers.jsx can be either POST or GET
• The request indicates the desired module and the corresponding parameters
• XML is received in response to a request.

Some modules and their meaning:

• “Folders” - the contents of folders
• “Message-body” - the body of the letter
• “Nearest-messages” - neighboring letters

To make it clearer, I will provide a screenshot from the same presentation by Alexei Androsov.







That is, it is clear that all the content is collected into a common interface using AJAX requests and rendered into a “human” form thanks to XSL templates.

Well, an example of a request from the same prezy:



/handlers.jsx?_handlers.0=message&ids=1234567890&_handlers.1=message&ids=1234567891



The answer is in the form of XML:

<handlers> <handler name=”message” key=”_h=message&ids=1234567890”> <!--  --> </handler> <handler name="message" key="_h=message&ids=1234567891"> <!--  --> </handler> </handlers> 

It seems simple. The _handlers parameter will determine the data we need (handler module), and ids is the identifier. That is, this example of the request loads letters with identifiers 1234567890 and 1234567891. Naturally, the first thing I tried was to replace ids and substitute there, for example, 123431337, which, ideally, would have returned me an email with this identifier, even not mine.



I did not succeed. By the way, the same action was taken by my colleague and friend - chipik . Last year, we’ve already broken Google for a couple (and we wrote about how it was ). But he also failed. But here's a funny thing: there is such a thing - “code cover”. That is, by taking some kind of verification action, we checked part of the code. It is logical to assume that if you try to replace the module name, it is still the same code that is responsible for checking access authorization by ids identifier. But a little luck helped to understand that it is not.

Baga

After some time, I again decided to replace ids, but for another module - “ nearest-messages ”, and about a miracle ... At first I didn’t even understand how it happened, but later I became convinced that this is the only module that does not check, Does ids belong to the current user? This means that with the help of this module I could load the “neighboring letters” of other server users! Let's analyze the legitimate request:



http:// mail.yandex.ru/neo2/handlers/handlers.jsx?_handlers=message-nearest&ids=2020000002590081157



2020000002590081157 are the ids of my letter, quite specific and definite. The Yandex server returns to this request:



(... - cut to reduce volume)

 <handlers> <handler name="message-nearest" gid="0" key="_handler=message-nearest&ids=2020000002590081157"> <message-nearest> <list> <message id="2020000002590182740"> <thread id="2020000001499988536"/> <folder id="2020000650059912118"/> <date> <timestamp>1320143331000</timestamp> <iso>2011-11-01T14:28:51</iso> <short>01.11.11</short> <full>1 . 2011  14:28</full> </date> <size>2 </size> <last_status/> <subject fwd="Fwd:">TEST</subject> <firstline>,     2</firstline> <to> <name>ne_eik01110d111@yandex.ru</name> . . . </to> <from> <name>SSS AAA</name> . . . </from> … </message> <message id="2020000002590081157"> <thread id="2020000001499929723"/> <folder id="2020000650059912118"/> . . . <size>1,8 </size> <last_status/> <subject re="Re[2]:">TEST</subject> <firstline> ,  … </firstline> … </message> <message id="2020000002590076913"> <thread id="2020000001499929723"/> <folder id="2020000650059912118"/> . . . <full>1 . 2011  14:01</full> . . . <subject>TEST</subject> <firstline> 1</firstline> <from> <name>Alexey Sintsov</name> <email ref="3cab8cda1a132a2d17803cc47cd55d91">ddookie1@inbox.ru</email> </from> <reply-to> <name>ddookie1@inbox.ru</name> <email ref="3cab8cda1a132a2d17803cc47cd55d91">ddookie1@inbox.ru</email> </reply-to> . . . </message> </list> <timer_db>266</timer_db> <timer_logic>175197</timer_logic> </message-nearest> </handler> <login>ne_eik01110d111</login> <actual-version>5.11.55</actual-version> <timestamp>1335882564270</timestamp> </handlers> 

The server returns XML with three objects. Each object is information about the letter:

• When
• From whom
• To whom
• Headline
• The first line of the body of the letter

And the message, the ids of which is indicated in the request, is the second object. The first and third objects are adjacent messages in the same folder as the requested object. Changing ids, for example, by one, we receive three alien messages. Rather, the date of receipt, headers, recipients, ids identifier and the first line of the letter. But actually the first line is not just the first line! Experience has shown that there may be several lines, and the main thing here is the volume and number of line feeds. In my experiments there were results and 5 lines each! That is, the volume is large enough to talk about the real threat.



Sent in body:



– 1



, – 3

----- – 4

– 5

– 6



– 8

! – 9







Intercepted using handlers.jsx:

 <firstline> –  1 ,   –  3 ----- –  4  –  5  –  6  </firstline> 

As you can see, this amount of data is enough to violate confidentiality and even to steal acca from services that send registration data to e-mail (for example, Facebook).

Little little

In general, everything is clear - the simplest bug, but there are a couple of questions:

• How to get access to the right box?
• How to get the right letter in the box?

These are the questions that any adequate cracker who is interested in more targeted and targeted attacks would ask. After all, we are dealing with ids, and to know the ids of the enemy letter is not always given to us (almost never). Thus, the attack becomes a little more dangerous and interesting from the point of view of technology (almost everyone can replace ids, but to calculate it ...)



And there are some other details that have also been clarified by experience. It turns out that ids is not just an identifier of a letter or folder, it is actually an object.



The first 4 digits are the node number (I don’t know how it is properly called, so I’ll call it that) on which the box is hosted. If you pay attention, you will notice that all your letters and folders have this number permanently. Therefore, using the identified vulnerability, you can read letters only from the node where your mailbox is located. There are several billion letters on one node! There are many nodes, and two users who register at the same time can go to different nodes.



In the middle, the type identifier is a folder or message (for message 00, for a folder like 65), and the last digits is the identifier for the message on the node. That's just the last change and you can. That is, in my example, the current message was with the number 259008115 7 . Now you roughly represent the volume of messages on a single node.



The second funny fact: the message identifier is an absolute, incremental value. That is, the next letter processed (received) by the current node will be 259008115 8 . Even if this letter is not sent to me. Now you can solve both problems. That is, perform a targeted attack, and not stupidly dump a billion letters 8)

Attack

It is necessary to create a mailbox on the same node as the victim. The task is difficult to solve if the victim's box is registered for a long time. You can buy or hijack boxes from different nodes and register the boxes on those nodes where possible. But if the victim's mailbox was created recently, then the attack has an absolute probability of success. For example, we will attack the target-mail1 @ yandex.ru box. We have created it recently. Therefore, the success of the attack is high. So, create a bunch of mailboxes: check-mail1 , check-mail2 , check-mail3 , etc. The main thing is that all created mailboxes should be on different nodes. Then we send the letter to target-mail1 and in a copy we put all the boxes we created.







What is humor? When we see ids letters in our “check-mail” accounts, we will try to increment and decrement this value by 5 units. And on the node where check-mailN coincided with target-mail1, we will see our letter. See an example:







So we can access the target box. And what about the target letter? But if you remember, the module through which we exploit the vulnerability shows us neighboring letters in the same folder of the same box (remember that the script shows three messages: what is indicated in ids, and two adjacent ones from the same box). If the selected letter is the last one, then only two letters will be shown to us: the current one and the previous one, including its ids. This means that we can choose this ids for the next query: then we will see it as the second object in the XML response, and the third will be an even older letter. Then we take it already ids and so “slide” down until we read all the letters stored in the folder and find the desired one.

findings

Code coverage in penetration tests and fuzzing is sometimes a key parameter. Here we saw a great example, when everyone tried to change the ids for the message-body module, saw that the request did not roll, and therefore did not begin to do similar tests with other, less obvious modules.



Although the vulnerability is simple, the attack itself is quite complex and requires analysis of the generation of ids and node architecture. Exploiting vulnerability is more interesting than just looking for a “hole”. It was an interesting challenge for hijacking a specific letter from a specific mailbox. It is difficult for old boxes, but still possible, and for newly created boxes, the probability of success is 100%. For old ones, it depends on the ability to start a mailbox on the same node. Statistics on fresh regams: every third or fourth created box falls on the same node. The period of registration at the node since its launch is about six months (that is, a “new” / “newly created” box, this is a box created no more than half a year ago). In theory, then, after six months, to register on this node is already, as I guess, you can not-overloaded.



Thanks:



Anton Karpov ( tokza ) and Yandex company - for an interesting challenge and competition, and for second place. After all, vulnerabilities are everywhere, and such a contest has helped to close many of them!

Dmitry Chastukhin ( chipik ) - for not being very upset when he found out about a bug that he “already checked” ...

d0znpp , kyprizel , ptsecurity - for participating in the competition and for finding terrible holes, which did not allow me to relax the whole month (I hate contests).



Finally proof video ...







Bye everyone!



PS: Since I am not an employee of Yandex, the details of the architecture, algorithms and names may be unreliable. All conclusions about the Yandex.Mail device are based on the author’s inner feelings and intuitive vision.