Shared Lottery Backend Exposes Civic Apps to Forgery

A significant security vulnerability has been uncovered in a shared backend system used by multiple Chinese civic and government-adjacent applications. The flaw, detailed in an ongoing series of security analyses, lies in the system's reward and lottery functionality. Specifically, the cryptographic secret used to sign and validate reward claims and lottery outcomes is easily recoverable from the client-side application code. This allows any attacker with basic technical skills to forge authentic-looking reward claims or manipulate lottery results, undermining the integrity of these systems.

The discovery stems from a broader effort to map and understand a specific ecosystem of applications. Researchers found that a set of these apps, which facilitate civic services and often incorporate gamified reward or lottery features, all connect to a single, common backend service for managing these functions. This shared architecture, while potentially efficient, creates a single point of failure and a wide attack surface.

The core of the vulnerability rests on how the backend verifies the authenticity of reward claims and lottery draw participations. Typically, such systems employ digital signatures to ensure that claims or results originate from legitimate sources and have not been tampered with. This requires a secret key held by the server, which is used to sign outgoing data and is also used to verify incoming signatures.

In this case, the secret key, referred to as the signing secret, is not adequately protected. Instead of being securely stored on the server or transmitted only under strict conditions, it is embedded directly within the client-side application code. This is a critical oversight, akin to leaving the key to your house in the mailbox for anyone to find. The research indicates that the secret is readily accessible by anyone who examines the application's code, for instance, by decompiling an Android APK or inspecting network traffic.

Diagram showing the flow of reward claims from client apps to the shared backend.

Exploiting the Recoverable Signing Secret

Once the signing secret is recovered, an attacker can effectively impersonate a legitimate user or system. The process involves intercepting the communication between the app and the backend, or more simply, constructing a malicious request locally. By using the recovered secret, an attacker can sign a forged reward claim, making it appear as if they legitimately earned a reward. Similarly, they can sign a lottery draw result that declares them a winner, even if they never participated or the draw was conducted with different outcomes.

The backend's validation logic, when presented with a signature created using the compromised secret, will incorrectly identify the forged claim or result as authentic. This bypasses the intended security controls, allowing for fraudulent activities. The implications are far-reaching, particularly for systems that may involve monetary rewards or other tangible benefits. It erodes trust in the application's integrity and potentially exposes users and the governing bodies to financial losses and reputational damage.

The research details the journey from a specific GitHub repository, which hosts part of the application code, to the shared backend service. This path highlights how developers might inadvertently expose sensitive information by including critical secrets directly in distributable code. The post walks through the reward validation flow, illustrating exactly where the secret is used and how its recovery enables the forgery of valid claims.

Broader Ecosystem and Trust Implications

The fact that multiple civic applications rely on this single, vulnerable backend raises concerns about the overall security posture of such digital services. If one app is compromised, or its code analyzed, the secret can be extracted and used to attack all other applications sharing the same backend. This creates a cascading risk, where a vulnerability in one seemingly isolated application can have widespread consequences across an entire network of services.

This situation is particularly worrying given the sensitive nature of government-adjacent applications. Users entrust these platforms with personal information and expect them to operate with a high degree of security and fairness. The ability to forge lottery wins or reward claims directly impacts this trust. It also raises questions about the diligence applied during the development and auditing of these systems. Were security reviews conducted? Were static analysis tools employed to detect such embedded secrets?

The research team's ongoing series aims to shed light on such systemic issues within digital ecosystems. By mapping dependencies and identifying shared components, they can reveal common vulnerabilities that might otherwise go unnoticed. For developers and security professionals working with similar architectures, this serves as a stark reminder of the importance of secure secret management. Secrets should never be embedded in client-side code. Instead, they should be managed through secure configuration systems, environment variables, or dedicated secrets management services, with stringent access controls and rotation policies.

The ease with which the signing secret was recovered—described as