“Our experience is shaped by our mission to protect our users in authoritarian regimes.”

— Pavel Durov, September 5, 2024; original post.

We agree with these words. More than that—we believed them.

For someone living under censorship, a Telegram proxy is more than a setting in an application. At times, it is the last narrow path to independent information and the open internet. But that path to freedom becomes a trap if it can silently disclose credentials, expose process memory, or give an attacker control of the device.

After discovering exactly such a risk, we could have reported it to Qt first, established a record of our discovery, and waited through the usual remediation cycle. We chose differently. The night before disclosure, we did not sleep: we revalidated the attack chain, assembled the technical evidence, and documented every stage so Telegram engineers could reproduce the issue immediately. On June 6, we sent Telegram a complete technical report, explicitly marked confidential and prohibited from distribution without permission from ExPatch LLC. Telegram controlled the application and could block the most dangerous path faster than anyone else. We therefore put user safety ahead of sleep, convenience, and the opportunity to establish priority with Qt first.

Telegram was given the first opportunity to protect its users—and used it. Soon afterward, corresponding fixes appeared in Qt, while we were neither informed of upstream coordination nor included in it, and neither the researchers nor ExPatch appeared in the public attribution. Was this routine upstream coordination, or a breach of the trust that gave Telegram its head start? This article presents the documents, code, and timeline so readers can decide for themselves.

The research was conducted against Telegram Desktop 6.8.4, which used Qt 6.11.1.

From Proxy Handling to NTLM

The investigation began with the architecture of Telegram Desktop’s proxy subsystem. We established that HTTP and SOCKS5 proxy connections are delegated to Qt. At this stage, our focus was not a particular library or company, but the trust boundary itself: what happens when a hostile proxy server controls responses during connection establishment? That question became the starting point for the audit.

For almost a month, we examined this mechanism from multiple angles: trust boundaries, state transitions, and ways to force the client into unexpected behavior. Most directions eventually reached a dead end, and the attack surface appeared nearly exhausted. The turning point came when we found that, during an active proxy exchange, Qt accepted a demand to switch authentication to NTLM. A modern proxy connection could silently transition to a legacy mechanism associated with NTLM Relay attacks for decades.

At a high level, the chain is remarkably simple. Telegram Desktop connects through a configured HTTP proxy and Qt sends a CONNECT request. A hostile proxy replies with 407 Proxy Authentication Required and advertises Proxy-Authenticate: NTLM. Qt treats the response as a normal authentication challenge, starts NTLM automatically, and sends the first handshake message—NTLM Type 1 (Negotiate). No explicit user consent is requested.

The key question was which checks Qt performed before allowing NTLM to use the user’s system credentials. Because NTLM Relay has been understood for decades, we expected a control that bound authentication to the intended proxy and prevented the same exchange from being replayed to another service. The implementation contained no such protection: Qt did not validate an expected SPN, did not bind the exchange to a protected channel through EPA, and did not require exchange integrity through MIC. An attacker controlling the proxy did not need to crack NTLM or recover a password; relaying the authentication messages to another service in real time was enough.

This finding changed the investigation completely. NTLM was not hidden behind an obsolete enterprise configuration—it could be triggered in the middle of an ordinary proxy exchange. After a victim connected to the attacker-controlled HTTP proxy, the attacker needed only one normal-looking response: 407 Proxy Authentication Required with Proxy-Authenticate: NTLM. A single header caused Qt to involve the user’s system credentials in an NTLM exchange automatically.

How Qt Starts NTLM Without Confirmation

To understand why one proxy response was sufficient, we traced the complete execution path from processing the 407 response to generating the authentication message. The path consists of three levels.

Level 1 — Qt Accepts the 407 Response

Telegram Desktop configures the proxy through QTcpSocket::setProxy. In qhttpsocketengine.cpp:562–599, Qt processes the proxy’s response to CONNECT. A 407 Proxy Authentication Required status is passed to the built-in authentication mechanism:

} else if (statusCode == 407) {                         // :562
    if (d->authenticator.isNull())
        d->authenticator.detach();

    priv = QAuthenticatorPrivate::getPrivate(
        d->authenticator
    );

    const auto headers = d->reply->header();

    priv->parseHttpResponse(
        headers,
        true,                                            // isProxy=true
        d->proxy.hostName()
    );                                                   // :567
}

NTLM has not yet been selected at this level. The important detail is that Qt passes every proxy-controlled response header to parseHttpResponse() with isProxy=true. The authentication method is therefore selected from attacker-controlled Proxy-Authenticate content. The next level shows how the string NTLM becomes an instruction to start system authentication.

Level 2 — Qt Selects the Authentication Scheme

The transition to NTLM is chosen inside QAuthenticatorPrivate::parseHttpResponse() in qauthenticator.cpp:466–558. Because the function was called with isProxy=true, Qt examines the proxy-controlled Proxy-Authenticate header:

const auto search = isProxy
    ? QHttpHeaders::WellKnownHeader::ProxyAuthenticate
    : QHttpHeaders::WellKnownHeader::WWWAuthenticate;

// isProxy=true  → Proxy-Authenticate
// isProxy=false → WWW-Authenticate

for (const auto &current : headers.values(search)) {
    if (method < Basic
        && str.startsWith("basic"_L1, Qt::CaseInsensitive)) {
        method = Basic;

    } else if (method < Ntlm
               && str.startsWith("ntlm"_L1,
                                 Qt::CaseInsensitive)) {
        method = Ntlm;                                  // :488–490        headerVal = QByteArrayView(current).mid(5);

    } else if (method < DigestMd5
               && str.startsWith("digest"_L1,
                                 Qt::CaseInsensitive)) {
        // ...

    } else if (method < Negotiate
               && str.startsWith("negotiate"_L1,
                                 Qt::CaseInsensitive)) {
        // ...
    }
}

// ...

case Ntlm:
case Negotiate:
    // work is done in calculateResponse()
    break;

An additional problem is that method is reset before each new response is parsed. A proxy can therefore demand NTLM not only in the first response, but in a later 407 and change the scheme while the connection is already being established. Once Ntlm has been selected, the function performs no additional trust checks; generation of the system response is deferred to calculateResponse().

Level 3 — Qt Starts NTLM Without Notifying the Application

After selecting the scheme, execution returns to qhttpsocketengine.cpp:574–599:

if (priv->phase == QAuthenticatorPrivate::Done
    || (priv->phase == QAuthenticatorPrivate::Start
        && (priv->method == QAuthenticatorPrivate::Ntlm
            || priv->method == QAuthenticatorPrivate::Negotiate))) {

    if (priv->phase == QAuthenticatorPrivate::Start)
        priv->phase = QAuthenticatorPrivate::Phase1;     // :578–580
    if ((priv->method != QAuthenticatorPrivate::Ntlm
         && priv->method != QAuthenticatorPrivate::Negotiate)
        || credentialsWasSent) {

        proxyAuthenticationRequired(
            d->proxy,
            &d->authenticator
        );                                               // :596–597
    }
}

The decisive point is the condition before proxyAuthenticationRequired(). With an ordinary scheme, Qt emits this signal so the application can request credentials or refuse authentication. During the first transition to NTLM or Negotiate, however, credentialsWasSent == false, making the entire condition false. No signal is emitted.

Telegram Desktop consequently has no opportunity to approve, warn about, or block the transition. Qt moves the authenticator to Phase1, calls calculateResponse(), asks Windows SSPI for system SSO credentials, and sends an NTLM Type 1 (Negotiate) message to the proxy. The transition is silent not only to the user, but to the application itself.

Why does this permit NTLM Relay? The critical issue is not a flaw in SSPI itself, but the way Qt invokes it during automatic proxy authentication. If QAuthenticator contains no username, Qt does not stop the connection or ask the application for credentials. It calls Windows SSPI and obtains the default credentials of the current logon session. In a domain environment, a hostile proxy can therefore initiate an NTLM exchange on behalf of the user’s corporate account without the user’s knowledge.

Stage 1 — calculateResponse() Selects System Authentication

The first confirmation appears in qauthenticator.cpp:585–592. When the proxy requests NTLM and no challenge has yet been received, Qt begins the first handshake phase:

case QAuthenticatorPrivate::Ntlm:
    if (challenge.isEmpty()) {
#if QT_CONFIG(sspi)
        QByteArray phase1Token;

        if (user.isEmpty()) {
            // Only pull from system if no user was
            // specified in authenticator
            phase1Token = qSspiStartup(
                this,
                method,
                host
            );        }

        // ...
#endif
    }

    // ...
    break;

The Qt comment is explicit: “Only pull from system if no user was specified in authenticator.” This is where a proxy-controlled demand for NTLM is connected to the current Windows account.

Stage 2 — System Credentials in qSspiStartup()

SEC_WINNT_AUTH_IDENTITY auth;
auth.Flags = SEC_WINNT_AUTH_IDENTITY_UNICODE;

bool useAuth = false;

if (method == QAuthenticatorPrivate::Negotiate
    && !ctx->user.isEmpty()) {
    // Explicit credentials are used only
    // for Negotiate with a non-empty user
    useAuth = true;
}

SECURITY_STATUS secStatus =
    pSecurityFunctionTable->AcquireCredentialsHandle(
        nullptr,
        L"NTLM",
        SECPKG_CRED_OUTBOUND,
        nullptr,
        useAuth ? &auth : nullptr,        nullptr,
        nullptr,
        &ctx->sspiWindowsHandles->credHandle,
        &expiry
    );

useAuth becomes true only for Negotiate when a username has been supplied explicitly. In the NTLM path, Qt passes nullptr rather than a SEC_WINNT_AUTH_IDENTITY structure to AcquireCredentialsHandle(). Under the SSPI model, this selects the default outbound credentials of the current Windows security context—typically the logged-on corporate account in a domain environment.

Qt does not obtain the password or NTLM hash in cleartext. SSPI returns an opaque credential handle from which it produces NTLM messages. This distinction matters: the vulnerability lets the attacker relay the victim’s authentication exchange.

Stage 3 — The NTLM Context Is Not Bound to the Intended Proxy

The credential handle is passed to qSspiContinue(), where Qt continues the handshake through Windows SSPI:

InitializeSecurityContext(
    &ctx->sspiWindowsHandles->credHandle,
    ...,
    ISC_REQ_ALLOCATE_MEMORY, // the only requested flag    ...
);

Qt requests only automatic allocation for the output token. Three controls that could have hindered relay are absent:

