내용을 간단히 정리하자면.. 이번 선관위 디도스 공격과 관련하여 디도스 청부가 이미 만연해 있으며 의뢰하면 5분만에 공격이 가능하다.. 정도 되겠다. 디지털타임스의 김지선 기자의 의도는 아마도 아니겠지만, 그리고 내가 삐뚤어진 시각을 가져서 그런 것인지는 모르겠지만, 디도스 공격은 마음만 먹으면 쉽게 할 수 있는 것이고 따라서 선관위에 대한 디도스 공격 (기사에는 진위 여부에 공방이 있다는 말이 처음에 등장하기는 하지만) 또한 충분히 개연성 있는 일이다는 늬앙스가 느껴진다. 이런 류의 기사가 많은 매체에서 쏟아져 나오고 있다. 이미 디도스 공격이라고 인정하고 배후가 있네 없네 따지는 기사들이 많다. 나꼼수가 절대적인 선이고 진실이라고 믿지는 않지만 (나름대로의 아젠다를 가지고 있고 공공연히 그것을 말하고 있으며 대부분 동조하는 바이기도 하지만) 적어도 이번 사건에 대해서 선관위 내부에서 벌어진 작업일 수 있다는 의혹을 제기하는 것은 충분한 근거가 있어보인다 -- 물론 김어준이 말한 팩트들이 (즉, 홈페이지 접속 가능 여부 등에 대한 내용) 진실임이 전제되어야 하지만 말이다. (이는 선관위에서도 인정한 것 같지만 말이다.)
외부에서의 디도스 공격에 의한 테러냐 아니면 선관위 내부에서 벌어지거나 협조가 있었냐에 대한 차이에 정치적인 의미를 분석할 능력은 없지만 후자임이 사실로 들어난다면 정부 기관에 의한 선거 방해라는 대한민국의 민주주의의 시계를 몇십년을 뒤로 돌리는 엄청난 무게의 사건이 될 것임은 분명하다.
서두에서 말했다시피 내 전공은 보안이나 인프라 쪽은 아니다. 하지만 개발자로 일하면서 보고 들은 일반적인 상식에 비추어 볼때 이번 사건을 디도스로 규정하는 것은 많은 의구심을 가지게 만든다. 보도를 보자면 선관위의 서버는 KT IDC (데이터 센터)에 운영을 위탁한 것으로 보인다. 개인 쇼핑몰 서버의 수준도 아니고 보통 이런 경우라면 인프라를 3-tier로 구성하게 된다.
3-tier라 함은 외부의 요청을 받게 되는 웹서버, 비지니스 로직을 처리하는 앱서버, 그리고 데이터를 저장하는 디비 서버를 말하는데 이들 사이마다 대개 방화벽이 있어 서버로의 임의적인 접근을 차단하게 된다. (DMZ도 일종의 방화벽으로 보면 된다.) 여기서 주의할 점은 거의 대부분의 경우 웹서버 뒤로는 별도의 내부 네트워크를 이용하는 경우가 많은데 이럴 경우 외부에서 바로 앱서버나 디비서버를 접근할 수 있는 방법은 없다. (물론 내부 네트워크와 연결된 장비를 털은 후 이를 경유해서 공격할 수는 있지만 이것은 디도스 공격이 아니다.)
선관위에서 서비스하는 내용이 무엇들이 있는지는 모르겠지만 메인프레임을 이용하지는 않을테고 (만약 그렇다면 오히려 더욱 보안은 강화될테고 직접 공격 또한 못하는 것은 아니지만 대개 더 어려워진다) 아마 위와 같은 구조가 아닐까 싶다. 클라우드 서비스를 이용하더라도 가상화라는 계층을 통할 뿐 근본적인 구조는 같을 것이다. 디비서버 등이 같은 물리적 서버에 존재하지 않는다면 말이다.
위와 같은 환경에서 디도스로 디비서버를 공격하는 것은 물리적으로 불가능하지 않을까? 선관위의 설명과 같이 디도스로 인한 공격이 맞기 위해서는 웹서버와 앱/디비 서버가 같은 물리적 서버에 존재하거나 또는 디도스로 DC 관리자의 시선을 분산시킨 뒤에 직접적인 서버에 대한 해킹이 이뤄져야 할 것이다. 전자의 경우는 인프라 환경을 알 수 없기 때문에 단언할 수는 없어도 동네 구멍가게 수준의 호스팅 환경이 아니라면 있을 수 없는 일일테고 후자의 경우라면 디도스로 인한 공격이 아닌 직접적 해킹에 의한 공격으로 인해 발생한 사건이며 디도스는 시선을 분산시키기 위한 연막일 뿐일 것이다. 디도스는 타 사용자의 웹서버 접근을 막는 단순 무식한 공격이고 많은 보안에 대한 지식이 필요하지 않으며 직접적인 해킹이라면 어느 정도 이상의 보안 지식과 경험을 가진 해커와 사전 준비 작업을 필요로 할 것이다. 따라서 보도된 바와 같이 컴맹인 공모씨가 도박사이트 운영을 하는 몇몇 종사자를 통해 단 하루만에 할 수 있는 일이 결코 아니다. 만약 그것이 가능했다면 KT IDC는 정말 보안의 개념이 없는 집단이겠지...
아무튼, 내 전공 분야도 아니고 깊은 지식이 없는 나도 이렇게 밖에 보이지 않는 사건을 많은 국내외의 IT 업계 종사자들은 이 사건을 무슨 심정으로 볼지 궁금하다.. 어이없어 하지 않을까??
매번 봐오던 것들이라 사실 눈에 잘 띄지 않았지만 오늘따라 출근길에 기차역에서 장애우들을 위한 램프가 눈에 들어왔습니다. 런던과 브라이튼 밖에 살아보지 않아서 영국이 다 이렇다고 말은 할 수 없지만 적어도 이 두 도시에서는 플랫폼과 기차 사이의 빈틈이 큰 역들이 많아서 아무 도움 없이 장애우들이 기차를 이용하기란 어렵습니다. 그래서 역들에 보면 다음과 같은 램프들이 비치되어 있고 기차가 역에 들어오면 역무원이 이 램프를 필요한 곳으로 (장애우가 기차에서 내리려 하는 경우 해당 기차 칸으로) 들고 갑니다.
브라이튼의 버스는 대개 장애우들의 탑승을 위해 램프가 장착되어 있고 버스의 높이도 낮출 수 있습니다.
물론 이 모든 것이 장애우들이 교통수단 이용에 전혀 불편함이 없게 해준다고 말할 수는 없지만.. 적어도 한국보다는 많은 배려를 해주고 있지 않나 싶습니다. 실제로 위와 같은 기구들을 사용하여 장애우들이 교통 수단을 이용하는 것을 아주 많이 보아 왔습니다.
몸의 장애가 이동의 자유까지 빼았으면 안되지 않을까요??
P.S. 이미지는 실제 런던/브라이튼의 이미지는 아닙니다만 거의 흡사한 것을 사용했습니다.
When I was growing up, phones were phones. You could call other phones and talk to people; they could call you. That was it. With the spread of smartphones, things have certainly changed. Today’s smartphones have more in common with computers than with the phones we had just a few years ago. In fact, smartphones are simply computers with extra hardware—namely, a GSM (Global System for Mobile Communications) radio and a baseband processor to control it. These extra features are great, but with the power they provide, there’s also a threat. Today, smartphones are becoming targets of attackers in the same way PCs have been for many years. Here, I focus on the security models of two smart phone operating systems: Apple’s iOS and Google’s Android. These two have a special place in my heart because I was the first to publicly exploit both of them.
Device security has many aspects. For brevity, I’ll put aside topics such as encryption, locking, and privacy and focus on what attackers really want: running their code on your device. Just as in the PC world, attackers can get remote code to run on a mobile device in two ways. The first is to get users to download, install, and run their software—that is, malware. The other is to attack the device by exploiting software vulnerabilities—that is, drive-by downloads. I’ll look at how iOS and Android try to prevent these two events.
Mobile Malware
iOS and Android both offer a public marketplace—respectively, the App Store and the Android Market—but take dramatically different approaches to limit malware on their devices.
iOS
In typical Apple fashion, the App Store is tightly controlled from the top down. Apple must approve an application before it can be in the App Store. Apple enforces this on the device through code signing. iPhones won’t run an application or load a library unless it’s signed by Apple’s private encryption key. No one besides Apple knows exactly how closely it reviews iOS apps. As a professional code auditor, I know Apple can’t be reviewing them all that carefully owing to the number of apps, but any kind of review will eliminate the most obvious malware. If a piece of malware did slip through the review and make it to the App Store, and people found out about it, Apple could remove it from the App Store and remotely remove it from devices on which it was installed.
You can argue about the App Store being bad for developers, but it’s an effective barrier to malware, perhaps only accidentally.
Once on the device, apps run in a sandbox that limits their actions. For example, one app can’t read another’s data. No app can read the stored SMS (short message service) messages, and so on. Because all apps share the same sandbox rules, they’re all allowed any action any app could ever need. For example, all apps can freely access the Internet and Address Book.[1]
Android
Developers can directly place their apps on the Android Market, and there’s no review of the apps before they arrive there. Android phones require applications to be signed, but they can be self-signed. So, Google uses these signatures for bookkeeping, not to control what code can run. Because of this, Android users can download apps from anywhere, not just the Android Market.
Instead of using a top-down approach to malware prevention, Android uses crowd sourcing. Users rate and comment on apps. They can see how many other users have downloaded an app and can report malicious apps to Google. If enough users complain about an app, Google will remove it from the Market and can remotely remove it from devices. A good tip for Android users is to never download an app without thousands of downloads and mostly positive comments. Another is to use only the Android Market. There have been a handful of malicious Android apps, but most of them were available only in markets other than the Android Market. The Android Market’s openness allows for easy use by developers but also allows ease of entry to malware developers.
Once the app is on the device, Android also uses a sandbox model. However, the Android sandbox is app-specific. During installation, apps inform the users about which permissions they need. Users can accept or reject these permissions. If they reject them, the apps won’t be installed. The good thing is that these sandboxes can be customized for each application instead of Apple’s one-size-fits-all approach. For instance, your Tetris game doesn’t need access to the Internet, so it won’t have that access. The bad thing is that this model forces the users to make the security decisions, which history has shown isn’t a good choice. Furthermore, users wanted those apps in the first place, or they wouldn’t be trying to install them. So, they’ll be inclined to just click through the screens.
Exploiting Vulnerabilities
Of course, attackers can just try to bypass the devices’ installation and review processes and exploit them directly. A mobile device’s attack surface is pretty similar to that of a PC; the easiest targets are applications such as Web browsers and email clients. Typically, the attack surface is smaller on mobile devices because there’s less code to attack. For instance, you don’t find Java or Flash in mobile browsers, but they’re quite common (and common exploitation targets) in desktop browsers.
However, smartphones offer two avenues of attack unavailable with PCs. One is SMS message processing. Collin Mulliner and I showed how to exploit a vulnerability in the iPhone’s SMS message parser to get control of the device.[2] Intrepidus Group researchers did the same thing against a Palm Pre.[3] The other avenue of attack—the GSM radio—has only recently been explored. Ralf - Philipp Weinmann showed how to use GSM software flaws to take over phones’ baseband processor.[4]
iOS
Having a software vulnerability is one thing; writing an exploit for it is another. Consider iOS, which uses a layered approach to prevent exploitation. iOS employs data execution prevention (DEP) andaddress space layout randomization (ASLR). DEP makes exploitation difficult by distinguishing between data and code. In this way, an attacker can’t supply data to a process and jump to that process to execute the data. The typical way to bypass DEP is to use return-oriented programming (ROP). However, ROP doesn’t work in the presence of ASLR because the attacker can’t find the code to reuse. So, taking a code execution vulnerability and getting a functional exploit from it will be difficult.
That was just the first defense layer. If an attacker can get code running in a process by way of an exploit, iOS has many restrictions that will limit the damage the attacker can do. For example, the code will be running in a sandbox. The attacker won’t be able to do things such as send or receive SMS messages. In addition, the code will be running as the less privileged user “mobile” rather than at the root level. Finally, the attacker won’t be able to install and run any software or tools on the device. Attackers generally want to upload keyboard sniffers or other attack tools, but the code-signing requirements will make this impossible. This, combined with the fact that iOS doesn’t even come with a shell or other useful utilities, means that attackers will have to do all their work in the exploited process and won’t have persistence on the device.
Of course, no defense is perfect, and the layered iOS security model has been broken at least a couple of times. The first was the SMS attack I mentioned earlier. It turns out the process that deals with incoming SMS messages runs at the root level and not in a sandbox. The other was a website called jailbreakme.com, which contained two exploits chained together. The first was a code execution exploit for the MobileSafari browser. This exploit’s payload contained the second exploit, which gave root-level privileges that proceeded to disable code signing and download and install the real payload, which would jailbreak the device. (For more on jailbreaking, see the sidebar.) So, these examples broke the defense layers, but the attacks had to be that much more sophisticated to work.
Android
Android sandboxes all the relevant applications, such as the Web browser, to restrict damage from attackers. This will require attackers to have two exploits, such as I outlined for iOS: one to get code running and one to break out of the sandbox.[5] One more feature that helps protect Android is that many Android apps are written in Java, which is mostly immune from memory corruption vulnerabilities. Collin and I found an SMS bug in Android that was similar to the one that defeated the iOS model.[6] But on Android, it was in a Java application and thus wasn’t exploitable.
However, one big drawback is that Android doesn’t utilize ASLR or DEP. This makes constructing exploits much easier than for iOS and Windows Phone 7, which both feature these technologies. Other smartphones such as the Palm Pre and Blackberry also lack ASLR and DEP. iOS, too, lacked DEP for the first year and added ASLR only this year. Hopefully, Android will soon follow suit.
Smartphones are becoming increasingly useful tools in everyday life. No one is ever lost or out of contact any longer. From a security perspective, these devices are typically more locked down than PCs and feature additional security measures such as sandboxing and code signing. However, because mobile devices store personal information, they’re attractive targets. Nevertheless, at this point in time, you’re less likely to lose personal data because of malware or drive-by downloads than if you had left your phone in a cab or at the local pub.
Jailbreaking
Jailbreaking disables code signing on iPhones to run apps not from the App Store. This breaks almost all the protections iOS offers. First, it disables code signing, which opens the platform up to malware. In addition, many of the added nonsigned applications run at the root level without a sandbox. The jailbreaking patches also somewhat disable data execution prevention by allowing writable and executable memory, which isn’t normally in iOS. So, the openness that jailbreaking offers also introduces potential security problems.
About the Author
Charlie Miller is a computer security researcher at Accuvant Labs. Contact him at charlie.miller@accuvant.com.
IEEE Security & Privacy's primary objective is to stimulate and track advances in security, privacy, and dependability and present these advances in a form that can be useful to a broad cross-section of the professional community -- ranging from academic researchers to industry practitioners.
