반응형

'분류 전체보기'에 해당되는 글 212건

반응형
반응형

1. UPX(Ultimate Packer for executables)

- 여러 운영체제에서 많은 파일 포멧을 지원하는 오픈 소스 실행 파일 압축 프로그램

- 압축 및 해제 모두 가능함

 

2. 패킹 관련 사항

* UPX0, UPX1, .rsrc 총 3가지로 구성됨

* Section UPX0 : 메모리에 로드된 후 압축코드가 해제 될 공간

* Section UPX1 : 압축코드가 저장되는 공간

 

3. UPX 언패킹

[그림 1-1] UPX 언패킹 시도

upx 프로그램을 사용해서 MsgBox.exe 파일을 언패킹을 시도한다. 언패킹에 성공하면 기존 파일 사이즈가 많이 줄어 들었음을 알 수 있다.

 

[그림 1-2] UPX 언패킹 결과

PEView 프로그램에 언패킹된 파일과 언패킹 되지 않은 파일을 올려서 비교해보면 벌써 내용이 달라졌다는 것을 확인할 수 있다. 여기서 중점적으로 봐야할 것은 SECTION .rdata 부분인데 원본 파일에서는 존재하지만 언패킹된 파일에선 존재하지 않는다. 

반응형

'악성코드분석' 카테고리의 다른 글

리버싱 기초 (2)  (0) 2021.01.11
리버싱 기초 (1)  (0) 2021.01.10
MP3 컨버터를 이용한 Exploit  (0) 2018.01.21
ollydbg와 mona를 이용한 BOF 실습  (0) 2018.01.21
BOF 기초실습  (0) 2018.01.21
블로그 이미지

만년필석사

,
반응형

2020년 12월 말, 이직에 성공했다.

기존에 있는 회사에서도 하는 업무는 만족스럽고 좋았지만 주로 단기, 중기 사업들을 위주로 하다 보니 모의해킹 레퍼런스는 잘 쌓여가지만 뭔가 불안했다.

경력 3년차에 접어들고 있고 분명 1년 이상 되는 장기 사업도 경험해봐야 하는데.... 현재 회사에선 그런 프로젝트를 할 기회가 적어 장기 사업을 해보고도 싶기도 하고 이것저것 좀 더 다양하게 경험해보고 싶어 이직을 결심하였다.

전엔 보안관제에서 모의해킹으로 이직을 하긴 했지만 그때는 말그대로 "중고 신입"이었고 경력직 이직은 처음 해봤다. 그래서 정보도 많이 없고 어떻게 해야 하나 많이 고민했던 것 같다. 이력서를 작성하고 그동안 했던 프로젝트 경력 프로필을 만들면서 "이렇게 하는게 맞나?" 이 말만 계속 되뇌였다. 게다가 경력직들 면접은 어떻게 물어볼지를 몰라서 그 정보를 구하는데 시간도 많이 들였다.

그렇게 이력서, 경력 기술서 등을 완성하고 이력서를 넣기 시작했다. 이번엔 정말 큰 회사를 가고 싶었고 여기가 안되면 그냥 이직 안한다는 각오로 했다. 내가 워낙 단기나 중기 사업 위주로 많이 했어서 경력직 서류 통과도 쉽지 않을 것이라고 예상했다. 회사는 총 세군데를 넣었고 1주일~2주일 뒤에 연락이 왔는데 놀랍게도 넣었던 회사들 모두 서류가 통과되었다. 신입 땐 서류 통과 조차도 안되었던 회사들이 통과되니까 자신감이 붙었다.

