여러분의 앱, 얼마나 안전한가? 정적 분석을 통해 보안 허점 찾기

[RAD]

• 원문제목: How Secure Is Your App? Static Analysis Finds Security Holes
• 원문: https://blogs.embarcadero.com/how-secure-is-your-app-static-analysis-finds-security-holes/
• 작성자: Ian Barker (2023.8)

앱이 얼마나 안전한가요? 보안 허점과 숨겨진 뒷문을 찾는 쉬운 방법 - Ian Barker

During our recent Coding Bootcamp I had several sessions covering a broad range of topics. One session looked at static analysis of your Delphi code. Static analysis, or to be more correct, static code analysis is a process that can locate sections of your app’s source code which, despite being syntactically correct and generating no compiler errors or warnings are, in fact, potential gaping security holes.

최근 코딩 부트캠프에서는 다양한 주제의 세션들을 진행했다. 그 중에서 델파이 코드 정적 분석에 대해 살펴본 세션이 있다. 정적 분석은, 더 정확하게 표현하자면 정적 코드 분석은 앱 소스 코드에서 구문상으로는 정확하고 컴파일러 오류나 경고는 발생하지 않지만, 잠재적으로 심각한 보안 취약점이 있는 부분을 찾아낼 수 있는 프로세스이다.

 

목차

GDPR, 데이터 보호법, HIPAA 준수, 그렇게 중요한 문제일까?

정적 분석으로 어떻게 해커를 막을 수 있을까?

정적 분석이란?

정적 분석의 종류는 어떤 것들이 있을까?

정적 분석 도구로 "여러분의 앱, 얼마나 안전한가(How secure is your app)" 세션에서 이안 바커가 사용한 것은?

[다시보기] 여러분의 앱, 얼마나 안전한가(How secure is your app)? 코딩 부트캠프 세션 중 이안 바커의 정적 분석 내용

---

 

GDPR, 데이터 보호법, HIPAA 준수, 그렇게 중요한 문제일까?

My session laid out a lot of reference material to make it clear that this is not FUD. I’m not trying to spread fear, but that doesn’t mean to say you shouldn’t be worried. The fines for failing to comply with GDPR and other data protection laws are astronomical. The current trend is for the fines and punishments to increase as our world moves ever more to everything being ‘online’ or ‘in the cloud’. Medical records, or indeed any personally identifiable data, even simple things like photos, are generally protected by a law, and that protection comes in the form of eye-watering financial penalties for non-compliance with best practices or breaches. If you’re a small business and you’re unlucky enough to fall foul of a hacker’s attentions the fines and even less judicial enforcements such as having to provide free identity clean-up services to your clients might mean the end your business and potentially personal financial ruin for you too.

해당 세션에서는 제목의 내용이 FUD가 아니라는 것을 분명히 하기 위해 많은 참고 자료들을 제시했다. 공포심을 주려는 것은 아니지만, 그렇다고 걱정하지 않아도 된다는 뜻은 아니다. GDPR 및 기타 데이터 보호법을 준수하지 않을 경우 부과되는 벌금은 엄청나다. 현재 추세로 보았을 때 전체적으로 '온라인' 또는 '클라우드'로 이동하면서 벌금과 처벌도 더 커지고 있다. 의료 기록이나 개인 식별 데이터, 심지어 사진과 같은 단순한 데이터까지도 법의 보호를 받게 되는데, 이러한 보호는 베스트 프랙티스 미준수 또는 위반에 따라 엄청난 금전적 처벌로 이어진다. 소규모 비즈니스의 경우 운이 나쁘게 해커에게 걸려 이러한 문제에 빠지게 되면 벌금은 물론, 고객에게 무료 신원 복구 서비스를 제공해야 하는 등 법적 처벌을 받게되어, 비즈니스는 물론 개인의 재정적 파탄까지 초래할 수 있다.

I know that sounds a lot like scare-mongering – which is why the session contains a whole raft of facts and figures to back it up. Due to my role at the time, I was one of the original signatories and advisors to the first British Data Protection Act in the late 1980s. Times were simpler then, but governmental committees had already started to worry that the mass processing of data by computers exposed a risk which had not previously existed. The release of the excellent War Games movie caught the feeling of the moment with its fanciful depiction of David Lightman (Matthew Broderick) phone-phreaking free calls by using a Coke can ring pull on a public phone box and hacky high jinks such as altering Ally Sheedy’s school grades by simply overtyping them on ‘the school mainframe’.

