mala

LunascapeとSleipnirに報告した脆弱性の話(スマホアプリではとにかくHTTPSを使え2021)

前置き

• この文章と、それに含まれる考察や各サービスへの脆弱性報告などはmala個人の活動であり、所属している企業とは関係ありません。
• 執筆時点で未修正の不具合や、過去に修正済みで運営元が開示していない脆弱性情報なども含みますが、公益を意図しています。

概要

2020年の年末に、スマホ向けのLunascapeとSleipnirに対して、以下の問題を脆弱性として報告した。

mala

Rails の CVE-2019-5418 は RCE (Remote code execution) です

2019-03-23 更新

• Remote Code Executionとして、Advisoryが更新された。
• https://groups.google.com/d/msg/rubyonrails-security/zRNVOUhKHrg/GmmcVXcmAAAJ
• Thanks to @sorah @tenderlove

前置き

mala

アカウント名にスペース入れてソーシャルディスタンス、って謎の風習、最初はどこから始まったの？

5/10 に書いたこれ https://gist.github.com/mala/08fdbc680d84bb1b2305688282f26cea に関連して

• "アカウント名にスペース入れてソーシャルディスタンス、って謎の風習、最初はどこから始まったの？" https://twitter.com/t_yano/status/1260033514788884480

というTweetがあり、自分もインターネットミームとしての側面については気になっていたため調べていた。(事前に把握していたものも含む)

普段からTwitterをクロールしていたわけではなく、大規模なデータを持っていないので、実際にどこが発端になって、どういう流れで広まっていったのか正確なところは良く分からない。経緯を把握しているものだとシャープを参考にした(シャープはアカウント名部分ではないけど)というものがあるのは知っている。フォロワー数も非常に多く、企業SNS運用担当者の中では圧倒的な影響がある。

mala

Chrome ExtensionのLive HTTP Headersを調査した。Firefox用のものではない。Firefox用のものではない。

• https://chrome.google.com/webstore/detail/live-http-headers/iaiioopjkcekapmldfgbebdclcnpgnlo

11/7追記

• 類似 or 同様の方法で難読化scriptを埋め込んでいる拡張機能が大量にあったため、Googleに報告済み。
• https://twitter.com/bulkneets/status/795260268221636608

English version: https://translate.google.com/translate?sl=ja&tl=en&js=y&prev=_t&hl=ja&ie=UTF-8&u=https%3A%2F%2Fgist.github.com%2Fmala%2Fe87973df5029d96c9269d9431fcef5cb&edit-text=&act=url

Summary in english.

mala

次世代Webカンファレンス 2019 振り返り

• この文章に関しても所属組織とは関係のない個人の見解です

所感など

• 本当に全く打ち合わせをしていないので、話題が分散しがちだったかもしれない。
• せっかくの所属組織とは無関係のレギュレーションなので、具体名を上げてガンガン治安の悪いことを言うつもりだったのだけど、直前に「具体的な企業名は避けましょう」と言われて若干遠慮した。
• マズいことをガンガンしゃべる覚悟で来たので、防刃ベストを着ているが、特に出番は無かった。トイレにも行った。
• 本当は話す予定だったトピックについて、いくつかは、別途private gistに書く。

mala

/* 
	// mxhr.js
	// BSD license

	var mxhr = new MXHR;
	mxhr.listen(mime, function(body){ process(body) });
	mxhr.listen('complete', function(status_code){ ... }); // 2xx response
	mxhr.listen('error', function(status_code){ ... });    // other case
	mxhr.open("GET", url, true); // or mxhr.open("POST", url, true);
	mxhr.send("");

mala

use strict;
use Net::Twitter;
use MongoDB;

my $nt = Net::Twitter->new(
    traits   => [qw/API::RESTv1_1/],
    consumer_key        => "xxx",
    consumer_secret     => "xxx",
    access_token        => "xxx",
    access_token_secret => "xxx",

mala

https://gist.github.com/mala/5062931

の続き。

Twitterの人に色々と問題点は伝えたんだけど、これからOAuthのサーバー書く人や、クライアント書く人が似たような問題を起こさないようにするために、どうすればいいのかについて簡単に書きます。既存の実装真似して作るとうっかりひどい目にあう。

自分は意図的に「Twitterの脆弱性」という表現を使わないように気を使っていて、それはクライアントアプリ側の責任もあるからなのだけれども、安全に実装するための方法がわかりにくかったり誤解を招きやすかったり、Twitterに買収されているTweetDeckにも問題があったりしたので、それはやっぱりTwitter側の責任の比重が大きいとは思う。とはいっても別に責任を追求したかったり◯◯はクソだといったことを言いたいわけではなく、誰が悪いとか言う以前に、複合的な要因によって問題が起きるときには原因を正しく理解する必要があると思う。

そもそも何を担保に安全性を保証しているのか

• サーバー側で秘密の鍵を持っている(それが無いとアクセストークンを取得できない or 使えない)

mala

どういう問題があったか

説明するのめんどい http://vividcode.hatenablog.com/entry/twitter-oauth-vulnerability

どういう対策がされたか

• 第一段階: locationヘッダでの自動リダイレクトからmetaタグでのリダイレクトに変更(X-Frame-Optionsが効くので、iframe総当り攻撃が困難に)
• 第二段階: https://dev.twitter.com/blog/changes-to-sign-in-with-twitter

とりあえず即座に攻撃できるような状態ではなくなっています。

フィッシング？

mala

** アクセス解析の類を設置するサイト運営者の一般的な想定
http://www.ninja.co.jp/rule/analyze

図1
訪問者 → 忍者ツールズ → 業務提携先
           ↓
        サイト運営者

この場合、業務提携先、業務委託先に「忍者ツールズが知っているデータ」の中で「忍者ツールズが第三者に提供しても大丈夫だと考えている情報」が共有されることになる。
それは利用規約とかプライバシーポリシーに、統計データのみとか、個人を特定できないようにするとか、必要な範囲でとか、守秘義務を結んだ上で、とか書かれるのが一般的。