'Crypto & Network & Etc/Study'에 해당되는 글 28건

Jar 파일 수정

2020. 2. 18. 23:48

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

Crypto Python Code

2019. 11. 20. 23:11

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

RSA

2019. 11. 11. 21:57

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

Transposition Cipher

2019. 11. 7. 02:13

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

Substitution Cipher

2019. 11. 7. 01:03

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

1. 개요

Stypr challenge의 eagle jump 풀다가 배웠던 기법인데, 웹쪽보다는 크립토인데 이게 웹이랑 연계되서 사용되는 경우도 은근 있어서 이참에 한번 정리해봤다. 해당 기법은 대충 어떻게 동작하는지에 대한 원리정도랑 해당 원리에 대한 이해를 기반으로 페이로드 생성해주는 HashPump 사용해서 실제 공격까지는 가능한 선으로만 이해하고 있고 실제로 로우레벨에서 페딩이 포함된 실제 페이로드 및 해당 공격을 통해 생성한 해쉬값 만들기를 직접 할 정도로 완벽하게 이해는 못한 상태이다. 그 이유는 암호학에 대한 근본적인 이해가 많이 없어서 라고 느꼈고 이걸 계기로 암호학도 조금씩 공부해둬야 겠다는 생각이 들었다.


2. 동작원리


동작원리와 같은 경우 그냥 내가 이해한 대로 그냥 부담없이 적어내려가는 형식으로 작성하겠다.


먼저 해당 기법과 같은 경우 공격 이름 그대로 길이를 확장해서 공격한다는 뜻이다. 이게 뭔 소리냐면 어떤 해쉬 값을 생성할 때 원본 텍스트에 패딩이라는 값을 추가하여 뭔짓을 하다보니 원본 텍스트의 길이가 늘어냐면서 이런 이름이 붙었다고 볼 수 있다. 해당 공격은 또 다른 말로 sha1,md5 padding attack 정도로도 불리곤 한다.


자 그럼 해당 공격이 뭔진 정확히 모르겠지만 대충 어떠한 상황에서 필요한지 알기 위해 아래 코드를 보자.


source.php


<?php

error_reporting(E_ALL);

ini_set("display_errors",0);


include("config.php");

if (isset($_GET['id'])){

    if (sha1(SECRET+$_GET['id'])===$_GET['hash']){

        if (strpos($_GET['id'],"admin")!==false){

            echo "Hi admin!! You Success";

        }

        else{

            echo "You not admin!! Bye Bye.";

        }

    }

    else{

        echo "You Bad Hash!!";

    }   

}

else{

    echo (string)sha1(SECRET+"guest");

}


자 코드를 보면 뭘해야 될지 느낄 수 있을 것이다. 딱봐도 id값에 admin을 주고 id가 admin일 때 sha1값을 구해서 보내주면 되는데, 문제는 sha1 생성 시 salt값이 추가되고 있고 우리는 salt값을 모른다는 거다. 문제에선 id가 guest일때의 salt가 포함된 sha1만 만들어주기 떄문에 우리는 이 로직을 우회하려면 일반적으로 salt+guest를 통해 생성된 해쉬를 대상으로 salt를 크랙하는 수밖에 없다.


근데 이러한 상황에서 우리는 바로 지금 우리가 다루는 length extension attack을 통해 해당 로직을 우회할 수 있다.


엄청나지 않은가?


아직 뭔진 모르지만 이러한 공격이 가능해진다는것만으로도 해당 기법을 이해하는데 큰 의미가 생길 것이다. 자 그럼 이제 본격적으로 해당 공격의 원리 및 익스 방법에 대해 알아보자.


해당 공격을 이해하기 위해선 우선 md5,sha1,sha2 류가 인풋을 받아서 해쉬처리를 할 때 어떠한 방식으로 동작하는지에 대해 알 필요가 있다.


이는 아래 사진을 보고 이해해보도록 하자.





