반응형

그냥 휴대폰 번호 하나 알고 있을 뿐인데, 그 사람의 이름과 집 주소까지 바로 알 수 있다면?

영화에서나 볼 법한 일이 현실에서 벌어진다면 어떤 기분일까.

생각만 해도 끔찍하다.

이름이랑 집 주소가 알려진다고 해서 큰 문제가 되지 않을 것 같다고 생각할 수도 있다. 

 

하지만 조금만 더 생각해 보면 이런 정보들이 심각한 문제를 초래할 수 있다.

첫째, 피싱 공격. 공격자는 이름과 주소를 이용해 더욱 신뢰성 있는 피싱 메시지를 만들어낼 수 있다.

둘째, 사생활 침해. 이름과 집 주소를 통해 개인의 사적 정보가 조사될 수 있고, 특정 시간에 부재 중일 때를 노려 물리적 침입이나 스토킹으로 이어질 위험이 있다.

셋째, 스미싱 및 스팸. 주소와 이름 정보는 스미싱(SMS 피싱) 공격에 사용되거나, 정교한 스팸 메시지를 보내 신뢰감을 높이는 방식으로 악용될 수 있다.

넷째, 개인화된 공격. 범죄자는 이름과 주소 정보를 바탕으로 더욱 정교한 공격을 계획할 수 있다. 

특정 지역이나 직업에 맞춘 사기 행각을 벌이거나, 실제 범죄로 이어질 수 있는 시도를 할 가능성도 존재한다.

 

이처럼 영화 속 이야기가 현실이 된 세상에 우리는 살고 있다. 

 

그만큼 현재 사회는 너무나도 발전해 있고, 동시에 위험도 커지고 있다.

해당 취약점은 3년 전에 발견되었으며, 제보까지 했던 것으로 기억한다.

 

하지만 지금까지도 조치가 되지 않은 것 같다.

 

발견했던 취약점을 직접 공개할 수는 없지만, 짧게나마 영상을 만들어 봤다.

 

 

 

휴대폰 번호이름주소는 모두 모자이크 처리를 했다.

단지 휴대폰 번호 하나만 알아도 이렇게 위험한 세상이 되어버렸다.

 

이처럼 개인정보 유출의 위협은 우리가 생각하는 것보다 훨씬 더 현실적이고 위험하다. 

 

개인의 정보를 보호하는 데 있어 더 강력한 법적 조치와 경각심이 필요한 때인것 같다.

반응형

'개인 프로젝트' 카테고리의 다른 글

12. SRT 매크로  (6) 2024.10.29
11. 멜론 티켓팅 매크로  (0) 2024.10.17
10. YES24 티켓팅 매크로  (0) 2024.10.17
9. 인터파크 스포츠 티켓팅 매크로  (248) 2024.10.08
8. MOD 앱 (Royal Match) - Unlimited Moves  (0) 2024.07.17
반응형

모의해킹을 하다보면 JEB분석 툴을 사용하기 위해서는 자바가 필수적으로 필요하다.

 

따라서 진단 및 분석을 위해서는 자바를 꼭 설치해줘야한다.

 

또한 JDKJRE 아무꺼나 설치해도 상관없다.

 

하지만 JRE는 꼭있어야하니 JRE를 설치해보자.

 

설치를 해보자.

 

일단 공식 홈페이지에 가서 다운로드를 받아준다. (클릭)

 

그 후 Java SE Runtime Environment 항목에서

 

jre-8u281-windows-x64.exe를 검색해서 다운로드 받아주자.

 

 

다운로드된 파일을 실행하자.

 

실행한 후 대상 폴더 변경을 원하는 폴더에 변경해도되고 그냥 설치를 눌러 설치를 진행해도된다.

 

 

그렇게 쭉 설치를 완료하자.

 

완료 한 후 자바를 사용하기위해서는 환경변수를 등록을 해줘야한다.

 

환경변수를 등록하는 방법은 다음과 같다.

 

시스템 속성-환경변수를 클릭한다.

 

환경변수를 클릭한 후 시스템 변수Path를 찾아 더블클릭을 해준다.

 

 

그 후 새로 만들기를 눌러 자바가 설치된 경로를 적어준다.

 

꼭 bin까지 적어줘야한다.

 

 

그 후 확인을 누르면 환경변수 설정은 끝났다.

 

잘 실행되는지 보자.

 

cmd창에 java라고 입력하면 자바가 실행된다.

반응형
반응형

모의해킹을 하다보면 이든 이든 진단을 하기 위해서는 프록시는 필수다.

 

대표적으로 피들러 버프 많이 사용된다.

 

하지만 모바일을 진단할때는 피들러버프+피들러를 많이 사용한다.

 

먼저 피들러를 다운로드 받자. (클릭)

 

 

저기에 정보를 입력하고 Download for Windows 클릭해서 다운로드 받아주자.

 

 

그리고 그냥 설치 해주면된다.

 

설치가 끝나면 피들러를 실행 시키면 다음과 같은 화면을 볼 수 있다.

 

이처럼 밑에 Capturing을 볼 수 있는데 이것은 지금 웹 프록시가 작동중이다는것이다.

 

피들러가 켜진 상태로 네이버에 들어가보자

 

 

이렇게 20번째로 잡힌 패킷에서 URL이 네이버인것을 볼 수 있는데 해당 패킷을 더블 클릭하면

 

오른쪽에 웹 프록시에서 잡은 패킷을 볼 수 있다.

 

하지만 저렇게 노란색 문구로 HTTPS decryption이 불가능하다고 한다.

 

HTTPS 프로토콜은 암호화 프로토콜이기 때문에 제 3자가 볼 수 없다.

 

하지만 웹 프록시에서 나의 패킷을 볼 수가 있는데 이를 보기 위해서 인증서를 설치를 해주어야한다.

 

따라서 저기 노란색 문구를 클릭해서 피들러 인증서를 설치해보자.

 

 

