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

1. Sequel Fun

- 페이지 소스 내 주석으로 ?source=1가 존재하며 접근할 경우 소스코드가 노출된다. 계정정보가 그대로 노출되지는 않지만 로그인하는 쿼리가 SQLi에 취약한 것으로 보였고 아이디와 패스워드에 1만 넣지 않으면 풀린다. 이에 따라 1이 아니라 true를 입력하여 solve하였다.

 - solve 요청

2. Roboworld

 - Flask 문제로 완벽하지 않은 소스코드를 제공해준다. 소스코드 내에 디버깅용 privkey가 존재하는데 해당 키를 가지고는 어떠한 문자열로도 모두 captchaVerify가 allow된다.

 - 아래 소스코드 일부를 보면 캡처 인증을 하는 요청을 볼 수 있는데 captchaUserValue 뒤에 privateKey가 나오게 되므로 HTTP Parameter Pollution을 통해 실제 제공된 privKey가 아닌 디버깅용 privKey를 통해 인증하도록 하면 시크릿페이지에 접근되고 그 중 mp4 파일을 열면 FLAG가 노출된다.

privKey = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" #redacted
    r = requests.get('http://127.0.0.1:{}/captchaVerify?captchaUserValue={}&privateKey={}'.format(str(port), captchaToken, privKey))
    #backdoored ;)))
    if username == "backd00r" and password == "catsrcool" and r.content == b'allow':
        session['logged'] = True
        return redirect('//redacted//')
    else:
        return "login failed"

- solve 요청

3. Rigged Election

 - 해당 문제는 vote.php의 g 파라미터가 존재할 때 총 6자리의 문자열이 설정되고 이후 h 파라미터의 값을 특정 문자열과 연결하여 md5한 결과의 앞 6자리가 이전에 얻은 6자리와 일치할 때까지 확인한다 .

 - 동일한 세션으로 해야해서 동시에 여러 요청을 보낼 수 없는데 코드를 짜서 돌리고는 있는데 이렇게 하는게 맞을까..?

4. X-MAS Helper

 - 개인 서버에 봇 추가 URL : https://discordapp.com/oauth2/authorize?clinet_id=[봇 ID]&scope=bot

 - 개발자 모드 활성화 : [사용자 설정 - 디스플레이 - 고급 - 개발자모드]

 - 개발자 모드 활성화 이후 봇 우클릭하여 봇 ID 획득 후 봇 추가를 한다. 이후 서버 설정에서 역할에 Organizer를 추가한 뒤 나에게 역할을 주고 !flag가면 Success

5. Execute No Evil

 - /* */는 보통 Multi-Line comment를 의미하는데 여기에 !를 사용하게 되면 실행가능한 주석이 된다. 이는 MySQL과 MariaDB에서만 가능하다. (검색 : executable comment )

 - 이후부터는 union을 이용하여 flag를 획득하면 된다.

1. 정의

(1) .[파일명].swp

 : swap-file로 현재 편집 중인 파일의 변경 내용을 저장하는 파일

 : 정상적으로 편집이 종료될 경우 해당 파일을 제거됨

(2) [파일명]~

 : 백업파일로써 backup이라는 옵션이 설정되어 있을 경우 파일에 변화가 생겼을 때 이전 데이터를 백업해 놓는 파일이다.

2. 실습

2.1 현재 설정 확인

 - vim 으로 임의의 파일을 열어 아래와 같은 명령어를 입력하면 현재 vim이 백업파일을 생성하는 옵션이 지정되어 있는지 확인할 수 있다.

- 아래의 경우 nobackup이라고 뜨는데 이는 현재 백업파일을 생성하지 않도록 설정되어 있다는 의미이다.

2.2. 백업파일을 생성하도록 설정 변경

 - 현재 편집중인 파일에 대해서 백업 파일을 생성하고 싶다면 :set backup 을 입력해주면 된다. 그 결과 저장하고 vim을 종료할 경우 변경된 파일과 백업 파일이 존재함을 알 수 있다.

 - 편집하는 모든 파일에 대하여 백업파일을 만들고 싶다면 아래와 같이 ~/.vimrc 파일에 set backup 을 지정해주면 된다.

3. 마무리

 - 실제 운영하는 웹 서비스의 경우 백업파일 혹은 swap-file을 통해 소스코드가 노출될 가능성이 존재하므로 모두 제거할 것을 권고한다.

1. HTTP 인증 설정

 (1) /etc/apache2/apache2.conf 내 AllowOverride를 None에서 AuthConfig 수정

 (2) [htpasswd -cb .htpasswd (아이디) (패스워드)] 명령어를 통해 .htpasswd 파일 생성

 (3) .htaccess 파일에 아래와 같이 입력

2. HTTP 인증 우회

 - 설정을 완료할 경우 아래와 같이 해당 디렉토리 내의 파일에 접근할 경우 로그인을 진행해야 한다.

 - 하지만 아래와 같이 지정되어있는 메소드가 아닌 Method로 요청을 보내면 인증을 우회하여 접근 불가능한 페이지에 접근이 가능하다.

3. 대응방안

 - /etc/apache2/apache2.conf 내 AllowOverride를 AuthConfig에서 All로 변경 (이후 service apache2 reload)

 - .htaccess 파일 내 아래의 내용을 추가해준다. 그 결과 GET과 POST를 제외한 다른 메소드의 경우 접근이 제한되어 Forbidden이 된다.

※ 에러 체크

만약 htaccess 설정하였는데 500 Internal Server Error가 뜰 경우는 apache2.conf의 AllowOverride가 수정되지 않았기 때문이다. All로 변경한 뒤 apache2 서비스를 reload해주어야 정상적으로 작동한다.

