기본 콘텐츠로 건너뛰기

[kali linux] sqlmap - post요청 injection 시도


아래 내용은 직접 테스트 서버를 구축하여 테스트 함을 알립니다. 

실 서버에 사용하여 얻는 불이익에는 책임을 지지 않음을 알립니다.


sqlmap을 이용하여 get요청이 아닌 post요청에 대해서 injection공격을 시도하자.

뚀한 다양한 플래그를 이용하여 DB 취약점 테스트를 진행을 해보려고 한다.


서버 
OS : windows 7 64bit
Web server : X
Server engine : node.js
Framework : expresss
Use modules : mysql
Address : 172.30.1.30
Open port : 6000번

공격자
OS : kali linux  64bit
use tools : sqlmap
Address : 172.30.1.57

우선 서버측 부터 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
var express = require('express');
var app = express();
var mysql = require('mysql');
var ccc = mysql.createConnection({
    host:'127.0.0.1',
    user:'root',
    post:'3306',
    password:'*********',
    database:'test'
})
app.post('/post1'function(req,res){
    var t = req.param('test');
    s = "SELECT *FROM test WHERE test = " +t
    ccc.query("SELECT *FROM test WHERE test = ?",[t],  function(err, data){
        if(!err){
            console.log(t)
            console.log(data);
            res.send(data);
        }else{
            console.log(err)
            res.end('err')
        }
    })
})
app.post('/post2'function(req,res){
    var t = req.param('test');
    
    s = "SELECT *FROM test WHERE test = " +t
    ccc.query(s,  function(err, data){
        if(!err){
            console.log(t)
            console.log(data);
            res.send(data);
        }else{
            console.log(err)
            res.end('err')
        }
    })
})
app.listen('6000'function(){
    console.log('server on''open port 6000');
});
cs






















첫번째로 post요청에 대해서 sqlmap을 사용하는 방법에 대해서 설명.
$ sqlmap -u 172.30.1.30:6000/post2 --method="post" --data="test=1" -p "test" -v 3 
-u : 인자로 해당 url을 입력을 해준다.
--method : post로 명시를 한다.
--data : post요청으로 보낼 데이터
-p : 어떤 parameter를 사용하여 indection을 시도할지 명시를 해준다.
-v : 테스트 level, 해당 플래그는 공격자 측에서 어떤 payload(쿼리문)를 사용하고 해당 응답을 볼 수 있다. level에 따라 detail증가(1~6) 3정도가 가장 적당하고 좋은것 같다.

이제 해당 명령문을 실행을 해보자.






















서버측에서는 미친듯한 요청이 들어왔다.

이제 공격자측 커맨드 창을 확인을 해보자.


























현재 -v를 3으로 줬을 때의 공격자 측에서 나타나는 정보이다.(-v의 범위는 1~6까지 된다.)