위에서 Decryption HTTPS traffic을 체크하면 옆의 피들러의 인증서를 설치하겠냐고 묻는다.

 

Yes를 눌러주자.

 

또 Yes

 

 

또 또 Yes

또 또 또 Yes

또 또 또 또 Yes

 

이렇게 하다보면 이제 HTTPS 프로콜의 내용도 볼 수있다.

 

다시 네이버에 접속해보자.

 

 

이제 HTTPS 패킷의 내용도 볼 수 있게된다!

 

추가


 

 

그리고 만약에 브라우저에서 서버로 Requset할 때 패킷을 수정하고 싶으면 F11을 누르고 

 

패킷을 수정하면 된다.

 

 

또한 서버로 보내고 응답오는 Response 패킷을 수정하고 싶으면 Alt+F11을 누르고

 

Response 패킷을 수정하면 된다.

 

 

실제 문제에서 사용하는 예시는 여기(클릭)에 있다.

반응형

'기타' 카테고리의 다른 글

[Anaconda] Frida 설치  (0) 2022.01.23
[Java] 자바 JR 설치  (0) 2021.11.06
[Python] 파이참(Pycharm) 설치  (0) 2021.11.06
[Python] 아나콘다(Anaconda) 설치  (0) 2021.01.15
Apache 및 PHP 연동  (0) 2020.12.08
반응형

 


1. 문제 설명


 

 

이번 문제도 SQLi 문제이다.

 

문제를 클릭해보자.

 

문제를 클릭하면 다음과 같은 화면을 볼 수 있었다.

 

 

 

이게 뭐지?

 

done! (0/70)??

 

뭔가 시도 횟수를 의미하는것 같았다.

 

역시나 뭐 별 다른 기능이 없어 view-source를 클릭해서 소스코드를 보았다.

 

역시나 소스코드가 길었다.

 

이럴때는 하나하나 분석을 해야한다.

 

$agent=trim(getenv("HTTP_USER_AGENT"));

$ip=$_SERVER['REMOTE_ADDR'];

if(preg_match("/from/i",$agent))
{
  echo("<br>Access Denied!<br><br>");
  echo(htmlspecialchars($agent));
  exit();
}

 

먼저 getenv 함수를 사용해서 HTTP_USER_AGENT 값을 가져온다.

 

가져온 값에서 trim 함수를 이용해서 나온 값을 agent라는 변수에 담는다.

 

그럼 getenv 함수와 trim 함수를 알아보자.

 

 

getenv 함수는 위와과 같이 정의 되어있다.

 

getenv 함수는 환경 변수의 값을 가져오는 함수이다.

 

그리고 인자 값에 가져오고 싶은 환경 변수 값을 적어주는데

 

문제에서는 "HTTP_USER_AGENT"가 인자로 들어가있다.

 

HTTP_USER_AGENT웹 사이트를 접속한 컴퓨터의 웹 브라우저 정보를 의미한다.

 

다음은 trim 함수이다.

 

 

trim 함수는 whitespace공백strip 하는 함수이다.

 

하지만 문장 가운데 존재하는 공백이 아니라 처음 시작과 끝의 공백을 제거하는 함수이다.

 

예를 들어,  __hello__라는 문장이 있다고 가정하자.

 

 

하지만 trim 함수를 사용하면 처음 시작 2개의 공백과 끝의 2개의 공백을 제거하여

 

다음과 같은 문장이 나온다.

 

 

여기까지 정리하자면 접속한 웹 브라우저의 정보를 읽어와 앞 뒤 공백을 제거한다는 의미이다.

 

다음 코드는 $ip=$_SERVER['REMOTE_ADDR'] 인데

 

REMOTE_ADDR는 웹 사이트에 접속한 컴퓨터의 ip 주소를 가져온다.

 

그 다음 preg_match 함수가 또 보인다. (preg_match -> 클릭)

 

regexp 하는 역할을 하는데 agent라는 변수에 들어간 웹 브라우저 정보에서 from을 필터링한다.

 

다음 코드를 보자.

 

$db = dbconnect();

$count_ck = mysqli_fetch_array(mysqli_query($db,"select count(id) from chall8"));

if($count_ck[0] >= 70)
{ 
  mysqli_query($db,"delete from chall8"); 
}

$result = mysqli_query($db,"select id from chall8 where agent='".addslashes($_SERVER['HTTP_USER_AGENT'])."'");

$ck = mysqli_fetch_array($result);

 

웹 브라우저 정보에 "from"이라는 단어가 없으면 dbconnect 함수를 이용해서 db에 접속한다.

 

그 후 다음과 같은 쿼리로 DB에 쿼리를 날린다.

 

말 그대로 chall8이라는 테이블에 id의 갯수가 몇개있는지 묻는 쿼리이다.

 

그 후 countid의 갯수를 count_ck라는 변수에 넣고

 

count_ck70개 이상이면 chall8 테이블을 삭제한다.

 

만약에 70개 미만이면 코드가 밑으로 내려와 DB에 다음과 같은 쿼리로 묻는다.

 

 

위의 쿼리의 의미를 해석 하기 전에 addslashes 함수에 대해서 알아보자.

 

addslashes 함수에 대한 설명은 여기에 자세히 설명이 되어있다. (클릭)

 

$_SERVER['HTTP_USER_AGENT']유저의 브라우저 접속환경을 의미한다.

 

브라우저 접속환경이 왜필요할까?

 

서버의 입장에서는 브라우저별로 스타일을 다르게 보여지게 하거나 필요한 동작이 다를 수 있다.

 

무튼 다시 쿼리문을 정리하자면 다음과 같이 정리할 수 있다.

 

 

그럼 해석 해보자면 chall8이라는 테이블에서 어떤 사용자의 user_agent 값이 있다면

 

user_agent 값을 가지는 id를 보여달라는것이다.

 

