2가지 메뉴가 있는데 우선 소스부터 분석한다. "Login" 메뉴를 누르면 "mem/login.php" 페이지로 이동되지만, "Join" 버튼을 누르면 에러가 발생한다. 적당한 게싱을 통해 "mem/join.php" 페이지를 유추한다. 유추한 페이지로 가면 빈 화면만 보이는데, 소스를 분석해야 한다. 뭔가 겁나 복잡하다. 알파벳들을 이상한 문자에 대입하고 아래쪽에서 비교하는 듯 하다. 다행히 콘솔에서 자동으로 복호화가 되기 때문에 부분 부분 복호화를 진행하면서 분석한다. 위 사진에서 얻은 평문을 기반으로 하면 아래와 같은 결과를 얻을 수 있다. if(eval(document.cookie).indexOf(oldzombie)==-1) { bye; } if(eval(document.URL).indexOf(mo..

base64로 인코딩 된 문자열을 볼 수 있다. 디코딩 하면 암호화 된 문자열이 나오는데, 길이를 보면 SHA 일 거 같은 느낌이 든다. 해쉬함수는 일방향 함수이기 때문에 이론적으로 복호화가 불가능하다. 따라서 레인보우 테이블 등을 이용하여 복호화를 진행해야 한다. 복호화 하면 또 다른 SHA1 값이 나온다. 이전 사진에서 얻은 SHA1 값을 또 다시 복호화하면 "test" 문자열이 나온다. 4번 문제 페이지에서 최종 결과 "test"를 입력한다.

퍼즐이 나타난다. 풀고 gogo 버튼을 눌러야지 다음 단계로 넘어간다. 위 사진과 같이 풀면 된다. name 입력 창이 나타나는데 느낌이 SQL-Injections 문제이다. 일단 name 부분에 임의의 값을 입력한다. 입력하면 페이지 하단에 name, answer, ip 값들이 출력된다. 혹시 name에 따라 answer가 다르게 나오는지 확인하기 위해 다른 아이디를 입력해보아도 answer 값은 동일하게 나온다. name='bob'를 입력하고 'write' 버튼을 누르면 위 사진과 같이 패킷이 날라간다. answer, name 변수를 모두 조절할 수 있기 때문에 해당 변수를 이용해서 문제를 풀어야 한다. 여러 SQL-Injection 기법을 사용하다 보면 "no hack"이라는 메시지를 볼 수 있는데..

2번 문제 페이지 소스를 보면 시간 값이 주석으로 나타난다. 쿠키를 보면 세션 값 이외 "time" 값이 추가되었다. "time" 값을 참으로 설정한다. 쿠키의 "time" 값이 참인 경우 시간값 끝부분이 '1' 로 변한다. "time" 값을 거짓으로 설정한다. 쿠키의 "time" 값이 거짓인 경우 시간값 끝부분이 '0' 으로 변한다. "time" 값이 인젝션 포인트 인것은 확실하니 인젝션에 자주 사용되는 함수가 필터링 되는지 확인한다. 함수가 필터링 되면 주석에서 시간값이 아예 사라진다. 2번 문제의 상단 메뉴 중 "Board"로 가면 글이 하나 있다. 그리고 "FreeB0aRd" 라는 문자열이 보이는데 웹 해킹은 게싱("Guessing") 또한 중요하기 때문에 해당 문자열을 데이터베이스의 테이블 값으..

index.phps 로 이동시 나타나는 소스의 일부를 해석하면 위사진과 같다. * php 사용시 서버에서 옵션을 활성화 시키면 웹 브라우저에 phps 로 확장자를 변경하면 php 원본 소스가 나타난다 현재 user_lv 값은 '1'로 세팅되어 있다. 클리어 조건을 만족시키려면 소수를 이용하면 된다. (5.1 ~ 5.9) 문제 클리어

"Webhacking.kr" 메인 페이지 예전에는 "Register" 버튼이 있었지만 지금은 보이지 않는다. 해당 페이지 소스를 보면 가입 관련 버튼이 주석 처리 된것을 볼 수 있다. location.href = "join/include~~~~~~" 부분으로 이동한다. id,pw,email은 개인이 입력하면 되지만, decode me 부분은 뭔가 난독화 되어있다. 일반적으로 문자열 끝에 "=" 문자가 보이면 "base64" 디코딩으로 추정 할 수 있다. 디코딩 하면 클라이언트의 공인 IP가 나온다. (58.xxx.xxx.xxx) 모든 빈 칸을 입력하고 decode 결과까지 제대로 넣은 뒤 "Submit"을 누르면 회원 가입이 완료된다.

보호되어 있는 글입니다.

사이트 오픈 초기에는 문제 이름이 "rubiya" 였는데, 직접 구축하면 이름이 "umaru"로 변경되어 있다. 이유는 모르겠음 reset_flag 가 추가되어서 꽤 어렵게 보이지만 따지고 보면 그렇게 어렵지는 않은 문제이다. 어쨌든 소스를 분석하면 다음과 같다. > flag 파라미터 길이가 100이 넘어가면 에러 발생 > realflag 변수에는 실제 flag 값이 저장됨 > prob_umaru_temp 라는 임시 테이블에 prob_umaru 값이 복사됨 > 입력한 flag 값이 prob_umaru_temp 테이블의 flag 컬럼으로 복사 됨 > 입력한 flag 값이 실제 flag와 일치하지 않으면 reset_flag 함수 호출 > reset_flag 함수는 flag 값을 임의의 값으로 갱신 정말 운이..

이전 hell fire 문제와 동일한 곳에서 인젝션이 발생한다. 문제는 에러 부분인데, 이전 문제에서는 적어도 리턴 페이지에 에러를 출력해 줬으나 이번 문제는 에러가 나면 리턴 페이지는 무조건 빈 페이지가 된다. limit 인젝션 특성 상 공격 쿼리가 무조건 오류가 나는데, 오류를 안 보여주니 미칠 노릇일 수 밖에 없다. 힌트는 바로 시간인데, 이번 문제는 "time based - sql injection" 기법을 사용해야 한다. 이전 문제에서 읽어보라고 했던 링크의 마지막 쿼리 끝에 보면 BENCHMARK 함수가 존재한다. 해당 함수가 실행되면 약간의 타임 딜레이가 발생하는데 이것을 이용하여 공격 쿼리의 성공/실패 여부를 판단할 수 있다. 즉, if 조건문을 이용해서 (공격쿼리, 참(시간 발생), 거짓..

limit 에서 sql injection이 발생하는 특이한 구조이다. 설명은 아래 글을 참고하길 바란다. SQL Injection in MySQL LIMIT