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

mysql limit 함수에서 sql injection 공격 하기 셀 수 없을 정도로 많은 문서들이 SQL Injection(이하 SQLI) 공격 기법을 다루고 있다. 이 글은 굉장이 특이한 상황에서의 SQLI 기법을 다루고 있다. 특정 응용프로그램에서 SQLI를 테스트 할 때 간단한 인터넷 검색만으로 풀 수 없는 경우가 있었다. 바로 MySQL 5.x 버전에서 LIMIT 함수가 SQLI 공격 기법에 취약한 경우였다. 예제 쿼리 “SELECT field FROM table WHERE id > 0 ORDER BY id LIMIT injection_point” 위 쿼리에서 중요한 점은 해당 쿼리에 “ORDER BY”가 사용되었다는 것이다. MySQL 에서는 “UNION” 전에 “ORDER BY”를 사용할 수..

이전 iron golem 문제와 비교해봤을 때 크게 달라진 점은 에러 처리 부분과 필터링 부분이다. 이전에는 에러가 나면 에러를 보여주고 종료했으나 이번에는 에러가 나면 그냥 빈 페이지로 돌아간다. 그리고 필터링에 'if', 'when'이 추가되어 조건문은 사용하지 못한다. 공격문은 그냥 조건문 없이 blind sql injection 하듯이 작성하면 되지만, 문제는 쿼리 성공/실패 판단 부분이다. 즉, 쿼리가 실패하면 빈 페이지로 리턴 되고, 성공하면 위 사진에서 해당 쿼리가 보여지게 될 것 이기 때문에 쿼리 성공시 항상 위 페이지에서 보여지는 아무 문자열이나 기준으로 잡아서 판단하면 된다. > 리턴 페이지에서 해당 문자열이 보이면 성공, 안 보이면 실패

필터링은 신경 쓰지 않아도 되지만 문제는 에러 처리 부분이다. 만약 쿼리 에서 에러가 발생하면 에러를 보여주면서 쿼리가 종료되게 코딩되었다. 즉, error based blind sql injection 기법을 이용해야 한다. 쿼리 내에서 에러를 발생시킬려면 조건문을 사용해야 한다. > if (쿼리문,참일때 값,거짓일 때 값) 위 조건문에서 이용할 형식들은 다음과 같다. - 쿼리문 : substr 함수를 이용하여 pw를 한 글자씩 자르고 비교 - 참일 때 : 한 글자씩 자르고 비교한 값이 맞으면 변수에 저장 - 거짓일 때 : 한글자씩 자르고 비교한 값이 다르면 에러 발생 - 에러 발생을 위한 쿼리문 : ( select 1 union select 2) - 참 거짓 비교 방식은 간단다. 에러가 나면 페이지에..