• ISC_REQ_INTEGRITY is not set, so Qt does not require context integrity;
• no SECBUFFER_CHANNEL_BINDINGS buffer is supplied, so EPA/Channel Binding does not bind the NTLM exchange to a protected channel;
• for direct NTLM, targetNameW remains empty, so no SPN binds the context to the intended service.

Together, these omissions mean the SSPI context is not tied to the proxy to which the user believes they are authenticating. In the tested configuration, Qt generated NTLM Type 1 and Type 3 messages for the domain user, and the controlling proxy could relay them to another corporate service in real time.

Impact and Attack Surface

The scope was substantial: any corporate Windows system on which a user was logged in with a domain account could become a potential entry point. This was not an exotic laboratory configuration, but a widespread class of enterprise devices.

The practical result was an authenticated session on a relay-vulnerable target with the victim’s permissions. Depending on the selected service and the victim’s privileges, the consequences ranged from access to corporate data to remote code execution or compromise of domain infrastructure—all initiated by a single 407 Proxy Authentication Required response.

Two-Stage NTLM → Negotiate Escalation (P1): Two NTLMv2 Responses in One Session

Even supplying an explicit proxy username and password did not protect the user. A controlled server could force two consecutive authentications over a single connection:

1. 407 + Proxy-Authenticate: NTLM
   │
   └─► Qt uses the explicitly configured proxy credentials
       and produces NTLMv2 response no. 1

2. The proxy rejects the first authentication
   │
   └─► qhttpsocketengine resets the authenticator;
       user becomes empty

3. 407 + Proxy-Authenticate: Negotiate
   │
   └─► qSspiStartup() requests the default SSPI credentials;
       Negotiate falls back to NTLM;
       Qt produces NTLMv2 response no. 2
       for the Windows domain user

The attacker therefore received two different NTLMv2 responses in one session: the first based on the explicit proxy credentials, and the second based on the logged-on domain user’s account. Both were under attacker control, and the domain user’s response could be relayed immediately to a selected corporate service.

This scenario significantly expanded the affected population. The attack was not limited to clients with an empty username field: after rejecting the first authentication and forcing a second exchange through Negotiate, the proxy could reach system credentials even when the user had supplied separate proxy credentials.

SOCKS5-in-Tunnel Vector (V3): Injecting a 407 Into an Active Tunnel

Vector V3 did not require the victim to follow a tg://proxy link. It affected domain-joined Windows systems where an enterprise proxy was deployed centrally through GPO, WPAD, or a PAC file.

The key difference from the base vector was the injection point. After a SOCKS5 tunnel had been established, the controlled proxy could see Telegram Desktop’s unencrypted HTTP request—including its headers, URL, and MTProto POST body—and substitute the server response:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM

Qt interpreted the response as a normal proxy-authentication challenge and entered the SSPI path automatically.

In a laboratory environment using a domain-joined Windows 10 machine, a single Telegram Desktop session produced more than 230 NTLM Type 3 messages. Qt’s repeated attempts multiplied the amount of authentication material available to the attacker and the number of relay opportunities.

The Root Cause Is in QtNetwork

Further analysis showed that Telegram Desktop was only one route into the vulnerable code. The root cause was located in QtNetwork’s shared HTTP authentication implementation, qauthenticator.cpp, and was not limited to 407 Proxy Authentication Required responses.

The same path could be reached without any proxy. If an attacker-controlled HTTP server answered an ordinary unencrypted request with 401 Unauthorized and the following header:

WWW-Authenticate: NTLM

Qt treated it as a routine authentication challenge. On a domain-joined Windows system with no explicit credentials supplied, the library called SSPI without user interaction and began an NTLM exchange on behalf of the current account.

The proxy was therefore not a prerequisite for exploitation, but an especially dangerous entry point in Telegram Desktop. The vulnerable mechanism lived deeper in the common Qt HTTP client stack used by many applications.

Where Else the Vulnerable Code Was Reachable

We did not stop at source review of Qt and Telegram Desktop. This was not a theoretical extrapolation from a shared API: we reproduced the same vulnerable primitive in qBittorrent, Nextcloud Desktop, and Electrum.

Other Applications Tested

• qBittorrent 4.6.3 with Qt 6.4.2. A controlled proxy switched the application from Basic to NTLM with a 407 Proxy Authentication Required response, without warning the user. The completed NTLM handshake produced a 65,076-byte NtChallengeResponse, approximately 64,876 bytes of which contained unrelated heap data.
• Nextcloud Desktop 3.11.0 with Qt 5.15.13. One test session performed four consecutive NTLM exchanges. Each response reached 65,076 bytes, disclosing roughly 260 KB of memory in total. The dumps contained complete HTTP requests, Nextcloud WebDAV and API routes, service headers, and NTLM tokens from previous exchanges.
• Electrum 4.7.2 with Qt 6.11.0. We found a separate direct path that required no proxy. A controlled Bitcoin or LNURL invoice description was rendered as rich text by a QML component; an injected <img src="http://…"> caused QNetworkAccessManager to request an attacker-controlled server. A 401 WWW-Authenticate: NTLM response made Qt send an unsigned NTLM Type 1 automatically, while Electrum had no authenticationRequired handler capable of stopping the exchange. We experimentally confirmed reachability and automatic NTLM initiation. Completing Type 3 through SSPI and relaying it requires a domain-joined Windows machine.

The same QtNetwork defect was therefore reproduced across independent products, Qt versions, and both 401 and 407 entry points. Telegram remained the principal object of the research, but the actual blast radius of the underlying root cause extended far beyond one application.

Second Primitive: Heap Memory Disclosure

Although the problem extended beyond Telegram, Telegram Desktop remained the primary target. We continued beyond forced NTLM authentication and relay. If an untrusted server could activate rarely used authentication code without user interaction and control the contents of NTLM Type 2, the remaining attacker-controlled fields also had to be audited.

That work exposed a second independent primitive: reading uninitialized heap memory in qExtractServerTime():