겁을 주는 것처럼 들릴 수 있다. 때문에 이 세션에서는 이를 뒷받침하는 팩트와 수치들을 제시했다. 나는 1980년대 후반 처음으로 영국 데이터 보호법에 서명한 사람이자 자문위원 중 하나였다. 그 시절은 더 심플하긴 했지만, 정부 위원회는 이미 컴퓨터에 의한 데이터 대량 처리가 이전에는 존재하지 않았던 위험에 노출될 수 있다는 우려를 하고 있었다. 당시 개봉한 영화 <위험한 게임(War Games)>은 데이비드 라이트먼(매튜 브로더릭 역)이 공중 전화 박스에서 콜라 캔 링을 당겨서 공짜로 통화를 하는 장면이나 앨리 쉬디가 '학교 메인프레임 (역자주 - 학교 내에서 중요한 컴퓨터 시스템)'에 입력하는 것만으로 학교 성적을 바꿔버리는 등의 해킹하는 장난을 보여주면서 당시 분위기를 잘 보여주었다.

But it doesn’t take the accidental triggering of global thermonuclear war to be in some serious legal trouble. Danish web hosting firm Cloud Nordic has just had to tell its entire customer base that all their data has been irretrievably lost due to a ransomware attack. Not a great day to be working on their support desk, I think.

하지만 우발적으로 글로벌 핵전쟁을 일으켰다고 해서 심각한 법적 문제가 생기는 것은 아니다 (역자주 - 영화에서 주인공이 어떻게 될지도 모른채 저질렀던 사건을 설명한 것). 덴마크 웹 호스팅 회사인 Cloud Nordic은 랜섬웨어 공격으로 모든 데이터가 복구 불가능할 정도로 손실되었음을 전 고객에게 알려야 했다. 고객 지원 센터에서 일하기 좋은 날은 아니었을 것이다.

 

정적 분석으로 어떻게 해커를 막을 수 있을까?

The crux of the movie [spoiler alert] is that there had been a ‘backdoor’ left in the military computer’s online menu. David could access the out-of-control war game computer by choosing an unlisted option: Falken’s Maze. But note something important: there is not a bug. The code presumably compiles with zero errors (and, like all good Delphi coders: zero warnings) – and it runs correctly. Any automated user interface tool or unit tests would pass. The problem is that the original developer had left in hidden functionality – the Falken’s Maze backdoor.

영화의 핵심은 [스포일러 주의] 군용 컴퓨터의 온라인 메뉴에 '백도어'가 남아있었다는 것이다. 데이비드는 목록에 없는 옵션을 선택해 통제 불능의 전쟁 게임 'Falken’s Maze (역자주 - 영화에 등장하는 가상게임)' 에 접속할 수 있었다. 하지만 기억해야 할 중요한 점은 버그가 아니었다는 것이다. 해당 코드는 아마도 오류 없이(그리고 훌륭한 델파이 코더들이 그러하듯 경고 없이) 컴파일되고 올바르게 실행되었을 것이다. 모든 자동화된 사용자 인터베이스 도구나 유닛 테스트도 통과할 것이다. 문제는 초기 개발자가 숨겨진 기능, 즉 Falken’s Maze 백도어를 남겨두었다는 점이다.

The movie makes a lot of nonsensical leaps of faith, like Joshua, the computer, chasing Lightman around to any nearby phone with ubiquitous robotic text to speech seemingly existing at a time when I can assure you it definitely did not, but it does serve to illustrate a good point, code quality and security is not just about the syntax of your Delphi code being right.

이 영화는 컴퓨터인 조슈아가 유비쿼터스 음성을 텍스트로 완벽하게 변환해주는 로보틱 기능을 통해 주위의 전화기로 Lightman을 쫓아다니는 내용이 나오는 등 말이 안 되는 부분들이 나온다. 분명한 점은 당시에는 그런 기술이 존재하지 않았다는 것이다. 하지만 이 장면은 좋은 포인트를 보여주는데, 코드 품질과 보안성이 델파이 코드의 구문이 올바른가 아닌가에 따라서만 정해지는 것은 아니라는 점이다.

Static analysis of your code by a tool with meaningful capabilities is the only way to lessen the burden on you.

의미 있는 기능을 갖춘 도구로 진행하는 코드 정적 분석은 부담을 줄일 수 있는 유일한 방법이다.

 

 

정적 분석이란?

Static code analysis examines all of the source code used in your application – including component libraries, runtime library, and other items such as resource files. It is called static analysis because it’s done directly from the source code without your app running. There is an adjunct to this which is dynamic analysis – checking the app while it is running but the session didn’t cover that.

정적 코드 분석은 애플리케이션에서 사용되는 모든 소스 코드를 검사한다. 예를 들어 컴포넌트 라이브러리, 런타임 라이브러리, 리소스 파일 등의 여러 항목들이 포함된다. 앱을 실행하지 않고 소스 코드에서 직접 수행하기 때문에 정적 분석이라고 칭한다. 앱이 실행중인 상태에서 검사하는 동적 분석이라는 것도 있지만, 이번 세션에서는 다루지 않았다.

 

 

정적 분석의 종류는 어떤 것들이 있을까?

