PC 영역에서 은행 멀웨어가 피해자들을 속이기 위해서 웹 공격을 사용하는 것은 흔한 일 입니다. 하지만 안드로이드 기반에서 금융 멀웨어는 이제 새로운 모습입니다. 전통적으로 안드로이드에서 금융 멀웨어는 오버레이 기술을 피해자들의 신분정도를 훔치는데 사용하였습니다.

2022년도에 IBM 보안 트러스티어 연구자들은 금융 모바일 멀웨어에서 새로운 흐름을 발견했는데 이는 기존의 전통적인 오버레이 범행방식을 대체하고 있었습니다. 이러한 공격은 옛날에 이용되던 웹 공격 방식을 안드로이드 용으로 변형을 한 것 입니다. IBM 트러스티어는 이 공격벡터가 안드로이드 웹뷰어의 요소를 가지고 있기 때문에 이러한 이러한 공격전술을 모바일 웹 공격이라고 불러왔습니다.

이 블로그에서는 2가지의 효과적인 공격기술인 웹인젝션공격과 모바일 쿠키공격에 대해서 이야기 합니다.

  Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials.
  In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets Android and is replacing the classic overlay M.O. (Modus Operandi). These new attacks use the good-old web attack tactics with adjustments made for Android. IBM Trusteer has dubbed these attack tactics Mobile Web(View) attacks because the attack vector is the Android WebView component, and not the browser application (for reasons that will be explained in the following sections).
  In this blog, two extremely effective attack techniques are discussed: Web(View) injection attack (based on web injects in the browser) and mobile cookie stealing.

무엇이 웹 인젝션 공격인가요? / What is a Web Injection Attack?

웹인젝션 공격은 화면이 실행되는 동안에 고객 쪽에서 보이는 페이지의 내용을 조작하고, 범죄자들이 몰래 빠져나올 수 있게 하는 멀웨어를 사용하는 기술을 이야기 합니다. 웹인젝션 공격동안 멀웨어는 웹싸이트 안에 HTML 또는 자바스크립트 코드를 넣는데, 이때 피해자의 기기에 설치 되어있던 웹 브라우저 프로세스 영영안에서 코드가 실행이 됩니다.

웹인젝션 공격은, 브라우저에서 피해자들이 보는 것이 웹서버에서 의도한 것과는 다르게 할 수 있습니다. 게다가, 웹사이트에서 써져있던 모든 사적인 정보들이 멀웨어에 노출이 되어집니다.

예를 들면 멀웨어에 의해서 주입된 자바스크립트 코드는 유저들이 기입하였던 HTML 양식으로 부터 데이터를 추출합니다. 이 방법을 활용하면서, 멀웨어는 로그인 신분정보, 신용카드 번호, CVV 등을 훔칠 수 있습니다. 이 데이터는 이후에 멀웨어를 작동하고 있는 C2C 서버로 전송이 됩니다.

또 다른 웹인젝션의 예시는 웹싸이트의 화면을 조작하는 것 입니다. 추가적인 개인의 식별정보를 훔치기 위해서 웹인젝션 공격으로 새로운 필드를 넣는데 사용이 됩니다. 이 필드는 합법적인 서비스에서는 요청하지 않는 것 입니다. 또는 기존에 존재하는 필드를 없애기도 하는데 이는 보안경고를 보여주기 위해 사용되는 것을 보지 못하도록 방해하는 것 입니다. 이 공격은 자금 전송버튼을 누를 때 수취인을 자금세탁용 계좌로 바꾸는 디바이스 안에서 이루어 지는 사기를 수행하는데 멀웨어를 사용합니다.

  A web injection attack is a technique used by malware to exfiltrate and manipulate the content of a website from the client side as it is being presented by the browser. During a web injection attack, the malware injects HTML or JavaScript code into the website by running code in the scope of the web browser process that is installed on the victim’s device.

  In a web injection attack, what the victim sees in the browser might be different from what is intended by the web server. In addition, every private detail entered by the victim on the website is exposed to the malware.

  For example, the JavaScript code that is injected by the malware can extract data from an HTML form that the user has filled in. Using this method, the malware can steal login credentials, credit card numbers, CVVs and so on. That data can then be sent to the command-and-control server (C2C) of the malware operator.