static QByteArray qExtractServerTime(const QByteArray &targetInfoBuff)
{
    QByteArray timeArray;
    QDataStream ds(targetInfoBuff);
    ds.setByteOrder(QDataStream::LittleEndian);
    quint16 avId, avLen;

    ds >> avId;
    ds >> avLen;
    while (avId != 0) {
        if (avId == AVTIMESTAMP) {
            timeArray.resize(avLen);                 // server-controlled length
            ds.readRawData(timeArray.data(), avLen); // short read is not checked        }
        // ...
    }
}

In NTLM Type 2, the server controls targetInfo, including the MsvAvTimestamp identifier and the 16-bit avLen field. We declared a length of 65,000 bytes but supplied only the eight-byte timestamp. Qt allocated the declared buffer, filled only the eight available bytes, and failed to check that readRawData() had performed a short read. The remaining 64,992 bytes retained prior heap contents. Qt then included the entire buffer—uninitialized area included—in the NTLMv2 response sent to the attacker’s server.

An ordinary NTLM exchange thus became a remote, repeatable memory-read primitive. In captured dumps, we confirmed disclosure of code pointers and heap metadata sufficient to bypass ASLR, network addresses, VPN client and adapter names, HTTP headers, and previous NTLM tokens. One hundred exchanges over approximately five minutes yielded about 6.5 MB of Telegram Desktop process memory.

What the Leaked Memory Contained

Individually, the fragments could look like random noise. Together, they formed a detailed profile of the device and its owner: username, work domain and hostname from NTLM, VPN software, virtualization, internal addressing, and enterprise network infrastructure.

The consequences were not limited to deanonymization. The vulnerability indiscriminately transmitted contents of reused heap buffers. Through controlled heap grooming, we placed test passwords and API-secret markers in those buffers and later recovered them from the NTLMv2 response sent to the proxy. The same mechanism could disclose API keys, session tokens, cookies, Authorization headers, and other secrets recently present in process memory. Later disclosures also contained previously generated NTLM Type 3 messages.

Importantly, the domain user’s password was not recovered directly from NTLM. Cleartext passwords could leak as contents of a reused buffer, independently of the NTLM protocol itself.

The most troubling aspect was the channel: a feature intended to help users bypass restrictions and retain access to information. The proxy continued to function, Telegram displayed no warning, and the user could not see that a malicious proxy operator was receiving process-memory fragments—including passwords, API secrets, and data capable of identifying the user or granting access to connected systems.

Video demonstration

Video · PoC 01 Heap-memory disclosure and NTLM relay through Telegram Desktop and QtNetwork

Full RCE Chain: Laboratory Confirmation

To determine the maximum practical impact, we built an isolated Active Directory environment using Windows Server 2022 and an Enterprise CA with AD CS Web Enrollment enabled.

The victim ran the official Telegram Desktop 6.8.2 without any modification to its source, executable, Qt build, or authentication mechanisms. The client used its ordinary configuration. The user’s only action was to add a proxy through Telegram’s supported interface; every offensive component remained on the controlled proxy and laboratory infrastructure.

Once Telegram connected to the proxy, the chain executed automatically:

Video demonstration

Video · PoC 02 The complete laboratory NTLM relay chain through AD CS to RCE with SYSTEM privileges

All nine AD CS relay attempts authenticated successfully and issued a certificate. Because the test account had Domain Admin privileges, we obtained NT AUTHORITY\SYSTEM on both the workstation and the domain controller. The complete chain took approximately 30–35 seconds and required neither password guessing nor password recovery.

Post-compromise access was determined by the victim account’s privileges: an ordinary user did not automatically become a domain administrator. Relaying an administrator, privileged employee, or service account, however, could lead directly to remote code execution and compromise of the corresponding systems. The experiment confirmed the worst-case impact demonstrated in our tests: complete domain takeover through an official, unmodified Telegram Desktop client after adding an attacker-controlled proxy.

The issued certificate also created persistence. A password change did not revoke it automatically; with a one- or two-year certificate lifetime, an attacker could continue authenticating until expiration, explicit revocation, or account disablement.

Why This Was a Telegram Desktop Vulnerability, Not Only a Qt Vulnerability

Reducing the issue to the source file containing the defect ignores the exploitation chain. The library root cause was indeed in QtNetwork. But the attack did not begin inside an abstract Qt application: it began in the official Telegram Desktop client after a proxy was added through the supported tg://proxy mechanism.

Telegram Desktop made the defect practically reachable by:

• accepting and persisting a user-supplied proxy;
• passing it to Qt without prohibiting NTLM and Negotiate;
• giving the user no opportunity to see or reject the proxy-selected scheme;
• allowing an untrusted proxy to activate SSPI and obtain an NTLMv2 response;
• transmitting Telegram Desktop process-memory fragments through the same channel.

This was more than the passive presence of a vulnerable dependency. Remove any key product element—tg://proxy, automatic proxy persistence, or the absence of an NTLM prohibition—and the Telegram path no longer works. Telegram’s product decisions were therefore a necessary part of exploitation, not incidental surroundings for a library flaw.

Responsible Disclosure and Timeline

June 6: Telegram Receives the Complete Report

After a night of continuous validation and preparation, on June 6, 2026, we sent Telegram not a short description or preliminary hypothesis, but a finished 21-page technical report: EXPATCH-2026-TG-002. The package included source-code analysis, exploitation conditions, a PoC, a video demonstration, laboratory results, and the complete RCE chain.

A dedicated section already documented the memory disclosure in qExtractServerTime(): the server-controlled MsvAvTimestamp.avLen field, expansion through timeArray.resize(avLen), the unchecked short read in readRawData(), and transmission of the unread heap contents inside the NTLMv2 response. On page 20, we proposed a specific remediation: validate avLen against the remaining buffer and accept a timestamp only at its expected length of eight bytes.

The image alone does not prove that the recipient downloaded the archive. Together with the email containing the poc.zip link, however, it establishes that the complete PoC existed and was available to Telegram on the day of disclosure.

The timeline is also supported by the original PDF metadata. Its cover is dated June 5, while CreationDate records June 6, 2026 at 04:04:01 UTC—approximately six hours before the email shown above. The file’s SHA-256 is:

SHA-256

c2c88a4db92a9fb06cd64a2efec3e337714a0ecdc32526c6a65b4dc477173f6c

The cover prominently marked the document CONFIDENTIAL and stated that it was supplied under Coordinated Responsible Disclosure, with redistribution prohibited without permission from ExPatch LLC. We approached Telegram before completing a separate disclosure to Qt because Telegram could immediately block the most dangerous path inside its own application.

June 7: Telegram Receives a Fully Working Exploit

The original report was not the end of the disclosure. On June 7, we sent Telegram an additional email with an improved sspi_rce_v3.py: a 694-line end-to-end exploit requiring no password, accompanied by a video of the complete attack. This was neither a conceptual demonstration nor a loose collection of techniques; all necessary credentials were relayed automatically or extracted from the resulting relay chain.

The email described consequences for an ordinary domain user: client-certificate issuance through AD CS, access to Exchange OWA and ADFS, movement to machines where the victim had local administrative rights, and privilege escalation where certificate templates were insecure. In the Domain Admin scenario, the demonstration ended with NT AUTHORITY\SYSTEM on both a workstation and the domain controller, from which complete domain compromise was possible.

The video showed the controlled proxy output, NTLM relay, certificate issuance, PKINIT authentication, and a command prompt appearing on the victim desktop. Telegram received not merely a description of potential harm, but a complete implementation reproducing the chain against a standard, unmodified Telegram Desktop client in an isolated environment.

June 8: Investigation Acknowledged and Two Precise Patches Appear

At 05:08 on June 8, Telegram Support acknowledged receipt and wrote:

“The team is investigating your research, and we will contact you soon.”

The public history of the dependency repository used by Telegram Desktop dates two new commits to the same day:

• at 13:23:04 UTC, a Qt 5 patch;
• at 13:27:01 UTC, a Qt 6 patch.

Both commits identify John Preston as the author. In New York time, they were recorded at 09:23 and 09:27—approximately four hours after Telegram’s reply.

Their content matters as much as their timing. The Qt 6 patch introduced a new file, qtbase_6.11.1/0038-disable-proxy-ntlm.patch, and addressed both independent issues described in our report: forced NTLM/Negotiate authentication through a proxy and the memory disclosure in qExtractServerTime().

The change was not generic “NTLM hardening.” It added an avLen > end - p remaining-buffer check, required avLen == 8, returned and wrote exactly eight timestamp bytes, and introduced qNtlmBufferFits() for targetName and targetInfo bounds checks. These are the same fields, conditions, and safeguards identified in the report.

The patch also covered both Qt network paths used by Telegram: QHttpNetworkConnection and QHttpSocketEngine. When NTLM or Negotiate was detected, the authenticator was reset, the connection ended with ProxyAuthenticationRequiredError, and no NTLMv2 response was sent to the proxy.

June 15–16: Bounty Offer, NDA, and Confirmation of the Fixes

On June 15, Telegram thanked us for the report and offered a $1,000 bounty:

“We would like to award you a bounty of $1000 for your findings regarding NTLM via proxy settings.”

By then, Telegram’s patch contained two independent measures: prohibiting NTLM/Negotiate for proxies and fixing the qExtractServerTime() memory disclosure. The wording of the message did not establish whether the decision covered the complete set of scenarios or only the proxy-related portion of the research.

Money was not our primary concern. We asked Telegram to donate the offered amount to a charity of its choice and requested clarification on whether the decision was final for every reported vulnerability or only for NTLM disclosure through proxy settings.

At 05:07 on June 16, Telegram said the bounty decision was final and directly proposed an agreement that effectively functioned as an NDA. According to the message, its purpose was not only to process the payment or donation, but also to ensure that details of discovered issues were shared “responsibly and only with authorized parties.”

At 05:56, we declined to sign the agreement and recorded our responsible-disclosure position: the technical report would be published after remediation or upon expiration of 90 days from the initial disclosure. We also asked Telegram to notify us once the issues had been fixed or otherwise mitigated.

At 08:53, Telegram sent a separate technical clarification:

“Telegram Desktop v6.9.2 contains fixes for all reported scenarios, with one exception.”

According to Telegram, NTLM was disabled for proxies explicitly configured inside Telegram Desktop, but remained available to system-wide proxies because those configurations are widely used in corporate networks. This exception exactly matched the distinction introduced while the patch was revised on June 10–11: proxies from tg://proxy and application settings were blocked, while system proxies were allowed to use NTLM.

After receiving this response, we decided to complete our separate disclosure to Qt and downloaded the current Qt 6.11.2 branch to check whether the issues were still reproducible. In that branch, however, the vulnerable paths had already been closed.

Reviewing Qt’s history after Telegram’s June 16 response, we discovered matching upstream fixes. Telegram had told us neither that the materials were being transferred nor that coordination with Qt was taking place. ExPatch and the researchers were excluded from the public record of the fixes.

What Matters Is Not the Number of Matches, but Their Precision

We do not claim every subsequent NTLM change in Qt. Our case does not require a long list of tasks and does not rest on broad thematic similarity. It is based on a documented sequence and correspondence traceable to specific lines of code.

On June 6, Telegram received our confidential report describing the qExtractServerTime() defect: the server-controlled MsvAvTimestamp.avLen field, expansion through timeArray.resize(avLen), the incomplete input read, and the subsequent inclusion of uninitialized heap memory in the NTLMv2 response. The report also proposed validating avLen against the remaining buffer and accepting only the expected eight-byte timestamp.

On June 8, Telegram’s repository history records a patch implementing those checks. It added avLen > end - p and avLen != 8, returned only the eight timestamp bytes, and limited the subsequent write to those same eight bytes. The patch simultaneously closed the second reported path by prohibiting NTLM/Negotiate for proxies configured explicitly inside Telegram Desktop.

On June 10, Qt opened QTBUG-147373, recording the start of upstream NTLM work two days after Telegram’s acknowledgement. The associated commit was 6e88e0f708. Two days later, on June 12, Gerrit 744448 appeared: the same qExtractServerTime() function, the same MsvAvTimestamp.avLen field, an eight-byte timestamp requirement, and boundary-condition tests.

Telegram’s patches addressed both problems described in our report: they prohibited NTLM/Negotiate for proxies added within the application and fixed the heap-memory disclosure. Qt subsequently fixed the same timestamp-handling flaw, checking the bounds of the input buffer and requiring an eight-byte timestamp. The match is traceable to the specific defect, the safeguards we proposed, and the behavior of the corrected code.

These changes addressed the problems at two levels. Telegram restricted the dangerous behavior within its own product; the Qt fix addressed the data-handling flaw in the shared library. That is why information about the upstream work mattered to us: we were preparing a separate disclosure to the Qt developers, only to discover that the corresponding changes had already been made. Users received protection, but the researchers were not included in the coordination behind it.

Neither Telegram nor Qt publicly explained the origin of the technical match between the report and the patches or credited us in the records we reviewed. The question is no longer whether a match exists, but how the results of our confidential research reached the upstream fix without notification or attribution.

This Is Not a Dispute Over One Thousand Dollars

For a small research team, public attribution is not a formality or a matter of ego. It is the professional result of forty days of work, evidence of competence, and the foundation of trust on which coordinated disclosure depends. A researcher gives a vendor unpublished material first, granting time and a technical advantage to protect users. In return, the researcher is entitled to expect transparent coordination and credit for their work.

Telegram used that head start to prepare fixes, and users benefited. But when the corresponding Qt changes appeared, we were not informed of the coordination, and neither ExPatch nor the researchers appeared in the public records we reviewed. The company received every benefit of responsible disclosure; the researchers did not receive even the basic transparency on which the model relies.

We are not asking readers to take our word for it. We are publishing the original report, its SHA-256 and metadata, correspondence, laboratory results, vulnerable code, patches, and an exact timeline. We expect Telegram and Qt to answer in the same language—the language of facts: how the results of our confidential research came to be reflected in the upstream fix, and why their source remained unattributed.

Thank you for your time and attention. Research does not live where it is published, but where it is read, verified, and discussed. That is how an individual finding becomes a contribution to the security of every user.

Sincerely,
Alexander Rostilov and Denis Rostilov
ExPatch Vulnerability Research Team

Research and demonstrations: Alexander Rostilov and Denis Rostilov, ExPatch Vulnerability Research Team.
Full report (PDF): English · Русский
Video and illustrations: ExPatch LLC.
Contact: security@expatch.llc · expatch.com

«Наш опыт сформирован нашей миссией — защищать наших пользователей в условиях авторитарных режимов».

— Павел Дуров, 5 сентября 2024 года. Перевод ExPatch; оригинал.

Мы согласны с этими словами. Более того — мы им поверили.

Для человека, живущего в условиях цензуры, прокси Telegram — не просто пункт в настройках приложения. Иногда это последняя узкая тропа к независимой информации и свободному интернету. Но тропа к свободе превращается в ловушку, если способна незаметно раскрыть учётные данные, содержимое памяти или передать злоумышленнику контроль над устройством.

Обнаружив именно такую опасность, мы могли сначала обратиться в Qt, зафиксировать свой приоритет и ждать обычного цикла исправления. Мы поступили иначе. В ночь перед отправкой отчёта мы не спали: перепроверяли цепочку атаки, собирали технические доказательства и подробно описывали каждый этап, чтобы инженеры Telegram могли немедленно воспроизвести проблему. Уже 6 июня мы передали Telegram полный технический отчёт, явно обозначив его как конфиденциальный и запретив распространение без разрешения ExPatch LLC. Telegram контролировал приложение и мог быстрее всех перекрыть опасный путь — поэтому безопасность пользователей мы поставили выше сна, удобства и возможности сначала закрепить свой приоритет у Qt.

Telegram получил возможность защитить пользователей первым — и воспользовался ею. Однако вскоре соответствующее исправление появилось в Qt, тогда как нас не уведомили о координации, не подключили к взаимодействию с upstream, а имена исследователей и ExPatch так и не появились в публичной атрибуции. Была ли это обычная upstream-координация или нарушение доверия, благодаря которому Telegram вообще получил эту фору? В этой статье мы представим документы, код и хронологию, позволяющие читателю ответить на этот вопрос самостоятельно.

Это было не первое наше исследование Telegram Desktop. Ранее мы обнаружили и сообщили команде Telegram об XSS-уязвимости в функции экспорта чатов (thehackernews.com). Завершив ту работу, мы обратили внимание на другой компонент приложения — встроенную поддержку прокси, которой пользователи вынуждены доверять не только свои сообщения, но и безопасность устройства и корпоративной инфраструктуры.

Значение этой функции определил сам Telegram. В официальной публикации возможность настройки Proxy была представлена в разделе Free Speech и прямо названа anti-censorship tool. Команда Telegram тогда заявила: «Мы считаем своей ответственностью предоставлять технологии, защищающие право пользователей на приватность и свободу слова во всём мире» (источник — telegram.org/blog/admin-revolution, перевод ExPatch). Таким образом, Proxy — не второстепенная настройка приложения, а технология, которую Telegram публично сделал частью своей миссии по защите пользователей.

Исследование проводилось на Telegram Desktop 6.8.4, использовавшем Qt 6.11.1.

От обработки прокси к NTLM

Исследование началось с анализа архитектуры прокси-подсистемы. Мы установили, что обработку соединений через HTTP- и SOCKS5-прокси Telegram Desktop делегирует библиотеке Qt. На этом этапе нас интересовала не конкретная библиотека или компания, а сама граница доверия: что произойдёт, если прокси-сервер окажется враждебным и получит возможность управлять ответами во время установления соединения? Именно этот сценарий стал отправной точкой дальнейшего аудита.

Почти месяц мы исследовали этот механизм с разных сторон: проверяли границы доверия, переходы между состояниями и возможные способы навязать клиенту неожиданное поведение. Большинство направлений постепенно упиралось в стену, и поверхность атаки казалась почти исчерпанной. Переломный момент наступил, когда мы обнаружили неожиданное поведение Qt: прямо во время обмена с прокси-сервером библиотека принимала требование переключить аутентификацию на NTLM. Современное прокси-соединение могло незаметно перейти на устаревший механизм, десятилетиями связанный с атаками класса NTLM Relay. Именно этот переход полностью изменил направление исследования.

Эта находка резко расширила модель угроз. До этого исследование ограничивалось логикой установления соединения через HTTP- и SOCKS5-прокси. Теперь же в цепочку включалась интегрированная аутентификация Windows: враждебный прокси-сервер мог заставить Qt инициировать NTLM-обмен от имени пользователя. Вопрос изменился — теперь требовалось понять, что именно получит атакующий после того, как приложение автоматически вовлечёт системные учётные данные в управляемый им обмен.

На верхнем уровне цепочка начинается предельно просто. Telegram Desktop устанавливает соединение через настроенный HTTP-прокси, а Qt отправляет ему запрос CONNECT. Враждебный прокси отвечает кодом 407 Proxy Authentication Required и указывает поддерживаемую схему: Proxy-Authenticate: NTLM. Qt воспринимает этот ответ как штатное требование аутентификации, автоматически запускает NTLM и отправляет первое сообщение рукопожатия — NTLM Type 1 (Negotiate). Всё это происходит без явного запроса согласия пользователя.

Следующим стал ключевой вопрос: какие проверки выполняет Qt перед тем, как доверить NTLM системные учётные данные пользователя? Поскольку атаки класса NTLM Relay известны уже несколько десятилетий, мы ожидали увидеть механизм, связывающий аутентификацию с конкретным прокси-сервером и не позволяющий повторно использовать тот же обмен на другом сервисе. Однако анализ реализации не выявил такой защиты: Qt не подтверждал ожидаемый SPN, не обеспечивал привязку к защищённому каналу через EPA и не требовал проверки целостности обмена посредством MIC. В результате контролирующий прокси атакующий мог не взламывать NTLM и не извлекать пароль — достаточно было переслать сообщения аутентификации другому сервису в реальном времени.

Это полностью взорвало нам мозг: давно забытый функционал NTLM оказался не спрятан за устаревшей корпоративной конфигурацией — его можно было затриггерить прямо посреди обычного обмена с прокси-сервером. После подключения контролируемого HTTP-прокси атакующему требовался всего один штатно выглядящий ответ: 407 Proxy Authentication Required с заголовком Proxy-Authenticate: NTLM. Никакой сложной цепочки для запуска механизма не требовалось — один заголовок, и Qt автоматически вовлекал системные учётные данные пользователя в NTLM-обмен.

Как Qt запускает NTLM без подтверждения

Чтобы понять, почему одного ответа прокси достаточно для запуска NTLM, мы проследили весь путь выполнения — от обработки ответа 407 до формирования сообщения аутентификации. Цепочка состоит из трёх уровней.

Уровень 1 — Qt принимает ответ 407

Telegram Desktop настраивает прокси через QTcpSocket::setProxy. Затем в qhttpsocketengine.cpp:562–599 Qt обрабатывает ответ прокси на запрос CONNECT. При получении статуса 407 Proxy Authentication Required управление передаётся встроенному механизму аутентификации:

} else if (statusCode == 407) {                         // :562
    if (d->authenticator.isNull())
        d->authenticator.detach();

    priv = QAuthenticatorPrivate::getPrivate(
        d->authenticator
    );

    const auto headers = d->reply->header();

    priv->parseHttpResponse(
        headers,
        true,                                            // isProxy=true
        d->proxy.hostName()
    );                                                   // :567
}

