Closed Bug 616038 Opened 11 years ago Closed 11 years ago

x-keyexchange-id Not Validated For Initial Put to Channel

Categories

(Cloud Services :: Server: Key Exchange, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mcoates, Unassigned)

References

Details

(Whiteboard: [infrasec:auth][ws:major])

Issue

Flow: Adding a new device when a sync account has already been created. -->"add device" and "I already have a sync account"

The second request sent to the server is method PUT to URL /xxxx (where xxxx is the channel id received from request #1).  More details in the detailed flow:
https://wiki.mozilla.org/Services/Sync/SyncKey/J-PAKE#Detailed_Flow

At this point the client sending the PUT has the x-keyexchange-id and this value is sent within the PUT message as a header. However, the server does not validate that this value is correct.  

As a result any user can successfully send the PUT message with arbitrary body data to any valid channel.  The likelihood of this attack is low since the attacker would need to be aware of the valid channel IDs and would risk blacklisting if they brute forced. 

The impact is that an unauthorized user could inject false data into the j-pake message exchange. This could easily cause the sync to fail. It may be possible for an attacker to insert malformed or malicious data that results in adverse effects to either of the legitimate parties in the sync transaction.

Steps to reproduce
1. Start a new sync transaction via "add device" and "I already have a sync account"
2. Grab the channel ID and insert it into the below request.
3. Send this request and observe a 200 is returned. Testing also showed this data did persist and would be received by the other clients.


Recommended Remediation
Check that the x-keyexchange-id is valid when receiving the PUT message. 





PUT /av83 HTTP/1.1
Host: stage-setup.services.mozilla.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b8pre) Gecko/20101127 Firefox/4.0b8pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
x-keyexchange-id: f53a6116e67335e447d50cddbc20df78124992c3f3859c80b98c8192c4b80de7ce656274a719a23d69fb4ff53666180dde59853ec756b1f9c48cad5f4474851f1e6f669ddc6d17259f2c5291cb48880ad2f11ed3942d1ff4429383727e09d350021c2f171961c40c4da66810540e9924e8a4e16974f9aced55eeebc601023123
Content-Type: text/plain
Cookie: WT_FPC=id=63.245.220.240-1742613184.30117871:lv=1291078491136:ss=1291078491136; wtspl=551220; SSID=AwB5wCkAAAgAV0v0TFJiAwFXS_RMAQAAAAAAAAAAAAAAAABXS_RMAAAM_v__AAAAAABEAAAARQAAAA; SSRT=WEv0TAE
Pragma: no-cache
Cache-Control: no-cache
Content-Length: 3334