Another common example of a web injection attack is to manipulate the visuals of a website. This type of web injection attack can be used to insert new fields to steal additional personal identifiable information (also known as PII) that is not requested by the legitimate service or even to remove existing fields, which can prevent the user from seeing security warnings. This attack is also used by malware to perform on-device fraud (ODF) by changing the payee of a transaction initiated by the victim to the fraudster mule account.

Figure 1 — An example of injected JavaScript code. The injection creates a fake login form of an e-commerce company instead of the original content of the legitime website (left) versus the original HTML of the legitime website (right).

Figure 2 — The result of the injected JavaScript code: a fake login form of an e-commerce company (left) versus the original legitime website (right).
Due to all of these capabilities, the web injection technique is especially common among desktop financial malware, such as the Zeus Sphinx variant, IcedID and TrickBot.

모바일에서 웹인젝션 공격이 왜 일어나지 않나요? / Why Are There No Web Injection Attacks on Mobile?

웹인젝 션공격의 사용이 컴퓨터용 금융멀웨어의 표준일지라도, 이것은 모바일의 경우가 아닙니다. 대신에 안드로이드에 있는 금융멀웨어는 오버레이 기술을 사용하고, 대부분의 경우, RAT (원격접속) 기술을 활용해 피해자들의 신분정보를 훔칩니다.

웹인젝션이 모바일에서 사용되지 않는 이유는 루팅되지 않는 컴퓨터에서는, 브라우저 앱 프로세스에 코드 인젝션을 할 수 없기 때문입니다.

안드로이드 OS는 안드로이드 샌드박싱의 설치를 하는데에 대한 제약들을 강화합니다.

  Although the use of web injection attacks has become the standard for desktop financial malware, this is not the case for mobile. Instead, financial malware on Android mostly uses the overlay technique, and more recently RAT techniques to steal victims’ credentials.
  The reason web injection is not used in mobile is that on a non-rooted Android phone (and without using exploits), code injection to the browser application process (or to any other application on the device) is not possible. The Android operation system enforces these restrictions with the implementation of Android sandboxing.

안드로이드 샌드박스 / Android Sandbox

일반적으로 안드로이드 OS에서, 고유한 리눅스 유저ID를 각각의 설치된 앱에 할당이 됩니다. 안드로이드는 이 UID를 이용해서 샌드박스 안에 커넬레벨 앱을 설치합니다. 커넬이 강화된 프로세스 아이솔레이션은 서로간의 파일과 리소스, 그드릐 코드의 조작에 접근하면서, 앱들이 서로 코드를 주입하는 것을 방해합니다.

샌드박스의 보호 덕분에 모바일 멀웨어는 구글크롬과 같은 다른 앱들에 코드를 주입할 수 없으며, 실제 은행 앱에 코드를 를 주입할 수도 없습니다. 결과적으로 안드로이드 멀웨어는 안전통적인 웹 인젝션 공격을 수행할 수 없습니다.

In general, in Android OS, a distinct Linux user ID (UID) is assigned to each installed application. Android uses this UID to set up a kernel-level Application Sandbox. The kernel-enforced process isolation prevents applications from injecting code into each other, accessing each other’s files and resources, and manipulation of their code. Due to the sandbox protections, mobile malware cannot inject code into other browser applications such as Google Chrome and cannot inject code into the real banking application. As a result, Android malware cannot perform classic web injection attacks on Android.

Figure 3 — An example showing the UID of three processes running on a device: a banking application, a malware application, and the Chrome browser application.

