Tag Archives: Security

LINE新卒エンジニアのしごと〜6月のセキュリティエンジニア編〜

LINEには、今年33名の新卒エンジニアが入社しています。この連載では、新卒で入社したエンジニアがどのように働き始め、どのような仕事をしているのかを月に1回程度の持ち回りで紹介してもらいたいと思います。
2018年秋〜2019年春入社の2回目は、LINEのセキュリティー部門であるアプリケーションセキュリティチームに所属しているKohさんに、仕事の始め方や最初にやった仕事、普段の業務を紹介してもらいました。

Another One Bites the Apple!

こんにちは。LINEでセキュリティを担当しているチャン・ジュノです。私は、LINEが提供するサービスをハッキングし、そのセキュリティを強化する仕事を担当しています。また、趣味として他社の製品の脆弱性を見つけて報告することで、より安全な世界を実現することに貢献しています。
このようにセキュリティの脆弱性を探すことを、ハッカーの間ではバグハンティング(bug hunting)と言います。ハッカーは、バグバウンティ(bug bounty)で賞金を獲得します。賞金がなくても、ハッカーとして名声を得るために、あるいは純粋に面白くてハッキングします。

この記事では、多くのハッカーがバグハンティングのターゲットにするApple製品で、バグハンティングを行った過程を紹介します。 

ゲームセキュリティ運営から見たチート対策としてのモニタリングについて

こんにちは。LINEのgame securityチームでLINE GAMEのセキュリティ運営を担当している李明宰です。

