https://tooltip.tistory.com/entry/%EC%9C%88%EB%8F%84%EC%9A%B010-XPS-%EB%B7%B0%EC%96%B4-%EC%98%A4%ED%94%84%EB%9D%BC%EC%9D%B8%ED%8F%90%EC%87%84%EB%A7%9D-%EC%84%A4%EC%B9%98%EB%B0%A9%EB%B2%95

Microsoft Windows 10 Enterprise

Version 10.0.19042.630

XPS 뷰어를 막아두는 곳이 있어서 당황 중이다.

CMD / 명령 프롬프트 - 관리자 권한으로 실행

dism /Online /Add-Capability /CapabilityName:XPS.Viewer~~~~0.0.1.0 ?

XPS Viewer : 수동 제거 방법

dism /Online /Remove-Capability /CapabilityName:XPS.Viewer~~~~0.0.1.0

https://pmandocom.tistory.com/m/88

웹 분석과, 웹 해킹 공부를 위해, Burp Suite를 설치하였다.

Burp Suite에서 웹 request와 response를 분석하는 방법은 2가지이다.

첫째, 전용 브라우저 이용.

둘째, 프록시 이용.

필자는 두 가지 모두 사용하는 편이다. 

이 과정에서, 프록시를 설정할 때마다 매번 설정에 들어가서 하기는 참으로 귀찮다.

이를 단축키로 자동화할 수 있는 방법이 없을까를 찾아보던 중, powershell용으로 작성된 script를 발견하였다.

https://social.technet.microsoft.com/wiki/contents/articles/53831.enable-disable-proxy-settings-via-powershell.aspx

이 스크립트는 함수의 형태로, 앞으로 이 함수를 이용하여 쉽게 실행할 수 있을 것이다.

powershell에서 함수를 사용하는 방법은 여러가지가 있다.

1. 현재 powershell 세션에서만 호출할 수 있는 형태
2. 꾸준히 호출할 수 있는 형태

https://www.jonathanmedd.net/2015/01/how-to-make-use-of-functions-in-powershell.html

위 사이트에서 사용법을 확인할 수 있을 것이다.

추가적으로, 다음의 방법도 사용할 수 있다.

●해당 powershell의 세션에 함수 로드

https://morgantechspace.com/2016/07/how-to-call-function-in-ps1-file-from-powershell.html

 . C:ScriptsMyScript.ps1
 ##혹은
 Import-Module C:ScriptsMyScript.psm1

●로드과정없이 함수 자체를 스크립트(.ps1파일)에서 호출 (아래 명령 실행시, 함수가 실행된다)

https://stackoverflow.com/questions/1405750/calling-a-specific-powershell-function-from-the-command-line

powershell -command "& { . 스크립트주소.ps1; 함수이름 }"
## 예시 powershell -command "& { . c:\test\script1.ps1; My-Func }"

필자는 꾸준히 호출하여 사용할 수 있도록 할 것이다. (profile 설정)

Step 1# profile설정.

New-Item -Path $profile -ItemType File -Force

notepad $PROFILE

notepad $PROFILE을 엔터로 실행하면, 메모장이 뜰 것이다.

해당 메모장 안에 다음 내용을 붙여넣는다.

<#
 .Synopsis
 This function will set the proxy settings provided as input to the cmdlet.
 .Description
 This function will set the proxy server and (optional) Automatic configuration script.
 .Parameter Proxy Server
 This parameter is set as the proxy for the system.
 Data from. This parameter is Mandatory.
 .Example
 Setting proxy information.
 Set-NetProxy -proxy "proxy:7890"
 .Example
 Setting proxy information and (optional) Automatic Configuration Script.
 Set-NetProxy -proxy "proxy:7890" -acs "http://proxy Jump :7892"
#>