해당 방식은 md5,sha1,sha2류가 해쉬를 만들 때 사용하는 방식으로 그림을 보면 알 수 있듯이 인풋의 첫번째 블록(M1)과 IV(H0)를 통해 압축과정을 거쳐 첫번째 해쉬 값을 만든다. 그 다음 해당 해쉬를  다시 IV삼아 두번째 인풋블록과 압축과정을 거치고, 이러한 과정을 인풋의 전체 블록을 대상으로 진행해 최종 해쉬값을 만든다.


그럼 이제 우리가 생각할건 인풋을 블록별로 나눌 때 당연히 인풋이 블록 배수로 딱 나누어 떨어지지 않을거니까 패딩이 붙을거라는 걸 생각해야 한다.


예를 들면 이런 형태다.


input : guest

m1 = salt + guest + padding

result hash = 40bd001563085fc35165329ea1ff5c5ecbdbbeef (예시로 임의로 쓴 해쉬)


위 상황에서 만약 우리가 input을 아래와 같이 준다면 어떻게 될까?


input : guest+padding ( padding은 정확히 block size 만큼)

m1 = salt + guest + padding

result hash = 40bd001563085fc35165329ea1ff5c5ecbdbbeef


럭키..


이를 통해 우리는 뭘 할 수 있을까?


input : guest+padding + admin

m1 = salt + guest + padding+admin

result hash = 7110eda4d09e062aa5e4a390b0a572ac0d2c0220


이게 뭘까? 잘 한번 생각해보자. 인풋이 salt랑 합쳐져서 salt + guest + padding+admin 가 됬을 때 블록단위로 나누면 


1블록 : salt + guest + padding

2블록 : admin+padding


이렇게 될꺼다.


여기서 1블록 결과는 우리가 알고 있는 40bd001563085fc35165329ea1ff5c5ecbdbbeef 요 값일 거고 최종해쉬를 생성하기위해 2번째 블록 admin+padding은 1블록 결과 40bd001563085fc35165329ea1ff5c5ecbdbbeef를 iv로해서 압축과정을 거쳐 최종 해쉬 7110eda4d09e062aa5e4a390b0a572ac0d2c0220를 만드는 거다.


그럼 결국 우리는 salt를 모르지만 기존 값(guest)에 추가적으로 내가 원하는 값(admin)을 삽입했을 때의 hash를 알 수 있다. 


그럼 이제 우리가 해야할 일은 guest+padding+admin을 줄 때 이 padding값을 어떻게 줘야하는지다.


md5,sha1,sha2류에서 쓰는 padding은 아래와 같은 형태로 구성된다.


salt+guest+1 000 0000 .... 0000 0000 + 해당 블록의 패딩을 제외한 값(salt+guest)의 비트 크기(만약 3글자 즉 3byte면 24 비트고 \x18로 표현됨)


위의 패딩부분에서 바로 나오는 1,0부분은 비트를 표현한거임. 구조가 인풋 다음 패딩 맨처음의 1비트는 1로 표현되서 1000 0000 = \x80으로 고정. 그담은 남은 크기만큼 0비트로 쭉 채워지니 \x00쭉가다가 마지막에 salt+input의 비트 크기로 마무리.


ex)

salt = "secret"

input = "guest"

위 놈들로 패딩을 채운다고 생각하면 아래처럼 될 것이다.

guest+"\x80"+"\00"*(64-len(input+salt)+2)+"\x58"


guest\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\58


굿... 간단하게 키좀긴걸로 하나더.



salt = 55글자 키

input = "guest"


guest+"\x80"+"\00"*(64-len(input+salt)+3)+"\x01\xe0"

guest\x80\x00\x01\xe0 가 나와야 할것 같은데


guest\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01\xe0


요게 나와버림. 아마 인풋 마지막 부분이 패딩인지 원본 값인지 몰라서 oracle padding처럼 어떻게 돌아가는거 같은데 이부분은 따로 관련 내용을 못봐서 몰게따. 쨋든 대충 이렇게 돌아가는거 아니까 걍 hashpump 쓰면 될 듯.


