2015. 8. 29. 08:42ㆍSecurity ★ Development/Paper
새 카테고리를 추가했습니다. 여기에는 앞으로 논문을 보고 내용을 정리해서 올리려고 합니다. 내용을 완벽하게 이해하지 못했을 수도 있으니 혹시 잘못된 점이 있으면 지적해주시면 감사하겠습니다.
Guess Who's Texting You? Evaluating the Security of Smartphone Messaging Applications
첫 논문은 스마트폰 어플리케이션에 관한 것입니다. Messaging Applications이라고 부르고 있으며 채팅, 메시지를 주고받는 프로토콜에서 발생할 수 있는 취약점에 대해 서술하고있습니다. (아래 나온 어플리케이션들은 해당 취약점이 패치되었을 수 있습니다.)
Authentication Mechanism and Account Hijacking : 최초 어플리케이션을 설치하고 디바이스와 폰 번호가 연동되는 메카니즘을 분석. 대부분 SMS 메시지를 통한 PIN번호 및 사용자에게 폰 번호를 입력하도록 지시.
제가 안드로이드 관련 로그인 시스템을 만들 때에는 안드로이드 ID를 직접 액세스하도록했는데 시험된 어플리케이션들은 대부분 사용자가 입력하도록 되어있습니다.
시험된 어플리케이션중 하나인 WhatsApp는 유저와 서버와의 메카니즘에서 공격자가 피해자의 폰 번호로 인증 메커니즘을 시도할 때 취약점이 있습니다.
1) 사용자 -> 서버 : 폰 번호
2) 서버 -> 사용자 : 코드
3) 사용자 -> 서버 : 코드
이런 메커니즘에서 공격자가 피해자의 번호를 서버에 전송합니다. 그럼 서버는 해당 번호로 코드를 전송하는데 이때 SSL proxy를 이용해 인터셉팅을 하게 되면 피해자의 계정이 공격자의 폰과 링크됩니다.
반면 또 다른 어플리케이션인 Viber는 폰 번호를 보내지않고 인증 요청 신호를 서버에 보냅니다. 그 후 코드 이동은 WhatsApp와 같은데 같은 폰 번호를 이용한 exploit은 불가능하게 됩니다. 테스트 환경에서는 HTTPS, SSL proxy를 쓰고 있는데 별도로 데이터 암호화를 해주는 편이 인증 과정에서는 필수인 것 같습니다. 저도 예전 프로젝트를 할 때 암호화를 하고 타임스탬프를 넣었었네요. 지금 하고 있는 프로젝트도 암호화 모듈을 추가하고 있고... 암호화라는 것이 적용하기 어려운 기술은 아닌데 그렇다고 클릭 한번으로 되는 것도 아니니 실제 업무에서는 별도의 지침이 없거나 이해관계가 확실하지 않으면 실천하기 어려운 것 같습니다.
Sender ID Spoofing / Message Manipulation : 폰과 서버 사이의 통신을 분석. 대부분의 실환경에서는 암호화를 적용하기 때문에 not practical.
Voypi와 Forfone 모두 전송 데이터를 암호화하지 않습니다. 단순 HTTP에 Forfone는 디바이스 식별자까지 사용하지만 말이죠. 대부분의 다른 어플리케이션은 XMPP를 써서 그에 따른 보안 특성에 의존하지만 저 두 어플리케이션은 직접 구현한 것에 의해 sender ID spoofing에 취약합니다.
Unrequested SMS / phone calls : 다른 사람의 폰 번호를 사칭하거나 아무런 확인 절차없이 희생자의 폰을 이용하는 것에 대한 취약점. 도청 또는 리플레이 공격.
공격자는 서버에 인증 요청을 하면서 피해자의 폰으로 요청메시지를 날릴 수 있습니다. 대부분 어느정도의 임계치를 두어 대량의 메시지는 예방하고 있지만 간격을 두고 끊임없는 메시지를 보내 피해자가 폰을 바꾸도록 할 수 있습니다.
Enumeration : 유저 서비스를 위한 정보제공 시 이에 따른 정보 유출(OS, to perform system specific attacks)
시험된 다른 모든 어플리케이션이 이 취약점을 가지는 반면 HeyTell은 주소록 전체를 업로드할 수 없도록 되어있습니다. 단, 번호를 하나씩 업로드할 수 있을 수가 있는데 이마저도 privacy setting에 제한됩니다.
Other vulnerabilities : WhatsApp는 상태 메시지를 공격자가 설정할 수 있도록하는 취약점이 있습니다.(modifying status message) 아무런 인증을 하지 않기 때문인데 cc, me, s 파라미터를 채운 HTTPS request만으로 설정 가능하도록 되어있습니다. 마찬가지로 WowTalk도 동일한 취약점을 가지고 있습니다.
이 논문에서는 많은 어플리케이션이 취약한 인증 메커니즘을 가지고 account hijacking 등의 공격에 취약하다는 것을 보여줍니다. 대부분의 어플리케이션은 account enumeration과 같은 취약점이 있고 이는 잘 알려진 소프트웨어 디자인&구현의 에러로서 발생합니다. 비록 이러한 취약점이 사람들의 생활을 직접적으로 위험에 빠뜨리진 않겠지만 수백만명의 사람들의 개인정보에 영향을 줄 수 있습니다. 공용 와이파이도 그렇고 개인정보, 서비스의 안전에 대한 문제를 예방하기 위해선 암호화를 기본값으로 보는 것이 좋을 것 같습니다.
'Security ★ Development > Paper' 카테고리의 다른 글
Improving Host Security with System Call Policies (0) | 2015.11.27 |
---|---|
How Secure is TextSecure? (0) | 2015.11.27 |
A Proxy-Based Data Security Solution in Mobile Cloud (0) | 2015.11.07 |
SCanDroid: Automated Security Certification of Android Application (0) | 2015.11.01 |
Payments Security (0) | 2015.09.25 |