Function Set-NetProxy
    {
        [CmdletBinding()]
        Param(
           
            [Parameter(Mandatory=$True,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
            [String[]]$Proxy,

            [Parameter(Mandatory=$False,ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
            [AllowEmptyString()]
            [String[]]$acs
                   
        )

        Begin
        {

                $regKey="HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
           
        }
       
        Process
        {
           
            Set-ItemProperty -path $regKey ProxyEnable -value 1

            Set-ItemProperty -path $regKey ProxyServer -value $proxy
                               
            if($acs)
            {         
               
                     Set-ItemProperty -path $regKey AutoConfigURL -Value $acs       
            }

        }
       
        End
        {

            Write-Output "Proxy is now enabled"

            Write-Output "Proxy Server : $proxy"

            if ($acs)
            {
               
                Write-Output "Automatic Configuration Script : $acs"

            }
            else
            {
               
                Write-Output "Automatic Configuration Script : Not Defined"

            }
        }
    }


Function Disable-NetProxy
{
  Begin
    {

            $regKey="HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
       
    }
   
    Process
    {
       
        Set-ItemProperty -path $regKey ProxyEnable -value 0 -ErrorAction Stop

        Set-ItemProperty -path $regKey ProxyServer -value "" -ErrorAction Stop
                           
        Set-ItemProperty -path $regKey AutoConfigURL -Value "" -ErrorAction Stop       
      
    }
   
    End
    {

        Write-Output "Proxy is now Disabled"

             
    }

}

저장하고 메모장 창을 닫아준다.

Step2# 원할 때 powershell을 열고 실행해준다.

(추가적으로 방금 적용한 profile을 현재의 powershell 세션(현재 열려있는 powershell 창)에 적용하려면, 다음 명령을 실행해주자.https://stackoverflow.com/questions/11546069/refreshing-restarting-powershell-session-w-out-exiting)

. $PROFILE

간단한 사용법은 다음과 같다.

이외의 사용법에 대해서는 위 함수 소스코드의 맨 위 주석을 참고하자.

## Proxy 시작
Set-NetProxy 프록시(IP)주소:포트
## 예시 : Set-NetProxy 127.0.0.1:8080

## Proxy 종료
Disable-NetProxy

사용하는 예시에 대한 스크린샷이다.

●Proxy 시작(enable)

●Proxy 종료(disable)

A Definitive Guide on XMLRPC for WordPress (+ How to Disable It) (servebolt.com)

Wordpress xmlrpc.php -common vulnerabilites & how to exploit them | by +Bilal Rizwan | Medium

The xmlrpc.php file can be found in the WordPress core and is generally enabled by default, which leaves your WordPress site exposed to all kinds of malicious attacks. 

We are going to look at what the XMLRPC file is, what it does, and, more importantly, how to manage it while boosting your website’s security. 

• What is XMLRPC?
• The Security Issues Associated With The xmlrpc.php File
• How to Block XMLRPC Attacks
• How Accelerated Domains and Servebolt CDN Handles XMLRPC Issues
• Blocking XMLRPC on Cloudflare
• Alternative Method: Disabling XMLRPC On The Server Altogether
• Why Installing a Security Plugin Isn’t a Wise Idea
• Conclusion

What Is XMLRPC?

XML-RPC (eXtensible Markup Language – Remote Procedure Call) was created to offer cross-platform communication. This is a protocol that uses HTTP as a transport and XML as an encoder to generate procedure calls, thus allowing for the ability to run functions on a remote computer. 

HTTP requests can be sent by the client (i.e., browser or mobile app) to the server, and the server then sends an HTTP response. The HTTP request can be used to invoke functions, and these functions can then be used to perform specific actions. 

This is different from the REST API, as that uses URL parameters to identify resources. In contrast, RPC uses query parameters to offer function arguments. 

XMLRPC allows users to interact with their site remotely, such as through the WordPress mobile app or via plugins like JetPack or WooCommerce.

The Security Issues Associated With The xmlrpc.php File

XMLRPC can expose your site to a variety of attacks. Since it’s easy to trace, hackers can send arbitrary XML data, which then allows them to control the site in a number of ways. Here are some security issues that you should know about. 

Brute Force Attacks

In a brute force attack, the hackers essentially try to guess the correct password and user name using pure brute force – by attempting thousands of combinations.

If you have a weak admin password and aren’t using multi-factor authentication, there’s a chance that a hacker can brute force their way into your website’s backend. 

WPSCAN, a popular tool from Kali Linux, can be used to easily find and list all valid usernames for the website. Once that’s done, hackers can use brute force via the xmlrpc.php file by sending the following request: 

POST /xmlrpc.php HTTP/1.1
User-Agent: Fiddler
Host: www.example.com
Content-Length: 164

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

This way, hackers can send thousands of combinations until the site sends the correct password. A response indicating that an incorrect input, while also telling the hacker to try again, is shown below:

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 26 May 2019 13:30:17 GMT
Content-Type: text/xml; charset=UTF-8
Connection: keep-alive
X-Powered-By: PHP/7.1.21
Cache-Control: private, must-revalidate
Expires: Sun, 02 Jun 2019 13:30:17 GMT
Content-Length: 403

<?xml version="1.0" encoding="UTF-8"?>
<methodResponse>
<fault>
<value>
<struct>
<member>
<name>faultCode</name>
<value><int>403</int></value>
</member>
<member>
<name>faultString</name>
<value><string>Incorrect username or password.</string></value>
</member>
</struct>
</value>
</fault>
</methodResponse>

It returns the HTTP 200 code, indicating that the username and password are incorrect. Hackers don’t even have to worry about reCaptchas or limited login attempts if security is low. 

DDoS Attacks

Distributed Denial of Service, or DDoS attacks, can completely take a server offline by sending thousands of requests simultaneously. The pingback feature in WordPress is commonly used by hackers in combination with the xmlrpc.php file to run DDoS attacks. 

Usually, hackers find a page that they can target multiple times and then start attacking it. To start the attack, the hacker begins by checking for the xmlrpc.php file. They do this by sending this request:

POST /xmlrpc.php HTTP/1.1

Host: servebolt.com
Connection: keep-alive
Content-Length: 175

<?xml version="1.0" encoding="utf-8"?>
<methodCall>
<methodName>demo.sayHello</methodName>
<params>
<param>
<value>admin</value>
</param>
</params>
</methodCall>

Once the hackers have confirmation that the xmlrpc.php file is enabled, they then start attacking it with a network of exploited websites to send different pingback requests. 

In many cases, this can be automated using the following code:

POST /xmlrpc.php HTTP/1.1
Host: withinsecurity.com
Connection: keep-alive
Content-Length: 293

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param>
<value><string>http://173.244.58.36/</string></value>
</param>
<param>
<value><string>https://example.com/blog/how-to-make-a-salad</string></value>
</param>
</params>
</methodCall>

Cross-Site Port Attacks

Cross-site Port Attacks (XSPA) are quite common. Hackers generally initiate these attacks by injecting malicious code to receive information about IP addresses and TCP ports. 

Hackers use the pingback.ping technique to pingback a post on a website, which returns the IP address. Then, they use a sniffer to establish an endpoint to send a live blog post URL and a pingback using the following request:

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

How to Block XMLRPC Attacks

There are several methods you can use to block XMLRPC attacks – most of which you’ll come across are ineffective – here’s how we recommend addressing this: 

How Accelerated Domains and Servebolt CDN Handles XMLRPC Issues

Servebolt has two products that perform XMLRPC security out of the box. They both take the approach that some traffic to this place can be valid, but too much or too often is a sign of a hack attempt. 

For example, our Accelerated Domains implementation listens to requests to xmlrpc.php, if there are more than 15 requests in a minute, it will ban that IP address for a whole day.  This effectively stops the hack attempt while allowing users of the website via WordPress Mobile or users of Jetpack/WooCommerce to continue to work. 

The Servebolt CDN deals with it slightly differently, it also has a threshold of 15 requests per minute from the same IP address to the xmlrpc.php and then bans the IP address for 1 hour. 

If you’ve already made the (wise 😄) decision to host your WordPress websites with us – when using Servebolt’s CDN or Accelerated Domains – one of these security options is automatically implemented for you.

Blocking XMLRPC on Cloudflare

It is possible to block traffic to xmlrpc.php directly on Cloudflare, stopping it from ever reaching your server. 

This is only a really valid solution if you are also blocking traffic that is not originating from Cloudflare. If you have not already set this up, then it will still be possible for hackers to attempt to access and exploit it on your origin server directly. And, of course, this is easily configurable in just a single click via the Servebolt admin interface.

Where this will help is that, like with Accelerated Domains or CDN from Servebolt, the xmlrpc.php traffic from bad actors is stopped at the edge long before it reaches the server. 

To block all traffic, login to Cloudflare admin, select the domain, click Security, click WAF, create a new firewall rule, and enter the details as shown in the photo below: 

• Rule Name = whatever you want to call it
• Field = URI Path
• Operator = equals
• Value = /xmlrpc.php

Or you can “edit the expression” and paste it into the following code:

(http.request.uri.path eq "/xmlrpc.php")

Choose the action of “Block” and save & deploy it. 

Remember: because you have set this up, you will have to remember it exists. There might be a time in the future when you are wondering why xmlrpc.php is not working, and you cannot see it in your server configuration.

Note: If you use this method, you must ensure that your server is configured only to allow traffic that is coming through Cloudflare. As otherwise, it would be possible to bypass this.

In Servebolt, this can be enabled in the control panel: 

Alternative Method: Disabling XMLRPC On The Server Altogether

On Apache Servers

A better alternative is to disable the XMLRPC file altogether. This is possible on Apache by just adding a snippet of code in your .htaccess file just before the firm rules added by WordPress:

<Files xmlrpc.php>
order allow,deny
deny from all
</Files>

You can also whitelist IP addresses through which you wish to access XMLRPC. For that, use this command:

<Files xmlrpc.php>
<RequireAny>
Require ip 1.1.1.2
Require ip 2001:db8::/32
</RequireAny>
</Files>

This is a wise option as it eliminates the misuse of XMLRPC, though there’s a downside: you’ll be disabling remote access to your site. As a result, the mobile app – or Jetpack, for that matter – won’t work properly. 

On Nginx Servers

Disabling Nginx is slightly harder as you need to have server configuration access rather than the more simple .htaccess of Apache. To disable, edit the virtual host config file, usually located in /etc/nginx/sites-available and add the following directive to the server block:

server {
  # // your standard server root and configuration
  location = /xmlrpc.php {
    deny all;
  }
  # // rest of the server configuration such as PHP-FPM
}

Servebolt uses the .htaccess method to deploy this solution to xmlrpc.php. If you are with a managed host like Servebolt and are using Nginx you will most likely need them to implement this for you.

Why Installing a Security Plugin Isn’t a Wise Idea

Most people might be thinking of installing a WordPress security plugin on their site. However, that’s not actually a good idea for several reasons:

• The request to xmlrpc.php will still be happening, with the security plugin sat in between it and WordPress, using up system resources that will fail quicker in the event of an attack.
• They are primarily effective at the application level, not at the server level.
• They add unnecessary code to your site, affecting its performance.
• They require constant load management. 
• Security plugins mess with crucial parts of WordPress security, including login – with just a single mistake in code that runs as a part of logins, your site is at greater risk. 

Conclusion

Cyberattacks are getting more sophisticated day by day. As a webmaster & business owner, it’s essential to be aware of and understand potential threats and the steps you can take to protect yourself against them. The majority of which can be mitigated with the help of a proactive approach – a combination of monitoring and keeping software up-to-date as well as taking advantage of solutions like Accelerated Domains. When enabled, Accelerated Domains or Servebolt CDN intelligently filters traffic and automatically takes action to protect your website from harmful attacks, ultimately keeping your origin server secure and your site safe.

Any specific questions about XMLRPC or security? Get in touch with us – our expert, friendly, and thorough support team is here to help.

https://ji-se.tistory.com/entry/03-XCP-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EB%A0%88%EC%9D%B4%EC%96%B4

XCP 데이터는 XCP 마스터 (측정/캘리브레이션 툴/시스템) 와 XCP 슬레이브 (ECU, Runtime 환경 등) 사이에 메시지 전송 방식으로 교환된다.

전송되는 XCP Message Frame 에 대해 설명하기에 앞서 XCP 통신 모델에 대해 정리하자면, XCP 패킷을 통한 통신은 명령어 (CTO) 를 위한 영역 하나와 동기화 데이터 (DTO) 발송을 위한 영역 하나로 구분된다.

※ CTO (Command Transfer Object) : 명령어 전송에 사용되는 패킷

※ DTO (Data Transfer Object) : 측정/신호 인가 데이터를 동기적으로 교환하는데 사용되는 패킷

CTO / DTO 기반의 XCP 통신 모델

위의 통신 모델에서 사용된 약어는 다음과 같다.

XCP Message Frame 전체는 Trasnport Layer 의 Frame 에 포함된다. (e.g. XCP on Ethernet 의 경우, UDP or TCP Packet 내에 포함)

XCP Message Frame 및 각 필드의 의미는 아래와 같다.

XCP Message Frame

Reference

Andreas Patzer, Rainer Zaiser, XCP-ECU 개발을 위한 표준 프로토콜 - 프로토콜 기초와 응용분야 (Vector, 2014)

https://www.autoelectronics.co.kr/article/articleView.asp?idx=4214 

목차

[연재 1]
1. 개요
2. 주요 내용
3. 방법론
4. 자동차 관련 취약점 - 건초 더미에서 바늘 찾기4.1 심각도 vs. 관련성
4.2 악명 높은 공급망 취약점
[연재 2]
5. 노후화된 소프트웨어 관련 위험
6. 자동차 소프트웨어에 영향을 미치는 메모리 손상
7. 결론

1. 개요

커넥티드 카(Connected car)의 등장이 현실이 되었다. 커넥티드 카는 기존의 운송 수단 및 모빌리티 서비스를 혁신할 자율주행 기술과 관련된 중요한 이정표를 제공한다. 그러나 이와 같은 발전에는 도전이 따른다.

증가하고 있는 자동차 산업에 대한 사이버 보안 위험에 대한 효과적인 사이버 보안 조치가 없을 경우 공격 표면이 넓은 최신 사양의 자동차는 물리적 손상을 일으킬 수 있는 각종 악의적인 활동에 취약할 수밖에 없고, 이에 따라 운전자와 보행자 모두의 안전에 영향을 미칠 수 있다.

각종 보안 위협에 대한 업계 전반의 인식은 UNECE WP.29 및 ISO/SAE 21434와 같은 국제표준에서도 분명히 드러난다. 두 국제표준 모두 OEM이 공급업체(Suppliers), 서비스 제공업체, 기타 조직과 관련된 다양한 위험을 관리하여 자동차 분야의 사이버 보안을 책임져야 한다고 규정하고 있으며, 다음과 같은 내용을 중심으로 자동차 사이버 보안에 대한 근본적인 변화를 주도한다.
 

그러나 자동차 분야의 사이버 위험을 관리하는 것은 간단하지 않다. 제품 보안팀은 제한된 인력으로 일상적으로 발생하는 다양한 보안 문제를 관리하고 자동차 분야 제조업체의 디지털 혁신까지 지원해야 하기 때문이다. 

이스라엘 자동차 사이버 보안 위험 평가 전문 기업인 사이벨리움(Cybellum)의 ‘2021 자동차 소프트웨어 보안 현황 보고서’는 2020년부터 2021년에 걸쳐 발견된 100개 이상의 자동차 소프트웨어 컴포넌트에 대한 취약점 분석을 기반으로 자동차 소프트웨어와 관련된 주요 보안 위험을 조명한다.


2. 주요 내용

1) “일반적인” 취약점과 다른 자동차 소프트웨어 취약점

2) 공급망 취약점의 영향을 받는 자동차 소프트웨어

3) 노후화된 소프트웨어로 인한 운영 상의 위험이 발생할 가능성

4) 메모리 손상(Memory Corruption)으로 인한 자동차 소프트웨어 보안 위협

3. 방법론

사이벨리움은 ‘2021 자동차 소프트웨어 보안 현황 보고서’를 통해 자동차 소프트웨어 보안의 현재 상태에 대한 심층적인 분석을 제공한다. 보고서의 핵심 내용은 2020년에서 2021년 사이에 발견된 100개 이상의 자동차 소프트웨어 컴포넌트에 대한 분석이며, 이와 관련하여 보고서에 포함된 일부 정보는 오픈소스 소프트웨어를 기반으로 작성되었다.


4. 자동차 관련 취약점

취약점으로 인한 사이버 공격 피해를 최소화하기 위해서는 취약점 완화의 우선 순위를 지정하는 것이 중요하지만, 자동차 대상의 취약점이 크게 증가하면서 심각도에 따른 취약점 우선 순위 지정 프로세스가 지연되고 있다. 특히 일반적으로 공개되는 취약점이 모두 자동차 소프트웨어에 영향을 미치는 것이 아니기에 자동차와 관련된 취약점을 명확하게 식별하는 것이 쉽지 않고, 이에 따라 적절한 시기에 취약점을 완화하고 해결하지 못하는 사례가 발생하고 있다. 이는 궁극적으로 자동차의 컴포넌트 및 자동차 산업 분야에 속한 조직의 사이버 복원력에 악영향을 미칠 수 있다.

표 1 – 공개된 CVE (Common Vulnerabilities and Exposure) 취약점
(출처: NIST NVD, https://nvd.nist.gov)


소프트웨어의 유효성에 대한 적절한 테스트가 이루어지지 않을 경우 공격자는 특정 형식을 악용하여 입력을 조작할 수 있으며, 이에 따라 응용 프로그램이 의도하지 않은 입력 값을 수신하게 된다. 이 경우 제어 흐름, 리소스에 대한 임의 제어 또는 임의 코드 실행이 이루어질 수 있기 때문에 소프트웨어에 악영향을 미칠 수 있는 취약점을 적절하게 식별할 필요가 있다.

이와 관련하여 아래 표 2의 구글(Google)에서 가장 많이 검색된 10개의 CVE 취약점과 사이벨리움이 분석한 자동차 소프트웨어 관련 CVE 취약점 비교 자료를 통해 비교해 볼 때, 일반적인 취약점 목록과 자동차 소프트웨어에 영향을 미치는 취약점 목록이 큰 차이점을 보인다는 것을 알 수 있다. 구글에서 가장 많이 검색된 CVE 취약점은 대부분 엔터프라이즈 및 IT 제품에 영향을 미치는 취약점에 해당하기 때문에 자동차와 관련된 임베디드 시스템과는 차이가 있다. 
 

표 2 – 일반 CVE 및 자동차 관련 CVE 비교


4.1 심각도 vs. 관련성

표 2에서 CVSS 점수로 표시된 취약점의 심각도를 통해 각 취약점이 자동차 보안에 미치는 영향을 확인할 수 있지만, 이러한 취약점 심각도만을 기준으로 자동차에 미치는 전체적인 보안 위험과 관련된 내용을 확인하는 것에는 한계가 있다. 그러나 일반적인 자동차 OEM 및 제조업체는 보안을 위한 인력 및 시간에 제한이 있기 때문에 자동차 보안에 영향을 미칠 수 있는 모든 취약점을 분석할 수 없고 이에 따라 심각도가 높은 취약점에 대한 식별 및 완화에 집중할 수밖에 없다.

심각도가 ‘중간 단계’로 평가되는 취약점은 전체 취약점에서 약 40%에 이르는 비중을 차지하지만, 심각도가 중간 단계로 평가되기 때문에 취약점 완화를 위한 패치가 적용되지 않은 상태로 자동차 컴포넌트 내에 존재하는 경우가 대부분이다. 그러나 중간 심각도라는 것이 ‘중간 위험’을 의미하는 것이 아니기 때문에, 일부 취약점에는 특정 익스플로잇(Exploit)이 존재하지 않는 일부 심각도가 높은 취약점보다 더욱 심각한 피해를 유발할 수 있다.

CVSS 점수는 취약점 평가 시 취약점 사이의 관련성 및 잠재적 영향을 고려하지 않음

특히 자동차 소프트웨어에 대한 취약점은 전체 공격 체인의 관점에서 컴포넌트 사이의 측면 이동이 가능하도록 자동차의 내부에 진입하는 역할을 한다. 대부분의 보안팀이 심각도가 높은 취약점의 식별 및 완화에 집중하고 있어 중간 심각도를 가진 취약점을 악용하는 공격의 성공률이 높기 때문에 공격자는 중간 심각도를 가진 CVE 공격을 선호한다.

앞서 언급한 것처럼 자동차 소프트웨어에는 다양한 취약점이 내재되어 있다. 자동차 소프트웨어와 관련된 컴포넌트, 소프트웨어 사이의 상관 관계를 분석할 수 있어야 자동차의 컴포넌트에 실질적인 영향을 미칠 수 있는 CVE 취약점을 식별할 수 있으며, 이를 통해 심각도 점수와 관계없이 자동차 보안에 악영향을 미칠 수 있는 CVE까지도 제거할 수 있다. 

그러나 사이벨리움의 연구 결과에 따르면, 평균적으로 자동차의 컴포넌트에서 탐지된 CVE 취약점의 80% 이상에 대한 관련성 분석이 이루어지지 않아 심각한 영향을 미칠 수 있는 취약점인데도 완화되거나 제거되지 않은 것으로 나타났다.

80% 이상의 CVE 취약점이 제거되지 않음

이를 통해 알 수 있듯이 소프트웨어 기능 사이의 상호 관계에 대한 인식(Context Awareness)은 취약점 관리 프로그램의 투자 수익(Return-On-Investment, ROI)을 최적화하는 동시에 전반적인 제품의 보안성을 향상시킨다. 


4.2 악명 높은 공급망 취약점

표 3의 취약점 목록에서는 일부 누락된 사항이 있다. 언론에서 수차례 헤드라인을 장식한 악명 높은 취약점은 자동차 소프트웨어 취약점을 나열한 목록의 상위 10위 안에 포함되지 않았기 때문이다.

자동차 소프트웨어를 위협하는 소위 ‘악명 높은 공급망 취약점’ 중 상위 3개에 해당하는 BlueBorne, DirtyCow, Drown 취약점은 이미 4~5년 전에 발견된 취약점이지만 여전히 자동차 소프트웨어에 영향을 미치고 있다. 체계적인 사이버 보안 관행이 뒷받침되었다면 이러한 취약점은 발견되고 얼마 지나지 않아 완화할 수 있는 해결책이 제시되었어야 한다.

 

 순위취약점 명칭발견된 년도

표 3 – 자동차 취약점을 위협하는 악명 높은 취약점 순위


Ripple20, Amnesia:33, Urgent/11와 같은 취약점은 여러 공급업체에서 널리 사용되는 통신 스택(Stack)에 내재되어 있는 취약점으로 최근 들어 발견된 공급망 취약점이다.
 

KEY TAKEAWAYS

• 공개된 CVE 취약점 중 대부분은 자동차 소프트웨어에 영향을 미치지 않지만 너무 많은 소프트웨어와 취약점이 존재하기 때문에 자동차 또는 컴포넌트에 실질적인 영향을 미치는 취약점을 식별하는 것은 건초 더미에서 바늘을 찾는 것처럼 까다롭다.
• 기존의 보안 관행은 수동 감지 및 대응을 토대로 수행되기 때문에 깊이 있는 통찰력을 제공할 수 없다. 신속한 문제해결을 위해서는 자동화된 프로세스가 필요하다.
• 취약점 관리 프로그램은 제품의 컴포넌트와 소프트웨어 사이의 상관관계에 대한 인식 및 분석을 기반으로 자동차 보안에 영향을 미칠 가능성이 높은 위험을 식별할 수 있어야 한다. 실제로 대부분의 보안문제는 제품이 생산되기 전 단계인 개발 과정에서 식별 및 해결될 수 있다.
• 공급망 위험은 자동차 소프트웨어에 실질적인 영향을 미친다. 몇 년 전 발견된 취약점은 견고한 보안 관행을 통해 완화되었어야 하고 완화될 수 있어야 하는 것이 정상이다.

출처: AEM (https://www.autoelectronics.co.kr)

https://throwexception.tistory.com/89

ARM 프로세서 동작 모드

- USER 모드 : 일반 사용자 프로그램 모드

- SYSTEM 모드 : CPSR을 완전히 읽기 쓰기 가능

- Supervisor 모드 : 운영체제를 위한 예외, 커널이나 디바이스 드라이버 처리

- FIQ 모드 : 긴급한 인터럽트 발생시 진입. 빠른 인터럽트 처리를 위한 모드

- IRQ 모드 : 일반 인터럽트 발생시 진입.

- Abort 모드 : 데이터 또는 명령어 거부시 진입

- Undefined 모드 : 패치된 명령어가 정의되지 않을시 진입

* CPSR : Current Program Status Register

(1) ARM 프로세서 동작모드

1) 프로그래머 모델

2) 프로세서 동작모드

3) 특권 모드