자 그럼 최초 문제로 돌아와서 


source.php


<?php

error_reporting(E_ALL);

ini_set("display_errors",0);


include("config.php");

if (isset($_GET['id'])){

    if (sha1(SECRET+$_GET['id'])===$_GET['hash']){

        if (strpos($_GET['id'],"admin")!==false){

            echo "Hi admin!! You Success";

        }

        else{

            echo "You not admin!! Bye Bye.";

        }

    }

    else{

        echo "You Bad Hash!!";

    }   

}

else{

    echo (string)sha1(SECRET+"guest");

}

이거 우회하는 코드 만들어보자.


여기서 중요한게 우리가 패딩을 만들려면 원본 키 길이를 알아야 한다. 키 길이 알아내는 방법은 어쩔수 없다. 가정하고 브포때리는거다.

대충 키 길이 1~64까지 가정해서 페이로드 만들고, 모든 페이로드를 날렸을때 정상적으로 인증 통과하는 값이 있으면 그게 키 길이고, 해당 페이로드를 사용해주면 된다.


여기서는 키 값이 8이라고 가정하고 페이로드를 만들어보자.


hashpump 사용해도되고 그냥 만들어도 되는데 그냥 만들어보자.


guest+"\x80"+"\x00"*(64-len(8+5)-2)+"\x68"+"admin"


hashpump 버전

hashpump -s '87c85771298bb84ae2703eb34eeeeac91f11f502' --data 'guest' -a 'admin' -k 8

2d3c477a9c38ba0dc9378b106975ad52139663b7


guest\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x68admin


굿잡.


대응방법 및 한계


만약 salt가 input 앞이 아닌 뒤쪽에 들어간다면?


input+salt+padding


이게 원래 구조일텐데


input+padding+salt ???? 내가 입력한 패딩을 포함한 인풋이 원래 블록에 들어가는 패딩 구조와 일치 할 수가 없음. 


즉 

salt + input + padding  요 구조일 때만 내가 인풋이랑 뒤에 padding을 넣어도 원래 패딩처리했을 때 값과 같으므로 이 공격할려면 해당 구조를 띄워야함.


또한 만약 salt+input+padding 구조여도 해쉬를 더블 해쉬 처리하면 공격이 불가능함. 이러한 형태를 띈 함수가 대표적으로 HMAC.


왜 이게 안되는지 생각해보면. 우리가 알고 있는 (hmac으로 생성됬다고 가정) 해쉬 값은 내가 넣은 인풋을 해쉬처리한 후 다시 해쉬처리해서 생성된 해쉬 값이다. 즉 내가 알고있는 결과 해쉬 값을 단순 sha1의 결과물이라고 생각하면 이놈의 원본 값은 내 인풋,솔트,패딩을 더한값이 아닌 이 놈들을 토대로 생성된 해쉬 값이 원본이란 거다. 그러므로 뭔가 막상 안되는거 구조적으로 엮어서 나열하면 헷갈리는데 딱 느낌올거다 구조적으로 안되는 상황인게. 쨋든 이놈은 딱 salt+input 상황에서 md5,sha1,sha2류의 해쉬함수를 더블해쉬아니고 한번만 해쉬처리할때 사용 가능하다.
























 











'Crypto & Network & Etc > Study' 카테고리의 다른 글

Substitution Cipher  (0) 2019.11.07
Block Cipher ECB Mode PlainText Leak  (0) 2019.09.05
ISMS 심사기준  (0) 2019.04.12
ISMS(Information Security Management System)  (0) 2019.04.11
Base64 원리  (0) 2018.12.31
블로그 이미지

JeonYoungSin

메모 기록용 공간

,

ISMS 심사기준

2019. 4. 12. 02:57

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

Base64 원리

2018. 12. 31. 17:58

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.