На этом уровне NTLM ещё не выбран. Важно другое: Qt передаёт все полученные от прокси заголовки в parseHttpResponse() с параметром isProxy=true. Следовательно, дальнейший выбор схемы аутентификации зависит от содержимого контролируемого атакующим заголовка Proxy-Authenticate. Следующий уровень показывает, как значение NTLM превращается из текста в HTTP-ответе в команду запустить системную аутентификацию.

Уровень 2 — Qt выбирает схему аутентификации

Решение о переходе на NTLM принимается внутри QAuthenticatorPrivate::parseHttpResponse() в qauthenticator.cpp:466–558. Поскольку функция была вызвана с параметром isProxy=true, Qt анализирует именно контролируемый прокси-сервером заголовок Proxy-Authenticate:

const auto search = isProxy
    ? QHttpHeaders::WellKnownHeader::ProxyAuthenticate
    : QHttpHeaders::WellKnownHeader::WWWAuthenticate;

// isProxy=true  → Proxy-Authenticate
// isProxy=false → WWW-Authenticate

for (const auto &current : headers.values(search)) {
    if (method < Basic
        && str.startsWith("basic"_L1, Qt::CaseInsensitive)) {
        method = Basic;

    } else if (method < Ntlm
               && str.startsWith("ntlm"_L1,
                                 Qt::CaseInsensitive)) {
        method = Ntlm;                                  // :488–490        headerVal = QByteArrayView(current).mid(5);

    } else if (method < DigestMd5
               && str.startsWith("digest"_L1,
                                 Qt::CaseInsensitive)) {
        // ...

    } else if (method < Negotiate
               && str.startsWith("negotiate"_L1,
                                 Qt::CaseInsensitive)) {
        // ...
    }
}

// ...

case Ntlm:
case Negotiate:
    // work is done in calculateResponse()
    break;

Именно здесь значение NTLM из контролируемого атакующим HTTP-заголовка становится внутренним состоянием method = Ntlm. Условие method < Ntlm позволяет NTLM заменить схемы с меньшим приоритетом, включая None и Basic.

Дополнительная проблема заключается в том, что перед разбором очередного ответа значение method сбрасывается. Поэтому прокси может потребовать NTLM не только в первом ответе, но и при последующем 407, изменив схему уже в процессе установления соединения. После выбора Ntlm функция не выполняет дополнительных проверок доверия к прокси — дальнейшее формирование системного ответа откладывается до вызова calculateResponse().

Уровень 3 — Qt начинает NTLM-обмен без уведомления приложения

После выбора схемы управление возвращается в qhttpsocketengine.cpp:574–599:

if (priv->phase == QAuthenticatorPrivate::Done
    || (priv->phase == QAuthenticatorPrivate::Start
        && (priv->method == QAuthenticatorPrivate::Ntlm
            || priv->method == QAuthenticatorPrivate::Negotiate))) {

    if (priv->phase == QAuthenticatorPrivate::Start)
        priv->phase = QAuthenticatorPrivate::Phase1;     // :578–580
    if ((priv->method != QAuthenticatorPrivate::Ntlm
         && priv->method != QAuthenticatorPrivate::Negotiate)
        || credentialsWasSent) {

        proxyAuthenticationRequired(
            d->proxy,
            &d->authenticator
        );                                               // :596–597
    }
}

Ключевым оказалось условие перед вызовом proxyAuthenticationRequired(). При обычной схеме Qt отправляет этот сигнал, позволяя приложению запросить учётные данные или отказаться от аутентификации. Но при первом переходе на NTLM или Negotiate, пока credentialsWasSent == false, всё условие становится ложным — сигнал не отправляется.

В результате Telegram Desktop не получает возможности подтвердить переход, предупредить пользователя или заблокировать его. Qt самостоятельно переводит аутентификатор в Phase1, вызывает calculateResponse(), обращается к Windows SSPI за системными SSO-учётными данными и отправляет прокси сообщение NTLM Type 1 (Negotiate). Именно поэтому переход происходит молча — не только для пользователя, но и для самого приложения.