4) 예외 모드

5) 동작 모드 변경

1) 프로그래머 모델

프로그래머 모델이란?

- 컴퓨터 시스템 구조와 동작을 표현한 추상적 개념모델

- 프로그래머가 코드 작성위해 알아야한 최소한 프로세서에 대한 정보

- 프로그램 최적화를 위한 중요 정보

프로그래머 모델 구성

- 프로세서 동작모드 : 운영체제를 하드웨어적으로 지원하는 모드

- 레지스터 구성방법 : CPU가 사용가능한 효율적인 저장장소

- 메모리접근방법 : 메모리서 데이터 읽거나 쓸때 적용

- 명령어 셋 :  프로세서가 실행할수있는 명령어 셋

- 예외처리방법 : 시스템의 실사간 처리에 큰 영향을 줌. 실시간 처리 성능 예측과 성능향상에 중요

2) 프로세서 동작모드

ARM 프로세서 동작 모드

- 프로세서가 프로그램 실행시 권한 설정

- 7개 동작 모드 : 6개 특권 privileged mode + 1개 사용자 모드 user mode

   특권 모드 : 예외 처리, 시스템 자원에 접근 - system 모드, supervisor 모드, fiq 모드, irq 모드, abort 모드 등

   사용자 모드 : 사용자 프로그램 실행 상태, 시스템 자원 접근 제한. 필요시 운영체제에 요청. 동작모드 변경불가