안드로이드 웹뷰에 주입하는 웹인젝션 공격의 소개 / Challenge Accepted: Introducing the Web(View) Inject Attack Android WebView

웹뷰는 URL을 불러오는데 사용되는 앱 안에 심을수 있는 브라우저 입니다. 웹뷰의 요소는 그 안에서 작동될수 있는 앱의 하나의 부분 입니다. 이것은 안드로이드 샌드박스에 의해서 보호되지 않습니다. 사실 안드로이드는 앱을 이용해서 자바스크립트 코드를 고유한 웹 뷰 안에 삽입합니다.

IBM 트러스티어에 의해 조사된 바에 따르면, 금융웹페이지를 조작하기 위해서 멀웨어는 은행 앱들을 모방하고 합법적인 은행 URL을 불러오는 웹뷰를 작동시킵니다. 멀웨어는 고유한 웹뷰안에서 공격에 필요로 되는 자바 스크립트 코드를 삽입하고 피해자들의 이름과 비밀번호와 같은 HTML필드안에 피해자에 의해서 기입된 정보를 갈취하는 코드를 사용합니다.

전반적인 공격 흐름은 아래의 그림과 같습니다.

  WebView is an embeddable browser inside an app that is used to load a URL. The WebView element is a part of the application it is running within; therefore, it is not protected by the Android Sandbox. In fact, Android allows an application to inject JavaScript code into its own WebView.
According to the malware analyzed by IBM Trusteer, to manipulate a banking website, the malware impersonates the banking application and runs a WebView that loads a legitimate URL of the bank. The malware injects JavaScript code that is required for the attack into its own WebView and uses that code to intercept text entered by the victim into the HTML fields such as the victim’s username and password.
  The overall attack flow is shown in the following figure:

 Figure 4 — Web(View) Inject attack flow.

*Smishing, also known as SMS-phishing, is a mobile text message containing a link to download malware or visit a malicious site via phishing.

How can malware inject its own code into a WebView element?

안드로이드 자바스크립트 인터페이스의 소개 / Introducing Android JavaScript Interface

안드로이드는 개발자들에게 자바스크립트 코드와 웹뷰를 사용하는 안드로이드 앱을 연결할 수 있도록 하는 인터페이스를 제공합니다. 웹뷰를 사용하여 웹앱을 만드는 안드로이드 개발자들은 자바스크립트 코드와 기존의 안드로이드 코드 사이에 인터페이스를 만들 수 있습니다.

이 기술을 사용하기 위해서는 합법적인 페이지의 HTML 에 안에 있는 정확한 필드이름을 알아야만 합니다. 결과적으로 자바스크립트 코드는 안드로이드의 기능들과 통신하기 위해서 인터페이스 안에 안드로이드 기능의 정확한 이름을 알아야만 합니다.

트러스티어가 조사한 멀웨어 안에, 안드로이드 자바스크립트 인터페이스 기능은 “sendCerd,” “closeFrom,” “sendBalance.” 이 있습니다. 유저들이 그들의 아이디와 비밀번호를 넣을 때, 멀웨어는 val() jQuery 을 활용하여 그 값을 추출하고 C2C 로 정보를 전송합니다. type=”Password”.라는 특별한 필드를 포함하여, 유저들이 채워 넣은 HTML안에 있는 텍스트 필드에서의 값을 가져올 수 있습니다.

잠재되어 있는 흥미로운 목표대상들을 분류하기 위해서, 공격자들은 특히 피해자들의 계좌의 잔액에 관심을 갖습니다. 잔액을 가져가기 위한 코드는 3초 안에 끝이 납니다.

  Android provides developers with an interface that allows them to bind JavaScript code into an Android app that uses a WebView. Android developers who build a web application using WebView can create interfaces between the JavaScript code and native Android code.
  The application must know the exact names of the fields within the HTML of the legitimate site to use this technique. In turn, the JavaScript code must know the exact names of the Android functions within the interface to interact with them.
  In the malware that Trusteer analyzed, the names of the Android JavaScript interface functions can be seen: “sendCerd,” “closeFrom,” and “sendBalance.” When the user enters their username and password, the malware extracts the values using the val() jQuery function and sends the information to the C2C. The script can get values from text fields in the HTML that the user filled in, including special fields with type=”Password”.