만약 나의 idtest이고 user_agent값이 123123이라면

 

chall8이라는 테이블에서 agent의 값이 123123id는 누구냐라는 의미이다.

 

쿼리상 문제가 없으면 id값(test)이 이제 ck라는 변수에 들어가게된다.

 

다음 코드를 보자.

 

if($ck)
{
  echo "hi <b>".htmlentities($ck[0])."</b><p>";
  
  if($ck[0]=="admin")
  {
    mysqli_query($db,"delete from chall8");
    solve(8);
  }
}

if(!$ck)
{
  $q=mysqli_query($db,"insert into chall8(agent,ip,id) values('{$agent}','{$ip}','guest')") or die("query error");
  echo("<br><br>done!  ({$count_ck[0]}/70)");
}

 

ck 변수에 이제 값(id)이 있다면 누구인지 echo 함수를 이용해서 알려주고

 

만약에 admin이라면 chall8이라는 테이블을 삭제 시킨 후

 

solve(8)이라는 함수를 실행 시키면서 문제를 clear 할 수 있다.

 

하지만 ck라는 변수 즉 user_agent로 조회를 했을때 id가 없다면 insert 함수를 이용해서

 

chall8이라는 테이블에 agent, ip, id 값을 각각 넣어준다.

 

여기까지 정리하면 다음과 같다.

 

해당 문제는 idadmin으로 맞춰줘야지만 solve(8) 함수를 실행시킬 수 있다.

 

그렇기 위해서는 adminuser_agent 값을 알아야한다.

 

그 이유는 id를 뽑기 위해서는 밑의 쿼리를 사용해야하기 때문이다.

 

 

하지만 우리는 adminuser_agent 값을 모른다.

 

아니면 chall8이라는 테이블에 admin이라는 id를 가진 값이 없을 수도 있다.

 

따라서 adminuser_agent 값을 알아내던, chall8이라는 테이블에 idadmin을 생성해줘야할것같다.

 


2. 문제 풀이


 

이번 문제를 풀기 위해선 2개의 가정을 생각해보았다.

  1. chall8이라는 테이블에 id가 admin이 있을 경우 -> admin의 user_agent 값을 알아내야함 or 우회
  2. chall8이라는 테이블에 id가 admin이 없을 경우 -> chall8에 id가 admin을 insert 해야함

위의 처럼 정리 해보았다.

 

확률상 1번일 확률은 적다고 생각했다.

 

왜냐하면 php 코를 봤을 때 adminuser_agent를 알아내기 위한 방법이 현재로써는 보이지 않았다.

 

따라서 2번의 가정으로 문제를 풀어봤다.

 

그 이유는 php 코드를 봤을때 아래의 그림처럼 insert문이 존재했기 때문이다.

 

 

그리고 insert에서 사용자의 입력이나 값이 들어가는곳은 2곳이다.

 

agentip이다.

 

ip는 서버에 접속한 클라이언트의 ip를 $ip=$_SERVER['REMOTE_ADDR']로 설정하기 때문에

 

ipSQLi를 하기는 어렵다고 생각하고 agent 변수에 

 

즉, user-agent 값을 수정해서 insert문을 이용해서 id가 'guest'가 아닌 'admin'으로 수정하려고한다.

 

user-agent 값을 수정하기 위해서는 web-proxy를 사용해야한다.

 

이렇게 웹 프록시로 보면 User-Agent에 접속한 브라우저나 환경 값들이 들어가 있다.

 

여기에 SQLi를 수행할것이다.

 

먼저 SQLi가 잘 먹히는지 확인하기 위해

 

프록시를 사용하여 User-Agentguest01이라고 입력하고 서버로 전송해보자.

 

 

 

chall8 테이블에 guest01이라는 user-agent값이 없으니 아래의 SQLiinsert할것이다.

 

그렇다면 다시 guest01를 그대로 user-agent 값에 넣어서 서버로 전송하면 어떻게 될까?

 

chall8guest01이 라는 user-agentinsert 되었기 때문에 "hi guest"라는 문구를 볼 수가 있다.

 

그렇다면 이제 user-agent를 변경해서 insert가 되는것을 확인했으니

 

chall8에 존재하지않는 user-agent 값과 뒤의 'guest' 부분을 'admin'으로 바꿔주고

 

다시 insert 했을때 사용했던 user-agent 값으로 변경하여 서버로 전송하면

 

"hi guest"가 아닌 admin이 될것이다.

 

페이로드는 다음과 같다.

 

이렇게 SQL문을 만들 수 있다.

 

뒤에 #이라고 넣어준 이유는 뒤에 남아 있는 원래의 SQL문을 주석 처리하기 위함이다.

 

 

이렇게 SQL문을 만들었으면 이제 직접 프록시를 이용하여 작성한 페이로드를 넣어보자.

 

 

guest02라는 새로운 user-agent 값과 아이피 주소, 그리고 guest가 아닌 admin을 넣어준다.

 

 

 

그 후 정상적으로 chall8이라는 테이블에 등록되었다는 done!이라는 문구를 볼 수 있다.

 

다시 guest02로 요청을 한다.

 

 

요청을 하게 되면 서버에서 clear 했다는 문구를 볼 수 있다.

 

 

반응형

'웹 해킹 > Webhacking.kr' 카테고리의 다른 글

10. old-10  (0) 2021.11.08
9. old-09  (0) 2021.11.08
7. old-07  (0) 2021.11.04
6. old-06  (0) 2021.11.03
5. old-05  (0) 2021.11.01
반응형

 

이번 문제는 아마 코딩으로 푸는 문제인 것 같다.

 

이제 저 모양이 어떤 문제를 의미하는지 알 것 같다.

 

문제를 클릭해보자.

 

 

클릭하면 view-sourceID: guest, PW: 123qwe가 보인다.

 

입력하는 폼과 URL에 파라미터도 보이지 않기 때문에 view-source를 클릭하여 힌트를 찾아보자.

 