{"type":"receiver1","payload":{"gx1":"87fb52e48cbc3ba8f88c97a74627fceb20bd22b41c1813f8f1f77d636341f50f08c9a925ad63f4184c235fd30b64753ea65cc6837fc641e0bae73182d23a40e7f3bf9763906b4883c523226f8ffc292747be04056ba85256552607ac516d4055e133b7282237c36b39908c71594982377cea6f9790ebeb2844712ba916663a5f00d267d74eed5cd7bb92639128e34064cb5171448083b9ebe71dbf4793e8b5d942c39066e1703c573e02416e1f35c9756480da38a2832e253659efc1969a22d3d115aa80e819e4ef38952ced3303296a9b18fb06b8a6b5f06e1f8eed64852227040d03fa99873e46f15f0e22b9d191e103044c1e1b88ead6ac81751ce0de69eea7e69bd602c504ff3722e8dd0733643de1683ee6a5bcf3acd43a18f4ead796a6a3b8873485811dbb3d36b732b3d050f7eadab550572d0f99e8e649b7f529984a9e25f14f5e99219098484aea42fce8173594e4a13709c1538fa60d3245119fff4772512e8cab5473ede4b108f7aafd4db80d4bbeac547a74a7ebe68ac9e6551a","gx2":"3ecd6bb7187e92b1e2c0d37895859a10ab7dddc608bd02c7373c23740d6a16a9970ef9412547286b157236cae66d6c53957122c38137ea9806d1d0c9725d2f7c8c3bdbb3c19a87ccc94a3042897b58e2aa4a9e4e7aa91bc6cb057261dc4d595693b639d13e87c3379668f94f4390203cd06be4ab5c1f283a7effb541c68e22350c926d9180fcb59ffc1a0ea0eedbf2b8e146bd61f4fd2f7e61e51a8c2ec62c25d40dac65ac70ae76c9260ba3d573048e0186a6e82aa6175467d1f265bc983ef53973cb8b1ee9968aadf59727c9f60e5049ce45ff82af1095c036d12f391dd7d9b195dfc888c4ac59e2dda106822803a2564de9e51f294c1e33caee966de4625e627a79e856889f806a8838a343f29745224bcca45e3d1e03730abfd6c67d3573c7ba6abc9f252ef942f259c65c13a96cd34aed6c2e4f9157e1a0ead91741a0b76349cc690ac5509b450925f3ac128cac4e730017bfc1f0e3a011034800376e422772bb613eaffbe7681dc393b11270f419b86a306dfeef8729485df4814bb5fa","zkp_x1":{"gr":"64834706c72f626ae1d60cfe2b05fe498ed1fd2d647ad9afd7b0bc585aaca5de8234fd533868d6a3a1c07de44862bfb34014ab57dac7b0663540c6cc77cda4e119c33a4af6002e28fc92f97b75ce463c6aa00a0b626650cb7950d1a5cfc61cf081d552d038b70edf0d4903406c4aedddd9279d1a96f8ac211c12de81abee6872a536c3ada03ac1c557ddb229c423ac546dc1d0f4d37c26b5baf4334a835e85f0fa346f8b48820e0724d535230dd2063d12048a3f39eac487e13ad0125a201fad5c52d223cc86d3999bbfe63290b3a80d4c8d3ffce997cbb2a1eb735b9bcf5a5d188708e6f4be72d95b38903fba433f1284372d508776489112bb88f28617e714328995c79cfecb711330b1a5bec8417cfcc6ecba57de012db361e78dfdd7714c44813307f26ff8b8a9b2ea64dda54ac8b5270d62169c451e8a13bbca9db3b298f1283b22ac1762e4ed772670b1f17c1939ad56195fe42cd2e85b0de032bb2652183ace2df417e415c1b0c6dbcd388153a7d173f5e043272e481323cce51fd789","b":"4ffdbbcab0d4b26144a1358d38f87f273157d74b7d6eb8d9672e5f1ef240bcb7","id":"receiver"},"zkp_x2":{"gr":"5872fdb84497c08121583705c3771b8816621385faf45347e862e2e6239258afdf819c059bf584e2eaf90a390352a4a8da49bd0cb3689ef142b77db85bbcca0259c9535ec14e64b275402406a7df140b5d56185b4f56221ab5c03fc2c0c6dfb177f102d3bb93c138a0b98a73ba05b759d39d45bb76989679f15a1d77266871cafc076fd69f6ff7d01f63400dd4adc8ce4257b2d53c7a0bf37534094c0769e113dfbb320a0afc603295a6b1d0133246083d585c856bf7eae4a828c20895850893e8ae6948daca363ac85b5e37675f4b723f79d80a430cefcac8c8a26b98daa6d0fd1be2bee6b7b2d1e89512adcccba0403aa6ebd3769f99c80dc743ac569a4d0e66add349f84cae53afa172787455d2a4d767ea6d7e09d2becd25e1c383a9538167e94013cd678c929739fce54be21fb7aea041c564394758d33f2e47bd4fa6d3d8f755b67d1e0f5e58cd6958f9826e9a125526a6a5c8530a3669c6ae7bae8c41be2071ad8a501b32472beabbe03eefea2fa06169a8d8a4f74857bb6c7e5b2203","b":"8694931c72a7b3e7a29fdde7d5b6d41ac372fdd9851b3d02baa0d1ee3c5a47a1","id":"receiver"}}}
Component: Server: Other → Server: Key Exchange
QA Contact: other-server → key-exchange-server
(In reply to comment #0)
> At this point the client sending the PUT has the x-keyexchange-id and this
> value is sent within the PUT message as a header. However, the server does not
> validate that this value is correct.  

The current mechanism is : 

* when the channel is created, the client id provided is associated to that channel
* on every new request on the channel
** if the client id is a new channel id, it's associated to the channel, unless the channel already has two IDs associated. If the later happens, the request is rejected and the channel closed.
** if the client id is already registered to the channel, the request is not rejected.

So, the filtering makes sure that one channel does not get more than two different client ids. If it happens, it gets closed.

In your test, you can validate this by:

- creating a channel with with client id "A"
- puting data with client id "B"
- any new attempt with client id "C" will fail and the channel will be deleted.


> The impact is that an unauthorized user could inject false data into the j-pake
> message exchange. This could easily cause the sync to fail. It may be possible
> for an attacker to insert malformed or malicious data that results in adverse
> effects to either of the legitimate parties in the sync transaction.

The very nature of J-Pake will avoid this issue because when client A initiates a channel to transmit data to client B, if a client C is able to take the place of client B on the first exchange, client A will get invalid data, unless client C was also able to guess the initial password.

In other words, an attacker needs to:
- guess the channel id in the second client A starts it
- guess the password client A used

the probability of this occurring is over 1/200 billions.
Blocks: 602876
No longer blocks: 60287
(In reply to comment #1)
> In your test, you can validate this by:
> 
> - creating a channel with with client id "A"
> - puting data with client id "B"
> - any new attempt with client id "C" will fail and the channel will be deleted.

Tested. Server properly failed and deleted the channel.

> In other words, an attacker needs to:
> - guess the channel id in the second client A starts it
> - guess the password client A used

Agreed. Very low probability. These controls are sufficient and working properly.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
Group: client-services-security → mozilla-services-security
Group: mozilla-services-security
Resolution: INVALID → WONTFIX
You need to log in before you can comment on or make changes to this bug.