Figure 5 — The malware JavaScript code.

Figure 6 — The malware corresponding JavaScript interface from the Android side.

멀웨어가 피해자들의 신분정보를 몰래 빼 나간 후에, 피해자들은 의심을 가지지 않은 체 합법적인 웹페이지 안에 있는 다른 웹페이지를 통에 계속 머물게 됩니다.

After the malware exfiltrates the victim’s PII, the victim continues through the following web pages on the legitimate website without raising their suspicions.

웹뷰의 설정 / WebView Settings

자바스크립트 코드를 삽입하기 위해서, 멀웨어는 웹뷰 설정 중 “setJavaScriptEnabled” 과 “setDomStorageEnabled” 을 “true”로 구성합니다.

To inject the JavaScript code, the malware sets the WebView settings “setJavaScriptEnabled” and “setDomStorageEnabled” to “true”.

Figure 7 — The malware’s WebView settings. Note the use of a constant user-agent of a Samsung device (SM-A205U).

자바 스크립트 삽입 하기 / Injecting JavaScript

안드로이드 자바스크립트와 웹뷰를 셋팅한 후에, 멀웨어는 loadUrl() 기능으로 자바 스크립트 코드를 웹뷰 안에 삽입합니다. 트러스티어에 의해서 분석되 멀웨어 안에서 자바스크립트는 Base64로 암호화가 되어 있습니다. 삽입된 페이지의 소스를 살펴보면, 삽임된 코드는 사람이 읽을 수는 없으나 이것은 단디 Base64로 암호화 되어있기 때문에 이것은 쉽게 복호화 될 수 있습니다.

After setting up the Android JavaScript and the WebView, the malware can inject the JavaScript code into its own WebView with the loadUrl() function. In the malware analyzed by Trusteer, the JavaScript was Base64 encoded. Looking at the source of the injected page, the injection code is not human readable; however, since it is only Base64 encoded, it can be easily decoded.

Figure 8 — The malware’s Base64 encoded JavaScript injected code.

웹뷰 공격 vs. 오버레이 공격 / Web(View) Attack Versus Overlay Attack

IBM 보안 트러스티어에 의해명명된 웹뷰 인젝션 공격에서 멀웨어는 가짜 피싱 페이지 또는 가짜 활동을 하기 보다는 은행의 합법적인 URL을 가져옵니다. 오버레이 공격에서, 멀웨어는 실제 은행 앱에 보여지는 은행 로그인 화면을 모방하여 오버레이 가짜 화면을 피해자들에게 보여줍니다.

웹뷰 인젝션의 방법의 1가지 이점은 멀웨어가 은행이 그들의 UI를 변경할때 마다, 오버레이 화면의 디자인을 변경할 필요가 없다는 점 입니다. 왜냐하면 이것은 합법적인 은행 웹페이지를 바로 들어간 것 이기 때문 입니다.

또 다른 이점은 오버레이 공격은 최소한 "android.permission.SYSTEM_ALERT_WINDOW” 권한을 요구하는 반면, 웹뷰는 그 보다는 덜한 “android.permission.INTERNET” 이 매니페스트에 선언되는 정도의 적은 권한을 사실상 요구합니다.

이 권한은 정마라 일반적이어서 따라서 거의 의심을 하지 않습니다. 이는 웹인젝션 기술이 사용되는 첫번째 모바일 멀웨어는 아니지만 이것은 IBM 트러스티어 연구진이 발견하였던 첫 사례로, 모바일 금융 멀웨어에서 사용되었습니다.