클릭하면 엄청나게 긴 PHP 코드가 나온다.

 

코드는 다음과 같다.

 

<?php
include "../../config.php";
if($_GET['view_source']) view_source();
if(!$_COOKIE['user']){
  $val_id="guest";
  $val_pw="123qwe";
  for($i=0;$i<20;$i++){
    $val_id=base64_encode($val_id);
    $val_pw=base64_encode($val_pw);
  }
  $val_id=str_replace("1","!",$val_id);
  $val_id=str_replace("2","@",$val_id);
  $val_id=str_replace("3","$",$val_id);
  $val_id=str_replace("4","^",$val_id);
  $val_id=str_replace("5","&",$val_id);
  $val_id=str_replace("6","*",$val_id);
  $val_id=str_replace("7","(",$val_id);
  $val_id=str_replace("8",")",$val_id);

  $val_pw=str_replace("1","!",$val_pw);
  $val_pw=str_replace("2","@",$val_pw);
  $val_pw=str_replace("3","$",$val_pw);
  $val_pw=str_replace("4","^",$val_pw);
  $val_pw=str_replace("5","&",$val_pw);
  $val_pw=str_replace("6","*",$val_pw);
  $val_pw=str_replace("7","(",$val_pw);
  $val_pw=str_replace("8",")",$val_pw);

  Setcookie("user",$val_id,time()+86400,"/challenge/web-06/");
  Setcookie("password",$val_pw,time()+86400,"/challenge/web-06/");
  echo("<meta http-equiv=refresh content=0>");
  exit;
}
?>
<html>
<head>
<title>Challenge 6</title>
<style type="text/css">
body { background:black; color:white; font-size:10pt; }
</style>
</head>
<body>
<?php
$decode_id=$_COOKIE['user'];
$decode_pw=$_COOKIE['password'];

$decode_id=str_replace("!","1",$decode_id);
$decode_id=str_replace("@","2",$decode_id);
$decode_id=str_replace("$","3",$decode_id);
$decode_id=str_replace("^","4",$decode_id);
$decode_id=str_replace("&","5",$decode_id);
$decode_id=str_replace("*","6",$decode_id);
$decode_id=str_replace("(","7",$decode_id);
$decode_id=str_replace(")","8",$decode_id);

$decode_pw=str_replace("!","1",$decode_pw);
$decode_pw=str_replace("@","2",$decode_pw);
$decode_pw=str_replace("$","3",$decode_pw);
$decode_pw=str_replace("^","4",$decode_pw);
$decode_pw=str_replace("&","5",$decode_pw);
$decode_pw=str_replace("*","6",$decode_pw);
$decode_pw=str_replace("(","7",$decode_pw);
$decode_pw=str_replace(")","8",$decode_pw);

for($i=0;$i<20;$i++){
  $decode_id=base64_decode($decode_id);
  $decode_pw=base64_decode($decode_pw);
}

echo("<hr><a href=./?view_source=1 style=color:yellow;>view-source</a><br><br>");
echo("ID : $decode_id<br>PW : $decode_pw<hr>");

if($decode_id=="admin" && $decode_pw=="nimda"){
  solve(6);
}
?>
</body>
</html>

 

핵심 코드들을 분석해보자.

 

if(!$_COOKIE['user'])
{
  $val_id="guest";
  $val_pw="123qwe";
  
  for($i=0;$i<20;$i++)
  {
    $val_id=base64_encode($val_id);
    $val_pw=base64_encode($val_pw);
  }
  
  .....
  
}

 

먼저 $val_id 변수에 "guest"$val_pw"123qwe"로 초기화시켜준다.

 

이것은 문제를 클릭하였을 때 볼 수 있었던 것과 동일하다.

 

그 후 for문으로 20번 id와 pw를 즉, "guest"와 "123qwe"를 base64 encode를 수행한다.

 

for문이 끝나면 "guest", "123qwe" 이 두 값을 20번 base64 encode 값이 들어가 있다.

 

공부하는 김에 base64가 먼지 짧게 알아보고 가자.


Base64

 

먼저 인코딩(encoding)이란, 파일에 저장된 정보의 형태나 형식을 데이터 표준화, 보안, 처리 속도 등을 위해 다른 형태로 변환하는 과정을 말한다.

 

특히 이메일, 동영상, 이미지 영역에서 많이 사용되며, 반대로는 디코딩(decoding)이라고 한다.

 

그중 Base64도 인코딩의 한 종류이며 말 그대로 64진법이라는 뜻이다.

 

쉽게 말해 데이터를 64진법으로 표현하는 방식이다.

 

2진법은 0,1로 2가지, 10진법은 0~9까지 10가지로 64진법은 총 64개로 표현이 가능하다.

즉 , 6bit로 문자 한 개를 표현할 수 있다는 의미이다.

 

따라서 8bit의 데이터(바이너리)를 6bit의 크기로 표현한다는 의미이고

 

24bit(3byte)를 단위로 하여 3개의 문자에서 4개의 문자를 얻게 된다.

 

이렇게 되면 3개의 문자에서 4개의 문자로 데이터의 양이 많아진다.

 

그럼 데이터의 양이 증가하는 데 사용하는 이유가 뭘까?

 

바로 통신과정에서 바이너리 데이터의 손실을 막기 위해서 사용한다.

 

간단한 예로 바이너리 파일의 원본 파일이 1,000byte가 있지만 이 데이터를 string 형태로 저장하면

 

1,406byte로 저장된다.

 

반대로 string 형태가 아닌 binary로 저장하면 1,000byte가 그대로이다.

 

이는 char 데이터는 non-signed 1byte : 양의 정수 (0~255 표현)

 

​byte 데이터는 signed 1byte : 정수 (-128~127 표현)

 

즉 표현할 수 있는 데이터의 범위를 넘어서 데이터 손실이 일어나는 것이다.