그 때 들었던 생각은 "그래, 떨어지더라도 최선을 다해보자, 해보지도 않고 어떻게 알아?" 였다. 인성 검사도 통과되고 기술 및 인성 면접을 한꺼번에 보게 되었는데 몇년만에 보는 면접이라 조금 긴장도 됐지만 자기소개가 끝나곤 마음이 편해졌다. 확실히 경력직 면접은 지금까지 해왔던 프로젝트들을 위주로 질문을 받았고 내가 직접 다 했던거라 편안하게 면접관들한테 답변했다. 엄청 테크닉적인 질문보단 해왔던 프로젝트 경험 위주, 만약 이 회사에 와서 어떤 업무를 할 수 있는지 등을 중점적으로 물어봤다. 또한 큰 회사라 그런지 인성 질문도 많이 받았다. 아마 조직생활에 대한 적응 능력, 팀원들과의 협업 능력, 태도 등을 평가하려고 했던 것 같다.

그렇게 면접이 끝나고 결과를 기다렸다. 면접을 본 지 3일 후 내 이메일로 최종 합격 통보를 받을 수 있었다. 걱정도 참 많이 했는데 받고 나니 얼마나 기뻤는지 모른다. 게다가 내가 한번 쯤은 꼭 가보고 싶었던 회사여서 더 열심히 해야겠다는 생각도 들었다. 이젠 건강검진만 남겨놓고 있지만 이직해서도 절대 안주하지 않고 지금보다 더 발전하고 스킬업 할 수 있게 최선을 다 할 생각이다.

반응형

'IT인의 여러가지 이야기' 카테고리의 다른 글

코딩 열풍에 대한 고찰  (0) 2021.07.25
야간 대학원 진학  (0) 2021.05.08
이직 그 후...  (0) 2021.03.06
2020년 회고록  (0) 2020.12.15
케이쉴드주니어 FAQ  (16) 2020.01.28
블로그 이미지

만년필석사

,
반응형

2020년 한해도 저물어가고 있다. 코로나로 인해 모두가 힘든 시기를 겪고 있고 모의해킹쪽도 프로젝트 일정이 밀리고 엉켜서 하반기로 많이 밀렸다. 얼른 코로나가 극복되었으면 좋겠는데... 생각 외로 오래가고 있는 것 같다. 자유도 많이 잃어버리고 얼른 다시 일상으로 돌아갔으면 하는 바램이다. 2020년 한 해를 돌아보면 정말 열심히 살았다고 말할 수 있을 것 같다. 내가 하고 싶었고 관심이 있었던 모의해킹 업무였던 만큼 내 힘이 닿는데까지 열심히 했다.


역시 단순히 돈만 보고 쫓아가는게 아닌 내가 정말 하고 싶은 일이 어떤 것인지 다시 생각하고 선택했던 것이 주효했던 한 해였다. 열심히 돌아다니고 많은 고객사를 방문해보면서 내 자신을 한단계 더 업그레이드 시켰다. 고객을 대하는 방법, 모의해킹 기술들, 위험 평가 등.... 모두 나에겐 자산이 되고 느낀게 많았다. 그에 따른 원동력은 역시나 사람들을 잘 만났던 것 같다.


같이 일한 PM님, 수석님들이 실력도 좋으시고 실수를 하는게 있어도 질타하는게 아닌 다시 한 번 어떤 부분이 잘못되었는지 알려주시는 방식으로 업무를 진행하셨고 나도 그런 윗사람들을 보면서 많이 배우고 느꼈던 것 같다. 프로젝트는 항상 나 혼자만을 생각하며 진행할 순 없기에... 늘 협업이라는 것이 중요했고 그러한 부분을 보면서 내껏으로 승화시키기 위해 노력했다. 지금 생각해보면 입사하고 정말 아무것도 모르는 상태에서 갑자기 금융권쪽 프로젝트에 투입되서 어떻게 진행했는지.... 처음부터 금융권 프로젝트에 투입될 진 생각도 못했지만 역시 금융권쪽이 배울게 가장 많았었다.


많은 돈이 왔다갔다하고 그만큼 보안에 엄청나게 투자를 하는 만큼 보는 시각이 좀 더 넓어졌다. 지금도 금융권쪽 커리어를 쌓게 해준 회사에 고마울 따름이다. 그렇게 여러 단기 프로젝트를 경험해본 후 계속 혼자 웹, 모바일 앱 모의해킹을 하면서 돌아다녔고 바쁠땐 3~4개월씩 본사 구경도 못해본 채 일만 했다. 때론 너무 돌아다녀 지치기도 했지만 다른 회사의 좋은 분들을 만나 다시 충전되고 일하고 그랬다.


