메뉴
BL
Ars Technica 10일 전

구글, 수천만 크로미움 사용자 위협하는 익스플로잇 코드 공개

IMP
9/10
핵심 요약

구글이 29개월 동안 패치되지 않은 크로미움(Chromium) 기반 브라우저의 심각한 취약점과 이를 악용하는 개념 증명(PoC) 코드를 버그 트래커에 실수로 공개했습니다. 이 취약점은 악성 사이트 접속만으로 기기를 좀비 PC처럼 활용해 DDoS 공격이나 사용자 활동 모니터링에 악용될 수 있어 크롬 및 엣지 등 크로미움 기반 브라우저 사용자들에게 매우 치명적입니다.

번역된 본문

구글은 수요일, 크롬(Chrome), 마이크로소프트 엣지(Microsoft Edge) 및 사실상 모든 크로미움(Chromium) 기반 브라우저를 사용하는 수백만 명의 사용자를 위협하는 해결되지 않은 취약점의 익스플로잇 코드를 공개했습니다.

이 개념 증명(PoC) 코드는 긴 동영상 및 기타 대용량 파일을 백그라운드에서 다운로드할 수 있게 해주는 표준인 브라우저 페치(Browser Fetch) 프로그래밍 인터페이스를 악용합니다. 공격자는 이 익스플로잇을 사용하여 사용자의 브라우저 사용 현황을 모니터링할 연결을 만들고, 사이트를 보기 위한 프록시로 사용하며 서비스 거부(DoS) 공격을 시작할 수 있습니다. 브라우저에 따라 연결은 브라우저나 실행 중인 장치가 재부팅된 후에도 다시 열리거나 열린 상태로 유지됩니다.

29개월 동안 (그리고 계속해서) 패치되지 않음 이 패치되지 않은 취약점은 사용자가 방문하는 모든 웹사이트에서 악용될 수 있습니다. 실제로 이 탈취는 장치를 제한된 봇넷의 일부로 만드는 제한된 백도어와 같습니다. 그 기능은 악성 사이트 방문, 다른 사람에 의한 익명 프록시 브라우징 제공, 프록시 디도스(DDoS) 공격 활성화, 사용자 활동 모니터링 등 브라우저가 수행할 수 있는 동일한 작업으로 제한됩니다. 그럼에도 불구하고, 이 익스플로잇을 통해 공격자는 수천, 어쩌면 수백만 대의 장치를 단일 네트워크로 묶을 수 있습니다. 별도의 취약점을 사용할 수 있게 되면 공격자는 이를 악용해 모든 장치를 탈취할 수 있습니다.

이 취약점을 발견하고 2022년 말에 구글에 비공개로 보고한 독립 연구원 리라 레반(Lyra Rebane)은 인터뷰에서 "여기서 위험한 부분은 다양한 브라우저를 한데 모아 향후 마음대로 코드를 실행할 수 있다는 점"이라고 말했습니다. 그녀는 구글이 시기상조로 공개한 익스플로잇 코드를 사용하는 것은 "꽤 쉬울 것"이라고 말했지만, 이를 확장하여 많은 수의 장치를 단일 네트워크로 구성하려면 더 많은 작업이 필요할 것이라고 덧붙였습니다.

구글에 대한 레반의 취약점 공개 스레드에서 두 명의 개발자는 별도의 답변에서 이것이 "심각한 취약점"이라고 말했습니다. 이 문제의 심각도는 두 번째로 높은 등급인 S1으로 평가되었습니다. 보고된 지 29개월이 지난 동안 이 취약점은 크로미움 개발자들을 제외하고는 알려지지 않았습니다. 그러다 수요일 오전, 크로미움 버그 트래커에 공개되었습니다. 레반은 처음에 이 취약점이 마침내 해결되었다고 생각했습니다. 얼마 후, 그녀는 실제로 패치가 적용되지 않은 상태로 남아 있다는 것을 알게 되었습니다. 구글이 게시물을 삭제했지만, 익스플로잇 코드와 함께 보관 사이트에서 계속 볼 수 있습니다. 구글 대표자는 어떻게 그리고 왜 취약점을 공개했는지, 패치가 제공될지 여부와 시기에 대해 묻는 이메일에 즉시 답변하지 않았습니다.

지연은 흔합니다 레반은 자신이 패치로 이어진 여러 다른 크롬 또는 크로미움 취약점을 보고했다고 말했습니다. 그녀는 이번 사례가 가장 길었지만, 수정의 긴 지연은 일반적이라고 말했습니다. "제 생각에 일어난 일은 이것이 정의된 보안 경계를 넘지 않기 때문에 다소 비표준적입니다."라고 그녀는 말했습니다. "따라서 이것은 공격자가 예를 들어 이메일이나 컴퓨터에 액세스하는 것을 허용하지 않습니다. 저는 그것이 [구글의] 직원이 할당되거나, 할당된 사람들이 그것을 이해하지 못해 그렇게 오래 걸렸다고 생각합니다."