IBM트러스티어 안드로이드에서 사용되는 금융 멀웨어세서 발견한 웹공격 기술에서 웹 인젝션만 있는 것은 아닙니다. 이 블로그에서 이야기 되는 다음 공격은 모바일 쿠키 공격으로, 웹인젝션과 같이 안드이드의 웹뷰 요소를 공격대상으로 삼고 있습니다.

  In this attack dubbed Web(View) Injection by IBM Security Trusteer, the malware loads a legitime URL of the bank rather than a fake activity or a fake phishing site. In an overlay attack, the malware shows the victim a fake overlay screen mimicking the bank’s login page on top of the real banking app.
  One advantage of the Web(View) Inject method is that the malware doesn’t need to change the design of the overlay screen every time the bank changes its UI since it is injecting straight into the legitimate banking site.
  Another advantage is that this attack requires fewer permissions than an overlay attack, which usually requires at least the “android.permission.SYSTEM_ALERT_WINDOW” permission. In fact, Web(View) attack requires only the “android.permission.INTERNET” permission to be declared in the manifest. This permission is extremely common and therefore much less suspicious.
  This is not the first time mobile malware has used the Web(View) inject technique, but this is the first time that IBM Trusteer researchers have identified it being used by mobile financial malware.
  Web(View) Injection is not the only web attack technique IBM Trusteer detected that financial malware used in Android.
  The next attack discussed in this blog is a Mobile Cookie Stealing attack that, much like the Web(View) Injection attack, targets the Android WebView component.

무엇이 쿠키 공격일까요? / What is a Cookie Stealing Attack?

쿠키는 웹싸이트가 브라우저 안에서, 유저들의 활동을 추적하고, 로그인 상태를 확인하기 위해서 저장하는 텍스트와 숫자들의 나열 입니다.

쿠기들은 세션을 구분하기 위해서 사용이 되어 집니다.

은행과 암화화폐 웹페이지들을 포함한 다양한 웹페이지들은 그들의 로그인 페이지에 세션을 구분하기 위해서 쿠키를 사용합니다. 만약 속이려는 공격자들이 유저들이 로그인 한 후 브라우저에서 쿠키를 훔친다면, 공격자들은 피해자들의 신분정보를 알지 않은채로 피해자들의 세션을 훔치기 위해서 쿠키를 사용할 지도 모릅니다.

이 공격은 금융 모바일 멀웨어인 SOVA가 다시 만든 MailBot, FluBot, SharkBot, Hydra, 와 BianLian 최신 버전에서 큰 인기를 얻었습니다.

  Cookies are strings of text and numbers that websites store in the browser to save the login state or track the user’s activity on the website.
  Cookies are used as session identifiers. Various websites including banks and cryptocurrency sites use cookies as session identifiers for their login pages. If a fraudster steals a cookie from the browser after the user logged in, the fraudster might be able to use the cookie to steal the victim’s session (as long as the cookie hasn’t expired) without even having to know the victim’s credentials.
  This attack has recently gained popularity among financial mobile malware, such as SOVA’s remake malware MailBot, FluBot, SharkBot, and Hydra, the newer version of BianLian.

누가 안드로이드에서 쿠키를 훔치는가? / Who Stole the Cookie From the Android Jar ?

안드로이드 샌드박스에 대해서 이야기 한 것 처럼, 안드로이드 앱은 브라우저 앱을 직접 조작할 수 없습니다. 결과적으로 피해자에 대한 정보 없이 쿠키를 훔칠 수 없습니다. 하지만 쿠키를 훔치는 것은 고유한 웹뷰를 통해서 가능해 집니다. BianLian은 금융 멀웨어의 하나로 RAT와 같은 오버레이 방식을 가졌습니다. IBM 트러스티어 연구자들은 히드라로 알려진 BianLian멀웨어를 분석해 왔으며, 여기서 BianLian이 쿠키공격의 실행이 밝혀졌습니다. 전반적인 공격의 흐름은 아래의 그림과 같습니다.