전국을 돌아다닌다는 것도 쉽지만은 않지만 그냥 여행 다닌다는 생각으로 다녔다. 내가 좋아서, 진심으로 하고 싶었던 일이었던 만큼 열과 성의를 다했고 틈나는 대로 모의해킹에 필요한 기술, 대학원 공부까지 꾸준히 했었던 만큼 후회없는 한 해를 보낸 것 같다.


이제 대학원도 졸업을 앞두고 있고 어느덧 보안 경력도 3년차에 들어가고 있지만 늘 현실에 안주하지 않고 꾸준히 올라가는 기술컨설턴트가 되는 것이 현재 내 목표다. 내년에도 나태해지지 않고 지금처럼만 하길 바라며 계획했던 것들이 모두 이루어지길 소망하며 글을 마친다.

반응형

'IT인의 여러가지 이야기' 카테고리의 다른 글

코딩 열풍에 대한 고찰  (0) 2021.07.25
야간 대학원 진학  (0) 2021.05.08
이직 그 후...  (0) 2021.03.06
이직 성공 후기  (4) 2021.01.01
케이쉴드주니어 FAQ  (16) 2020.01.28
블로그 이미지

만년필석사

,
반응형

https://dev.to/thawkin3/protecting-against-xss-attacks-in-react-441m?fbclid=IwAR38Fe8L3jovxxdmJWNxVM0-SxeQFGXYwzgalcJNE-sEEyVdbEvUrD-LPds


이건 버그바운티는 아니지만 리액트에서의 XSS 공격에 대한 대응방안을 잘 적어놨다. XSS 공격은 버그바운티 뿐만 아니라 실무에서도 많이 나오는 공격이기 때문에 좋은 대응 방안은 알면 알수록 도움이 많이 된다. 생각보다 어렵진 않다. dangerouslySetInnerHTML이라는 속성 사용을 자제하면 리액트에선 간단하게 XSS 공격이 막힌다.  대신 아래와 같은 코드를 사용한다.


<p style={searchResultsStyle}>You searched for: <b>{this.state.submittedSearch}</b></p>

[출저]:https://dev.to/thawkin3/protecting-against-xss-attacks-in-react-441m?fbclid=IwAR38Fe8L3jovxxdmJWNxVM0-SxeQFGXYwzgalcJNE-sEEyVdbEvUrD-LPds


현재 사진은 링크 걸어놓은 문서 안에 있는 사진인데 어떻게 방어되는지 써보고 싶어 캡쳐했다. XSS 공격이 방어되면 경고창이 출력되지 않고 사진과 같이 입력값 형태로 출력됨을 볼 수 있다. 생각했던것보다 리액트에선 XSS 공격 방어가 간편하다.

반응형

'버그바운티' 카테고리의 다른 글

Write-up / Mass account takeovers [Slack]  (0) 2020.07.14
블로그 이미지

만년필석사

,
반응형

https://hackerone.com/reports/737140


해당 버그 헌팅은 HTTP Request Smuggling bug라는 취약점을 이용해서 많은 계정들의 세션탈취를 성공했다.


https://paper.seebug.org/1049/


한국어로 된건 많이 없어서 생각보다 많이 어렵다. 그나마 해당 링크가 잘나와있는 편인데 좀 간단하게 말해서 동일한 HTTP 요청을 여러종류의 서버들이 각기 다른방식으로 처리하기 때문에 발생되는 취약점 중 하나다. Smugging bug 중에서도 CLTE 기법을 사용했는데 해당 공격기법은 Content-Length 헤더와 Transfer-Encoding 헤더를 동시에 전송하는 공격기법이다. Transfer-Encoding은 hop-by-hop 헤더로, 리소스 자체가 아닌 두 노드 사이에 메시지를 적용한다. 프론트엔드 서버에서는 Content-Length를, 백엔드 서버에서는 Transfer-Encoding을 각각 해석하는것을 이용하여 요청을 변조한다.