Well, a worrying number of things really! Everything from obvious errors like weak default passwords embedded in your code to inclusion of libraries with known vulnerabilities. A proper static code analysis tool goes a long way beyond that. For example, take a look at the following screen shot.

걱정스러운 것들이 정말 많기는 하다! 코드에 내장되어 있는 취약한 기본 비밀번호와 같은 명백한 오류부터 이미 알려진 취약점이 있는 라이브러리까지 말이다. 적절한 정적 코드 분석 도구는 이러한 문제 해결에 많은 도움이 된다. 예를 들어, 다음의 스크린샷을 한 번 살펴보자.

 

This is just a very small sub-section of 3,601 vulnerabilities found by static analysis of a medium-sized example Delphi app. As you can see, the call is using HTTP instead of HTTPs to open a web page. That’s the first error, the other, less obvious error is that it’s doing so using ShellExecute which means it is vulnerable to a ‘man in the middle attack’ since the shell handler can be replaced, and quite easily for HTTP. A ‘grep’ search might have found the first condition, but only static analysis of the code would have found the second one. Unless, of course, you think you’re really capable of reading through the 836,394 lines of code manually and faultlessly spot every single problem. Oh, and do it again the next time you have a major release? Note that in this case the automated scan took 27 minutes to complete and gave you a full rundown of all the vulnerabilities found, including the exact line of code at which they occur.

이미지에 보이는 것은 중간 규모의 샘플 델파이 앱을 정적 분석하여 발견한 3,601개의 취약점 중 극히 일부에 불과하다. 이 호출은 웹 페이지를 열 때 HTTPS가 아닌 HTTP를 사용하고 있는데, 첫 번째로 발견한 오류이다. 또 다른 오류는 'ShellExecute'를 사용하고 있다는 것인데, 쉘 핸들러가 대체될 수 있으므로 '중간자 공격'에 취약함을 의미한다. 특히 HTTP의 경우 이 공격에 더욱 취약하다. 'grep'으로 첫 번째 부분은 찾을 수 있었겠지만, 두번째 부분은 코드 정적 분석으로만 찾아낼 수 있다. 물론 836,394줄에 달하는 코드를 수동으로 확인하고 모든 문제를 완벽하게 찾아낼 수 있는 능력이 있다고 생각하지 않는 한 말이다. 그런데 다음 주요 릴리스 때도 또 할 수 있을까? 도구를 활용하니 자동 스캔 완료에 27분이 걸렸으며, 발견된 모든 취약점에 대한 전체적인 요약은 물론 취약점이 발생한 정확한 코드 위치까지 알려주었다.

 

정적 분석 도구로 "여러분의 앱, 얼마나 안전한가(How secure is your app)" 세션에서 이안 바커가 사용한 것은?

The static analysis tool I demonstrated during the webinar was DerScanner from Embarcadero’s newest Technology Partner, DerSecur. DerSecur supplied the demo data you see in the session and these screenshots and as you can see DerScanner fully understands Delphi code at a very deep level of detail.

해당 세션에서 사용된 정적 분석 도구는 엠바카데로의 기술 파트너인 DerSecur의 DerScanner였다. DerSecur에서 제공한 데모 데이터와 스크린샷은 해당 세션에서 확인할 수 있다. DerScanner가 매우 깊은 수준에서 델파이 코드를 완벽하게 이해한다는 사실을 알 수 있을 것이다.

 

The pricing model is per scan, but that scan is hugely comprehensive and finds a frightening number of types of unintentional and, more importantly, intentional code vulnerabilities, backdoors, errors, and security holes.

스캔 당 가격이 책정되어 있지만, 이 스캔은 매우 포괄적이며 의도치 않은 코드 취약점, 백도어, 오류, 보안 허점 등 다양한 부분들을 찾아낸다.

Static code analysis doesn’t help you write code in the way that code completion, error insight, and compiler warnings can do, but as I skimmed through the things it found I started to see how some common constructs in code are actually potential security risks. It was a bit of an eye opener to be honest and I think that given the increasing complexity, variety, and frequency of hacking and other related attacks it’s obvious that adding static analysis of your code to your release process not only gives you peace of mind but can also demonstrate due diligence to corporate customers and auditors too.

정적 코드 분석은 코드 완성, 에러 인사이트, 컴파일러 경고와 같은 방식으로 코드 작성을 도와주지는 않는다. 하지만 발견한 내용을 훑어보면서 코드 구조상에 잠재적인 보안 위험이 존재할 수 있다는 사실을 알게 되었다. 솔직히 말해서 놀라웠다. 해킹과 기타 관련 공격이 많아지면서 릴리스 과정 중 코드 정적 분석을 진행하면 안심할 수 있고, 기업 고객과 감사인에게도 입증하는 용도로 활용할 수 있다.