# # 학교 전자 일지의 치명적 BAC 취약점: 권한 없이 교사가 되는 법
인기 있는 학교 전자 일지 앱의 리버스 엔지니어링 과정에서 치명적인 Broken Access Control (BAC) 취약점이 발견되었습니다. 이 취약점으로 인해 모든 사용자가 교사 기능을 완전히 사용할 수 있게 됩니다. 코드 분석 결과 서버 측 권한 확인이 없고 비밀 키가 평문으로 저장되어 있었습니다.
리버스 엔지니어링으로 드러난 취약점
조사는 앱의 APK 파일을 JADX 디컴파일러로 분석하면서 시작되었습니다. 초기 발견 사항은 충격적이었습니다:
- 로그의 디버그 쿠키: 세션 쿠키
X1_SSO가 암호화되지 않은 채logcat에 로깅되어 세션 하이재킹이 가능했습니다. - 자작 암호화: 주장된 AES 대신 하드코딩된 키(앱 패키지 이름
ru.vendor.schoolapp)를 사용한 간단한 XOR를 사용했습니다. - 유니버설 폴백: 디바이스 키가 없으면 앱이 고정 ID
000xpda로 기본 설정되었습니다.
이러한 결함으로 이미 학생 개인 데이터에 대한 자동화된 접근이 가능했습니다. 하지만 더 깊은 API 분석에서 더 심각한 문제가 드러났습니다: 서버 측 권한 확인이 없었습니다. X1_SSO 토큰 없이 요청에서 사용자의 guid를 단순히 바꾸기만 하면 어떤 학생 데이터든 접근할 수 있었습니다.
특히, 최소 세 개의 러시아 지역에서 사용되는 앱에서 동일한 취약점이 발견되어 수십만 명의 학생 데이터가 위험에 처했습니다.
책임 있는 공개: 위협 무시
저자는 Responsible Disclosure 절차를 통해 관련 기관에 통보를 시도했습니다. 디지털 개발부에 연락했으나 지역 기관으로 넘겨졌고, 개발자로 나열된 지역 정보기술 센터(RCIT)로 지정되었습니다.
RCIT는 "문제를 해결하겠다"는 약속으로 응답했으나 수정 사항은 피상적이었습니다:
- 쉽게 탐지되는 XOR 암호화를 제거했습니다.
- AES로 교체했으나 키를 앱 코드에 그대로 남겨두었습니다.
Crypt.java 클래스 예시:
package ru.vendor.schoolapp2.common;
import android.util.Base64;
import javax.crypto.Cipher;
import javax.crypto.spec.SecretKeySpec;
/* JADX INFO: loaded from: classes2.dex */
public class Crypt {
public static String alt_api_key = "gqhy671nmn3478fhsdjf4f09f45sf4fg4lf842d1";
private static Cipher cipher = null;
public static String encryptedTOKEN = "";
private static SecretKeySpec key = null;
public static String session_apikey = "0xt25240s9s12xv767v1ll17757e32e34x12ppix332vdi2i";
private static String transformation = "AES/ECB/PKCS5Padding";
private static byte[] encrypt(SecretKeySpec secretKeySpec, byte[] bArr) {
try {
Cipher cipher2 = Cipher.getInstance(transformation);
cipher = cipher2;
cipher2.init(1, secretKeySpec);
return cipher.doFinal(bArr);
} catch (Exception unused) {
return null;
}
}
private static byte[] decrypt(SecretKeySpec secretKeySpec, byte[] bArr) {
try {
Cipher cipher2 = Cipher.getInstance(transformation);
cipher = cipher2;
cipher2.init(2, secretKeySpec);
return cipher.doFinal(bArr);
} catch (Exception unused) {
return null;
}
}
public static String encryptString(String str) {
return Base64.encodeToString(encrypt(key, str.getBytes()), 2);
}
public static String decryptString(String str) {
byte[] bArrDecrypt = decrypt(key, Base64.decode(str, 2));
if (bArrDecrypt != null) {
return new String(bArrDecrypt);
}
return "";
}
public static void initKey() {
key = createSecretKey();
}
private static SecretKeySpec createSecretKey() {
return new SecretKeySpec(new byte[]{10, 20, 30, 40, 50, 23, 19, 31, 0, 0, 0, 0, 0, 0, 0, 0}, 0, 16, "AES");
}
}Roskomnadzor를 통한 후속 연락도 다른 지역의 취약점을 수정하지 못했습니다. 시스템은 여전히 클라이언트 측 역할 확인에 의존하여 BAC 취약점이 치명적이 되었습니다.
Broken Access Control: 1분 만에 교사가 되는 법
주요 취약점은 앱이 shared_prefs 파일에 세션 데이터를 평문으로 저장하는 데서 비롯되었습니다. 두 개의 매개변수가 접근을 제어했습니다:
user_sys_guid— 사용자 식별자.rolename— 역할 문자열 ("Student" 또는 "Teacher").
실험은 루트 접근이 가능한 Waydroid (컨테이너화된 Android)에서 진행되었습니다:
- 학생 계정으로 로그인합니다.
/data/data/ru.vendor.schoolapp/shared_prefs/파일을 편집합니다:
* rolename을 "Teacher"로 변경합니다.
* API를 통해 이전에 얻은 교사의 user_sys_guid로 교체합니다.
- 앱을 재시작합니다.
결과: 인터페이스가 즉시 교사 모드로 전환되어 성적부에 대한 완전한 접근이 가능해졌으며, "SAVE"와 "ADD COLUMN" 버튼을 포함합니다. 서버는 사용자의 역할을 확인하지 않고 클라이언트에서 제출된 데이터를 맹목적으로 신뢰했습니다.
이것은 서버가 모든 요청에서 접근 권한을 검증하지 않는 전형적인 Broken Access Control (BAC) 사례입니다.
교훈: 보안은 장식품
이번 연구는 정부 IT 솔루션 개발의 체계적 결함을 드러냈습니다:
- 기본 보안 부재: 코드에 키 저장과 권한 확인 생략은 치명적 오류입니다.
- 피상적 수정: 아키텍처 개편 없이 XOR를 AES로 바꾸는 것은 아무것도 해결하지 않습니다.
- 위협 규모: 취약점이 여러 지역에 영향을 미쳐 수백만 명의 학생 데이터가 위험합니다.
이러한 결함은 성적 조작과 개인 데이터 유출을 포함한 대규모 무단 접근의 길을 열어줍니다. 책임 기관은 증거에도 불구하고 위협을 무시하고 있습니다.
주요 포인트
- BAC 취약점으로 인해 로컬 파일의 두 매개변수만 조정하면 모든 사용자가 교사가 될 수 있습니다.
- API와 암호화 비밀 키가 앱에 하드코딩되어 디컴파일 후 쉽게 추출할 수 있습니다.
- 당국은 근본 원인을 무시하고 피상적 수정에 그칩니다.
- 문제는 여러 지역에 걸쳐 있어 보안이 소홀한 템플릿 개발을 지적합니다.
— Editorial Team
아직 댓글이 없습니다.