따라서 이렇게 데이터의 손실을 막고 안전하고 정확하게 데이터를 전송하기 위해 Base64를 많이 사용한다.


다시 본론으로 돌아와 다음 코드를 보자.

 

위에서 20번 base64를 돌린 값을 replace 해주는 방식이다.

 

예를 들어 20번 돌린 base64 값에 1이 있으면 !로, 2가 있으면 @로 replace 해주는 코드이다.

 

val_pw로 마찬가지다.

 

....

  $val_id=str_replace("1","!",$val_id);
  $val_id=str_replace("2","@",$val_id);
  $val_id=str_replace("3","$",$val_id);
  $val_id=str_replace("4","^",$val_id);
  $val_id=str_replace("5","&",$val_id);
  $val_id=str_replace("6","*",$val_id);
  $val_id=str_replace("7","(",$val_id);
  $val_id=str_replace("8",")",$val_id);
  
 ....

 

그다음 아래의 코드를 볼 수 있는데 Setcookie 함수를 이용해서

 

"user"라는 쿠키명에 replace를 거친 값을 넣어주는 것이다.

 

마찬가지로 "password" 쿠키명에 replace를 거친 값을 넣어준다.

 

....

  Setcookie("user",$val_id,time()+86400,"/challenge/web-06/");
  Setcookie("password",$val_pw,time()+86400,"/challenge/web-06/");
  
 ....

 

그럼 그렇게 쿠키값이 있는지 확인해보자.

 

 

위의 쿠키 값을 URL-decoding을 하고 보면 replace가 된 @를 볼 수 있다.

 

 

이처처럼 20번의 base64 econdingreplace가 잘 수행된 것을 확인할 수 있다.

 

다음 코드를 보자.

 

....

$decode_id=$_COOKIE['user'];
$decode_pw=$_COOKIE['password'];

....

 

아까 그림에서 확인한 user라는 쿠키 값과 pwassword라는 쿠키 값을

 

각각 decode_iddecode_pw에 초기화한다.

 

....

$decode_id=str_replace("!","1",$decode_id);
$decode_id=str_replace("@","2",$decode_id);
$decode_id=str_replace("$","3",$decode_id);
$decode_id=str_replace("^","4",$decode_id);
$decode_id=str_replace("&","5",$decode_id);
$decode_id=str_replace("*","6",$decode_id);
$decode_id=str_replace("(","7",$decode_id);
$decode_id=str_replace(")","8",$decode_id);

$decode_pw=str_replace("!","1",$decode_pw);
$decode_pw=str_replace("@","2",$decode_pw);
$decode_pw=str_replace("$","3",$decode_pw);
$decode_pw=str_replace("^","4",$decode_pw);
$decode_pw=str_replace("&","5",$decode_pw);
$decode_pw=str_replace("*","6",$decode_pw);
$decode_pw=str_replace("(","7",$decode_pw);
$decode_pw=str_replace(")","8",$decode_pw);

....

 

처음 replace는 숫자를 문자로 replace 하였지만 지금은 다시 문자를 숫자로 replace 해준다.

 

....

for($i=0;$i<20;$i++)
{
  $decode_id=base64_decode($decode_id);
  $decode_pw=base64_decode($decode_pw);
}

....

 

그 후 for문으로 20번 decode준 값을 $decode_id$decode_pw에 초기화해준다.

 

이러면 원래의 평문이 나올 것이다.

 

....

echo("<hr><a href=./?view_source=1 style=color:yellow;>view-source</a><br><br>");
echo("ID : $decode_id<br>PW : $decode_pw<hr>");

if($decode_id=="admin" && $decode_pw=="nimda")
{
  solve(6);
}

....

 

그 후 echo로 decoding 된 평문의 IDPW를 출력해준다.

 

이때 출력하는 ID와 PW가 "admin", "nimda"이면 solve(6)이 실행되면서 이번 문제를 clear 할 수 있다.

 

여기까지 무리 없이 이해가 되었다면

 

user와 password 값에 admin, nimda를 20번 encoding 한 후

 

replace 한 값을 쿠키 값에 넣어주고 새로고침을 하면 문제를 해결할 수 있을 것 같다.

 

그런데 조금만 생각해보면 replace는 안 해도 된다.

 

어차피 replace로 원래의 "admin", "nimda" base64 값을 구하기 때문에 

 

그냥 "admin", "nimda" 값을 base64 encoding을 20번 값을 쿠키값에 넣으면 된다.

 

바로 코드를 작성해보자.

 

 

코드는 이처럼 짧다.

 

나온 값을 쿠키에 넣고 새로 고침을 하면 

 

 

ID와 PW에 "admin", "nimda"가 출력되면서 6번 문제를 해결할 수 있다.

 

반응형

'웹 해킹 > Webhacking.kr' 카테고리의 다른 글

8. old-08  (0) 2021.11.05
7. old-07  (0) 2021.11.04
5. old-05  (0) 2021.11.01
4. old-04  (0) 2021.11.01
3. old-03  (0) 2021.10.19
반응형

 

문제를 보면 다음과 같이 또 DB 모양이 있다.

 

이번 문제도 SQLi 문제일까? 하는 생각에 문제를 클릭해보자.

 

 

문제를 클릭하면 다음과 같이 LoginJoin 창이 보인다.

 

Login을 눌러보자.

 

 

Login을 눌르면 이렇게 IDPW를 입력하는 창이 나온다..

 

별다른 정보가 없기 때문에 페이지 소스를 보았다.

 

 

페이지 소스 보기를 봐도 별 다른 정보가 없어서 test/test를 입력해보았다.

 

 

 

test/test을 입력하고 login을 클릭한 결과 Wrong password라는 문구와 함께 다시 login 폼이 보인다.

 

IDPW를 알아내기 위해 IDPWSQLi를 수행보았지만 별다른 반응이 없었다.

 