LINE GAMEが誕生してから6年以上(https://6thanniversary.game.line.me/)経ちますが、今回はその6年間を通して、セキュリティ運営から見たゲームのチート対策とそのモニタリングについて、皆さんにご紹介したいと思います。

チートとは、悪意のあるユーザー(以下、アビューザー)により、ゲームを有利に攻略する目的でアプリが改ざんされる行為全般を指します。

LINEでは、LINE GAMEのユーザーの皆さんが安心できるように、ゲームアプリのリリース後、様々な取り組みを通じて、ゲーム内に存在するアビューザーの分析や対応を行っております。

特にチート対策の考え方として、アプリ側での対策のほか、後ほどご紹介するモニタリングを中心とした対応の観点にも着目してお読みいただければと思います。

APK Signingについて

こんにちは。LINEでAIR GOの開発を担当しているKIM SEUNGHOONです。
最近、Googleは、Android 9(Pie)で、APK Signature Scheme v3を紹介しました。
これに伴い、AIR GOも、APK Signature Schemeを検知できるようになりましたので、このブログでは、APK Signing(APK Signature Scheme)が何かとAIR GOがどのように検知するかについて紹介したいと思います。
(AIR GOについては前回の記事を読んでいただければと思います。)

LINE and Intertrust Security Summit 2018, Autumn参加レポート

セキュリティ室の市原です。

今回は、2018年10月29日(月)にローマ(Museo de Arapacis)で開催された
“LINE and Intertrust Security Summit 2018, Autumn”について、幾つかのスピーチやパネルセッションをピックアップして報告します。

Website: https://www.intertrust.com/company/events/2018-fall-line-summit/

ハイライト映像: 

Best practices to secure your SSL/TLS Implementation

この記事は、 LINE Engineering Blog 「夏休みの自由研究 -Summer Homework-」 の 11日目の記事です。

こんにちは、LINE Infra Protection チームのSecurity Engineeringを担当しているLee Jihoon(李志勲)です。

Infra Protectionチームは、業務環境とサービス環境で使用されるインフラを、より安全に作る業務を担当しています。そのような活動の一つとして、SSL/TLS証明書に対する管理や関連ガイドを提供する活動も行っています。大規模な環境ではセキュリティはもちろん、クライアントに対する互換性とサービス環境についても考慮が必要ですが、それらに関連する経験の一部を共有します。

はじめに

まず、TLS(Transport Layer Security、以前のSSL。一般的な表記に従い以下 SSL/TLS と表記します)とは何か、簡単に解説することからスタートします。

ブラウザのようなクライアントとウェブサーバが、公開されたインターネット網を利用してコミュニケーションする際に、望む相手と安全につながるために、必要なセキュリティメカニズムを提供するインターネットプロトコルがTLSです。

技術的な要件についてはRFC 2246(TLS 1.0)、RFC 4346(TLS 1.1)、RFC 5246(TLS 1.2)まで、現在広く利用されているTLSプロトコルについて確認することができますが、持続的にセキュリティ水準が高まっています。 最近(2018/3/21)、Proposed Standardで定められたTLS 1.3には、既知のセキュリティ問題を追加で考慮した設計が含まれています。

「Bug Bounty」をテーマとしたSecurity Meetupを開催しました!

こんにちは、LINEのセキュリティ室でセキュリティエンジニアをしているコキチーズです。LINEでは、社内のエンジニアであれば誰でも技術イベントの企画や、勉強会での登壇が可能です。またそういったエンジニアの対外的な活動を支援してくれる専門のチームが社内に存在します。
それを利用して「Bug Bounty」をテーマとした勉強会「Meetup in Tokyo #34 – Security Bug Bounty –」を開催しました。
セキュリティの勉強会を主催するのは初めてで不安でしたが、結果的に大勢の方にお越しいただきました。皆様ありがとうございます。

[LINE x SECCON 2017] LINE Security Bug Bounty Program キャンペーンのお知らせ

Developer Relations チームの三木です。

LINEでは、コミュニケーションアプリ「LINE」および一部関連サービスに存在する脆弱性を早期に発見し、ユーザーにより安全なサービスを提供することを目的として、「LINE Security Bug Bounty Program」を実施しています。
該当サービスの安全性向上に繋がると判断した脆弱性の報告を対象に、報奨金を提供しています。

LINEがスポンサーを務めさせて頂いた、日本国内最大のセキュリティコンテストSECCON2017決勝大会(2月17日、東京電機大学)では、セキュリティ室の久保田 量大(@k2wanko)が登壇し、LINE Security Bug Bounty Programの概要やその経緯、具体的な脆弱性の報告事例、皆様に報告頂くにあたってのTipsなどを紹介いたしました。
またその発表の中で、キャンペーン「LINE x SECCON 2017 LINE Security Bug Bounty Program」の開始について、触れさせて頂きました。

告知開始から時間が経過しておりますが、 本Engineering Blogでもあらためてご案内させて頂きます。

2017年LINE Security Bug Bounty Programの結果について

こんにちは。LINEでセキュリティに関する業務を担当しているMJです。

今回の記事では、2017年(1月1日〜12月31日)の「LINE Security Bug Bounty Program」を振り返り、皆さんにご紹介していきたいと思います。このプログラムは、LINEが提供するサービスにおいて潜在的に存在する脆弱性を外部のエンジニアの方々からご報告を頂き、我々が迅速に修正していくことで皆様により安全なサービスを提供することを目的としています。

VoIPのオープンソースライブラリPJSIPにおけるバッファオーバーフロー

こんにちは。セキュリティ室(アプリケーションセキュリティチーム)で主にLINEサービスのセキュリティ診断を担当しているYoungsung Kim(Facebookアカウント/Twitterアカウント)です。

これはLINE Advent Calendar 2017の24日目の記事です。

今日はVoIPのオープンソースライブラリであるPJSIPの脆弱性(CVE-2017-16872およびAST-2017-009)について書かせていただきます。PJSIPは、標準プロトコル(SIP、SDP、RTP、STUN、TURN、ICE)を実装したオープンソースのマルチメディア通信ライブラリです。たとえばIP PBXやVoIPゲートウェイなどで広く使用されているAsteriskフレームワークは、PJSIPを使用してSIPスタックを実装しています。

はじめに

今回発見した脆弱性は、64ビット環境においてクライアントから受け取ったデータを処理する際にsigned intからunsigned longへの暗黙的な型変換(型キャスト)が行われており、そこで整数型の符号拡張を考慮していないことが原因でバッファオーバーフローが発生するというものでした。この脆弱性についての詳細は、「(Security) Function in PJSIP 2.7 miscalculates the length of an unsigned long variable in 64bit machines」を参照してください。