Yandex.Probki. Do you go there?
The last article touched upon the topic of information security of such a large company as Google.
It is time to look towards the domestic manufacturer, namely, Yandex and its service cards.
How it all began I stood, it means, somehow in a traffic jam and I thought that it forces all people to go by one route or another. The answer is obvious: a lot of things.
However, the presence of traffic jams and all sorts of traffic situations definitely plays a significant role (traffic accidents, cloth repairs, cameras).
In addition, these factors take into account all modern navigators when plotting a route.
Well, let's try to influence the traffic situation, at least virtually ...
We will play with cards from Yandex. First, let's look at how the system works. It's simple: mobile users install the application and send data with coordinates, direction and speed to a cozy Yandex server, where the data is aggregated, after which the map is drawn.
In short, you go slowly - it means you are standing in traffic, quickly - everything is free. The more people (devices) send statistics, the more accurate the data. More about the work of the system is written at the very Yandex .
Reading the descriptions of the work of the system, an inquiring mind must certainly be interested in the following phrase:
"All data is impersonal, that is, it does not contain any information about the user or his car."
')
So-so-so, if the data is impersonal, then why don't we try to become that bunch of users who send data, for example, with the speed we need, so that the information about traffic in the chosen direction changes? ( http://en.wikipedia.org/wiki/Spoofing_attack )
So, we have an Android phone on board, a Yandex map application and a Shark sniffer.
You need to start to see how the application and the server communicate with each other.
We agree to send data about road situations, launch a sniffer and ride around the city, collecting packets (network, of course).
To begin with, let's try to put some label on the traffic situation, for example:
catch the package:
uuid - user id parameter
catidx - tag category
lat; lon - coordinates where the mark is placed
comment - comment
packetid - package ID
As, in fact, expected, you can randomly change the uuid. Tags successfully put. The change of packetid also did not affect anything.
Playing with different values (coordinates and label type) and repeatedly sending packets, you can make it difficult to view the map in a short time:
But this is all childish, where is the traffic data?
You do not have to wait long, the following package immediately catches the eye:
uuid is a familiar identifier parameter, whose value can be arbitrarily changed.
packetid - as the name implies, is the package ID. It is also its checksum.
In the payload of the POST request, this is nothing more than gzip, inside which you can see something like:
Just what we are looking for: current location, direction, speed and time.
We try to play with the values in xml, changing the direction, position, speed and time => packets are not accepted by the server. It is obvious, the checksums do not converge. Only one way out: learn how to generate packetid.
Much has already been said about how to get the source code of the Android application, so we will not dwell on this.
Gorgeous. The source is, it remains only to figure out how it works.
And it worked as follows:
1) xml with gzip data
2) the resulting gzip is byte-by-byte with uuid
3) CRC32 was calculated from the result obtained
4) the final result was the coveted packetid
We know how checksums are generated - now nothing prevents us from nakodit script that will send data with our coordinates and speed to the Yandex server.
Test
Everything works fine: a non-existent congestion appeared on the street.
And if there is still a couple of marks about the accident or road works, then it is quite possible to force some gullible drivers (or their navigators) to decide to change their route, thereby allowing me, my darling, to freely drive home!
This and many other infobase reports can be heard at the monthly meetings of the Russian Defcon Group , which take place in St. Petersburg. Come, there is always interesting.
So it goes.
Oh yeah, the information about this bug was promptly provided to the guys from I, who covered everything very quickly. Well done.
You also suggest not to get upset, because there is still Google and Nokia with their traffic jams!
Well, quite curious - the script code for spoofing Yandex.Probok: http://pastebin.com/9y4hmFX9
Many thanks ntkt for help and with the past DR!
See you on the roads.
It is time to look towards the domestic manufacturer, namely, Yandex and its service cards.
How it all began I stood, it means, somehow in a traffic jam and I thought that it forces all people to go by one route or another. The answer is obvious: a lot of things.
However, the presence of traffic jams and all sorts of traffic situations definitely plays a significant role (traffic accidents, cloth repairs, cameras).
In addition, these factors take into account all modern navigators when plotting a route.
Well, let's try to influence the traffic situation, at least virtually ...
We will play with cards from Yandex. First, let's look at how the system works. It's simple: mobile users install the application and send data with coordinates, direction and speed to a cozy Yandex server, where the data is aggregated, after which the map is drawn.
In short, you go slowly - it means you are standing in traffic, quickly - everything is free. The more people (devices) send statistics, the more accurate the data. More about the work of the system is written at the very Yandex .
Reading the descriptions of the work of the system, an inquiring mind must certainly be interested in the following phrase:
"All data is impersonal, that is, it does not contain any information about the user or his car."
')
So-so-so, if the data is impersonal, then why don't we try to become that bunch of users who send data, for example, with the speed we need, so that the information about traffic in the chosen direction changes? ( http://en.wikipedia.org/wiki/Spoofing_attack )
So, we have an Android phone on board, a Yandex map application and a Shark sniffer.
You need to start to see how the application and the server communicate with each other.
We agree to send data about road situations, launch a sniffer and ride around the city, collecting packets (network, of course).
To begin with, let's try to put some label on the traffic situation, for example:
catch the package:
GET /userpoi/addpoint?uuid=a61d46553953fc3e346dae59d852c950&catidx=2&lat=59.985712&lon=30.350740&utf&comment=bla%20bla&packetid=2936036690 HTTP/1.1
Host: mobile-partners.maps.yandex.netuuid - user id parameter
catidx - tag category
lat; lon - coordinates where the mark is placed
comment - comment
packetid - package ID
As, in fact, expected, you can randomly change the uuid. Tags successfully put. The change of packetid also did not affect anything.
Playing with different values (coordinates and label type) and repeatedly sending packets, you can make it difficult to view the map in a short time:
But this is all childish, where is the traffic data?
You do not have to wait long, the following package immediately catches the eye:
POST /ymm_collect/2.x/?uuid=a61d46553953fc3e346dae59d852c950&packetid=2052426273&compressed=1&oauth_token= HTTP/1.1
Content-Type: multipart/form-data; boundary=edge_here
Host: mobile-partners.maps.yandex.net
--edge_here
Content-Disposition: form-data; name="data"
Content-Type: application/gzip
..........m.[.. .E.....(/.4.C1... ..../ml.Y;G....i..........'....4..}..>..3...[.:.E...1i.d![)x..?.'.k...a<.......0.=o..*w.[.FH...J)c.)ot^.......z#oq..x...
.i......uuid is a familiar identifier parameter, whose value can be arbitrarily changed.
packetid - as the name implies, is the package ID. It is also its checksum.
In the payload of the POST request, this is nothing more than gzip, inside which you can see something like:
<?xml version="1.0" encoding="utf8" ?><traffic_collect><point lat="59.946379" lon="30.329207" avg_speed="2" direction="180" time="23052011:194509" /></traffic_collect> Just what we are looking for: current location, direction, speed and time.
We try to play with the values in xml, changing the direction, position, speed and time => packets are not accepted by the server. It is obvious, the checksums do not converge. Only one way out: learn how to generate packetid.
Much has already been said about how to get the source code of the Android application, so we will not dwell on this.
Gorgeous. The source is, it remains only to figure out how it works.
And it worked as follows:
1) xml with gzip data
2) the resulting gzip is byte-by-byte with uuid
3) CRC32 was calculated from the result obtained
4) the final result was the coveted packetid
We know how checksums are generated - now nothing prevents us from nakodit script that will send data with our coordinates and speed to the Yandex server.
Test
Everything works fine: a non-existent congestion appeared on the street.
And if there is still a couple of marks about the accident or road works, then it is quite possible to force some gullible drivers (or their navigators) to decide to change their route, thereby allowing me, my darling, to freely drive home!
This and many other infobase reports can be heard at the monthly meetings of the Russian Defcon Group , which take place in St. Petersburg. Come, there is always interesting.
So it goes.
Oh yeah, the information about this bug was promptly provided to the guys from I, who covered everything very quickly. Well done.
You also suggest not to get upset, because there is still Google and Nokia with their traffic jams!
Well, quite curious - the script code for spoofing Yandex.Probok: http://pastebin.com/9y4hmFX9
Many thanks ntkt for help and with the past DR!
See you on the roads.
Source: https://habr.com/ru/post/142166/
All Articles