반응형

'버그바운티' 카테고리의 다른 글

리액트에서의 XSS 대응방안  (0) 2020.07.14
블로그 이미지

만년필석사

,
반응형

1. 취약점 소개

애플리케이션 패칭 취약점이란 안드로이드의 클라이언트 코드를 변경해 비정상적인 작동을 유도하도록 APK 파일을 변조해 실행되는 취약점을 말한. 대표적인 예로 배포된 악성코드들이 정상적인 서비스 앱을 조작( 변조) 사용자들을 유인해 사용자의 개인 정보, 공인 인증서, 휴대폰 정보 등을 탈취한다. 서버 인증이 아닌 클라이언트 단의 인증을 우회해서 여러가지 인증 절차를 무력화 시킬 있다.

 

2. 취약점 진단

[그림 2-1] 릴리즈된 apk 파일 확인 디컴파일

릴리즈된 ap 파일을 확인한 apktool -d [릴리즈 파일 ] 명령어를 입력해 디컴파일을 한다.

 

[그림 1-2] smali 코드 생성

디컴파일 하면 app/app-release/smali/com/android/insecurebankv2/ smali 코드가 생성된다.

 

[그림 2-3] 루팅 체크 smali 코드

PostLogin.smali 파일에서 "Rooted Deviced" 다른 문자로 수정한다. 여기선 Hacker!!!! 수정했다.

 

[그림 2-4] 릴리즈된 apk 컴파일

smali 코드를 수정한 apktool 도구를 활용해 다시 컴파일한다. apktool -d [릴리즈 파일 ] 입력 실행한다. 컴파일 apk 파일은 InsecureBankv2/app/app-release/dist/ 존재한다.

 

[그림 2-5] 서명키 인증

새로 릴리즈된 apk 파일은 단말기에 설치 에러가 발생한다. 따라서 서명키 인증을 해야 하는데 https://github.com/appium/sign 에서 서명키 인증과 관련된 파일을 다운 받고  java -jar signapk.jar [서명키.pem] [서명키.pk8] [리패키징.apk] [서명된 리패키징 이름.apk]  명령어를 입력하면 새로 릴리즈된 apk 파일에 대한 서명키 인증이 진행된다.

 

[그림 2-6] 변조된 실행

서명키 인증 변조된 앱이 정상적으로 설치되고 로그인하면 변조했던 Hacker!!! 문구가 출력됨을 있다. 실무에선 smali 코드 변조를 통해 루팅 우회를 하거나 인증 프로세스를 우회하는 곳에 코드 패칭을 적용한다.

 

3. 취약점 대응 방안

안드로이드 앱의 위변조에 대응하기 위해 NDK 사용하는데 소스코드 난독화가 되어 있지 않다면 프로세스를 분석해 메모리에서 중요한 제어를 조작한다. 안드로이드 스튜디오에선 기본적으로 난독화 도구인 프로가드를 제공한다. 프로가드는 자바코드에서 사용하 않는 클래스, 필드, 메서드들을 찾은 삭제해서 코드 전체의 크기를 줄여주고 클래스, 필드, 메서드 등의 이름을 난독화 해주는 프로그램이다.

 

[그림 3-1] 프로가드 설정

인시큐어뱅크 폴더 목록에서 Gradle Scripts>build.gradle 파일에 buildType 존재한다. minifyEnabled 기본적으로 false 설정되어 있고 이를 true 수정하면 적용이 가능하다.

 

[그림 3-2] 서명 인증

변조된 파일의 설치를 위해 서명 키로 인증한 릴리즈 파일로 저장한다.

 

[그림 3-3] 릴리즈 파일 디컴파일

dex2jar 도구를 사용해 릴리즈 apk 파일을 디컴파일 해서 jar 파일로 생성한다.

 

[그림 3-4] jar 파일 확인