※ 참고

- https://httpd.apache.org/docs/2.4/mod/overrides.html

로그인을 위해서 일반적으로 아이디와 패스워드를 입력한다.

이를 서버 측으로 전달하여 데이터베이스에서 검증 이후 해당 사용자로 로그인을 진행하는데 이 때, 서버 측으로 패스워드를 평문으로 전달하게 된다면 악의적인 사용자가 중간에 가로채 정보가 유출될 가능성이 존재한다.

뿐만 아니라 주소, 이메일, 전화번호 등의 개인정보들이 네트워크 상에 평문으로 노출될 가능성이 존재한다.

이에 대해서는 두가지 대응방안이 존재한다.

1. HTTPS 통신

 - HTTPS 통신을 위해서는 인증된 기관에서 발급한 SSL 인증서가 필요하다. 하지만 일반적으로 SSL 인증서는 유료이기 때문에 작은 규모의 사이트나 개인 블로그 같은 경우는 도입하지 않는 경우가 일반적이다. 

 - 하지만 유료가 아닌 무료로 SSL 인증서를 발급받아 적용이 가능한 경우도 있다.

1) 자체 발급한 인증서

 - 자체 발급한 인증서의 경우 처음 접근 시 아래와 같은 경고창이 뜨며, 계속 탐색합니다 클릭 시 웹 서비스 이용이 가능하지만 여전히 주소창에는 발간색으로 [인증서 오류]가 노출된다.

2) 인증서 기관이 무료로 배포한 인증서

 - 개인적으로 추천하는 방식으로 HTTPS 사용을 권장하기 위해 무료로 배포하는 것으로 대표적으로 Let's Encrypt가 있다.

 - Let's Encrypt의 경우 모질라와 시스코 등 다수 굵직한 기업이 후원하는 것으로 믿을만하며 대표 사이트는 다음과 같다. ( https://letsencrypt.org/ko/ )

 - 설치 과정은 이미 다수의 블로그에서 다루고 있기 때문에 패스합니다.

2. 암호화

 - 만약 서버 측 제한 혹은 환경적인 제한으로 인해 HTTPS 적용이 힘들 경우 암호화를 통해 전송되는 데이터를 노출되지 않도록 할 수 있다.

 - 비밀번호같은 경우는 일반적으로 원본 데이터가 필요하지 않으므로 현재 가장 많은 분야에서 채택하여 사용되고 있는 암호 방식인 SHA256 혹은 그 이상의 알고리즘을 이용하여 Hash한 상태로 전송할 것을 권고한다.

 - 평문 데이터가 필요한 데이터의 경우는 복호화가 가능해야 한다. 복호화가 가능한 암호화 방식으로는 대표적으로 대칭형과 비대칭형 방식으로 나뉘는데 대칭형의 경우에는 암호화한 키를 통해 복호화가 이루어지기 때문에 보안적으로 안전하지 않다고 할 수 있다. 이에 따라 비대칭형 방식으로 암호화하기를 추천하며 대표적인 비대칭형 암호시스템으로는 RSA가 있다.

 - 다수의 고객사가 JSP로 이루어진 만큼 JAVA 기반으로 RSA 암호화를 적용하는 방법을 알아보았는데 개인적으로 권남님의 블로그(http://kwon37xi.egloos.com/4427199)가 잘 정리되어 있다고 생각한다.

 개인적으로 알아보며 정리한 것이니 잘못된 점이 있다면 댓글로 알려주시면 바로 확인하여 수정하도록 하겠습니다.

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

※ 참고

- 암호화 알고리즘 : https://naleejang.tistory.com/218

나는 HackCTF의 LOL 문제(https://rootable.tistory.com/entry/HackCTF-LOL)를 풀고  정확히 0.0.0.0이 무엇을 의미하는지 찾아보았다.

기존에 내가 알고 있던 0.0.0.0의 의미는 '모든 IP를 의미한다' 정도로만 알고 있었는데 왜 서버 측에서 0.0.0.0으로 접근하는데 local의 웹 서버로 접근이 되는지 이해가 되지 않았기 때문이다.

내가 참고한 글은 아래의 글이다.

https://www.howtogeek.com/225487/what-is-the-difference-between-127.0.0.1-and-0.0.0.0/

해당 글을 보면 다음과 같은 문구가 나온다.

In the context of servers, 0.0.0.0 means all IPv4 addresses on the local machine. If a host has two IP addresses, 192.168.1.1 and 10.1.2.1, and a server running on the host listens on 0.0.0.0, it will be reachable at both of those IPs

이 문구를 보면, 0.0.0.0은 local machine의 모든 IPv4 address를 의미하기 때문에 0.0.0.0로 접근하면 로컬 호스트의 모든 IPv4로 되어있는 호스트에 접근이 가능하다는 의미이다.

조금 더 설명을 붙이자면, 정확한 address가 할당되어 있지 않다면, 각각의 host는 그 address를 자신이라고 주장하게 되고 이에 따라 웹 서비스에서 0.0.0.0을 지정하면 자신의 IP를 그 address로 지정하게 되어 local로 접근이 되는 것이다.

그렇기 때문에 해당 문제에서 내가 0.0.0.0으로 요청을 하였을 때 해당 서버는 0.0.0.0를 자신의 IP로 변경하여 요청을 하였고 이에 따라 로컬로 인식되어 flag.php에 접근이 된 것이다.

자세한 내용을 보고 싶은 분들은 참고한 글을 정독하길 바란다.