따라서 이번 문제를 풀기 위해서는 계정을 알아야할것같았다.

 

따라서 제일 처음으로 돌아와 Join을 눌러보았다.

 

 

Join을 눌러 보니 Access_Denied이라는 문구와 함께 Join을 할 수 없게 되어있다.

 

페이지 소스에서도 아무런 정보도 찾을 수도 없고, ID, PWSQLi도 안먹히고..

 

그 다음 할 것이 없어 URL 주소를 보았다.

 

로그인 화면의 URL은 다음과 같다.

 

https://webhacking.kr/challenge/web-05/mem/login.php

 

우리는 할 수 있는 시도를 다 해보았고 문제에 힌트가 될 정보가 없기 때문에

 

https://webhacking.kr/challenge/web-05/mem를 입력하여

 

디렉토리 인덱스 취약점이 있는지 살펴보았다. 

 

여기서 말하는 디렉토리 인덱스 취약점을 짧게 정리하면 다음과 같다.


웹 애플리케이션을 사용하고 있는 서버의 미흡한 설정으로 인해 인덱싱 기능이 활성화 되어 있을 경우

공격자가 강제 호출을 통해 서버내의 모든 디렉터리 및 파일에 대해 접근이 가능하며

웹 애플리케이션 및 주요 정보가 노출될수 있는 취약점이다.


https://webhacking.kr/challenge/web-05/mem를 입력하니 디렉토리 인덱스 취약점이 발견되었다.

 

 

여기서 우리가 원하는 페이지인 join.php 페이지를 볼 수 있다.

 

join.php 페이지를 클릭해보자.

 

 

클릭하니 bye라는 문구와 함께 검은색 창만 보인다.

 

뭐지??하고 맨날 보았던 페이지 소스를 보았다.

 

 

script 태그에 이상한 script가 존재하였다.

 

원래의 보통의 script가 아니였기 때문에 이게 힌트일 것 같았다.

 

HTMl 소스코드를 가독성 있게 보면 다음과 같다.

 

<html>
<title>Challenge 5</title>
</head>

<body bgcolor=black>
<center>
<script>
l='a';
ll='b';
lll='c';
llll='d';
lllll='e';
llllll='f';
lllllll='g';
llllllll='h';
lllllllll='i';
llllllllll='j';
lllllllllll='k';
llllllllllll='l';
lllllllllllll='m';
llllllllllllll='n';
lllllllllllllll='o';
llllllllllllllll='p';
lllllllllllllllll='q';
llllllllllllllllll='r';
lllllllllllllllllll='s';
llllllllllllllllllll='t';
lllllllllllllllllllll='u';
llllllllllllllllllllll='v';
lllllllllllllllllllllll='w';
llllllllllllllllllllllll='x';
lllllllllllllllllllllllll='y';
llllllllllllllllllllllllll='z';
I='1';
II='2';
III='3';
IIII='4';
IIIII='5';
IIIIII='6';
IIIIIII='7';
IIIIIIII='8';
IIIIIIIII='9';
IIIIIIIIII='0';
li='.';
ii='<';
iii='>';

...... 생략 ........

</script>
</body>

</html>

 

뭔가 딱 보자마자 바로 느낌이 왔다.

 

치환이다!!

 

예를 들어보자.

 

l='a';

 

말 그대로 l은 a이다. 

 

생략한 코드를 치환하면 다음과 같다.

 

<html>
<title>Challenge 5</title></head><body bgcolor=black><center>
<script>


...... 생략 ........

if(eval(document.cookie).indexOf(oldzombie)==-1) 
{
    alert('bye');
    throw "stop";
}

if(eval(document.'U''R''L').indexOf(mode'='+1)==-1)
{
    alert('access_denied');
    throw "stop";
}

else
{
    document.write('<font size=2 color=white>Join</font><p>');
    document.write('.<p>.<p>.<p>.<p>.<p>');
    document.write('<form method=post action='join.php'>');
    document.write('<table border=1><tr><td><font color=gray>id</font></td><td><input type=text name='+id+' maxlength=20></td></tr>');
    document.write('<tr><td><font color=gray>pass</font></td><td><input type=text name='+pw+'></td></tr>');
    document.write('<tr align=center><td colspan=2><input type=submit></td></tr></form></table>');
}
</script>
</body>
</html>

 

이렇게 위의 코드처럼 치환하면 문제를 풀 수 있을 듯하다.

 

코드를 분석해보자.

 

 

위의 코드는 현재 cookie값 중에 oldzombie 라는 값이 있는지 체크하는것이다.

 

즉, 현재 cookie값 중에 oldzombie가 없다면 bye라는 문구와 함께 alert창을 볼 수 있다.

 

따라서 먼저 이 부분을 우회를 해야할것같다.

 

따라서 cookie 이름은 test, 값은 oldzombie를 설정하는 명령어로 cookie값을 설정해보았다.

 

 

그리고 다시 join.php 페이지에 접속해보았다.

 

 

아까와는 달리 access_denied라는 문구를 볼 수 있다!!

 

그럼 그 아래의 코드 또한 우회 해주면 된다!!

 

document.URL 값은 다음과 같이 'https://webhacking.kr/challenge/web-05/mem/join.php' 값이다.

 

 

근데 위의 소스코드에서는 oldzombie처럼 mode=1이 있는지 확인하는것이다.

 

따라서 https://webhacking.kr/challenge/web-05/mem/join.php/mode=1를 입력해보았다.

 

 

이처럼 Join 할 수 있는 폼이 생겼다.

 

여기서 JoinIDPW를 입력하고 제출 버튼을 눌러보자.

 

 

 

이제 Login.php에 접속해서 가입한 정보로 로그인을 해보자!

 

 

이렇게 로그인은 된다.

 

하지만 admin이 아니라는 문구가 뜬다.

 

따라서 이 문제의 출제 의도는 admin으로 로그인을 해야 한다는 것이다.

 

