티스토리 뷰
< Weak Cryptography implementation >
: 암호 알고리즘에 대한 취약점
- 개발 단계에서 자주 발생하는 취약점 : 인코딩으로 계정 비밀번호 등 민감한 데이터를 감추어 보내는 것
- 키값을 소지하지 않으므로 공격자가 얼마든지 인코딩 함수로 똑같은 데이터를 만들고 변조 가능
- 알고리즘 이용시 표준화된 알고리즘 사용하고, 결함이 발생한 알고리즘은 사용 X
(오래된 알고리즘은 무차별 대입 공격 등에 취약함)
- 해시 알고리즘도 마찬가지로 결함 발생한 해시 알고리즘은 사용 X
- 취약한 알고리즘 : RC2, RC4, RC5, MD4, MD5, SHA1, DES, 3DES 등
< 취약점 진단 과정 >
LoginActivity.java 일부
if (str2 != null && str1 != null) {
byte[] arrayOfByte = Base64.decode(str2, 0);
try {
this.usernameBase64ByteString = new String(arrayOfByte, "UTF-8");
} catch (UnsupportedEncodingException unsupportedEncodingException) {
unsupportedEncodingException.printStackTrace();
}
this.Username_Text = (EditText)findViewById(2131558520);
this.Password_Text = (EditText)findViewById(2131558521);
this.Username_Text.setText(this.usernameBase64ByteString);
str1 = (new CryptoClass()).aesDeccryptedString(str1);
this.Password_Text.setText(str1);
return;
}
아이디, 비밀번호를 입력 받고 아이디는 Base64, 비밀번호는 AES로 암호화 함
CryptoClass.java 일부
public class CryptoClass {
String base64Text;
byte[] cipherData;
String cipherText;
byte[] ivBytes = new byte[] {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0 };
String key = "This is the super secret key 123";
String plainText;
public static byte[] aes256decrypt(byte[] paramArrayOfbyte1, byte[] paramArrayOfbyte2, byte[] paramArrayOfbyte3) throws UnsupportedEncodingException, NoSuchAlgorithmException, NoSuchPaddingException, InvalidKeyException, InvalidAlgorithmParameterException, IllegalBlockSizeException, BadPaddingException {
IvParameterSpec ivParameterSpec = new IvParameterSpec(paramArrayOfbyte1);
SecretKeySpec secretKeySpec = new SecretKeySpec(paramArrayOfbyte2, "AES");
Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
cipher.init(2, secretKeySpec, ivParameterSpec);
return cipher.doFinal(paramArrayOfbyte3);
}
AES에 사용되는 키값을 String 변수에 그대로 넣는 방식으로 하드코딩 해 취약점 노출
- 코드 내부에 암호화키 노출 시 ==> 모바일에서 자바 언어 특성으로 인해 암호화키 노출할 가능성 ↑
( 암호 알고리즘 이용하더라도 키값이 상수 형태로 프로그램 내부에 존재하는 것은 매우 위험 )
- 안드로이드의 경우, 디컴파일 통해 키값을 노출하고 싶지 않을 시 해시 함수 이용해 키값 생성하는 것이 안전
키값을 외부 디렉터리에서 불러오는 것도 좋은 방법
초기화 벡터(IV)는 전부 0값을 넣어 사용 했다.
< 초기화 백터 >
- 프로그램이 실행된 후에 생성하는 것이 안전
- 운영 방식마다 사용방법, 요구하는 성질 다르지만, 같은 초기화 벡터 반복적으로 사용하면 안된다는 공통점 지님
(초기화 벡터 값 같은 경우, 비슷한 2개 평문을 암호화 했을 경우 앞부분 블록이 같아지는 문제점 노출 가능성 있기 때문)
- 초기화 벡터 설정 시 가능한 한 암호 알고리즘이 사용되기 직전에 계산하여 사용
- 사용한 직후에는 0 값을 채워 넣는 방식으로 지우는 것이 안전
- 초기화 벡터값은 블록 암호 알고리즘에서 맨 처음 단 한 번만 사용하므로, 첫 번째 블록을 암호화 한 후에 바이트를 0으로
초기화 해 공격자가 초기화 벡터값 유추하지 못하도록 해야 함
암호화 로직 살펴보면,
AES/CBC/PKCS5Padding로 설정되어 있음.
초기화 벡터는 AES 알고리즘 사용해 CBC 모드로 운영하며,
패딩은 PKCS5 방식으로 사용한다는 것을 의미
이 코드에서 문제점은 솔트 값 없이 암호 알고리즘 사용했다는 점
< 대응 방안 >
1. 암호 알고리즘은 학계 및 업계에서 검증된 표준화된 알고리즘 사용
< 대칭키 암호 알고리즘 사용 시 주의 할 점 >
1) 암호화 모드, 패딩 명시적으로 지정
2) 강한 암호화 기술 사용하며, 암호화 모드와 패딩을 포함
3) 암호화 값은 솔트 사용
4) 암호키의 값은 적절한 해시 반복 횟수 지정
5) 암호화 강도 보장하기 위해 충분한 키의 길이 사용
'Security Study > Android' 카테고리의 다른 글
Apk 코드 패치(리앱) 후 서명(Signing) 하는 법 (0) | 2023.01.27 |
---|---|
[InsecureBankv2] 애플리케이션 패칭 (0) | 2023.01.27 |
[InsecureBankv2] 안전하지 않은 웹 뷰 실행 (0) | 2023.01.25 |
[InsecureBankv2] 안전하지 않은 콘텐츠 프로바이더 접근 (1) | 2023.01.25 |
[InsecureBankv2] 루팅 탐지 및 우회 (0) | 2023.01.20 |
- Total
- Today
- Yesterday
- 모바일
- FTKImager
- 리버싱
- 취약점
- Android
- web
- CTF
- Cookie
- rev
- dreamhack
- 안드로이드
- 드림핵
- networking
- 포렌식
- AssaultCube
- sqlinjection
- reversing
- 해킹
- cheatengine
- mongodb
- SQLi
- Fiesta
- forensic
- MISC
- md5
- 스테가노그래피
- Steganography
- 인시큐어뱅크
- forensics
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |