How does personal data leak, and what should be done in this situation?

**How is personal data leaked and what should be done in this situation?**

By late October, reports began circulating on networks about leaks of personal data belonging to citizens of Uzbekistan, including PINFL (Personal Identification Number of Physical Persons), address, and passport details. Some users stated they found their information in Telegram bots and even posted screenshots as proof on their pages.

Following such alarming reports, the Ministry of Internal Affairs and the Cyber Security Center under the State Security Service announced the start of an investigation. However, as the first week of November comes to a close, officials have not yet released the results. It is also unknown at what stage the investigation currently stands.

How and through which sources is data actually leaked? What should an ordinary user and a company do in such cases? What determines whether applications are secure and reliable? How can one know if data is being transmitted to another server? Cybersecurity specialist Akmal Sodiqov answered these questions in an interview with Gazeta. The full text of the interview is provided below.

— Incidents regarding the leakage of citizens' personal data seem to be observed more frequently in recent years. What is your position on this situation?

— The increase in personal data leaks is not unique to Uzbekistan; it is happening worldwide. As government services become digitized, more data is consolidated into single applications, meaning the number of targets worth attacking also increases. Without technical evidence regarding a specific application, it is difficult to say "yes" or "no"—there is a possibility, but it needs to be verified.

Many of the databases being circulated under the claim that "data leaked from a certain application" are actually aggregations compiled from older databases. Sometimes, the data does not come directly from the application itself, but leaks from another place that has access to the government system to which the application is integrated. For this reason, each case must undergo an independent technical investigation, and the results should be publicly announced. However, it should also be noted that it does not matter whether personal data is old or new; that information remains relevant regardless. Such information can be used for many purposes.

— Where does data usually leak from? What causes this?

— In practice, most leaks occur on the server side, not within the application itself. The most common causes are:

1. Authorization flaws in APIs. The server does not check whether the user sending the request has the right to view that data. As a result, by altering the ID in the request, it becomes possible to obtain another person's data. This is the most widespread vulnerability in the world.

2. Misconfigured storage. Databases left open to the internet without passwords, backup copies, and test servers also open the way for data leaks.

3. Insiders. These could be employees of organizations that have access to the database or are integrated into it; a large portion of the "doxxing/lookup" (probiv) services on Telegram operate precisely through this method.

4. Third-party services. This includes analytics and advertising SDKs (Software Development Kits) embedded in the application, SMS gateways, and cloud services.

The application itself—that is, the code on the phone—is usually not the source of the data. However, hardcoded keys, tokens, and server addresses inside it can open a path for an attacker.

A situation that requires special attention is paid services on the internet. Usually, they do not breach anything themselves. They gather databases leaked from various systems over different years, along with open data from social networks, and turn them into a single search engine.

Searching for, selling, and distributing information about another person without their consent violates personal data legislation.

— By what means can data entered into an application be obtained? Is it an easy process?

— The main methods are:

1. Scraping data en masse from an unprotected API (for example, sequentially generating phone numbers or vehicle plate numbers);

2. Hacking into the server;

3. Misusing internal access privileges;

4. Malware and phishing on the user's phone.

The complexity of these depends on how the system is built. If authorization on the API does not work properly, if there are no rate limits on requests, and if monitoring is absent, obtaining data does not require high qualifications—a few hours of work is enough. In a properly built system, however, this becomes a very expensive and complex process.

— Does a single instance of a data leak mean that the system was hacked?

— Not always. "Hacking" and "leaking" are different things. Data can be exposed without any hacking at all—for instance, through an open database, an API without authorization, an employee selling data, or an error at a partner organization. However, no matter the method, it indicates that security controls failed, and the operator's liability still remains.

— How can it be determined exactly which system the leaked data was taken from? What technical evidence is required for reliable confirmation?

— The primary method is to analyze the structure of the leaked dataset. One must examine whether it contains fields, internal identifiers, record formats, and date ranges unique to only one specific system. After that, it is cross-referenced with activity in that system's logs to check which account or IP address sent requests in an unusual volume and at what time. For reliable confirmation, the following are required:

1. Server and API logs (who requested which records, and when);

2. Audit trails of database access;

3. Precise matching of records from the leaked sample with records in the system;

4. If possible, results from specially set "canary records" (decoy entries).

In a system where logs are not maintained, proving the source is almost impossible. Therefore, retaining logs is also a part of protection.

— How can an ordinary user verify data safety when using an application? What specific points should be kept in mind regarding the privacy policy?

— Google Play has a "Data safety" section, and the App Store has an "App Privacy" section. These indicate what data the application collects and to whom it transmits it. In the privacy policy, one should look at the following:

1. Exactly what data is collected and for what purpose;

2. Who it is transmitted to (third parties, partners, ad networks);