그럼 다시 Join.php에서 admin으로 가입해보자.

 

 

 

????

 

이미 admin이라는 계정이 존재한다.

 

하지만 이번 문제는 admin으로 로그인을 해야 한다.

 

앞에서 로그인 화면에선 SQLi가 통하지 않았기 때문에 이번 문제는 Join.php에서

 

admin으로 가입을 해야한다.

 

가입할때의 패킷을 보자.

 

다음과 같다.

 

id와 pw라는 파라미터로 입력한 admin123POST 형식으로 서버로 넘어간다.

 

예전에 학교 다닐때 DB에 저장될때 띄어쓰기나 공백이 들어가면 저장되는 형태에 따라서

 

'admin'과 'admin '이 같다는걸 배운적이 있다.

 

따라서 id값에 'admin' 대신 'admin '로 서버로 보내봤다.

 

그 후 로그인을 해보았다.

 

 

기억을 더듬어 문제는 풀었는데 정확하게 기억이 나지 않아서 찾아보았다.

 

https://techblog.woowahan.com/2559/ 여기서 정말 자세히 설명이되어있다.

 


쉽게 정리하자면 mysql DB에서는 'a'와 'a ' 또는 ' a'는 같다라고 인식을 한다.

 

즉, 공백이 있어도 같은 문자나 문자열이라고 인식을 한다는것이다.

 

하지만 이건 DB에 저장될때의 자료형이 CHAR일때만 가능하다.

 

비교하려는 두 문자열의 길이가 다른 경우

 

짧은 쪽에 공백을 이어붙여 길이를 똑같이 만든 다음 비교하기 때문에 발생하는 일이다.

 

이런 식이라면 'admin'와 'admin  '를 비교해도 똑같을 수밖에 없다.


반응형

'웹 해킹 > Webhacking.kr' 카테고리의 다른 글

7. old-07  (0) 2021.11.04
6. old-06  (0) 2021.11.03
4. old-04  (0) 2021.11.01
3. old-03  (0) 2021.10.19
2. old-02  (0) 2021.10.18
반응형

첫번째 문제는 php로 되어있었다.

 

두번째 문제는 DB 그림이 존재하는것으로 보아.

 

 

SQLi 공격을 이용해야할듯하다. (이것 또한 힌트일 수 있다.)

 

2번째 문제를 클릭해서 들어가보면 다음과 같은 문구를 볼 수 있다.

 

 

근데 이게 전부???

 

아무런 기능이 없다...

 

따라서 할 수 있는거는 페이지 소스라도 봐야한다.

 

페이지 소스를 보니 주석으로 admin.php라는 페이지가 있다고 친절하게 알려준다.

 

따라서 https://webhacking.kr/challenge/web-02/admin.php에 에 접속해보자. 

 

접속하면 다음과 같이 볼 수 있을것이다.

 

 

패스워드를 입력하라고한다.

 

여기서도 마찬가지로 페이지 소스를 보았다.

 

위의 페이지 소스를 보아하니 여기서는 딱히 얻을 힌트는 없어 보인다.

 

따라서 처음 문제에서 힌트(DB)를 얻었던것을 생각해 SQLi를 수행보았다.

 

하지만 아무런 반응을 볼 수 없었다.....

 

따라서 다시 처음으로...

 

아무리 생각해도 패스워드를 입력하는곳에서 SQLi를 수행하는것이 맞는거같은데... 하면서

 

혹시 몰라서 쿠키값을 보았다.

 

 

쿠키값을 보니 현재 timestamp가 적혀있다.

 

timestamp값을 알아보니 처음 페이지 소스보기에서 주석처리로 되었던 시간과 똑같이 적혀있었다.

 

따라서 쿠키값을 임의의 숫자인 123456789를 입력하고 다시 페이지 소스보기를 눌러보았다.

 

 

그러니 다음과 같이 페이지 소스에 시간이 반영이 되었다.

 

따라서 여기서 힌트를 얻었다. (Attack Vector)

 

힌트를 조금 알기쉽게 풀어 설명하면,

 

time이라는 쿠키값에 시간이나 어떤 값을 입력하면

 

페이지 소스보기의 시간을 출력(서버의 반응)을 볼 수 있다는 것이다.

 

여기까지의 내용으로 정리하고 가정을 세워보면 다음과 같다.

  1. 해당 문제의 그림에서 DB가 나왔기 때문에 해당 문제는 SQLi를 이용해야한다.
  2. 하지만 어디에서 SQLi가 발생하는지는 알 수 없다.
  3. 패스워드를 입력하는곳에 SQLi 공격을 수행해보았지만 딱히 별다른것이 없다.
  4. time이라는 쿠키값에 사용자가 입력한 timestamp가 반응을 보인다.
  5. time이라는 쿠키값을 가지고 SQLi를 수행해본다.

먼저 true, false 반응이 나오는지 보기 위해서

 

원래의 timestamp 뒤에 and 1and 0을 삽입하여 페이지 소스 보기 살펴보자.

 

예를들어 현재 기준으로 1634532456라는 time이 나와있을때는 참이다.

 

왜냐? 서버에서 미리 쿠키값을 설정했기때문이다.

 

따라서 1634532456 and 1을 넣었을때 이면 페이즈 소스 보기에서의 시간이 나오는 주석에는

 

2021-10-18 01:47:36가 보일것이고 1634532456 and 0,

 

false일때는 2021-10-18 01:47:36가 아닌 다른 값이 나와야한다.

 

만약 1634532456 and 0가 false인데도 2021-10-18 01:47:36가 나온다면

 

true/false를 알 수 없기 때문에 다른 방법으로 찾아봐야할것이고

 

SQLi 공격으로 푸는 문제가 아닐 수 있다.

 

그럼 time이라는 쿠키에 1634532456 and 1를 넣어보자.

 

 