브라우저 페치(Browser fetch) API를 악용함으로써 코드는 지속적으로 활성 상태를 유지하는 서비스 워커(service worker)를 엽니다. 이 연결은 악성 사이트에서 실행되는 자바스크립트(JavaScript)에 의해 호출됩니다. 특히 엣지(Edge)에서 실행될 때 이 익스플로잇은 탐지하기가 매우 어렵습니다. 자바스크립트는 다운로드 드롭다운 창을 "열 수도" 있지만, 항목을 추가하지는 않습니다. 이후 브라우저를 실행할 때는 더 이상 창이 나타나지 않습니다. 크롬에서는 다운로드 드롭다운 창이 조금 더 지속적으로 나타납니다. 어느 쪽이든 숙련도가 낮은 사용자는 이러한 동작을 단순한 버그로 인한 가벼운 문제로 여기며 기기가 탈취되었다는 사실을 전혀 알지 못할 가능성이 높습니다.

비공개 버그 공개 스레드에서 한 개발자는 해당 로그를 기반으로 익스플로잇이 사용된 흔적을 발견했다고 전했습니다.

원문 보기
원문 보기 (영어)
Text settings Story text Size Small Standard Large Width * Standard Wide Links Standard Orange * Subscribers only Learn more Minimize to nav Google on Wednesday published exploit code for an unfixed vulnerability in its Chromium browser codebase that threatens millions of people using Chrome, Microsoft Edge, and virtually all other Chromium-based browsers. The proof-of-concept code exploits the Browser Fetch programming interface, a standard that allows long videos and other large files to be downloaded in the background. An attacker can use the exploit to create a connection for monitoring some aspects of a user’s browser usage and as a proxy for viewing sites and launching denial-of-service attacks. Depending on the browser, the connections either reopen or remain open even after it or the device running it has rebooted. Unfixed for 29 months (and counting) The unfixed vulnerability can be exploited by any website a user visits. In effect, a compromise amounts to a limited backdoor that makes a device part of a limited botnet. The capabilities are limited to the same things a browser can do, such as visit malicious sites, provide anonymous proxy browsing by others, enable proxied DDoS attacks, and monitor user activity. Nonetheless, the exploit could allow an attacker to wrangle thousands, possibly millions, of devices into a network. Once a separate vulnerability becomes available, the attacker could use it to then compromise all those devices. “The dangerous part here is that you can just have a lot of different browsers together that you can in the future run something on that you figure out,” said Lyra Rebane, the independent researcher who discovered the vulnerability and privately reported it to Google in late 2022 in an interview. She said using the exploit code Google prematurely published would be “pretty easy,” although scaling it to wrangle large numbers of devices into a single network would require more work. In the thread of Rebane’s disclosure to Google, two developers said in separate responses that it was a “serious vulnerability.” Its severity was rated S1, the second-highest classification. Since its reporting 29 months ago, the vulnerability remained unknown except to Chromium developers. Then on Wednesday morning, it was published to the Chromium bug tracker. Rebane initially assumed the vulnerability was finally fixed . Shortly thereafter, she learned that, in fact, it remained unpatched. While Google removed the post, it remains available on archival sites, along with the exploit code. Google representatives didn’t immediately respond to an email asking how and why it published the vulnerability and if or when a fix would become available. Long delays are common Rebane said she has reported multiple other Chrome or Chromium vulnerabilities that have resulted in patches. She said long delays in fixing them are common, although this instance was the longest. “I think what happened is sort of nonstandard in that it does not get past any defined security boundaries,” she said. “So this does not let an attacker, for example, access your emails or your computer or something like that. I guess that led to [Google’s] own people getting assigned, or the people who were assigned not understanding it, and then that’s how it took such a long time.” By exploiting the browser fetch API, the code opens a service worker that remains persistently active. The connection is invoked by JavaScript running on a malicious site. Exploits are particularly hard to detect when run on Edge. The JavaScript “might” open a downloads dropdown window, but it doesn’t add any items to it. On later browser launches, the window will no longer appear. On Chrome, the download dropdown is more persistent. In either case, less experienced users are likely to consider the behavior the result of a nuisance bug and have no idea their device is compromised. In the private bug disclosure thread, a developer said that logs indicate that use of the background fetch feature is extremely limited on Chrome, with on average “~17 completed files per user per day.” “That’s pretty solid confirmation that nothing awful is happening at scale,” the developer wrote. It’s not known how widely used the feature is for browsers other than Chrome. Rebane said she doubts the vulnerability is being actively exploited against other browsers. Nonetheless, the vulnerability poses a risk. Users of Chromium browsers should be suspicious of download dropdowns that appear for no reason. Drilling into the cause and discovering they’re the result of the vulnerability being exploited remains more complicated. Other browsers Rebans confirmed as vulnerable include Brave, Opera, Vivaldi, and Arc. Both Firefox and Safari are unaffected because they don’t support the browser-fetching feature. Dan Goodin Senior Security Editor Dan Goodin Senior Security Editor Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82. 32 Comments