Почему этот переход позволяет провести NTLM Relay? Критическая проблема заключается не в уязвимости самого SSPI, а в том, как Qt использует его внутри автоматической прокси-аутентификации. Если имя пользователя в QAuthenticator не задано, Qt не останавливает соединение и не запрашивает учётные данные у приложения. Вместо этого библиотека обращается к Windows SSPI и получает стандартные учётные данные текущей logon-сессии. В доменной среде это означает, что контролируемый атакующим прокси может без ведома пользователя инициировать отправку NTLM-токенов его корпоративной учётной записи.

Этап 1 — calculateResponse() выбирает системную аутентификацию

Первое подтверждение находится в qauthenticator.cpp:585–592. Когда прокси требует NTLM, а challenge ещё не получен, Qt начинает первую фазу рукопожатия:

case QAuthenticatorPrivate::Ntlm:
    if (challenge.isEmpty()) {
#if QT_CONFIG(sspi)
        QByteArray phase1Token;

        if (user.isEmpty()) {
            // Only pull from system if no user was
            // specified in authenticator
            phase1Token = qSspiStartup(
                this,
                method,
                host
            );        }

        // ...
#endif
    }

    // ...
    break;

Условие challenge.isEmpty() означает, что Qt формирует первое сообщение NTLM-обмена. Затем проверяется user.isEmpty(): если приложение не указало имя пользователя, выполнение не прерывается и управление не возвращается Telegram Desktop. Вместо этого вызывается qSspiStartup().

Комментарий разработчиков Qt прямо описывает это поведение: Only pull from system if no user was specified in authenticator — если пользователь не был явно указан в аутентификаторе, учётные данные необходимо получить из системы. Именно здесь контролируемое прокси-сервером требование NTLM соединяется с учётной записью текущего пользователя Windows.

Этап 2 — Получение дескриптора системных учётных данных в qSspiStartup() (qauthenticator.cpp:1566–1607)

SEC_WINNT_AUTH_IDENTITY auth;
auth.Flags = SEC_WINNT_AUTH_IDENTITY_UNICODE;

bool useAuth = false;

if (method == QAuthenticatorPrivate::Negotiate
    && !ctx->user.isEmpty()) {
    // Явные учётные данные используются только
    // для Negotiate с непустым user
    useAuth = true;
}

SECURITY_STATUS secStatus =
    pSecurityFunctionTable->AcquireCredentialsHandle(
        nullptr,
        L"NTLM",
        SECPKG_CRED_OUTBOUND,
        nullptr,
        useAuth ? &auth : nullptr,        nullptr,
        nullptr,
        &ctx->sspiWindowsHandles->credHandle,
        &expiry
    );

Переменная useAuth становится истинной только для метода Negotiate, когда имя пользователя было задано явно. В пути NTLM функция передаёт в AcquireCredentialsHandle() значение nullptr вместо структуры SEC_WINNT_AUTH_IDENTITY. Согласно модели SSPI, это означает использование стандартных исходящих учётных данных текущего контекста безопасности Windows. В доменной среде ими обычно становятся учётные данные вошедшего в систему корпоративного пользователя.

При этом Qt не получает пароль или NTLM-хеш в открытом виде. SSPI возвращает непрозрачный credential handle, с помощью которого далее формируются сообщения NTLM-аутентификации. Это важное уточнение: уязвимость позволяет атакующему перенаправить готовую аутентификацию пользователя.

Этап 3 — NTLM-контекст не привязывается к ожидаемому прокси

Полученный credential handle передаётся в qSspiContinue(), где Qt вызывает Windows SSPI для продолжения рукопожатия:

InitializeSecurityContext(
    &ctx->sspiWindowsHandles->credHandle,
    ...,
    ISC_REQ_ALLOCATE_MEMORY, // единственный запрошенный флаг    ...
);

В этом вызове Qt запрашивает только автоматическое выделение памяти для выходного токена. При этом отсутствуют три механизма, способные затруднить перенаправление аутентификации:

• флаг ISC_REQ_INTEGRITY не установлен, поэтому Qt не требует защиты целостности создаваемого контекста;
• буфер SECBUFFER_CHANNEL_BINDINGS не передаётся, а значит NTLM-обмен не связывается с конкретным защищённым каналом через EPA/Channel Binding;
• для прямого метода NTLM значение targetNameW остаётся пустым, поэтому контекст не привязывается к ожидаемому сервису посредством SPN.

В совокупности это означает, что сформированный SSPI-контекст не связан с тем прокси-сервером, которому, как полагает пользователь, он аутентифицируется. В протестированной конфигурации Qt генерировал сообщения NTLM Type 1 и NTLM Type 3 с ответом доменного пользователя, которые контролирующий прокси мог в реальном времени перенаправить другому корпоративному сервису.

Воздействие и поверхность атаки

Итог оказался пугающе масштабным: потенциальной точкой входа становилась практически любая корпоративная Windows-система, на которой пользователь вошёл под доменной учётной записью. Речь идёт не об экзотической конфигурации, а об огромном классе корпоративных устройств по всему миру.

Если имя пользователя для прокси не было указано, Qt автоматически обращался к SSPI, получал дескриптор учётных данных текущей Windows-сессии и формировал от их имени сообщения NTLM Type 1 и NTLM Type 3. Атакующему не требовалось знать пароль или извлекать NTLM-хеш: он перенаправлял готовый NTLMv2-ответ на выбранный корпоративный сервис, который воспринимал соединение как аутентифицированное самой жертвой.

Что это даёт? На уязвимой relay-цели — полный карт-бланш в пределах прав доменного пользователя. В зависимости от выбранного сервиса и привилегий жертвы последствия могли начинаться с доступа к корпоративным данным и заканчиваться удалённым выполнением кода или компрометацией доменной инфраструктуры. И всё это запускалось одним ответом 407 Proxy Authentication Required.

Соберём все этапы в единую цепочку. Прокси атакующего не взламывает NTLM и не извлекает пароль пользователя — он действует как посредник, пересылая сообщения аутентификации между Telegram Desktop и выбранным корпоративным сервисом. Windows SSPI формирует корректный NTLMv2-ответ от имени доменного пользователя, но получает его соединение, контролируемое атакующим. Если целевой сервис принимает NTLM и не применяет relay-защиту, он аутентифицирует эту сессию как сессию жертвы. Полная последовательность обмена показана ниже.

Двухэтапная эскалация NTLM → Negotiate (P1): два NTLMv2-ответа за один сеанс

Даже явное указание логина и пароля для прокси не защищало пользователя. Контролируемый сервер мог провести две последовательные аутентификации в рамках одного соединения:

1. 407 + Proxy-Authenticate: NTLM
   │
   └─► Qt использует явно заданные учётные данные прокси
       и формирует NTLMv2-ответ №1

2. Прокси отклоняет первую аутентификацию
   │
   └─► qhttpsocketengine сбрасывает authenticator
       user становится пустым

3. 407 + Proxy-Authenticate: Negotiate
   │
   └─► qSspiStartup() запрашивает стандартные credentials SSPI
       Negotiate переключается на NTLM
       Qt формирует NTLMv2-ответ №2
       от имени доменного пользователя Windows

Таким образом, атакующий получал за один сеанс два различных NTLMv2-ответа: первый — на основе явно заданных учётных данных прокси, второй — на основе системной учётной записи Windows. Оба ответа оказывались под контролем атакующего, а ответ доменного пользователя мог быть немедленно перенаправлен выбранному корпоративному сервису в рамках NTLM Relay.

Этот сценарий существенно расширяет класс затронутых пользователей. Уязвимым оказывался не только клиент с пустым полем username: отклонив первую аутентификацию и навязав повторный обмен через Negotiate, прокси мог открыть путь к системным credentials даже после того, как пользователь явно указал отдельный логин и пароль для прокси.

Вектор SOCKS5-in-tunnel (V3): внедрение 407 внутрь активного туннеля

Вектор V3 не требовал перехода по tg://proxy-ссылке. Он затрагивал доменные Windows-системы, на которых корпоративный прокси централизованно настраивался через GPO, WPAD или PAC-файл.

Ключевое отличие V3 от базового вектора заключалось в точке внедрения ответа 407. После установления SOCKS5-туннеля контролируемый прокси видел незашифрованный HTTP-запрос Telegram Desktop — включая заголовки, URL и тело MTProto POST — и мог подменить ответ сервера:

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: NTLM

Qt интерпретировал этот ответ как штатное требование прокси-аутентификации и автоматически запускал SSPI-путь.

В этом сценарии атакующему не требовалось настраивать прокси-аутентификацию или убеждать пользователя вводить отдельный пароль. SOCKS5-прокси уже присутствовал в системе и применялся без непосредственного участия пользователя.

В лабораторной среде с Windows 10, присоединённой к домену, одна тестовая сессия Telegram Desktop сформировала более 230 сообщений NTLM Type 3. Повторные попытки Qt многократно увеличивали количество доступного атакующему аутентификационного материала и возможностей для его перенаправления.

В отличие от базового сценария с tg://proxy, этот вектор был направлен прежде всего на корпоративных пользователей, чьи прокси-настройки распространялись централизованно. Пользователь мог даже не знать, что его трафик проходит через инфраструктуру, способную инициировать NTLM-аутентификацию от его имени.

Корень уязвимости находится в QtNetwork

Дальнейший анализ показал, что Telegram Desktop был лишь одним из способов достижения уязвимого кода. Первопричина находилась в общей реализации HTTP-аутентификации модуля QtNetwork — qauthenticator.cpp — и не ограничивалась ответами 407 Proxy Authentication Required.

Тот же путь можно было запустить без прокси. Если контролируемый атакующим HTTP-сервер отвечал на обычный незашифрованный запрос кодом 401 Unauthorized и заголовком:

WWW-Authenticate: NTLM

Qt воспринимал его как штатное требование аутентификации. На присоединённой к домену Windows-системе, при отсутствии явно заданных credentials, библиотека без диалога с пользователем обращалась к SSPI и начинала NTLM-обмен от имени текущей учётной записи.

Таким образом, прокси был не обязательным условием эксплуатации, а лишь особенно опасной точкой входа в Telegram Desktop. Уязвимый механизм находился глубже — в общем HTTP-клиентском стеке Qt, которым пользуется множество приложений.

Потенциальная поверхность атаки за пределами Telegram

Получив сообщения NTLM от Qt-клиента, сервер атакующего мог перенаправить рукопожатие на другой сервис, принимающий NTLM: Exchange, AD CS, SMB или LDAP. При отсутствии необходимых relay-защит целевой сервис открывал контролируемую атакующим сессию от имени доменного пользователя.