예상했던거와 달리 1634532456 and 1(true)를 입력하니 2021-10-18 01:47:36가 나오지 않고

 

2070-01-01 09:00:01가 나왔다.

 

????

 

그럼 1634532456 and 0(false)인 경우일 때는 어떤지 보자.

 

 

이번에는 2070-01-01 09:00:01이 아니라 2070-01-01 09:00:00가 나왔다.

 

그럼 여기까지 정리를 해보면 true(참)일 경우에는 2070-01-01 09:00:01이 나오고 

 

false(거짓)일 경우에는 2070-01-01 09:00:00이 나온다.

 

그렇다면 time이라는 곳에 timestamp 값 말고 1=1, 1=0 true, false를 입력해도 값을까?

 

넣어보니 같았다. (Point 1)

 

따라서 이것을 기준으로 삼아 SQLi를 수행해보자. 

 

먼저 패스워드를 알려면 DB명도 알아야하고 table 명도 알아야하고 column명도 알아야 하고

 

각각의 이름을 알려면 길이 또한 알아야한다.

 

따라서 갈길이 먼것같다. 그리고 이렇게 푸는게 아직 맞는지도 모르겠다.

 

DB명을 알아내는것으로 해당 문제가 쿠키값에서 SQLi를 진행하는지

 

또한 2번 문제가 SQLi로 푸는건지 판단할 수 있을것 같다. 

 

일단 해보자.

 

일단 DB 길이를 알아내기 위해서 length(database())=DB 길이를 이용할 것이다.

 

EditThisCookie에 하나 하나 대입하는것보다 그냥 코드로 짜서 돌리는게 편할것같아 코드로 돌려버렸다.

 

코드로 DB의 길이를 알아보니 6자리임을 알 수 있었다.

 

자리수를 알아냈으니 DB명을 알아보자.

 

코드를 작성해서 알아본 결과 DB명은 다음과 같이 chall2라는것을 알 수 있다.

 

DB명을 알아냈으니 이제 테이블 구조를 살펴보자.

 

먼저 chall2이라는 DB에 몇개의 테이블이 있는지 테이블의 길이를 구해보자.

 

테이블 길이와 테이블 명, column 길이와 명을 알아내는 방법은 여기(클릭)에 가서 참고하자!

코드를 작성한 결과 0번째 테이블의 길이 즉, 첫번째 테이블은 13자리, 2번째 테이블 길이는 3개이다.

 

나머지는 1로 보아 1번째, 2번째 테이블에 우리가 원하는 패스워드 값이 있을것이라고 추측해본다.

 

따라서 먼저 첫번째 13자리의 테이블명을 알아보자.

 

13자리의 테이블명은 admin_area_pw이다.

 

여기에 우리가 원하는 패스워드가 있을것같다.

 

테이블 명을 알았으니 이제 admin_area_pw의 존재하는 column갯수길이이름을 알아야한다.

 

먼저 column의 갯수는 1개이다.

 

길이는 2자리이다. (뭔가 느낌상 column명이 pw인것 같다.)

 


역시 코드를 작성해서 실행해본 결과 컬럼명이 pw로 나왔다.

 

이제 해당 pw를 알아내면 끝이다!!

 

pw를 알아내기 위해서는 길이를 먼저 알아야한다.

 

이렇게 총 길이는 17자리이다.

 

이제 pw의 값을 알아보자!

 

코드를 작성해서 돌려본 결과 다음고 같이 pw값이 나왔다.

 

위의 pw값을 https://webhacking.kr/challenge/web-02/admin.php에 입력해보자. 

 

 

반응형

'웹 해킹 > Webhacking.kr' 카테고리의 다른 글

6. old-06  (0) 2021.11.03
5. old-05  (0) 2021.11.01
4. old-04  (0) 2021.11.01
3. old-03  (0) 2021.10.19
1. old-01  (0) 2021.10.18
반응형

먼저 old-01 문제를 클릭해서 들어가 본다면 다음과 같은 화면을 볼 수 있다.

 

딱히 다른 기능이 없어 보이므로 view-source를 클릭해보자.

 

 

view-source를 클릭하면 다음과 같은 php 소스 코드를 볼 수 있다.

 

위의 php 소스 코드 중 핵심 코드는 다음과 같다.

 

바로 solve(1); 함수를 실행시켜야지 이번 old-01 문제를 해결 할 수 있을것 같다.

 

solve(1); 함수를 해결 하기 위해서는 3개의 if문을 잘 봐야한다.

 

3개의 if문의 조건절에 COOKIE값이 들어가있다.

 

따라서 이번 문제는 COOKIE 값을 이용해야한다는것을 알 수 있다.

 

editthiscookie를 이용하여 COOKIE값을 보게되면 user_lv이라는 이름을 가진 쿠키의 값이 1이라고 셋팅되어 있다.

 

다시 3개의 if문으로 돌아와 첫번째 if문은 숫자인지 아닌지를 판단하는것 같다.

 

여기서 쿠키값은 문자가 아닌 숫자임을 알 수 있다. (Point 1)

 

2번째 if문에서는 user_Iv값이 4이상이면 다시 user_Iv값이 1로 셋팅된다. (Point 2)

 

마지막 if문에서는 user_Iv값이 3보다 크면 solve(1)를 실행 시킨다. (Point 3)

 

3개의 힌트를 조합해보면 user_Iv값은 숫자이며 3보다는 크고 4보다는 작아야 한다.

 

따라서 3.1~3.9로 user_Iv값을 설정해주면 solve(1) 함수가 실행되며 문제를 clear 할 수 있다.

 

반응형

'웹 해킹 > Webhacking.kr' 카테고리의 다른 글

6. old-06  (0) 2021.11.03
5. old-05  (0) 2021.11.01
4. old-04  (0) 2021.11.01
3. old-03  (0) 2021.10.19
2. old-02  (0) 2021.10.18

+ Recent posts