3) 사용자 모드

사용자 모드

- 시스템 자원 접근 제한하여 시스템 자원 보호

- 다른 동작 모드 진입 불가

- 변경 시 소프트웨어 인터럽트로 특권모드 진입후 가능

- 사용자 모드서 레지스터 사용 : R0 ~R12 범용레지스터 R13 스택 포인터 R14 링크레지스터 R15 프로그램카운터

4) 특권 모드

- 예외 처리하거나 시스템 자원에 접근가능모드

- 시스템 모드 : 운영체제를 위한 모드 운영체제 커널 작업 실행. 시스템 자원 접근 가능. 예외 발생 없이 진입.

- 슈퍼바이저 모드 : 운영체제를 위한 보호모드로 시스템 리셋이 진입시 초기 동작모드. 전원 공급시 가장 먼저 진입

- IRQ 모드 : 일반 인터럽트 모드시 진입

- FIQ 모드 : 고속 인터럽트 발생시 진입. 레지스터 뱅킹 세트 확장. R8~R12까지 5개레지스터 추가하여 8개 레지스터 추가사용

- Abort 모드 : Abort 예외발생시 진입. 명령어나 데이터 메모리 접근 오류시 발생.

   명령어 접근 오류 : 명령어 pre-fetch 과정서 발생 오류

   데이터 접근 오류 : 데이터 alignment 오류, 가상 어드레스 변환오류, 메모리 도메인/ 접근권한 위반 오류 등

- Undefined 모드 : Undefined 예외 발생시 진입. 정의 되지 않은 명령어가 디코딩 시

5) 예외 모드

- 특권 모드 중 예외와 관련있는 동작 모드

- 시스템 모드를 제외한 5가지 -> 슈퍼바이저, IRQ, FIQ, Abort, Undefined

- 하드웨어 또는 소프트웨어 예외발생시 진입

- 동작 모드 전확 속도 향상을위해 레지스터 셋 뱅킹

- 시스템 자원에 접근

6) ARM 프로세서 동작 모드 설정

- ARM 프로세서 동작 모드 설정은 상태레지스터 CPSR의 동작 모드 필드 M[4:0] 사용

- 사용자 모드 : 10000

- 시스템 모드 : 11111

- 슈퍼바이저 모드 : 10011

- FIQ 모드 : 10001

- 동작 모드 값 변경은 특권 모드에서만 변경가능

7) 동작 모드변경

프로세서 동작 모드 변경

- 동작모드 설정 : 상테레지스터의 동작모드 필드 값 변경하여 변경 -> 특권모드서 가능

- 예외 발생하여 특권모드 진입 -> 특권모드에서 동작모드 필드 변경하여 가능

(2) 레지스터 구성

1) 레지스터 구성

2) 프로그램 상태 레지스터

1) 레지스터 구성

ARM 프로세서 구성

- 레지스터 : 모드 37개 32비트 레지스터로 31개 범용, 6개의 상태 레지스터. 프로세서 모드에 따라 사용가능한레지스터가 바뀜

특수용도 레지스터

- R13 : 스택 포인터로 각 동작 모드에 사용되는 스택 위치 정보를 저장. R13을 이용하여 스택 관리

- R14 : BL명령어로 실행. 링크 레지스터 PC 내용 복사해서 복귀 위치 저장. 

- R15 : 프로그램 카운터 

- CPSR : 현재 상태 레지스터 . 상태표시 플래그, 동작모드 설정비트, 제어비트 등 포함. SPSR(이전 CPSR 값저장)

Thumb state 레지스터 구성

- 레지스터 사용이 크게 재한

- R8 ~ R12 까지 범용 레지스터는 사용 불가

- ARM state처럼 범용 레지스터 뱅킹 이점을 갖지 못함

2) 프로그램 상태 레지스터

프로그램 상태 레지스터

- 1개의 CPSR

- 5개의 SPSR : CPSR의 뱅킹 레지스터. 예외 처리 함수에서 사용. 모드 변경시 CPSR 내용을 SPSR로 복사

- condition code flag, control bits

컨디션 코드 플래그 필드

- CPU 연산 결과를 반영하는 플래그 필드

- nzcv 4개의 플레그 사용

- N : 연산 결과가 음수

- Z : 연산 결과가 음수

- C : 캐리 발생, 자리빌림, 최상위 비트로 쉬프트되어 나온값

- V : 연산결과가 오버플로시 표시

컨트롤 비트 필트

- 인터럽트 허용 여부 결정 -> T/I비트

- 프로세서 동작모드설정 -> 모드설정비트

- 프로세서 상태 표시 -> T 비트

- 예외 발생시 변경

- 특권 모드에서 소프트웨어적으로 변경 가능

* T 비트 :  프로세서의 state 표시. 0이면 ARM state, 1이면 thumb state

* I 비트 : 인터럽트 disable 비트. 1설정시 인터럽트 불허

동작 모드 필드

- 동작 모드 필드 값에 따라 프로세서의 동작 모드가 결정됨

https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=goodkus&logNo=220214389063 

이번 장에서는 exception vector table을 공부합니다.

exception vector table은 여러가지 인터럽트와 예외를 처리할수 있는 주소를 모아놓은 테이블입니다.

먼저 예외와 동작모드에 관해서 보겠습니다.

arm에서의 예외는 총 7가지가 있습니다.

Data Abort : 메모리의 데이터를 읽거나 데이터를 쓰려다가 실패하는 경우 발생.

FIQ, IRQ : 외부 인터럽트가 코어에 전달될 때 발생.

Prefetch Abort : 명령어를 해석하다가 실패하는 경우 발생. 메모리에 존재하는 명령어를 읽어오다가 오류가 생기면 발생.

SWI(Software Interrupt) : 프로그램 내부에서 발생시키는 인터럽트. 소프트웨어 인터럽트라고 함. 시스템 콜의 핵심.

Reset : ARM 코어가 리셋되었을 경우 발생

Undefined Instruction : 읽어온 명령어가 ARM 코어와 코프로세서에 정의디지 않은 명령어일 때 발생.