3. Where it is stored (according to Uzbekistan legislation, citizens' data must be hosted on servers within the country);

4. How long it is stored and how it can be deleted;

5. Who the operator is and how to contact them.

If a privacy policy is absent, consists of vague general terms, or is copied from another application, this is a red flag.

— Is it normal if an application requests permissions unrelated to its function, such as access to contacts, microphone, SMS, or location? Can such permissions turn into a serious threat?

— It is not normal. Permissions must match the application's functionality. An application for checking traffic fines does not need access to SMS, contacts, or the microphone. Access to SMS is especially dangerous because one-time passwords from banks and government services are stolen through it. Granting access to contacts exposes not only your data but also the data of your relatives. Constant access to location allows the collection of your movement history. The rule is simple: grant permissions only when necessary, set them to "only while using the app" mode, and deny unnecessary requests.

— What does it mean for an application to obtain user consent to collect personal data? Does giving consent alone grant permission to store and transmit data in any manner?

— No. Consent is granted for a specific purpose and permits the use of data only within the scope of that purpose. Transmitting it to third parties, using it for other purposes, or keeping it longer than necessary requires a separate basis. Consent also does not relieve the operator of the obligation to store the data securely. By clicking the "I agree" button, a user does not consent to having their data leaked. The user also has the right to revoke their consent and demand the deletion of their data.

— Is it possible to check which servers an application sends data to over the internet?

— Yes, it is possible. On iPhone, the "Settings — Privacy & Security — App Privacy Report" section shows which domains each app has contacted. On Android, tools like PSAPdroid or NetGuard allow viewing traffic without root privileges. The Exodus Privacy service identifies tracking SDKs inside an application. Specialists can also analyze the contents of requests using mitmproxy or Burp Suite. If an application sends data to foreign servers, especially to unknown domain names, serious attention should be paid to this.

— What determines the security of an application? How accurate is it to assess it based on its popularity, number of downloads, or developer reputation?

— It is not accurate. The number of downloads indicates how convenient the application is, not how secure it is. On the contrary, an application with many users is a more valuable target for attackers. Security is determined by engineering practices: secure architecture, proper API authorization, encryption, independent pentests, an open channel for reporting vulnerabilities, and fast incident response. A developer's reputation alone is also not enough. It is demonstrated not by talk about the app, but by independent audits and how they conduct themselves when incidents occur.

— What additional risks are introduced by installing an application from a Telegram channel or via an APK file instead of Google Play or the App Store?

— Official stores scan applications for malicious code and verify developer signatures. APKs on Telegram offer no such guarantee. It is possible to distribute a modified version under the name and icon of a popular app: the external appearance remains identical, but inside there is a trojan that steals SMS messages or remotely controls the phone.

In Uzbekistan, a large portion of funds stolen from bank cards occurs precisely through APK files sent under the guise of "check your fine" or "view photos." Furthermore, a user who grants permission to "install from unknown sources" once remains vulnerable to subsequent attacks.

— If a person's full name, phone number, vehicle plate number, and PINFL have been leaked, what should they do first? What risks does this pose?

— The primary risk is social engineering. Because fraudsters know your exact details, they can make convincing calls pretending to be employees of a bank, the Road Traffic Safety Department (YHXX), or another state agency, and ask for SMS codes or card details. In addition, there are risks of attempts to register online microloans in your name, re-issue your SIM card, and targeted scams (phishing). What needs to be done:

1. Do not share SMS codes or card details with anyone. A real bank or government employee will never ask for them, especially via Telegram: Telegram is not an official channel for information exchange;

2. Enable additional protection and two-factor authentication in banking apps and on my.gov.uz;

3. Periodically check loans opened in your name through the credit bureau;

4. Ask your mobile operator about the possibility of placing a restriction on SIM card re-issuance;

5. Immediately report suspicious situations to the bank and law enforcement agencies.

— If a data leak is confirmed, what initial technical measures should developers and the company take?

1. Stop the source.

Close the vulnerable API or exposed database, block compromised accounts, and rotate keys, tokens, and passwords.

2. Preserve evidence.

Make copies of logs and servers. Do not hastily wipe or reinstall servers; otherwise, it will be impossible to identify the source.

3. Assess the scope.

Determine which data, how many users, and what time period are affected.

4. Notify competent authorities.

Inform the Cyber Security Center and the designated state authority in the field of personal data.

5. Openly inform users.

Provide information on what happened and what steps they need to take. Denying or concealing the fact will lead to even greater loss of trust later.

6. Monitoring.

Monitor the distribution of the data across Telegram channels and the darknet.

— Is it possible to completely erase leaked personal data from the internet? If the data has been copied and redistributed, what can the user do?

— Unfortunately, in practice, it is impossible. Once data is copied, it spreads across dozens of channels and archives. Blocking certain channels or websites and submitting complaints to platforms can reduce the spread, but it will not eliminate it completely. Certain paid services exist that offer a "data removal" service, but this merely hides the result on their end; the same database remains in the archives of other systems. Paying for this essentially means funding that very market.

Therefore, the primary focus should be on mitigating the consequences: taking protective measures assuming your data is already public. If a user suffers damage, they can go to court. The operator remains liable for the damage caused.

— What technical requirements do you think are necessary for applications handling personal data in Uzbekistan?

1. Mandatory independent pentesting prior to launch. For applications integrated with state databases, this should be repeated annually. Compliance with international standards such as OWASP MASVS and ASVS must be verified.

2. Data minimization and masking. Data that is not required for the application's operation should not be collected; PINFL and phone numbers must be partially masked on screens and in API responses.

3. API protection. Verifying authorization on every request, implementing rate limiting on requests, and detecting automated scraping attempts.

4. Encryption. Data must be encrypted both in transit and at rest.

5. Access auditing. Recording who viewed which entry and when. This applies especially to employees and integrated partners, as it is the most effective tool against unauthorized lookups ("probiv").

6. Listing and monitoring third-party SDKs.

7. An open channel for reporting vulnerabilities. If a researcher finds a vulnerability, they must know whom to contact.

8. Strict deadlines for incident reporting, both to the competent authority and to users.

9. Enforcing compliance with data localization requirements in practice.

Most importantly, these requirements must not remain merely on paper; they must be verified in practice, and there must be real liability for operators that violate them.