SEB integrity bypass

[uznplay]

Describe the Bug
SEB has a mechanism to check the integrity of the application by sending the hash code to the server to check, but that hash code can be easily replayed and sent directly to the server and used again

Steps to Reproduce
Steps to reproduce the behavior:

1. open friddler everywhere
2. open seb
3. capture the hash
4. when you have the hash string you can edit the seb source code to send it directly or use proxy to inject hash header
5. done you passed integrity check, enjoy the exam

Version Information

• OS: window 10
• seb 3.10

[danschlet]

The Browser Exam Key hash value is itself hashed with the URL of the page/request the hash is sent on/with. The assessment system must make sure that the hash is verified throughout the exam and that each time the check is performed, the URL differs. If this also differs for each user (random order or an additional random string in the URL query), then a replay attack is hardly realistic.

Also the App Signature Key used together with SEB Server offers additional security and is harder to be replayed.

Additional security features are being worked on currently.

[uznplay]

nah i dont know
i jusst test in our college exam system : exam.fpt.edu.vn

the installer here : https://drive.google.com/drive/folders/18YV2s6gIA8LCdsBsocdOEVenOnnCd-tm

and ưhen the integity wrong , server notice that wrong seb version and i cant login it
but i try capture seb hash header when it send to server and replay it
yeah i success and take an exam without problem

[dbuechel]

Please specify to which mechanism you refer exactly and provide detailed, step-by-step instructions on how to reproduce the exploit as a security advisory.

[midiakiasat]

What the reporter is describing is not a generic replay, but a lack of freshness binding between the integrity proof and a server-validated challenge.

If the server accepts a static or predictably derived hash (even if it is URL-bound), then replay remains possible unless all of the following are enforced server-side:

1. A per-session or per-request nonce/challenge generated by the server
2. One-time or short-lived validity of that nonce
3. Verification that the hash is computed over (binary signature + nonce + request context)
4. Rejection of previously seen proofs (replay cache)

Relying on “different URLs” or client-controlled query parameters is insufficient if:

• the URL is observable,
• the hash is deterministic,
• or the server does not track reuse.

The fact that the reporter could replay a captured header against a real exam system strongly suggests the backend treats the hash as a bearer token, not a challenge–response proof.

If possible, this should be evaluated under responsible disclosure as a protocol-level issue, not an implementation detail. A minimal reproduction would be:

• server issues nonce N
• client returns H(binary_signature || N || context)
• server verifies N unused and expires it

Without that pattern, replay resistance is not guaranteed.

[dbuechel]

Thanks for the detailed information @midiakiasat, I think we'll definitely take this up and discuss your findings internally.