jadx-gui 실행시킨 디컴파일 jar 파일의 소스 코드를 확인하면 a,b,c,d 같은 이름으로 변경되었고 어떤 함수인지 판별하기 어렵게 되었다.

 

[그림 3-5] 루팅 소스 코드 난독화

PostLogin 파일의 소스코드를 보면 루팅 방지 부분 코드고 문자열 난독화는 적용되지 않았지만 루팅을 체크하는 몇몇의 함수가 난독화 되서 공격자가 분석하기 어렵게 된다.


반응형

'안드로이드 앱 취약점 진단 > 인시큐어뱅크' 카테고리의 다른 글

개발자 백도어 취약점  (0) 2021.09.19
파라미터 조작  (0) 2020.02.29
취약한 액티비티 컴포넌트  (0) 2020.02.15
XSS 공격  (0) 2020.02.10
로컬 암호화 이슈  (0) 2020.02.09
블로그 이미지

만년필석사

,
반응형

1. 하트블리드 취약점 개요

하트 블리드 취약점은 2014 4월에 발견된 OpenSSL 소프트웨어 버그다. CVE-2014-0160이며  취약점은 사용자나 관리자의 아이디, 패스워드, SSL 비밀키 등을 노출하게 하는 매우 위험한 취약점으로 판명됐다. OpenSSL 1.0.1 이후 '하트비트'라는 세션 연결을 확인하는 방법을 제공하지만 전달되는 값의 길이가 검증되지 않아 버퍼 오버플로우가 발생한다.  결함은 최대 64KB 응용 프로그램 메모리 내용을 요청할  있다. 서버의 메모리 정보를 평문으로   있어 지속적으로 공격해 정보들을 합치면 아이디, 패스워드, 기타 개인 정보 노출이 가능해진다.

 

                                                                                                          <사진 출저 : blog.alyac.co.kr>

[그림 1-1] 하트블리드 시나리오

하트블리드 시나리오를 보면 클라이언트는 의도적으로 거짓 정보를 서버에게 전달해 오류를 발생시킨다. 서버측은 클라이언트에서 받은 거짓 정보를 검증 하지 않고 클라이언트가 요청한 거짓 정보 값을 그대로 다시 응답한다. 예를 들면 "이것은 잘못된 정보입니다. 사용자의 ID 값은 Hello PW 1234$ 입니다." 잘못된 정보를 포함해  다른 정보들을 클라이언트에게 전달하게 된다. 이러한 정보들이 합쳐져 아이디, 패스워드, 개인 정보 등과 같은 중요 정보들이 노출되게 된다.

 

2. 취약점 실습 환경 구성

 

사용 환경

OS 및 IP 주소

공격자 PC

Kali-linux 2019.03

IP 주소: 192.168.171.188

웹 서버

Bee-box

IP 주소: 192.168.171.187

희생자 PC

Win-7 x.64

IP 주소: 192.168.171.185

 

3. 하트 블리드 취약점 스크립트 코드 시연

 

[그림 3-1] 하트 블리드 취약점

Nginx 웹 서버가 취약한 버전의 OpenSSL을 사용하고 있다. 8443 포트로 공격 스크립트를 작동하라는 메시지가 출력되었다.

 

[그림 3-2] 명령어 입력

위의 스크립트를 다운 받아 저장 후 실행한다. Python heartbleed.py [웹 서버 IP] | more 명령어를 입력하고 실행하면 공격 스크립트가 실행된다.

 

[그림 3-3] 8443 포트 접근

희생자 PC에서 웹 서버의 8443 포트로 접근한 후 계정 정보로 로그인을 시도한다.

 

[그림 3-4] 계정 정보 노출

로그인 시도 후 실행했던 공격 스크립트를 확인하면 메모리 단에 로그인했던 계정 정보가 평문으로 노출되어 있음을 확인할 수 있다.

 

[그림 3-5] 와이어 샤크 패킷 전송

