Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[113]LINExNAVER 개발 보안 취약점 이야기

2,899 views

Published on

[113]LINExNAVER 개발 보안 취약점 이야기

Published in: Technology

[113]LINExNAVER 개발 보안 취약점 이야기

  1. 1. LINE x NAVER 개발 보안 취약점 이야기 이명재(LINE) 허규(NAVER security)
  2. 2. CONTENTS .-/ 1 E ' .-/ A E - E A8 E E .-/ .-/ A E EA E E E E ' / 3 0 1 E / 3 0 A E - E A8 8 BA EA E E / 3 0 2A E E 8 AB
  3. 3. 1. 2018 라인 버그바운티
  4. 4. 1.1 버그바운티란 버그바운티 프로그램이란 ? Bug Bounty Program 1. 취약점 보고 2. 심사 및 취약점 수정 (보상금 책정) 3. 보상금 수령 Hackerone, Bugcrowd Google, Facebook, LINE, NAVER Microsoft, Samsung 자사운영형태 전문대행회사 이용형태
  5. 5. 1.1 버그바운티란 취약점 발견시 어디에 연락해야 하는가? A社 취약점 보고창구가 없음 (제품문의 접수폼/email) B社 취약점 보고창구가 있음 (취약점보고 접수폼/email) C社 취약점 보고창구가 있음 (버그바운티 프로그램) 기관운영&비영리 단체 (취약점보고 접수폼/email) KISA, IPA, CNVD 국내 : LINE, NAVER, SAMSUNG 등 해외 : Google, Facebook, Microsoft, Tencent 등 제품벤더(microsoft, juniper, panasonic 등)
  6. 6. 1.2 버그바운티의 효용성 버그바운티 프로그램은 - 해커를 고용하는 가장 좋은 방법 - 회사의 보안을 지키는 가장 좋은 방법 “Not running a bug bounty program amounts to negligence.” - Joe Sullivan, Uber’s CISO “The best thing we have done to secure Facebook is to have a bug bounty program” - Sheryl Sandberg, COO, Facebook (https://www.youtube.com/watch?v=fzL9r47F4-8) 화이트 해커 참여에 의한 취약점 정보, 노하우를 배울 수 있다. 해커들은 다각도로 다양한 서비스를 보고 있기 때문에 한곳에 발견된 서비스가 다른 곳에도 있는지도 본다.
  7. 7. 1.2 타사의 사례 https://hackerone.com/directory?query= 2010 2011 2012 2013 2014 2015 2016 2017 2018 Google Facebook Microsoft LINE https://bugcrowd.com/programs
  8. 8. 1. 대상앱 ·LINE for iOS ·LINE for Android ·LINE for Chrome ·LINE for Windows 10 Mobile 2. 대상 WEB사이트 ·https://store.line.me/ ·https://news.line.me/ ·https://music.line.me/ ·https://live.line.me/ 3. 기타 ·참가조건, 취약성으로 인정되지 않는 항목, 금지항목 등 · 홈페이지에 상세내용 기재 ·이용규약 참조 https://bugbounty.linecorp.com/ 1.3 LINE Security Bug Bounty Program 취약성명 설명 참고금액 SQL Injection Ability to access private information through an SQL injection attack USD 3,000 Cross-Site Scripting (XSS) Ability to hijack a session or execute scripts through an XSS attack USD 500~ Cross-Site Request Forgery (CSRF) Ability to force a LINE user to perform an undesired process through a CSRF attack USD 500 Remote Code Execution Ability to send packets containing arbitrary code to the client or server side USD 10,000 Authentication Bypass Ability to masquerade as another person by bypassing authentication procedures USD 5,000 Purchase Bypass Ability to obtain items while bypassing in-app payment procedures USD 5,000 Encryption Break Ability to obtain another person’s authentication information by cracking encrypted data USD 10,000 Improper Certificate Validation Ability to obtain sensitive information by failing to validate SSL certificate. USD 10,000 Server-Side Request Forgery (SSRF) Ability to abuse functionality on the server to read or update internal resources. USD 2,500 Client-Side Enforcement of Server-Side Security Ability to bypass protection mechanism by relying on the client side protection only. USD 500 Improper Access Control Ability to access originally non-public pages because of access control failure. USD 500~ Password in Configuration File Ability to obtain a password or sensitive information in a configuration file. USD 500 Insecure Direct Object Reference (IDOR) Ability to bypass authorization and access resources directly by modifying the value of a parameter. USD 5,000 Information Exposure Through Debug Information Ability to obtain sensitive information through debugging information. USD 500 Privilege Escalation Ability to obtain elevated access to resources that are normally protected from an application or user. USD 3,000 Cleartext Transmission of Sensitive Information Ability to eavesdrop sensitive information in the network traffic. USD 500~ Path Traversal Ability to access arbitrary files and directories by manipulating variables USD 500~ Other Other vulnerabilities USD 500
  9. 9. 2015년부터 프로그램 자체 운영, for hacker, by hacker 1.3 라인 버그바운티 / 운영통계 2015년 (프로그램 실시) 2016년 (상시 운영 개시) 2017년 (프로그램 대상 확대) 2018년 (보상금 테이블 갱신) 실시 기간 8/24~9/23 6/2~12/31 1/1~12/31 1/1~6/30 접수 건수 194건 (일본:89, 한국 포함 타 국가:105) 97건 (일본:15, 한국 포함 타 국가:82) 212건 (일본:11, 한국 포함 타 국가:201) 148건 (일본:35, 한국 포함 타 국가:113) 보상금 대상의 취약점 수 14건 13건 45건 33건 hall of fame 8명 3명 11명 9명 special contributors 9명 8명 21명 11명 발생한 보상금 USD 44,000 USD 27,000 USD 76,500 USD 48,000 Double reward program by hackerone+google https://hackerone.com/googleplay
  10. 10. 1.3 라인 버그바운티 / 운영통계 한국어 : https://engineering.linecorp.com/ko/blog/detail/329 영어 : https://engineering.linecorp.com/en/blog/detail/329
  11. 11. 2. 라인이 말하는 보안
  12. 12. 2.1 의 위협 LINE app 기프트 서비스 네이티브 기능제공(js) • 친구리스트 • 토큰(유저식별자 등) • 프로필 정보 • 라인앱이 제공하는 다양한 기능 WebView에서는 라인앱이 제공하는 네이티브 기능에 접근하여 다양한 서비스를 제공 선물 보내기 게임서비스 하트 요청하기 WebView WebView xxx서비스 xxx WebView
  13. 13. 네이티브 기능에 접근하는 에서 페이지의 로딩은 위험하다 또한 로딩되는 페이지가 일지라도 가 존재하면 위험하다 2.1 의 위협 webview http://normal.site 네이티브기능제공api by addjavascriptinterface Native App http://attack.site • http페이지가 MITM공격에 의한 변조 • 스크립트 실행가능한 XSS webview 네이티브기능제공api by addjavascriptinterface Native App
  14. 14. 오래된 Android OS에서의 webview에서 HTTP페이지의 로딩은 위험하다 2.1 WEBVIEW의 위협(MITM/XSS) webview http://normal.site OS시스템 Native App http://attack.site • http페이지가 MITM공격에 의한 변조 • 스크립트 실행가능한 XSS Android OS(3.0 - 4.1.x) webview OS시스템 Native App Android OS(3.0 - 4.1.x) WebView를 사용하는것 만으로도 addJavascriptInterface가 자동으로 사용되는 취약점 (CVE-2013-4710) http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-4710 http://api.ma.la/androidwebview/
  15. 15. MITM ? Webview서비스는 모두 https 대응 상시SSL(AOSSL: Always On SSL) 은 이제 기본 - https://about.yahoo.co.jp/info/aossl/ - App Transport Security - https://transparencyreport.google.com/http 메시지, 통화기능에 관련한 리포트 - https://linecorp.com/en/security/encryption_report XSS ? 버그 바운티 프로그램에서 가장 많이 보고되는 웹취약점, XSS대응은 이스케이프 처리가 기본 기업이 공개한 xss filter사례 • https://github.com/naver/lucy-xss-filter • https://github.com/salesforce/secure-filters -로그인 도메인에서의 XSS 는 2,500달러 지급사례 -webview서비스에서의 XSS 는 1,500달러 지급사례 -결제 도메인에서의 XSS 는 1,500달러 지급사례 2.1 how should 『&』 --> 『&amp;』 『<』 --> 『&lt;』 『>』 --> 『&gt; 』 『"』 --> 『&quot; 』 『'』 --> 『&#x27 』
  16. 16. URL링크를 클릭하는 것 만으로도 유저가 의도하지 않게 등록/수정/삭제 처리가 되는 문제 2.2 CSRF(Cross Site Request Forgery) https://service.domain/regist.php https://attacker.domain/regist.php 1 <html><body> <form action=“https://service.domain/regist.php" method="post"> 이름:<input type="hidden" name="name“ value=“deview”><br> 전화번호:<input type=“hidden" name=“tel” value=“01012345678”><br> 주소:<input type=“hidden" name=“address” value=“seoul”><br> <input type="submit" value=”등록"> </form> </body></html> <html><body onload="document.reg.submit();"> <form action=“https://service.domainregist.php" method="post"> 이름:<input type="hidden" name="name“ value=“deview”><br> 전화번호:<input type=“hidden" name=“tel” value=“01012345678”><br> 주소:<input type=“hidden" name=“address” value=“seoul”><br> <input type="submit" value=”등록“ name=“reg”> </form> </body></html> 2 <html><body> <form action=“https://service.domain/regist.php" method="post"> 이름:<input type="hidden" name="name“ value><br> 전화번호:<input type=“hidden" name=“tel” value=“01012345678”><br> 주소:<input type=“hidden" name=“address” value=“seoul”><br> <input type=“hidden" name=“csrf_token” value=“a3rea35nd9zom”><br > <input type="submit" value=”등록"> </form></body></html> 공격 불가능
  17. 17. 대책 : POST 랜덤 파라메터 혹은 리퍼러 헤더, 커스텀 헤더 (공격자가 링크를 못만들도록 하기 위함) Referer: https://service.domain vs Referer: https://service.domain.attacker.domain 커스텀 헤더의 장점 : 서버에서 헤더만 추가하는 심플한 방법, 커스텀 헤더로 인증을 관리하는 도메인에서는 CSRF가 발생하지 않는다. 쿠키헤더로 인증을 관리하는 사이트에서 CORS설정이 * 로 되어 있으면 CSRF이 가능하게 되어 크로스 도메인에서 api에 접근 가능한 문제가 발생하는 경우가 있음 2.2 how should https://service.domain/api/users.json https://attacker.domain/users.html 1 GET /api/user.json Host: service.domain User-agent: xxxx Cookie: session_id=131a3ea092zegxil7; xxx HTTP/1.1 200 OK Access-Control-Allow-Origin: * {name: deview, tel:010-1234-5678, address:”seoul”, …} <html> <head><script> var req = new XMLHttpRequest(); req.open('get','https://service.domain/api/users.json',true); req.withCredentials = true; req.onload = reqListener; req.send(); function reqListener() { alert(req.responseText) }; </script> </head> <body> TESTING </body> </html> 2 GET /api/user.json Host: service.domain User-agent: xxxx Auth-Token: 131a3ea092zegxil7; xxx HTTP/1.1 200 OK Access-Control-Allow-Origin: * {name: deview, tel:010-1234-5678, address:”seoul”, …} 공격불가능
  18. 18. 당신의 사이트에는 기능이 있습니까 2.3 Open Redirect https://sign.service.domain/auth/login?redirectUrl=https%3A%2F%2Fservice.domain https://sign.service.domain/auth/login?redirectUrl=https%3A%2F%2Fservice.domain 로그인을 환영합니다. https://service.domain ID PASS https://sign.service.domain/auth/login?redirectUrl=https%3A%2F%2attacker.domain https://sign.service.domain/auth/login?redirectUrl=https%3A%2F%2Fattacker.com 로그인을 환영합니다 패스워드를 변경해 주세요 https://attacker.domain ID PASS
  19. 19. 2.3 Open Redirect User agent client Service provider Oauth 2.0인증개시 인증페이지 리다이렉트 인증화면표시 Callback 유알엘로 인가코드를 Redirect 인증/인가 https://client.service/ https://service.provider/ https://client.service/login/callback?code=인가토큰&state=rando m 엑세스토큰 요청(/w 인가토큰) 엑세스토큰 발행 https://attacker.domain%5c@client.service/ https://attacker.domain@client.service/login/callback?code=【인가토큰】&state=random https://service.provider/oauth/weblogin?client_id=1234567890 &redirect_uri=https://client.service/login/callback?response_type=code&stat e=random 공격payload 서버의 호스트체크를 바이패스한 사례 @client.service 부분이 host파트로 인식되어 체크로직에서 바이패스됨 url.getUserInfo() 체크추가
  20. 20. 1. 외부 도메인에 redirect 필요시 화이트 리스트 방식으로 관리 - Ex) /^https://white.domain/ 2. 외부 도메인에 redirect 필요없을시에는 경로만 지정 - 취약ex) : location.replace(get_query_param("redirectUrl")) - 안전ex) : location.replace("/path/to/app/" + get_query_param("redirectUrl")); 3. 바이패스에 주의하자 - attacker.domain%5C@service.domain - attacker.domain#@service.domain @service.domain 부분이 host파트로 인식되어 체크로직에서 바이패스되는 경우가 있으므로 url.getUserInfo() 체크추가 - attacker.domain/service.domain 2.3 how should
  21. 21. 에 취약할 수 있는 곳 내부 이미지 로딩하는 부분 등 2.4 https://developers.line.me/console/channel/1510978178/basic/ https://clova-developers.line.me/cek/#/skill/com.example.test/ja_JP/edit/config https://service.domain/getimage.php?url=/image/test.png -http://127.0.0.1:8080 / http://사내시스템IP (or 추측 가능한 도메인 or jenkins, Elasticsearch GET rest api)
  22. 22. 1. Restrict the URL protocol to HTTP and HTTPS. - 불필요한 『javascript:』 , 『ftp://』, 『file://』스킴도 허용하면 안된다. 2. DNS lookup the host name and check it's not a local address. - localhost 및 사내 내부 IP를 허용하면 안된다. - Java의 경우 InetAddress의 getByName/getHostAddress을 사용해서 DNS resolve하여 사내IP인지를 체크가능 3. Disable redirects. 4. bypass에 주의하자 - https://127.0.0.1 vs https://127.0.0.1#test@example.com - javascript://alert(1)//http://example.com 선두일치 체크가 안된 사례 - https://[::]/ (localhost in IPv6) 2.4 how should
  23. 23. • /server-status, /jkmanager 등의 페이지가 외부에서 접근 가능하지 않습니까 • jenkins서버가 인증없이 외부에서 접근 가능하지는 않습니까 • memcached 서버가 인증없이 외부에서 접근 가능하지 않습니까 • mongoDB서버가 인증없이 외부에서 접근 가능하지 않습니까 2.5 서버 설정미스로 인한 정보노출 https://www.shodan.io/ mongodb jenkins X-application-Context org:”xxxcorp” jenkins org:”xxxcorp” mongodb org:”xxxcorp” port:”11211” org:”xxxcorp” country:”KR” port:”443” $telnet a.b.c.d 11211 stats items stats cachedump 숫자 숫자 Spring boot actuator endpoint /trace /dump /env /autoconfig /beans /health /mappings /shutdown Pip install wpscan Wpscan –url https://service.domain
  24. 24. USD 1,500 지불 https://service.domain/static/etc/passwd https://service.domain/static/etc/hosts 2.6 설정미스로 인한 수정전 수정후 RewriteRule ^/static(/.*)$ $1 [L] <Location /> Order Deny,Allow Allow from All </Location> RewriteRule ^/static(/.*)$ %{DOCUMENT_ROOT}/$1 [L]
  25. 25. App security improvement program https://developer.android.com/google/play/asi 2.7 Other efforts Campaign Started Remediation Deadline Path Traversal 9/22/2017 1/17/2018 Insecure Hostname Verification 11/29/2016 3/01/2017 Fragment Injection 11/29/2016 3/01/2017 Supersonic Ad SDK 9/28/2016 1/26/2017 Libpng 6/16/2016 9/17/2016 Libjpeg-turbo 6/16/2016 9/17/2016 Vpon Ad SDK 6/16/2016 9/17/2016 Airpush Ad SDK 3/31/2016 7/11/2016 MoPub Ad SDK 3/31/2016 7/11/2016 OpenSSL (“logjam” and CVE-2015-3194, CVE-2014-0224) 3/31/2016 7/11/2016 TrustManager 2/17/2016 5/17/2016 AdMarvel 2/8/2016 5/17/2016 Libupup (CVE-2015-8540) 2/8/2016 5/17/2016 Apache Cordova (CVE-2015-5256, CVE-2015-1835) 12/14/2015 7/11/2016 Vitamio Ad SDK 12/14/2015 3/14/2016 GnuTLS 10/13/2015 1/19/2016 Webview SSLErrorHandler 7/17/2015 11/25/2016 Vungle Ad SDK 6/29/2015 11/11/2015 Apache Cordova (CVE-2014-3500, CVE-2014-3501, CVE-2014-3502) 6/29/2015 8/31/2015
  26. 26. AIR GO를 활용한 취약점 자동 진단(https://air.line.me/airgo) 2.7 other efforts
  27. 27. 3. NAVER가 말하는 보안
  28. 28. . 3.1 네이버 버그바운티
  29. 29. . , 3.2 Whale 버그바운티
  30. 30. HA a Ie ) c , . 1 HS ) A ) S 2 HA H 3 K 3.3 현재의 버그바운티 Process
  31. 31. I L E N G F , , . 3.4 버그바운티의 범위
  32. 32. 8 % 7 8 1 0 62 3.5 2017 버그바운티 결과 0 20 40 60 80 100 120 XSS CSRF 서 비 스 어 뷰 징 리 다 이 렉 트 불 필 요 한 메 소 드 노 출 DLL Hijacking Blind XXE Injection 서 버 버 전 정 보 노 출 세 션 탈 취파 일 탈 취 취 약 점취 약 점 버 전 노 출 파 일 다 운 로 드 2017년 NAVER BUGBOUNTY
  33. 33. 3.6 2018년 ING
  34. 34. Jo a G + usG + e t? à L lc d e t? à ) kg d B b s ! T Sm n r G ( + i 3.7 Security Bug의 존재
  35. 35. L a A l l e W l è L c S è XlL ,, U è U b g CR 3.8 XSS의 해결 과정
  36. 36. 3.8 XSS의 해결 과정
  37. 37. 41 w ,10 2 18 4 a T l 15 2 - 4 w ci i G w e s .,, a r ci t .,, T y u ci eXC w i w w yn S j G o 3.9 소정의 성과
  38. 38. 3.10 Logical Security Bug
  39. 39. ? 3.10 Logical Security Bug http://AAA.naver.com/close.nhn?pollKey=[다른누군가가 생성한 투표의Key]
  40. 40. I E U 5 . 1 0 1 L R . M 3.11 제보된 XXE
  41. 41. . 3.12 XXE의 원인
  42. 42. T i c i S /- . ,c m a c S i c i c? e 3.13 경험으로 얻은 결론
  43. 43. .T V ? a N S c RA a è a E N 3.14 한계 그리고 가야할 방향
  44. 44. t o n . , S , cb s i A r r yC B db o cb u n , u g e B b 3.14 한계 그리고 가야할 방향
  45. 45. n n g ? ? g . o g bb n - n B n t 3.15 Bugbounty 산출물의 활용
  46. 46. c P d c cA t bi b g S eT / y b U D . u S r a o . C Z I t d A . - 1. . m o l 3.16 To developers
  47. 47. . 0-/ mw h RE m r ( ) a c h Ve r pe N v RE b v 2 2: 9 A 91? : rn u / 1 o tg dv pe y 변화의 시도
  48. 48. Q & A
  49. 49. 질문은 Slido에 남겨주세요. sli.do #deview TRACK 1
  50. 50. Thank you

×