​OS나 임베디드 OS를 만들 경우엔 저 예외들은 필수로 들어간다고 생각합니다.

(현재 arm 아키텍쳐를 제일 많이 사용하니 보편적으로 사용하는 최소한의 예외라고 생각합시다.)

그리고 ARM에는 7가지 exception과 연결된 일곱가지의 프로세서 동작모드가 있습니다.

Abort(ABT)

Fast Interrupt Request(FIQ)

Interrupt Request(IRQ)

Supervisor(SVC)

System(SYS)

Undefined(UND)

USER(USR)

ABT, FIQ, IRQ, SVC, UND 모드는 exception이 발생할 때 자동으로 변경되는 동작모드,

SYS와 USR는 프로세서의 일반적인 동작 모드입니다.

예외가 발생할 경우 해당하는 동작모드로 변경을 하려면 cpsr(Current Program Status Register)의 0~4번 비트를 수정해 주어야 합니다. 전에 3장에서 보았던 LED를 끄고 켤 때 관련된 레지스터의 비트를 수정하는 것과 같습니다.

​

​ <!--[endif]--> 

​

​cpsr의 0~4번 비트에 위의 표에서 나오는 모드 비트값을 넣으면 해당모드로 작동합니다.

근데 자세히보면 모드 비트의 자리수는 0~4번까지 5개의 비트를 사용합니다. 실제로 사용하는 모드는 총 7개뿐인데 말이죠.

​방금 보았던 Prefetch Abort예외와 Data Abort예외가 Abort 동작모드에서 처리가 되도록 설정되었지만,

​동작모드를 새로 하나 만들고 Prefetch Abort와 Data Abort를 각각 처리를 할수도 있다는 것을 유추해볼수 있습니다.

(2^5승이니 32개. 총 32개까지 모드를 만들 수 있겠죠.)

책에서는 리눅스에서의 동작모드에 대해 엄청 잘 설명해놨습니다.

“리눅스에서는 일반적으로 사용자 프로그램은 전부 다 USER모드에서 작동한다. 그러다가 프로그램 안에서 시스템 콜을 호출하면 프로그램은 SWI exception을 발생시키고, ARM 코어가 프로세서의 동작 모드를 SVC 모드로 변경시켜 Software Interrupt를 처리한 후에 다시 USER모드로 복귀한다. 마찬가지로 키보드 입력같은 경우는 대부분의 운영체제에서 IRQ로 처리한다. 우리가 키보드를 누르면 키보드 케이블을 통해 메인보드에 신호가 전달되고, 메인보드에 있는 여러 회로를 거쳐 ARM코어에 IRQ exception이 발생한다. 그러면 ARM 코어는 프로세서 동작 모드를 IRQ 모드로 변경하고 IRQ 관련 처리를 한 다음 USER모드로 복귀한다.”

근데 리눅스를 잘 사용하지 않아 조금 거부감이 있는 사람들을 위해 윈도우 측면에서 설명해 보겠습니다.

(왠만하면 위에껄로 이해하세요. 제가 설명하는게 정확한지 모릅니다.)

“윈도우에서는 일반적으로 사용자 프로그램은 각각 생성된 윈도우 계정에서 작동한다.[USER모드에서 작동] 그렇게 프로그램에서 작업을 하던 중, 작업하던 프로그램이 멈춰버렸다. 응답이 없는 프로그램을 처리하기 위해서 우측 상단의 X표를 누른다.[SWI exception을 발생시킨다.] 그리고 예외를 처리하기 위해서 프로세서의 모드를 프로그램을 종료시킬수 있는 모드로 변경한다.[SVC 모드로 변경] 마지막으로 응답없는 프로그램을 종료 시키고[Software Interrupt 처리] 다시 프로그램이 켜지기 전의 상태로 돌아간다.[USER모드 복귀]

이제 예외를 처리하는 방법을 봅시다.

exception을 ARM에서 처리하는 순서.

1. exception이 발생함.

2. exception 모드의 spsr에 cpsr을 저장함.

3. exception 모드의 lr에 pc값을 저장함.

4. cpsr의 모드 비트를 변경하여, 해당 exception에 대응하는 프로세서 동작 모드로 진입함.

5. pc에 exception 핸들러의 주소를 저장하여 해당 exception에서 해야 할 일을 처리함.

spsr(Saved Program Status Register) : 각 동작모드에 존재하며, exception이 발생하여 cpsr을 변경해야 할 때 이전 모드의 cpsr을 spsr에 백업한다.

링크레지스터(lr) : exception의 처리후 복귀하기 위한 pc의 주소를 저장.

4번째에 보면 모드비트를 변경하고 나서, 대응하는 프로세서 동작 모드로 진입한다고 되어있습니다.

​각 동작모드가 있는 주소를 모아 놓은 것이 exception vector table입니다.

감이 안잡힌다면 포인터 개념으로 생각하면 편합니다.

https://rninche01.tistory.com/entry/Linux-Memory-Protection

checksec스크립트나 peda-gdb, pwndbg를 이용하면 mitigation확인할 수 있음

1. ASLR(Address Space Layout Randomization)

메모리 상의 공격을 어렵게 하기 위해 스택이나 힙, 라이브러리 등의 주소를 랜덤으로 프로세스 주소 공간에 배치함으로써 실행할 때마다 데이터의 주소가 바뀌게 하는 기법

현재 실행되고 있는 프로세스 주소 매핑 확인

cat /proc/self/maps 

→ 주소가 랜덤하게 바뀌는 것 확인

ASLR 활성화 및 비활성화

echo [0, 1, 2] > /proc/sys/kernel/randomize_va_space

[0] : ASLR 비활성화

[1] : 랜덤 Stack, Library 활성화

[2] : 랜덤 Stack, Library, Heap 활성화

2. NX(Never eXecute bit), DEP(Data Execution Prevention)

데이터 영역에서 코드가 실행되는 것을 방지하는 기법으로 스택이나 힙에서 실행 권한을 없애 쉘 코드 실행을 막아주는 기법이다. 윈도우에서는 DEP라고 부르고 리눅스에서는 NX bit라고 불러서 결국 둘 다 동일한 말

NX 비활성화 옵션

gcc -z execstack 

3. Stack Canary

함수 진입 시 스택에 SFP와 return address값을 저장할 때, 이 값을 공격자로부터 덮어씌워지는 것을 보호하기 위해 스택 상의 변수들의 공간과 SFP사이에 특정한 값을 추가하는데 이 값을 Canary라고 부른다. 함수가 종료할 시점에 Canary값의 변조 유무로 bof를 탐지할 수 있으며 변조 시 프로그램이 종료된다. 보통 SFP앞에 카나리 있음.

Canary 종류

• Terminator Canary : NULL(0x00), CR(0x0d), LF(0x0a), EOF(0xff)와 같은 Terminator 문자를 포함시키는 Canary로 종료 문자들 때문에 Canary값을 알고 있어도 똑같이 작성하여 공격이 불가능
• Random Canary : Canary값이 랜덤으로 계속해서 생성하는 방법
• Radom XOR Canary : Canary값을 모든 제어 데이터 또는 일부를 사용해 XOR-scramble하여 생성

canary 활성화 및 비활성화 옵션

[비활성화]
gcc -fno-stack-protector

[활성화]
gcc -fstack-protector-all

4. RELRO(Relocation Read-Only)

GOT Overwrite와 같은 공격에 대비해 ELF 바이너리 또는 프로세스의 데이터 섹션을 보호하는 기법이다. 바이너리 컴파일 시 Full-RELRO 옵션을 주면 .ctors, .dtors, .jcr, .dynamic, .got섹션이 Read-Only가 됨 → GOT Overwrite 불가능

Lazy Binding(Lazy Linking, on-demand symbol resolution)

모든 함수의 주소를 한 번에 로딩하지 않고 함수를 처음 호출한 시점에 공유 라이브러리에서 해당 함수의 주소를 알아오는 것을 Lazy Binding이라고 한다.

Now Binding

프로그램이 실행될 때 해당 프로그램에서 사용하는 모든 함수들의 주소를 읽어와 got영역에 저장

추가 설명)

Dynamic Linking 방식으로 컴파일된 바이너리에서 라이브러리 함수를 호출할 때 실제 함수의 주소를 모르기 때문에 동적으로 알아오기 위해 plt, got를 이용한다. 처음 함수를 호출할 때는 plt영역의 got를 참조하고 뭐 여러가지 과정을 거치고 dl_runtime_resolve()로 가서 dl_fixup()에서 드디어 실제 함수의 주소를 got에 넣어준다. 이후에 다시 함수를 호출할 때는 위와 같은 복잡한 과정을 거치지 않고 걍 got에 있는 함수를 호출한다.

[No-RELRO]

[Partial-RELRO]

[Full-RELRO]

추가 설명)

Full RELRO를 사용하면 GOT가 Read-Only인 상태여서 Partial RELRO보다 보안상 더 안전할 것 같은데 Full RELRO보다 Partial RELRO가 더 널리 사용되는 이유는 Full RELRO의 경우 프로세스가 시작될 때 링커에 의해 모든 메모리에 대해 재배치 작업이 일어나 실행이 느려지기 때문이다.