와이어샤크에서 ip.addr == [웹 서버 IP]로 필터링하고 패킷을 확인하면 하트블리드 공격에 의해 전송된 값을 볼 수 있고 입력 했던 계정 정보가 평문으로 노출되고 있음을 확인할 수 있다.

 

[그림 3-6] TCP Steam

정상 SSL 통신에서 암호화되는 요청 패킷의 내용이 하트블리드 취약점에 의해 요청 패킷 내용이 평문으로 전송되고 있다.

 

4. 하트블리드 취약점 메타스플로잇 시연

[그림 4-1] 모듈 검색

msfconsole 실행 후 search heartbleed 명령어로 하트블리드 관련 모듈을 확인한다. 하트블리드 취약점 시연을 위해 auxiiary/scanner/ssl/openssl_heartbleed 모듈을 사용한다.

 

[그림 4-2] 옵션 지정

하트블리드 모듈을 실행하고 옵션을 지정한다. 지정 옵션들은 다음과 같다.

 

명령어

정의

set rhost [IP 주소]

공격대상 IP 지정

set rport [Port 주소]

공격대상 Port지정

set verbose true

로깅 출력 지정

 

[그림 4-3] 공격 수행

옵션 지정 후 공격을 수행하면 스캔이 시작된다. 스캔이 되고 메모리 값이 노출되는데 웹 서버에서 로그인 했던 계정 정보가 평문으로 노출되고 있음을 확인할 수 있다.

 

5. 대응 방안

Open SSL 버전 업데이트, 비밀번호 이중 인증, 인증서 재발급, IPS 탐지룰 설정 등으로 방어한다. 사용하는 운영체제의 정식 페이지에서 Open SSL 업데이트 버전을 설치한 후 테스트 해보는 방법도 필요하다.

반응형

'웹해킹 > Bee-box' 카테고리의 다른 글

스택오버플로우 공격  (0) 2018.01.03
쉘 쇼크 취약점  (0) 2018.01.02
디바이스 접근 제한/서버 측 요청 변조  (0) 2018.01.02
디렉터리 리스팅  (0) 2018.01.01
ARP 스푸핑 공격  (0) 2017.12.31
블로그 이미지

만년필석사

,
반응형

1. 취약점 소개

사용자가 안드로이드 앱을 사용하기 위해 로그인을 시도한다. 입력되는 파라미터 값들이 보호되지 않으면 공격자가 파라미터 정보를 수정해 악용할 경우, 개인 신상 유출, 신용카드 도용, 가격 변조 등과 같은 피해가 발생할 있다. 안드로이드 앱에서도 웹과 똑같이 요청하는 중간에서 값을 가로채 매개변수값을 변조해서 전송한다. 공격을 통해 본래 요청값이 변조된 값으로 수정되고 민감한 정보가 포함된 요청이면 정보 유출 위험성이 존재한다. 웹에서는 인증 우회 취약점으로 분류하기도 한다.

 

2. 취약점 진단

2.1) 가격 조작

[그림 2-1] 요청 패킷

프록시 설정 완료 인시큐어뱅크 파라미터 조작 취약점을 진단한다. 인시큐어뱅크 서버 IP 포트를 지정한 로그인을 시도한다. 로그인 시도 Transfer 버튼을 클릭해 버프스윗으로 요청 데이터 값들을 인터셉트한다. 인터셉트 파라미터 값으론 로그인 계정 파라미터를 포함해 5개가 존재한다.

 

[그림 2-2] DB 확인

인시큐어뱅크 서버 DB mydb.db 파일을 sqliteBrowser 도구를 이용해 확인해보면 555555555 금액은 777994437 저장되어 있고 888888888 금액은 98403 저장되어 있음을 확인할 있다.

 

[그림 2-3] 가격 조작

Transfer 시도 이체할 금액을 변조해서 데이터를 보낸다. 금액을 10000에서 1000으로 변조한 Intercept is on 버튼을 클릭한다.

 

[그림 2-4] ViewStatement