Уязвимый код использовался двумя основными путями:

• QNetworkAccessManager — при обработке ответа 401 WWW-Authenticate: NTLM от HTTP-сервера;
• QTcpSocket через прокси — при обработке ответа 407 Proxy-Authenticate: NTLM.

Для запуска первого пути было достаточно, чтобы Qt-приложение выполнило доступный атакующему или перехватываемый незашифрованный HTTP-запрос. Наличие отдельного прокси при этом не требовалось.

Уязвимость не ограничивалась теоретической общей функцией QtNetwork. После обнаружения первопричины мы воспроизвели тот же путь атаки в нескольких независимых Qt-приложениях: контролируемый ответ 401 или 407 запускал автоматическое обращение к SSPI и приводил к формированию NTLM Type 3 от имени текущего пользователя Windows. Эти тесты подтвердили, что Telegram Desktop был не единственным уязвимым продуктом, а лишь первой исследованной точкой входа в значительно более широкую поверхность атаки. Ниже приведены как приложения, на которых цепочка была подтверждена практически, так и дополнительные продукты, в которых мы обнаружили достижимый уязвимый путь QtNetwork.

Где ещё достигается уязвимый код

Мы не ограничились анализом исходного кода Qt и Telegram Desktop. Это была уже не теоретическая экстраполяция по общему API: тот же уязвимый примитив мы практически воспроизвели в qBittorrent, Nextcloud Desktop и Electrum.

Практически подтверждённые приложения

• qBittorrent 4.6.3 с Qt 6.4.2. Контролируемый прокси переключил приложение с Basic на NTLM ответом 407 Proxy Authentication Required — без уведомления пользователя. Полный NTLM-handshake завершился формированием NtChallengeResponse размером 65 076 байт, из которых около 64 876 байт приходилось на посторонние данные из heap.
• Nextcloud Desktop 3.11.0 с Qt 5.15.13. За одну тестовую сессию приложение выполнило четыре последовательных NTLM-обмена. Каждый ответ достигал 65 076 байт, поэтому суммарно за одну сессию раскрывалось около 260 КБ памяти. В дампах находились полные HTTP-запросы, WebDAV- и API-маршруты Nextcloud, служебные заголовки и NTLM-токены предыдущих обменов.
• Electrum 4.7.2 с Qt 6.11.0. Здесь обнаружился отдельный прямой путь, не требовавший прокси. Контролируемое описание Bitcoin- или LNURL-счёта отображалось QML-компонентом как rich text, а внедрённый <img src="http://…"> заставлял QNetworkAccessManager выполнить запрос к серверу атакующего. В ответ на 401 WWW-Authenticate: NTLM Qt автоматически отправлял неподписанный NTLM Type 1, причём Electrum не подключал обработчик authenticationRequired, способный остановить этот обмен. Достижимость уязвимого кода и автоматическое начало NTLM-аутентификации были подтверждены экспериментально; завершение Type 3 через SSPI и последующий relay требуют Windows-машины в доменном окружении.

Прямой HTTP-вектор — 401 WWW-Authenticate: NTLM

В этом сценарии прокси не требуется. Достаточно, чтобы Qt-приложение выполнило HTTP-запрос к контролируемому серверу, который ответит требованием NTLM-аутентификации. Помимо подтверждённого в Electrum пути, такая поверхность присутствует в клиентах WebDAV, RSS, внутренних API, картографических сервисов и репозиториев обновлений. К ней относятся Nextcloud и ownCloud Desktop, KDE/KIO, QGIS, RSSGuard, QuiteRSS и другие приложения, передающие HTTP-запросы через QNetworkAccessManager.

Прокси-вектор — 407 Proxy-Authenticate: NTLM

Этот путь был практически подтверждён в Telegram Desktop, qBittorrent и Nextcloud Desktop. Та же поверхность возникает в Mumble и других Qt-приложениях при использовании HTTP- или SOCKS5-прокси. В корпоративной среде она дополнительно охватывает приложения, работающие через прокси, централизованно распространяемый посредством GPO, WPAD или PAC-файла, включая Qt Creator, Wireshark и KeePassXC.

Таким образом, речь шла не об изолированной ошибке Telegram Desktop и не о предположении, основанном только на чтении исходного кода. Один дефект QtNetwork был практически воспроизведён в нескольких независимых продуктах, разных версиях Qt и двух точках входа — через ответы 401 и 407. Telegram оставался главным объектом нашего исследования, однако фактический радиус воздействия обнаруженной первопричины оказался значительно шире одного приложения.

Второй примитив: раскрытие heap-памяти

Масштаб проблемы оказался значительно шире Telegram, однако именно Telegram оставался главной целью нашего исследования. Мы решили не останавливаться на принудительной NTLM-аутентификации и relay-атаке. Если недоверенный сервер мог без участия пользователя активировать редко используемый код аутентификации и управлять содержимым NTLM Type 2, следовало проверить, насколько безопасно Qt разбирает остальные контролируемые атакующим поля.

Именно там мы обнаружили второй независимый примитив — чтение неинициализированной heap-памяти в qExtractServerTime():