As stated in the Android Sandbox section, an Android application cannot manipulate the browser application directly and, as a result, can’t steal cookies from it without the victim’s knowledge. However, cookie stealing can be done from its own WebView.

BianLian is a piece of financial malware that has overlay capabilities as well as RAT capabilities. IBM Trusteer researchers have analyzed the BianLian malware, aka Hydra, and here BianLian’s implementation of the cookie stealing attack is unpacked. The overall attack flow is shown in the following figure:

Figure 9 — Cookie stealing attack flow

The malware creates an instance of CookieManager and then the “getCookie()” method is used with the legitimate URL loaded to get the cookie.

Figure 10 — BianLian’s cookie theft function.

BianLian steals cookies from e-mail, social networking and financial applications, using the real application’s URLs:

Figure 11 — BianLian’s cookie theft configuration list.

BianLian은 유저들이 목표로 삼고있는 앱들 중에 하나를 열어서 접근서비스를 실행할 때를 기다립니다.

웹뷰가 목표대상의 앱의 실제 로그인 URL을 불러와서 합법적인 앱 화면에 겹쳐 보이게 합니다. 이 방법은 피해자의 관점에서 보면, 모든것들은 예상할 만한 것 입니다. 그러나 피해자들이 이 시점부터 하는 통신은 멀웨어 화면에서 하는 것 이지 실제 앱에서 진행하는 것은 아닙니다.

멀웨어 웹뷰는 “setMixedContentMode” 프로퍼티 설정을 가지고 있어서, 어떠한 형태로 안전하지 않더라도 형태가 어떠한하든지 내용을 불러올 수 있습니다. 이것은 또한 “setCacheMode” 프러퍼티 셋팅으로 캐시를 가져오지 않는 설정을 합니다. 이것은 네트워크에서 바로 로딩되는 것을 의미합니다.

그런데 멀웨어는 유저들이 서비스에 로그인 하기를 기다립니다. 분명 피해자들은 “onPageFinished” 방법으로 불러진 URL을 확인하고 그들 계좌에 성공적으로 로그인을 하고 난 후 쿠키매니저를 활용하여 세션쿠키를 얻습니다.

일단 공격자들이 쿠키를 훔치게 되면, BianLian은 쿠키를 C2C로 발송합니다. 마침내 공격자들은 훔친 쿠키를 활용하여 피해자들의 세션을 훔칩니다.

  BianLian detects when the user opens one of the targeted apps using the accessibility service. It then overlays the legitimate application with its own WebView loaded with the real login URL of the targeted application. This way, from the victim’s perspective, everything seems to be as expected. However, any interaction the victim has from this point on is with the malware screen and not the actual application.

  The malware WebView has the “setMixedContentMode” property set to load content from any other origin, even if that origin is insecure. It also has the “setCacheMode” property set to load no cache, which means loading from the network.

  The malware then waits for the user to log in to the service. It makes sure the victim is successfully logged into their account by checking the loaded URL with the “onPageFinished” method and then grabs the session cookie using the Cookie manager.

  Once it steals the cookie, BianLian sends the cookie to its C2C (at the time of writing, the malware sends requests to the server unencrypted via HTTP). Finally, the fraudster uses the stolen cookie to hijack the victim’s session.

더 적은 권한과 더 적은 의심 Fewer Permissions, Fewer Suspicions

웹인젝션 공격와 유사하게, 쿠키를 훔치는 공격은 오직 “android.permission.INTERNET” permission. 권한만을 요구합니다. 만약 웹싸이트들이 HTTPS를 사용할 지라도, 멀웨어는 설명된 기술을 가지고 쿠키의 값을 가로챈다는 것을 주의해야 합니다.

Similar to the Web(View) injection attack, the cookie stealing attack requires only the “android.permission.INTERNET” permission.

Note that even if the website uses HTTPS, the malware can still intercept the cookie value with the described technique.



https://securityintelligence.com/posts/view-into-webview-attacks-android/