다른 테스트를 테스트 하기에 앞서서 
아래와 같은 페이로드를 날린다.
$ [22:35:11] [PAYLOAD] 1",(.',"(,"
$ [22:35:11] [PAYLOAD] 1'XdET<'">Aojo
 특수문제에 대한 반응흘 테스트 한 후 다음 테스트들을 진행을 한다.
위 사진에서는 test parameter에 대해서 injection이 불가능하다고 나왔다.
인젝션이 불가능 하다고 판단해도 인젝션에 사용되는 쿼리를 끝까지 날린다.


























-v 3으로 할 경우 

[info] : 어떤 종류의 페이로드를 작성할지 설명
[payload] : 어떤 쿼리문을 사용하는지 표시
[debug]
순으로 콘솔창에 찍힌다.

더많은 정보를 보고싶으면 값을 더 올리면 된다 최대 6까지 가능하다.

























요청 헤더, 응답헤더까지 보여준다.

























해당 parameter에 취약점이 나타나지 않는다라고 뜬다.

이제 옵션을 추가적으로 더 달아보자.

우선 기존의 페이로드에서 더 미친듯한 페이로드를 작성을 하기를 원한다면

--level과 --risk를 명시하면 된다.
각각 1~5, 1~3까지의 범위를 가지고 있다.

해당 옵션은 범위를 벗어나면 명령문을 실행 시킬수가 없다고 콘솔창에 찍히면서 범위를 보여준다.

$ sqlmap -u 172.30.1.30:7000/post2 --method="post" --data="test=1" -p "test" -v 3 --level=5 --risk=3

lever이 높을수록 risk가 높을수록 더 위험한 쿼리를 보낸다.


이제는 쿼리를 날릴때 그냥 평문으로 날리는 것이 아닌 인코딩을 하여 날리는 방법에 대해 알아봐보자.

--tamper라는 플래그를 사용할 것이다.

1
2
3
4
5
6
tamper=apostrophemask,apostrophenullencode,base64encode,
between,chardoubleencode,charencode,charunicodeencode,
equaltolike,greatest,ifnull2ifisnull,multiplespaces,
nonrecursivereplacement,percentage,randomcase,securesphere,
space2comment,space2plus,space2randomblank,unionalltounion,
unmagicquotes
cs


tamper는 위처럼 많다. 

이제 tamper를 적용을 하여 명령문을 완성을 해보자.

$ sqlmap -u 172.30.1.30:7000/post2 --method="post" --data="test=1" -p "test" -v 3 --level=5 --risk=3 --tamper=apostrophemask,apostrophenullencode

























값이 인코딩이 되어서 쿼리가 만들어진다.


$ man sqlmap
sqlmap은 man에서 설명을 지원하기 때문에 더 많은 정보를 확인을 할 수 있다.




리눅스에서는 대부분의 명령어들이 man을 통해서 해당 툴의 사용법을 알 수 있다.

댓글

이 블로그의 인기 게시물

[git] git log 확인하기

git log를 통해서 커밋 이력과 해당 커밋에서 어떤 작업이 있었는지에 대해 조회를 할 수 있다. 우선 git에서의 주요 명령어부터 알아보겠다. $ git push [branch name] $ git pull [branch name] 여기서 branch name은 로컬일 경우 해당 브런치 이름만 적으면 되지만 깃허브 원격 저장소로 연결을 원할 경우는 해당 브런치 이름 앞에 꼭 origin을 붙이도록 한다. $ git brnch [branch name] $ git checkout [branch name] branch일경우 해당 브런치를 생성을 한다. 여기서 현재의 브런치를 기준으로 브런치를 따는것이다. checkout은 브런치를 바꾸는 것이다.(HEAD~[숫자]를 이용하면 해당 커밋으로 움직일수 있다.. 아니면 해당 커밋 번호를 통해 직접 옮기는것도 가능하다.) -> 해당 커밋으로 옮기는 것일뿐 실질적으로 바뀌는 것은 없다. 해당 커밋으로 완전히 되돌리려면 reset이라는 명령어를 써야한다. 처음 checkout을 쓰면 매우 신기하게 느껴진다. 막 폴더가 생겼다가 지워졌다가 ㅋㅋㅋㅋㅋ  master 브런치에서는 ht.html파일이 존재하지만 a브런치에서는 존재하지않는다. checkout 으로 변경을 하면 D 로 명시를 해준다.  $ git log 해당 브런치의 커밋 내역을 보여준다. a 브런치의 커밋 내역들이다. (머지 테스트를 하느라 커밋 내용이 거의 비슷하다 ㅋㅋ) master 브런치의 커밋 내역들이다. 커밋 번호, 사용자, 날짜, 내용순으로 등장을 한다. 이건 단순히 지금까지의 내역을 훑어보기 좋다. 좀더 세밀한 내용을 봐보자. $ git log --stat --stat을 붙이면 기존의 로그에서 간략하게...

[git] pull을 하여 최신코드를 내려받자

보면 먼가 로고가 다르게 뜨는것을 확인을 할 수가있다. C:\Users\mung\Desktop\etc\study\python-gene>git checkout remotes/origin/master Note: checking out 'remotes/origin/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:   git checkout -b HEAD is now at 29e282a... fetch test C:\Users\mung\Desktop\etc\study\python-gene>git branch * (HEAD detached at origin/master)   master   test1   test2 깃이 잘 쓰면 참 좋은놈인데 어지간히 쓰기가 까다롭다. 처음에 깃을 푸시 성공하는데만 한달정도 걸렸던걸로 기억이 난다.. ㅋㅋㅋ 여담으로  깃 프로필을 가면 아래사진 처럼 보인다. 기여도에 따라서 초록색으로 작은 박스가 채워지는데 저걸 잔디라고 표현을 한다고 합니다 ㅎ 저 사진은 제 깃 기여도 사진입니당 ㅋㅋㅋㅋ 다시 본론으로 돌아와서 ㅋㅋ pull을 하면...