static QByteArray qExtractServerTime(const QByteArray &targetInfoBuff)
{
    QByteArray timeArray;
    QDataStream ds(targetInfoBuff);
    ds.setByteOrder(QDataStream::LittleEndian);
    quint16 avId, avLen;

    ds >> avId;
    ds >> avLen;
    while (avId != 0) {
        if (avId == AVTIMESTAMP) {
            timeArray.resize(avLen);                 // длина контролируется сервером
            ds.readRawData(timeArray.data(), avLen); // результат короткого чтения не проверяется        }
        // ...
    }
}

В NTLM Type 2 сервер управляет содержимым targetInfo, включая идентификатор MsvAvTimestamp и 16-битное поле avLen. Мы указывали длину 65 000 байт, но передавали только восьмибайтовое значение timestamp. Qt выделял буфер заявленного размера, записывал в него восемь доступных байт и не проверял, что readRawData() выполнил короткое чтение. Оставшиеся 64 992 байта сохраняли прежнее содержимое heap. Затем Qt включал весь буфер — вместе с неинициализированной областью — в NTLMv2-ответ и отправлял его серверу атакующего.

Это превратило обычный NTLM-обмен в удалённый и повторяемый примитив чтения памяти. В полученных дампах мы подтвердили утечку указателей кода и метаданных heap, достаточных для обхода ASLR, сетевых адресов, названий VPN-клиентов и адаптеров, HTTP-заголовков, а также предыдущих NTLM-токенов. За 100 повторных обменов, занимавших около пяти минут, прокси мог получить приблизительно 6,5 МБ памяти процесса Telegram Desktop.

Что находилось в утекшей памяти

Чтобы оценить практическую ценность примитива, мы развернули контролируемый прокси, извлекли неинициализированную область из NTLMv2-ответов и исследовали результаты повторных обменов.

По отдельности эти фрагменты могли выглядеть случайным мусором. Вместе они образовывали подробный профиль устройства и его владельца: имя пользователя, рабочий домен и hostname из NTLM, используемый VPN-клиент, виртуализацию, внутреннюю адресацию и корпоративную сетевую инфраструктуру.

Но последствия не ограничивались деанонимизацией. Уязвимость без разбора передавала содержимое повторно используемых heap-буферов. В ходе контролируемого heap-grooming мы заранее помещали в них тестовые пароли и маркеры API-секретов, а затем обнаруживали эти значения в NTLMv2-ответе, отправленном прокси. По тому же механизму могли раскрываться API-ключи, токены сессий, cookie, заголовки Authorization и другие секреты, недавно находившиеся в памяти процесса. В последующих утечках также появлялись ранее сформированные NTLM Type 3.

Важно: пароль доменного пользователя не извлекался непосредственно из NTLM. Открытые пароли могли утекать как содержимое повторно использованного буфера, независимо от самого NTLM-протокола.

Примитив был повторяемым. Если первый ответ не содержал нужных данных, атакующий мог инициировать следующий NTLM-цикл, не нарушая видимую работу прокси. В нашем эксперименте 100 обменов примерно за пять минут раскрыли около 6,5 МБ памяти Telegram Desktop. Обнаруженные указатели кода и метаданные heap также позволяли обходить ASLR и подготавливать эксплуатацию других ошибок повреждения памяти.

Особенно тревожно, что каналом утечки становилась функция, предназначенная помогать пользователю обходить ограничения и сохранять доступ к информации. Прокси продолжал работать, Telegram не показывал предупреждений, а пользователь не видел, что оператору вредоносного прокси последовательно передаются фрагменты памяти — включая пароли, API-секреты и данные, способные раскрыть его личность или предоставить доступ к связанным системам.

Видеодемонстрация

Видео · PoC 01 Раскрытие heap-памяти и NTLM relay через Telegram Desktop и QtNetwork

Полная RCE-цепочка: лабораторное подтверждение

Чтобы проверить максимальный практический ущерб, мы построили изолированный стенд с доменом Active Directory, Windows Server 2022 и Enterprise CA с доступным AD CS Web Enrollment.

На стороне жертвы использовался официальный Telegram Desktop 6.8.2 без каких-либо изменений исходного кода, исполняемого файла, Qt или механизмов аутентификации. Клиент работал в штатной конфигурации. Единственным действием пользователя было добавление прокси предусмотренным Telegram способом. Вся атакующая логика находилась на стороне контролируемого прокси и лабораторной инфраструктуры.

После подключения Telegram к прокси цепочка выполнялась автоматически:

Видеодемонстрация

Видео · PoC 02 Полная лабораторная цепочка NTLM relay через AD CS до RCE с правами SYSTEM

На стенде все 9 из 9 попыток relay к AD CS завершились успешной аутентификацией и выпуском сертификата. Поскольку тестовая учётная запись обладала правами Domain Admin, мы получили NT AUTHORITY\SYSTEM как на рабочей станции, так и на контроллере домена. Полная цепочка занимала около 30–35 секунд и не требовала подбора или восстановления пароля.

Уровень последующего доступа определялся правами скомпрометированной учётной записи: обычный пользователь не превращался автоматически в администратора домена. Однако relay учётной записи администратора, привилегированного сотрудника или сервисного аккаунта мог непосредственно привести к удалённому выполнению кода и компрометации соответствующих систем. Наш эксперимент подтвердил верхнюю границу воздействия: полный захват домена через штатный, немодифицированный Telegram Desktop после добавления контролируемого прокси.

Выданный сертификат создавал отдельный механизм сохранения доступа. Смена пароля не отзывала его автоматически: при сроке действия сертификата в один–два года атакующий мог продолжать проходить аутентификацию до истечения срока, явного отзыва сертификата или блокировки учётной записи.

Почему это уязвимость Telegram Desktop, а не только Qt

Сводить вопрос к тому, в каком исходном файле находилась ошибка, — значит игнорировать всю цепочку эксплуатации. Библиотечная первопричина действительно находилась в QtNetwork. Но атака начиналась не в абстрактном приложении Qt: она начиналась в официальном Telegram Desktop, после добавления прокси штатным механизмом tg://proxy.

Именно Telegram Desktop делал дефект практически достижимым:

• принимал и сохранял предоставленный пользователем прокси;
• передавал его в Qt без запрета NTLM и Negotiate;
• не предоставлял пользователю возможности увидеть или отклонить выбранную прокси-сервером схему;
• позволял недоверенному прокси активировать SSPI и получить NTLMv2-ответ;
• передавал через этот же канал фрагменты памяти процесса Telegram Desktop.

Это не просто присутствие уязвимой зависимости. Уберите любой из ключевых продуктовых элементов — tg://proxy, автоматическое сохранение прокси или отсутствие запрета NTLM — и описанная цепочка через Telegram прекращается. Следовательно, решения Telegram были необходимой частью эксплуатации, а не случайным окружением библиотечной ошибки.

Правила bug bounty Telegram также не поддерживают попытку вынести такой отчёт за пределы scope. В них прямо сказано:

“Generally, any Telegram-owned or operated app, web service, domain, server and protocol that either handles or stores private user data is in scope.” — Telegram Bug Bounty Program

Telegram Desktop является официальным приложением Telegram и обрабатывает частные данные пользователей. В нашем случае через него раскрывались NTLMv2-ответы, сведения, позволяющие идентифицировать пользователя, и содержимое памяти самого процесса. При наличии необходимых корпоративных условий подтверждённая relay-цепочка приводила к выполнению кода с правами скомпрометированной учётной записи.

Программа исключает невоспроизводимые проблемы устаревших или заведомо дефектных версий стороннего ПО. Наш случай был противоположным: атака воспроизводилась на официальном немодифицированном Telegram Desktop, сопровождалась PoC и привела к изменению кода. Сами правила Telegram указывают, что соответствующие scope отчёты, результатом которых стало изменение кода или конфигурации, могут претендовать на награду. Позднее Telegram и сам признал продуктовую составляющую, предложив нам $1000 именно за находки, связанные с NTLM через настройки прокси.

Наконец, Telegram располагал полным контролем над немедленным устранением проблемы — и фактически им воспользовался. Уже 8 июня публичная история его репозитория датирует появление отдельных патчей для Qt 5 и Qt 6. Они запретили NTLM/Negotiate для прокси, добавленных внутри приложения, и исправили qExtractServerTime, не дожидаясь выпуска новой версии Qt.

Поэтому здесь нет противоречия: Qt отвечал за дефект библиотеки, а Telegram — за уязвимый путь внутри поставляемого им продукта. Исправление upstream было необходимо, но оно не отменяло ни принадлежность Telegram Desktop к заявленному scope, ни ответственность за защиту пользователей официального клиента.

Ответственное раскрытие и хронология

Сорок дней исследования

Изначально нашей целью был Telegram Desktop. Но чем глубже мы разбирали обработку прокси-аутентификации, тем дальше исследование уходило за границы самого приложения — сначала в QtNetwork, затем в SSPI и инфраструктуру корпоративной аутентификации. Так поиск одной уязвимости Telegram превратился в анализ целого класса ошибок, затрагивавшего экосистему Qt.

Мы потратили на эту работу более сорока дней: изучали исходный код, тестировали разные версии Qt, проводили фаззинг, строили доменный стенд и проверяли цепочки эксплуатации на штатном Telegram Desktop. К этому моменту у нас было два независимых результата. Первый — практически подтверждённая NTLM relay-цепочка, которая в лабораторном домене приводила к SYSTEM. Второй — повторяемое чтение до 65 КБ heap-памяти, раскрывавшее секреты и указатели, пригодные для обхода ASLR.

Эти результаты важно не смешивать. Relay уже обеспечивал RCE в подходящем корпоративном окружении. Для отдельной универсальной клиентской RCE-цепочки, не зависящей от Active Directory и прав доменной учётной записи, нам требовался дополнительный примитив записи или управления памятью.

К концу исследования мы были физически истощены. Нам хотелось получить от Telegram техническую обратную связь, понять, правильно ли команда оценивает серьёзность находок, и затем продолжить поиск недостающего примитива. Одновременно мы готовили отдельное обращение в Qt.

Но ждать означало оставлять пользователей Telegram под угрозой. Поэтому мы решили сначала дать Telegram возможность немедленно перекрыть опасный путь на уровне приложения. Не прерывая работу и не ложась спать, мы собрали полный 21-страничный отчёт: с анализом исходного кода, PoC, видео, утечкой памяти, деанонимизацией и лабораторно подтверждённой RCE-цепочкой. Затем обозначили документ как конфиденциальный и передали его Telegram.

6 июня: полный отчёт передан Telegram

После ночи непрерывной проверки и подготовки материалов 6 июня 2026 года мы направили Telegram не краткое описание и не предварительную гипотезу, а законченный 21-страничный технический отчёт EXPATCH-2026-TG-002. В переданный пакет входили анализ исходного кода, условия эксплуатации, PoC, видеодемонстрация, результаты лабораторных испытаний и полная RCE-цепочка.

Отдельный раздел отчёта уже тогда описывал утечку памяти в qExtractServerTime(): контролируемое сервером поле MsvAvTimestamp.avLen, увеличение QByteArray через timeArray.resize(avLen), неполное чтение readRawData() и последующую отправку непрочитанного содержимого heap внутри NTLMv2-ответа. На странице 20 мы предложили конкретное исправление: проверять avLen по оставшемуся размеру буфера и принимать timestamp только ожидаемой длины — восемь байт.

На этой странице зафиксирован весь путь данных: сервер объявляет AVTIMESTAMP длиной 65 000 байт, Qt заполняет только восемь байт выделенного буфера, а затем включает оставшиеся 64 992 байта в отправляемый NTLM Type 3. Там же приведены фрагмент уязвимого кода и категории данных, обнаруженных во время практического тестирования.

Первый скриншот показывает начало обращения. На следующем видна нижняя часть отправленного письма: защищённый архив с PoC, описание видеодемонстрации полной цепочки, пять конкретных рекомендаций для Telegram, имена исследователей, дата раскрытия и прикреплённый PDF-отчёт.

Существование PoC на дату обращения отдельно подтверждается карточкой архива poc.zip в Google Drive. Для файла размером 151 МБ указаны две отметки: Created — Jun 6, 2026 и Modified — Jun 6, 2026. Дата Opened — Sep 17, 2026 относится только к последующему открытию файла и не изменяет первоначальную датировку.

Само по себе это изображение не доказывает скачивание архива получателем. Однако вместе со скриншотом письма, содержащим ссылку на poc.zip, оно подтверждает, что полный PoC существовал и был доступен Telegram уже в день обращения.

В совокупности эти материалы показывают, что Telegram получил не абстрактное сообщение об NTLM. Ему был передан полный пакет исследования: датированный технический отчёт, точное описание heap leak, воспроизводимый PoC, видео, готовые меры исправления и сведения об авторах.

Хронологию дополнительно подтверждают метаданные исходного PDF. Его обложка датирована 5 июня, а поле CreationDate содержит время 6 июня 2026 года, 04:04:01 UTC — примерно за шесть часов до отправки показанного письма. SHA-256 файла:

SHA-256

c2c88a4db92a9fb06cd64a2efec3e337714a0ecdc32526c6a65b4dc477173f6c

На обложке документ был прямо обозначен как CONFIDENTIAL и передан в рамках Coordinated Responsible Disclosure с требованием не распространять его без разрешения ExPatch LLC. Мы обратились к Telegram раньше, чем завершили отдельное обращение в Qt, поскольку Telegram мог немедленно перекрыть наиболее опасный путь на уровне собственного приложения.

7 июня: Telegram получил полностью работоспособный exploit

Первоначальным отчётом раскрытие не ограничилось. Уже 7 июня мы направили Telegram дополнительное письмо с усовершенствованным sspi_rce_v3.py — 694-строчным zero-password end-to-end exploit — и видеозаписью полной атаки. Это была не концептуальная демонстрация и не набор разрозненных техник: все необходимые учётные данные автоматически перенаправлялись либо извлекались из результатов relay-цепочки.

В письме были отдельно описаны последствия для обычного доменного пользователя: выпуск клиентского сертификата через AD CS, доступ к Exchange OWA и ADFS, перемещение на компьютеры, где жертва обладала локальными административными правами, а при небезопасной конфигурации шаблонов сертификатов — повышение привилегий. Для сценария с Domain Admin демонстрация заканчивалась получением NT AUTHORITY\SYSTEM на рабочей станции и контроллере домена; дальнейшие действия могли привести к полной компрометации домена.

Видеозапись последовательно показывала вывод контролируемого прокси, NTLM relay, выпуск сертификата, PKINIT-аутентификацию и появление командной строки на рабочем столе жертвы. Telegram получил не только описание возможного ущерба, но и полностью работоспособную реализацию, воспроизводившую всю цепочку на изолированном стенде против штатного, немодифицированного Telegram Desktop.

В совокупности два скриншота связывают дату, содержимое и факт передачи: 7 июня Telegram располагал анализом первопричины, эксплуатационным кодом и видеодоказательством полной цепочки. Иными словами, речь шла уже не о гипотетическом риске, который ещё требовалось подтвердить, а о воспроизводимой компрометации, продемонстрированной от первого сетевого ответа до выполнения команд на целевой системе.

8 июня: подтверждение расследования и два точечных патча

8 июня в 05:08 Telegram Support подтвердил получение материалов и сообщил:

“The team is investigating your research, and we will contact you soon.”

В тот же день публичная история используемого Telegram Desktop репозитория зависимостей датирует появление двух новых коммитов:

• в 13:23:04 UTC — патч для Qt 5;
• в 13:27:01 UTC — патч для Qt 6.

Автором обоих изменений указан John Preston. По времени Нью-Йорка это 09:23 и 09:27 — примерно через четыре часа после ответа Telegram.

Особенно важно не только время появления изменений, но и их содержание. Патч для Qt 6 был добавлен новым файлом qtbase_6.11.1/0038-disable-proxy-ntlm.patch и одновременно закрывал две независимые проблемы, описанные в нашем отчёте: принудительную NTLM/Negotiate-аутентификацию через прокси и утечку памяти в qExtractServerTime().

Изменение не ограничивалось общей рекомендацией «усилить NTLM». В нём появилась проверка остатка буфера avLen > end - p, требование avLen == 8, возврат и запись ровно восьми байт, а также отдельная функция qNtlmBufferFits() для проверки границ targetName и targetInfo. Это те же поля, условия и защитные меры, которые были названы в нашем отчёте.

Патч также охватывал оба сетевых пути Qt, использовавшихся Telegram: QHttpNetworkConnection и QHttpSocketEngine. При обнаружении NTLM или Negotiate аутентификатор сбрасывался, соединение завершалось с ProxyAuthenticationRequiredError, а NTLMv2-ответ больше не отправлялся прокси.

Совпадение затрагивало не только общую тему, но и конкретную функцию qExtractServerTime(), атакующее поле MsvAvTimestamp.avLen, ошибочное поведение при коротком чтении, точную допустимую длину timestamp и предложенный нами запрет NTLM/Negotiate для прокси. Всё это появилось в одном новом патче, история которого датирована днём подтверждения расследования.

Коммитные даты сами по себе не устанавливают точный момент публичной публикации патчей или их доставки пользователям. Однако история репозитория показывает, что 8 июня — через два дня после передачи отчёта и примерно через четыре часа после ответа Telegram — были подготовлены точечные исправления именно тех двух независимых проблем, которые содержались в EXPATCH-2026-TG-002.

15–16 июня: предложение награды и подтверждение исправлений

15 июня Telegram поблагодарил нас за отчёт и предложил награду в размере $1000:

“We would like to award you a bounty of $1000 for your findings regarding NTLM via proxy settings.”

К этому моменту патч Telegram уже включал две независимые меры: запрет NTLM/Negotiate для прокси и исправление утечки памяти в qExtractServerTime(). Поэтому формулировка письма не позволяла понять, оценивалась ли вся совокупность переданных сценариев или только proxy-часть исследования.

Деньги не были для нас главным вопросом. Мы попросили направить предложенную сумму на благотворительность и прямо уточнили, является ли решение окончательным для всех описанных уязвимостей либо только для NTLM disclosure через настройки прокси.

16 июня в 05:07 Telegram сообщил, что решение о награде окончательное, и предложил оформить соглашение для обработки выплаты или пожертвования.

В 05:56 мы сообщили, что не намерены подписывать соглашение, и зафиксировали собственную позицию по responsible disclosure: технический отчёт будет опубликован после устранения уязвимостей либо по истечении 90 дней с даты первоначального обращения. Мы также попросили Telegram уведомить нас, когда проблемы будут исправлены или иным образом нейтрализованы.

В 08:53 Telegram направил отдельное техническое уточнение:

“Telegram Desktop v6.9.2 contains fixes for all reported scenarios, with one exception.”

По словам Telegram, NTLM был отключён для прокси, явно добавленных внутри Telegram Desktop, но оставлен для системных прокси, поскольку такая конфигурация широко используется в корпоративных сетях. Это исключение точно соответствует разделению, которое появилось при доработке патча 10–11 июня: прокси из tg://proxy и настроек приложения блокировались, тогда как системному прокси разрешалось использовать NTLM.

Это письмо стало одним из наиболее сильных документальных подтверждений связи между нашим исследованием и исправлениями. Telegram указал не одну находку, а “all reported scenarios”, назвал конкретную исправленную версию и отдельно описал оставшийся системный proxy-вектор. Поскольку переданный отчёт включал NTLM relay, утечку памяти и несколько способов достижения уязвимого кода, такая формулировка заметно шире первоначального описания награды как относящейся только к NTLM через настройки прокси.

При этом письмо не сообщало о координации с Qt и не содержало сведений о публичной атрибуции исследователей. Поэтому наиболее сильная и проверяемая позиция звучит так: Telegram получил полный отчёт, подготовил совпадающие исправления, а затем сам подтвердил, что версия 6.9.2 закрывает переданные сценарии, — но ExPatch и имена исследователей в связанных публичных изменениях указаны не были.

Когда технический вопрос стал вопросом атрибуции

После ответа Telegram мы собирались продолжить исследование: найденный read-примитив открывал путь к поиску write-примитива и прямой RCE-цепочки, не зависящей от конфигурации корпоративного домена. Однако при повторной проверке актуального кода выяснилось, что ключевые пути уже закрыты: NTLM/Negotiate больше нельзя было навязать через прокси, вручную добавленный в Telegram, а qExtractServerTime() отклоняла некорректный timestamp и больше не включала непрочитанный хвост heap в NTLMv2-ответ.

Мы хотели, чтобы эти ошибки были устранены — именно поэтому и передали Telegram полный отчёт. Вопрос был не в том, имел ли Telegram право оперативно защитить пользователей: разумеется, имел. Вопрос заключался в другом: когда появились эти изменения, почему они настолько точно соответствовали переданным нами материалам и почему исследователей не уведомили о работе с Qt.

Независимо обнаружить общий риск автоматической NTLM-аутентификации возможно. Гораздо труднее объяснить простым совпадением одновременное совпадение конкретной функции qExtractServerTime(), управляемого поля MsvAvTimestamp.avLen, механизма утечки непрочитанного heap и способа исправления через проверку оставшегося размера буфера и обязательную длину timestamp в восемь байт.

Чтобы отделить факты от предположений, мы восстановили публичную историю патчей — по датам, функциям и отдельным строкам кода. Она не раскрывает канал, по которому информация попала в Qt, но показывает, что последовательность событий и техническая точность изменений требуют объяснения, а вопрос атрибуции нельзя списать на случайное совпадение.

Не количество совпадений, а их точность

Мы не будем приписывать себе каждое изменение NTLM-кода, появившееся в Qt в последующие недели. Наш довод не требует длинного списка задач и не строится на общем тематическом сходстве. Он основан на документированной последовательности и соответствии, прослеживаемом до конкретных строк кода.

6 июня Telegram получил наш конфиденциальный отчёт с описанием дефекта в qExtractServerTime(): управляемое сервером поле MsvAvTimestamp.avLen, увеличение QByteArray через timeArray.resize(avLen), неполное чтение входного буфера и последующая отправка непрочитанного содержимого heap внутри NTLMv2-ответа. В отчёте также было предложено проверять avLen по оставшемуся размеру буфера и принимать timestamp только ожидаемой длины — восемь байт.

8 июня история репозитория Telegram датирует появление патча, реализующего эти проверки. В нём появились условия avLen > end - p и avLen != 8, возврат только восьми байтов timestamp и ограничение последующей записи теми же восемью байтами. Одновременно патч закрывал второй описанный нами путь — запрещал NTLM/Negotiate для прокси, явно настроенных внутри Telegram Desktop.

12 июня в Qt Gerrit было создано изменение 744448. Оно исправляло ту же функцию qExtractServerTime(), проверяло то же поле MsvAvTimestamp.avLen, требовало восьмибайтовую длину timestamp и добавляло тесты для усечённого targetInfo, некорректного avLen и выхода заявленной длины за границы входного буфера.

Публичная история фиксирует однозначную последовательность: сначала Telegram получил конфиденциальный отчёт с конкретным дефектом и способом его исправления; через два дня те же меры появились в патче Telegram; ещё через четыре дня практически идентичное изменение было оформлено в Qt Gerrit.

Ни Telegram, ни Qt публично не объяснили происхождение этого технического соответствия и не указали нас в просмотренных записях. Поэтому вопрос заключается уже не в том, существует ли совпадение, а в том, как результаты переданного нами исследования оказались отражены в upstream-исправлении без уведомления и атрибуции.

Это не спор о тысяче долларов

К этому моменту речь уже шла не о размере награды. Мы потратили более сорока дней на анализ исходного кода, фаззинг и лабораторное воспроизведение атак. Нам удалось связать поведение официального, немодифицированного Telegram Desktop с двумя независимыми последствиями: автоматическим NTLM relay, подтверждённым вплоть до RCE в доменной лаборатории, и повторяемой утечкой памяти через NTLMv2-ответы. Следующим этапом должен был стать поиск write-примитива для построения цепочки, не зависящей от корпоративной инфраструктуры.

Для небольшой исследовательской команды публичная атрибуция — не формальность и не вопрос самолюбия. Это профессиональный результат сорока дней работы, доказательство компетенции и основа доверия, на котором вообще существует coordinated disclosure. Исследователь передаёт вендору неопубликованные материалы первым, предоставляя ему время и техническое преимущество для защиты пользователей. В ответ он вправе ожидать прозрачной координации и сохранения авторства исследования.

Именно такое преимущество мы предоставили Telegram. Мы не стали сначала закреплять приоритет через публичные материалы или обращаться к разработчику библиотеки. После бессонной ночи мы направили Telegram законченный конфиденциальный отчёт, потому что считали безопасность пользователей важнее собственного признания и верили, что команда поступит с переданной информацией ответственно.

Telegram использовал эту фору для подготовки исправлений — и пользователи от этого выиграли. Но после появления соответствующих изменений в Qt нас не уведомили о координации, а ExPatch и имена исследователей не появились в просмотренных публичных записях. Компания получила все преимущества ответственного раскрытия; исследователи не получили даже базовой прозрачности, на которой эта модель держится.

Мы не предлагаем читателю верить нам на слово. Мы публикуем исходный отчёт, его SHA-256 и метаданные, переписку, лабораторные результаты, уязвимый код, патчи и точную последовательность дат. От Telegram и Qt мы ожидаем ответа на том же языке — языке фактов: как результаты нашего конфиденциального исследования оказались отражены в upstream-исправлении и почему их первоисточник остался без атрибуции.

Благодарим вас за время и внимание к этой работе. Исследование живёт не там, где оно опубликовано, а там, где его читают, проверяют и обсуждают. Именно так отдельная находка становится вкладом в безопасность всех пользователей.

С уважением,
Александр Ростилов и Денис Ростилов
ExPatch Vulnerability Research Team

Исследование и демонстрации: Александр Ростилов и Денис Ростилов, ExPatch Vulnerability Research Team.
Полный отчёт (PDF): Русский · English
Видео и иллюстрации: ExPatch LLC.
Контакт: security@expatch.llc · expatch.com