ViewStatement 탭을 클릭해서 변조해서 보낸 데이터를 확인하면 금액이 10000으로 이체되었다고 표시된다. 하지만 ViewStatement에서 표시되는 금액일 실제로는 1000 이체되었다.

 

[그림 2-5] DB 확인

sqliteBrowser 도구를 이용해 mydb.db 파일을 확인해보면 [그림 2-2] 달리 가격이 조금 변동되었음을 확인할 있다. 555555555 금액은 777995437, 888888888 금액은 97403으로 변동이 되었다. 처음 이체 시도 10000 보냈지만 파라미터 조작을 통해 1000으로 변조해 실제로는 1000 전송되었음을 확인할 있다.

 

2.2 CSRF 공격

[그림 2-6] 요청 패킷

CSRF 요청되는 값을 변조해서 공격하는 기법이다. 사용자가 특정 링크나 페이지에 접근했을 사용자도 모르게 요청값을 변조해 서버에 전달해서 중요 정보를 임의로 수정한다. Chanegepassword 페이지로 이동해 비밀번호를 변경할 패킷을 가로챈다.

 

[그림 2-7] Submit Form 클릭

만든 코드를 HTML 파일로 저장해 브라우저에서 실행한다. 실행 Submit Form 클릭한다.

 

[그림 2-8] 비밀번호 변경 확인

Submit Form 클릭하면 비밀번호가 변경되었다는 결과 메시지가 출력된다.

 

[그림 2-9] 인시큐어뱅크 서버 로그

인시큐어뱅크 서버 로그에서도 비밀번호가 변경되었다는 결과 메시지가 출력된다.

 

 

[그림 2-10] 로그인 시도

변경된 비밀번호인 Jack@123$% 로그인을 시도한다.

 

[그림 2-11] 로그인 성공

변경된 비밀번호를 이용해 로그인에 성공했음을 확인할 있다.

 

3. 대응 방안

[그림 3-1] 서버 코드

서버 코드에서 POST 메서드를 이용해 전달되는 매개변수를 처리하도록 코드가 구현 되어 있다. 단순히 데이터베이스 유저 이름과 매개변수의 유저 이름이 같으면 매개변수의 새로운 비밀번호를 저장하고, 변경 성공 메시지를 저장해 다시 응답값이 포함되도록 하고 있다.

 

 

[그림 3-2] 클라이언트 코드

ChangePassword.java 파일을 보면 입력 받은 값에 따라 조건을 주고 실행하고 있다. 먼저 httppost 변수에 매개변수를 포함시킬 URL 입력하고 유저 이름과 새로운 비밀번호를 변수로 저장한다. 입력된 비밀번호가 복잡한지 검증하고 합당하면 추가 변경 과정을 실행한다. 코드에선 비밀번호 복잡성은 검증 진행이 되고 있지만 매개변수를 암호화하거나 변경하는 페이지에 대한 추가 인증에 관련된 코드는 구현되어 있지 않다.

 

파라미터 조작은 가장 막기 힘든 취약점이다. 소프트웨어에 대한 입력값이 신뢰를 전제로 보호 메커니즘 구현 공격자가 입력값을 조작한다면 보호 매커니즘은 무의미하다. 소프트웨어를 개발할 기발자들이 모든 입력값에 대해 검증을 수행하는 것이 안전하다. 안전한 소프트웨어 개발을 위해 가장 먼저 모든 입력 값에 대한 검증을 "서버"에서 수행하고 상태 정보, 민감한 데이터, 사용자 세션 정보와 같은 중요한 정보들은 특히 "서버"에서 검증해야 한다.

 

 

반응형

'안드로이드 앱 취약점 진단 > 인시큐어뱅크' 카테고리의 다른 글

개발자 백도어 취약점  (0) 2021.09.19
애플리케이션 패칭 취약점  (0) 2020.04.15
취약한 액티비티 컴포넌트  (0) 2020.02.15
XSS 공격  (0) 2020.02.10
로컬 암호화 이슈  (0) 2020.02.09
블로그 이미지

만년필석사

,