5. PIE(Position Independent Executable)

PIE는 위치 독립 코드로 이루어진 실행 가능한 바이너리이며 바이너리 주소가 상대적인 주소로 랜덤하게 매핑시키는 기법이다. 모든 심볼을 상대주소로 작성하므로 Base Address가 달라지게 함으로써 모든 심볼 주소가 실행할 때마다 달라져 ASLR과 같은 효과를 가질 수 있다.(Base Address + Relative offset, 참고로 Base Address는 매번 변경되지만 offset은 동일)

참고로 PIE는 OS의 ASLR기능에 의존하므로 OS의 ASLR이 dsiable되어 잇으면 randomize 불가하며 더 구체적으로는 OS loader의 영향을 받는다.

PIE 활성화 및 비활성화 옵션

[비활성화]
gcc -no-pie

[활성화]
gcc -fPIE -pie

6. ASCII-Armor

RTL공격에 대응하기 위한 방법으로 공유 라이브러리 영역의 상위 주소에 0x00을 포함시킨다. ASCII-Armor가 적용되면 라이브러리를 공유 라이브러리 영역에 할당하지 않고 텍스트 영역의 16MB아래의 주소에 할당된다. 따라서 라이브러리 영역의 주소 최상위 1byte가 NULL로 인식된다. bof공격을 위해 string관련 함수(strcpy, strcat, ...)를 사용하게 되면 문자열을 읽다가 NULL값이 나오면 중지되므로 라이브러리 함수를 호출하는 그 때 최상위 1byte가 NULL값이므로 동작이 끝나 버린다.

→ GOT Overwrite로 우회 쌉가능

Reference)

https://velog.io/@embeddedjune/%EC%9E%84%EB%B2%A0%EB%94%94%EB%93%9C-%EB%A0%88%EC%8B%9C%ED%94%BC-%EC%9A%94%EC%95%BD-%EB%B0%8F-%EC%A0%95%EB%A6%AC-Chapter-8.-Debug

0. 들어가기 전에

• 지난 chapter 1~7의 모든 내용이 머릿속에 있다는 가정하에 이야기를 전개한다.
• 이 chapter는 가상의 시스템을 가정하고 특정 문제상황에서 어떻게 디버깅을 하면 좋을지 설명한다.
• 따라서 시스템의 특징에 대해 먼저 정의를 내리고 이야기를 진행해야 한다.
• 이 시스템은
  1. High vector를 사용한다. 따라서 EVT와 bootloader는 0xFFFF_0000번지에 존재한다.
  2. ISR을 SYS mode에서 처리한다. (∵ Nesting interrupt & mode change를 용이하게 하기 위해)
  3. SVC mode에서 user application과 kernel을 모두 실행한다.
  4. R13_SYS의 시작주소는 0x00FE_E730이다.

1. Reset 디버깅

1.1. Interrupt lock

• 우선 PC값이 High EVT의 reset handler를 가리키고 있기 때문에 HW reset이 발생했음을 눈치챌 수 있다.
• Reset이 발생했으니 당연히 SVC mode다.
• 안타깝게도 reset은 일반적인 상황이 아니다보니 제대로 context가 남아있지 않을 때도 많기 때문에 SPSR의 정보를 신뢰할 수 없다. 현재 우리는 지푸라기 잡는 심정으로 LR을 믿어보는 수 밖에 없다.
• LR이 가리키는 0x00EDCF19로 이동해보자. 만일 LR이 제대로 정보를 가지고 있다면, 이 근방에서 reset이 발생했을 것이다.

• 해당 주소로 이동해보니 0x00ED_CF18번지에서 b명령어로 자기자신으로 branch 하는 line을 발견할 수 있다.
• 원인은 다름아니라 while(1); 무한 loop를 발생시키는 코드 때문이었다.
• 그래서 task가 끝나지 못하고 watch dog task에게 report해서 timer를 reset 시키지 못해 HW reset이 발생한 것이다.
• 사실 굉장히 운이 좋은 경우다. Reset은 LR의 유효성을 보장하지 않는다. 그 위의 Interrupt_Lock() 덕분에 blx명령어가 실행돼 LR에 복귀주소가 기록되는 바람에 LR에 유용한 정보가 남아있었던 것이다.
• 게다가 MCU reset pin에 신호를 걸어주도록 설계된 시스템의 경우에는 HW reset이 났을 때 모든 레지스터와 메모리 정보가 싹 사라지기 때문에 디버깅이 매우 힘들어진다.

1.2. Task lock

• 이번에는 조금 더 어려운 상황을 생각해보자.

• 이번에도 PC는 EVT의 reset handler를 가리키고 있으므로 HW reset이 발생했음을 눈치챌 수 있다.
• 이번에도 LR을 믿어보자. 0x0000_1323번지를 덤프해보면 다음과 같다.

• LR은 bl명령어를 만나 Interrupt_Free()를 수행한 뒤 복귀주소로 0x0000_1323번지를 담고 있었다.
• 그리고 pop명령어는 R7, PC값을 반환했다. 저 PC값이 무엇이었는지 확인하기 위해 R13이 가리키는 주소 0x0116_FD3C로 이동해보자.

• R13은 0을 가리키고 있다. Stack은 full descending stack이니까 pop을 2회 하면 주소가 높아졌을 것이다.
• 즉, SP를 두 칸 아래로 옮기면, 0x00FC_4584는 R7, 0x00ED_CEB1은 PC에 저장됐을 것이다.
• 이제 원래 PC값을 알게 됐으니 0x00ED_CEB1번지를 덤핑해보자.
• 덤핑해보니 방금 다뤘던 시나리오처럼 무한 loop를 발생하는 while(1)문이 들어있었음을 확인할 수 있다. 따라서 task가 끝나지 못하고 watch dog에 의한 HW reset이 발생했음을 알 수 있다.
• 이번에는 LR과 SP를 활용해서 stack backtracing을 통해 문제 원인을 밝힐 수 있었다.

1.3. 0x0 branch

• 이번에도 reset이 발생했는데 특이하게 PC가 EVT를 가리키지 않고 low vector 일 때의 EVT를 가리키고 있다.
• 즉, HW reset이 아니라 SW적인 원인으로 발생한 reset임을 눈치챌 수 있다.
• 우선 이번에도 우리가 할 수 있는건 LR을 따라가는 것 뿐이니 0x00ED_CF3B로 이동해보자.

• 당장 눈에 보이는건 blx명령어인데, 이전까지 Thumb mode로 실행되고 있다가 이때부터 ARM mode로 실행됐다.
• blx명령어를 만나고 복귀주소로 LR에 집어넣은 것 같으니 운이 좋다.
• 위를 보니 memset()함수가 보인다. 범인을 찾은 느낌이 든다.
• memset()함수는 함수의 시작주소로부터 60-bytes를 0으로 초기화한다.
• 따라서 R0에는 0x0이 들어가고, 그 주소로 branch를 해버렸으니 reset이 발생한 것이다.

2. Abort exception 디버깅

• Abort는 reset보다 상대적으로 문제 원인을 찾기 매우 쉽다.

2.1. Data abort

• 우선 context를 보면 ABT mode이며 PC가 0x10로 abort handler를 가리키고 있으므로 data abort가 발생했음을 알 수있다. 따라서 LR - 0x8 주소로 이동하면 된다.
• LR이 0x00ED_CF26이므로 해당 주소로 이동한 뒤 0x8을 뺀 line을 보면, STR R0,[R1] 명령어가 있다.
• R1이 0xFFFF_FFFF값을 가지고 있는데, 현재 시스템의 memory map에는 해당 주소가 정의돼있지 않다.
• 즉, 접근할 수 없는 주소에 write하려는 시도 때문에 data abortion이 발생했음을 알 수 있다.
• C 소스코드를 보니 HWIO_ADDR이라는 전역변수가 0xFFFF_FFFF를 가리키는데 여기에 0x8을 쓰려다가 abortion이 발생했음을 알 수 있다. 잘못된 주소를 가리키고 있으니 초기화 값을 수정해주면 오류를 해결할 수 있다.

2.2. Prefetch abort

• Context를 보면 ABT mode이며 PC가 0x0C로 prefetch handler를 가리키고 있으므로 prefetch abort가 발생했음을 알 수 있다. 따라서 LR - 0x4 주소로 이동하면 된다.
• 그런데 LR을 보니 0x0000_0002라는 이상한 값을 갖고 있다. 무슨 이유에선지 LR이 corrupt 됐음을 직감할 수 있다.
• 단서로 사용할 수 있는 다음 후보 R13을 바라보자. 물론 ABT mode의 R13을 봐서는 안 된다.
• SPSR을 보니 10011로 이전 mode가 SVC임을 알 수 있다.
  • R14_SVC는 0xFFFF_FFFF를 가리키고 있다. 이쪽도 LR이 corrupt 됐다.
  • R13_SVC는 0x0116_FD24를 가리키고 있으니 그쪽으로 가보자.

• 일단 SP를 포함해 인근 영역이 전부 0xFF로 가득찬 것을 보아하니 심상치 않은 일이 발생했음을 알 수 있다.
• Stack을 backtracing 해보면, 가장 최근에 push한 정보는 0x00ED_D0FD이므로 우선 이 주소로 이동해보자.
• 이동해보니 bl 0xEDCE52 명령어가 보인다. bl 명령어를 만나 복귀할 주소를 LR에 남겨놓은 흔적을 볼 수 있다. ([※] 근데 왜 LR이 stack에 저장돼있었는지는 모르겠네요.)
• 이번에는 0xEDCE52로 이동해보자. void chaos(void)라는 함수가 시작되는 부분이다.
• 아하, 이 함수에서 memset((void *)(LocalBuffer - 10), 0xFF, 40)을 호출하는 것을 알 수 있다.
  • 지역변수로 word형 LocalBuffer[10]을 선언하고
  • LocalBuffer 시작주소로부터 20-bytes 밑(void * type이 2-byte 크기라고 가정하자)에서부터 40-bytes만큼을 0xFF로 초기화한다.

• 정리하면 위 그림의 설명과 같다.

2.3. Interrupt 처리 중 abort

• 이번에도 PC가 abort handler를 가리키는 것으로 보아 data abort가 발생했음을 알 수 있다.
• SPSR값을 보니 11111로 이전 mode가 SYS였다. 즉, 이번 abortion은 ISR을 처리하다가 발생했음을 눈치챌 수 있다.
• R14값 0x476A로 이동해보니 역시 clock_tick_ISR()이라는 ISR을 처리하다가 abortion이 발생했다.

• Data abort이므로 LR - 0x8인 0x0000_4762부터 바라보니 심상치 않은 어셈블리를 볼 수 있다.
• ldmia명령어가 계속 반복되며 딱 봐도 C 코드와 일치하지 않는 mnemonic이다.
• 높은 확률로 이쪽 주소 영역의 코드가 corruption이 발생한 것이므로 0x0000_4762번지에 write breakpoint를 걸어 누군가 이쪽 주소에 데이터를 쓰려고 시도하면 break가 걸리도록 해보자.
• 확인해보니 memset((void *)(functionsMarcel.HWIO_init), 0xABCD, 10);이라는 함수가 원인임을 발견했다.
  • functionsMarcel.HWIO_init이 어떻게 초기화 됐는지 확인해보니
  • functionsMarcel = {clock_io, clock_tick_isr};로 clock_tick_isr이 HWIO_init함수 포인터가 가리키는 함수로 초기화 돼있음을 확인할 수 있다.
• 따라서, memset()에 의해 clock_tick_isr() ISR의 시작주소로부터 10-bytes의 영역이 0xABCD로 초기화 됐고,
• Little endian이므로 해당 영역의 opcode가 CDAB로 채워져있었음을 알 수 있다.

3. Memory 불량

• 지금까지 우리는 정말 다양한 exception 시나리오와 대처방법을 배웠다.
• 이번에는 정말 웃기지도 않는 황당한 경우를 보면서 ‘정말 다양한 원인으로 문제가 발생하는구나’라고 느껴보자.

• 계속되는 reset 및 abort로 인해 메모리를 덤프해보니 위와 같았다.
• 뭔가 규칙성이 느껴지지 않는가? 특정 열만 0xFD인 규칙성이 보인다.
  • 0xFF이면 1111_1111인데, 0xFD는 1111_1101이다.
• 즉, 메모리의 특정 bit가 고장이 난 SDRAM 불량인 경우다.
• 이런 경우는 진짜 오랜 개발경험이 없는 한 전혀 감이 안 오는 상황이다. Stack이 문제인가? 실행 binary를 잘

https://kr.analysisman.com/2021/04/bluetooth-attack.html

블루투스(Bluetooth) 공격 기법

----- 목차 ------

• 블루투스 기술
• 블루투스 공격 기법
• 블루투스 공격 도구
• 블루투스 취약점
• 블루투스 해킹 대응 방안

 

• 블루투스 기술

블루투스(Bluetooth)는 1994년에 에릭슨이 최초로 개발한 디지털 통신 기기를 위한 개인 근거리 무선 통신 산업 표준이다. 자세한 스펙과 설명은 위키 페이지를 참조하고, 이 블로그 글에서는 블루투스 기술에 대한 요약과 함께 블루투스를 이용한 해킹에 관해 설명한다.

✓ 클래스에 따라 도달 거리가 0.5m~100m 다르지만, 보통 10m(미터) 이내의 초단거리에서 저전력 무선 연결에 쓰인다.

✓ 주파수는 ISM 대역인 2.402~2.480 GHz, 총 79개 채널을 쓴다. 

ISM이란 산업, 과학, 의료용으로 할당된 주파수 대역으로, 아마추어 무선, 2.4GHz 무선랜, 블루투스가 이 ISM 대역을 사용한다.

✓ 여러 시스템과 같은 주파수 대역을 이용하기 때문에 시스템 간 전파 간섭이 생길 우려가 있는데, 이를 예방하기 위해 블루투스는 주파수 호핑(Frequency Hopping) 방식을 취한다.
주파수 호핑이란 많은 수의 채널을 특정 패턴에 따라 빠르게 이동하며 패킷(데이터)을 조금씩 전송하는 기법이다. 블루투스는 할당된 79개 채널을 1초당 1600번 호핑한다.

✓ 이 호핑 패턴이 블루투스 기기 간에 동기화되어야 통신이 이루어진다. 

블루투스는 기기 간 마스터(Master)와 슬레이브(slave) 구성으로 연결되는데, 마스터 기기가 생성하는 주파수 호핑에 슬레이브 기기를 동기화시키지 못하면 두 기기 간 통신이 이루어지지 않는다. 이로 인해 다른 시스템의 전파 간섭을 피해 안정적으로 연결될 수 있게 된다. 참고로 하나의 마스터 기기에는 최대 7대의 슬레이브 기기를 연결할 수 있다.

✓ 블루투스 버전 별 최대 데이터 전송 속도는 아래와 같다.
버전연도최대 전송 속도

1.0, 1.0B + BR (Basic Rate)	1999	768 Kbps
1.1	2002	768 Kbps
1.2	2003	1 Mbps
2.0 (2.1) + EDR (Enhanced Data Rate)	2004	3 Mbps
3.0 + HS (High Speed)	2009	24 Mbps
4.0 + LE (Lower Power, aka Bluetooth Smart), 4.1	2010	24 Mbps
4.2	2014	24 Mbps
5.0	2016	48 Mbps

• 블루투스 공격 기법

 

▶ 블루재킹(Bluejacking)

블루스패밍(Bluespamming)이라고도 하며, 스팸처럼 익명으로 블루투스 사용자에게 메시지를 보내는 기법이다. 귀찮은 존재긴 하지만 보안에 큰 위협을 가하지는 않는다.

▶ 블루스나핑(Bluesnarfing)

블루투스의 취약점을 이용하여 장비의 임의 파일에 접근하는 공격으로 모바일 기기에 저장된 일정표, 전화번호, 이메일, 문자메시지 등에 접근하는 방법이다.

▶ 블루버깅(Bluebugging)

블루투스 장비 간의 취약한 연결 관리를 악용한 공격으로 공격 장치와 공격 대상 장치를 연결하여 공격 대상 장치에서 임의의 동작을 실행하는 공격이다.

희생자의 휴대폰을 원격 조종해 통화내용을 엿듣는 해킹 방법으로 치명적인 피해를 야기할 수 있다. 이 기술을 이용하려면 타겟과 10m 이내에 있어야 가능하다.

 

• 블루투스 공격 도구

 

▶ 레드팽(RedFang)

숨겨진 블루투스 기기를 찾아내는 PoC 애플리케이션으로 무차별 대입을 통해 피해자의 블루투스 MAC 주소를 추측한다.

 

▶ 블루스니프(BlueSniff)

검색 가능하고 숨겨진 블루투스 기능이 활성화된 장치를 찾는 간단한 유틸리티다.

 

▶ BT스캐너(BTScanner)

무차별 대입 스캔, 반경 내 블루투스 기기 식별, 스캔 결과 내보내기 및 결과 정렬을 수행할 수 있는 블루투스 스캔 프로그램이다.

 

▶ 블루버그(BlueBugger)

블루투스가 활성화된 모바일 기기의 보안 취약점을 이용하는 도구. 연락처와 통화 목록을 다운로드하고 공격자 모바일에서 SMS 메시지를 보내고 읽을 수 있게 해준다.

 

이외 블루투스 공격 도구 모음 링크

 

• 블루투스 취약점

 

▶ BlueBorne (2017)

✓ 이 취약점은 안드로이드, iOS, 윈도우, 리눅스, 사물 인터넷 기기 등 약 53억대 이상의 기기에 영향을 미치는 것으로 나타났다.

✓ 블루본(BlueBorne)은 공격자가 블루투스가 활성화되어 있는 장치에 페어링하지 않아도 장치를 제어할 수 있는 공격 형태다.

✓ 공격자는 피해자의 장치 블루투스가 활성화된 상태로, 가까운 위치에 있기만 하면 된다.

✓ 아래와 같은 8개의 CVEs가 IoT 보안회사 아미스 랩(Armis Labs)에 의해 발견되었다.

 - 안드로이드: RCE (CVE-2017-0781, CVE-2017-0782), Information leak (CVE-2017-0785), MITM (CVE-2017-0783)

 - iOS: RCE (CVE-2017-14315)

 - 윈도우: MITM (CVE-2017-8628)

 - 리눅스: Information leak (CVE-2017-1000250), RCE (CVE-2017-1000251)

 

* 참고: BlueBorne Technical White Paper, 11.30.2017, Armis (PDF 41 pages)

 

* 관련 기사

Blueborne 취약점 정리

블루투스의 심각한 위험, "블루본"의 이해(ITWorld)

블루투스 악용한 제로데이 취약점 ‘블루본’, 보안 업데이트 발표 (보안뉴스)

▶ KNOB (2019)

✓ CVE-2019-9506이라고 불리는 이 취약점은 '암호화 키 협상 프로토콜'이 두대의 장비에 보안 연결을 할때 두대의 블루투스 BR/EDR 디바이스가 암호화 키를 위한  앤트로피 값을 선택하는 방식에서 나타난다.

✓ KNOB(Key Negotiation of Bluetooth) 공격이라고 불리는 이 취약점은 원격 공격자가 가까운 거리에서 타깃 디바이스에 연결된 두 디바이스 사이에 암호화된 블루투스 트래픽을 조작하거나 감시하거나  가로채는 것이 가능하다.

✓ KNOB 공격을 완화하기 위해 Bluetooth 사양 관리자는 장치 제조업체와 소프트웨어 공급 업체가 BR/EDR 연결에 최소 7옥텟의 암호화 키 길이를 적용 할 것을 강력히 권장했다.

 

* 참고: Low Entropy Key Negotiation Attacks on Bluetooth and Bluetooth Low Energy (Daniele Antonioli 외, PDF 13 pages)

 

USENIX Security '19 - The KNOB is Broken: Exploiting Low Entropy in the Encryption Key

YouTube (19:39), https://youtu.be/v9Xg9XcnNh0

 

 

* 관련 기사

공격자가 암호화된 연결을 감시 할 수 있는 새로운 블루투스 취약점

▶ BIAS (2020.3)

✓ 이 취약점(CVE-2020-10135)은 코드네임 BIAS(Bluetooth Impersonation AttackS)로 명명되었으며, Bluetooth BR/EDR, Bluetooth Classic 등으로 불리고 있는 블루투스 프로토콜의 클래식 버전에 영향을 준다.

✓ 암호화 연결을 생성하기 위해서는 두 개의 블루투스 기기를 페어링할 때 링크 키를 사용해야 하는데, 기기와 물리적으로 근접한 무단 공격자는 이전에 페어링(연결된) 기기를 위조하여 링크 키 없이도 인증할 수 있다.

✓ BIAS와 KNOB를 조합한다면 공격자가 블루투스 클래식 기기가 안전 인증 모드에서 동작한다고 하더라도 인증을 깰 수 있다.

 

* 관련 기사

신규 블루투스 취약점 발견돼…모든 블루투스 기기 BIAS 공격에 위험 (데일리시큐)

블루투스 클래식에서 발견된 취약점들, 모든 블루투스 장비에 적용된다 (보안뉴스)

▶ BLURtooth (2020.7)

✓ 이 취약점은 블러투스(BLURtooth)라고 불리며, CVE-2020-15802라는 번호가 붙었다.

✓ 이 취약점을 익스플로잇 할 경우 인증을 통과하지 못한 공격자들이 페어링 된 장비들 간 통신 내용을 바꾸거나 엿들을 수 있다.

✓ 블루투스 4.0~5.0 버전의 페어링 과정을 ‘교차 전송 키 파생(Cross-Transport Key Derivation, CTKD)’이라고 부르는데, 이것의 구현 방법과 취약점에 밀접한 관련이 있다.

 

※ 블러투스 취약점과 관련된 블루투스 프로토콜에는 두 가지 유형이 있다.

1) 블루투스 클래식(Bluetooth Classic) : 블루투스 Basic Rate / Enhanced Data Rate(BR/EDR)이라고도 불린다. 좀 더 오래된 유형이다.

2) 블루투스 로우 에너지(Bluetooth Low Energy) : 줄여서 BLE라고도 하며 클래식보다 새로운 유형의 프로토콜이다.

BR/EDR은 주로 오디오 관련 애플리케이션들에 사용되고, BLE는 웨어러블 장비들에서 보다 많이 나타난다.

 

* 관련 기사

블루투스 4.0~5.0에 적용될 수 있는 중간자 공격 취약점, 블러투스 (보안뉴스)

BLURtooth vulnerability lets attackers overwrite Bluetooth authentication keys (ZDNet)

 

▶ BLESA (2020.9)

✓ 블레사는 퍼듀대학의 연구원들이 블루투스 저전력(BLE)에서 취약점을 발견했다. (CVE-2020-9770)

✓ 블레사(BLESA)는 BLE 스푸핑 공격(BLE Spoofing Attacks)의 준말로, 블루투스 연결이 재차 성립되는 과정에서 발동된다.

✓ 전 세계 수십억 대의 사물인터넷 장비에 영향을 줄 만한 것이며, 안드로이드 장비들은 거의 대부분 이 취약점에 노출된 채 사용되고 있다.

✓ 공격자들은 재연결 시 필요한 인증 과정을 BLESA를 통해 우회해 표적으로 삼은 장비에 접근해서 가짜 데이터를 보낼 수 있다.

✓ 문제는 BLE가 애드버타이징 패킷(advertising packet)을 항상 평문으로 전송하고, 장비 간 재연결이 이뤄질 때 인증이 필수가 아닌 경우가 많은 것.

 

* 참고: BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy (PDF 18 pages)

 

WOOT '20 - BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy

YouTube (17:32), https://youtu.be/wIWZaSZsRc8

 

 

* 관련 기사: 

블루투스 재연결이 위험해! 새로 등장한 블레사 취약점 (보안뉴스)

BLESA: Spoofing Attacks against Reconnections in Bluetooth Low Energy (USENIX)

▶ BleedingTooth (2020.10)

✓ 구글과 인텔이 리눅스 블루투스 프로토콜인 블루지(BlueZ)에서 고위험군에 속하는 취약점을 발견했다. 

✓ 블루지는 리눅스 기반 사물인터넷(IoT) 장비들에 탑재된 블루투스 기능을 구현하는 데 있어 핵심적인 요소 중 하나다.

✓ 구글에 의하면 리눅스 커널 5.9 이전 버전의 경우 블리딩투스(BleedingTooth) 취약점에 노출되어 있다고 한다.

✓ 블리딩투스 취약점의 가장 큰 특징은 피해자가 링크를 클릭하거나 파일을 열지 않아도 되는 ‘제로 클릭 공격’이 가능하다는 점이다.

✓ CVE-2020-12351 (high), CVE-2020-12352 (medium), CVE-2020-24490 (medium)

 

* 참고: Linux kernel version history

 

* PoC 익스플로잇 영상 - BleedingTooth: Linux Bluetooth Zero-Click Remote Code Execution

YouTube (0:24), https://youtu.be/qPYrLRausSw

 

 

* 관련 기사

리눅스 블루투스 프로토콜에서 심각한 ‘블리딩투스’ 취약점 나와 (보안뉴스)

Google warns of severe 'BleedingTooth' Bluetooth flaw in Linux kernel (ZDNet)

 

 

• 블루투스 해킹 대응 방안

 

① 블루투스이 필요할 때만 연결하고 사용하지 않을때는 블루투스를 OFF 합니다.

패치가 나와 업데이트했더라도 평소에 필요할 때만 블루투스 기능을 켜는 것은 좋은 습관입니다.  보안 측면에서 공격 표면(Attack Surface)를 줄이고, 스마트폰은 배터리를 아낄 수 있는 추가 장점도 있습니다.

 

특히 리눅스의 경우, 커널 5.9 이전 버전의 경우 블리딩투스(BleedingTooth) 취약점에 노출되어 있습니다. 커널 패치가 어려운 경우가 많으니 블루투스를 사용하지 않는 경우 disable 하기를 권장합니다.

 

* 참고:

How to disable Bluetooth in Red Hat Enterprise Linux?

How to disable Bluetooth in Ubuntu

 

② 블루투스 연결 시 페어링 요청을 보내는 디바이스를 정확히 확인하고, 신뢰할 수 있는 경우에만 승인합니다.

 

③ 시스템이나 모바일 장치의 펌웨어나 소프트웨어를 항상 패치하여 최신 상태로 유지합니다.

최신 버전의 소프트웨어를 유지하는 것은 사이버보안에서 가장 중요합니다.

 

 

▶ 함께 읽어보면 좋은 관련 글: 무선(Wi-Fi) 네트워크 보안 및 취약점

 

* 참고 자료 및 출처

[IT강의실] 무선 세계를 통일하려는 '푸른 이빨' - 블루투스 (아이티동아)