こんばんわ、hisayukiです。
今日、運用中サービスのTwilioにアタックをかけられました💦
暇な人がいるもので、13時〜14時の間に370回近くのCallを受けましたね・・・
というわけで、対応を書き残します。
結論
被害は自体ほぼありませんでした。
攻撃されたといっても、Twilioの電話番号に電話掛けられてるだけなので。
電話系サービス作る時点でこの辺りは考慮して、よくわからない人からの電話を繋がないようにはしてます。
想定された事といえば、攻撃されてる最中に対象の電話番号に繋がりにくくなってたかも？くらい
あと、Call logが汚されたのでこれはかなりウザかったですね・・・・
詳細のお話
番号どうしてもれた？
運用中サービスは登録型の電話サービスです。
そのため、もともとサービスに登録している人しか電話ができない仕組みになってます。
一応仕組み的にはサービス登録者からじゃないと番号は見えない様になっています。
ただ、登録者は電話をかける際にTwilio側の電話番号を知ることになるので漏れる可能性は全然ありましたね。
ある程度は仕組みで回避
まずTwilio側の番号にかけると、WebhookでAPIサーバーに問い合わせてTwiMLを取得します。
かかってきた番号と登録情報を紐付けて存在している場合は、実際の相手の電話番号に転送するTwiMLを返しています。
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Dial callerId="twilioの番号" timeLimit="60">
<Number>転送先番号</Number>
</Dial>
</Response>
それがホワイトリスト的な機能になっているので、登録者以外の電話番号からの着信はすべてBusyになるTwiMLが返ってきます。
加えてサービス側の仕様で、登録者でもサービスから通話ボタンを押すことで初めて通話先との通話ルート情報がDBに格納されます。
DBに問い合わせてこのルート情報が無ければBusyになるTwiMLが返ってきます。
<?xml version="1.0" encoding="UTF-8"?>
<Response>
<Reject reason="busy"/>
</Response>なので今回のようにサービス未登録者がループで電話番号に攻撃するようなことされても、実際つながらないわけです。
例外もある
ただ、1回だけサーバーアクセスに失敗してます。
電話されるたびにWebhookでAPI呼び出すので、503のBad Gatewayになりました。
この時だけはAPIで返ってくるはずのTwiMLが取得できなかったので接続した扱いに。
まぁ、繋がってもTwiMLないのでその先の挙動もないんですけどね。
結局やったこと
一度番号漏れてしまってるのでTwilio側の番号は取り直しをしました。
こういう時に電話番号すぐすり替えられるのがTwilioのいいところですね。
あと、知らなかったのですがWebhookでAPIの呼び出しに失敗した場合の挙動が設定できたようです。
ということは、503のBad Gatewayで返ってきた場合のハンドリングもできるという事。
TwiML Binを指定できるので予めbusy用のTwiML作っておけば、サーバーにつながらなければ一旦busyってこともできますね。
まとめ
今回特に被害はなかったのでよいのですが、困るのはAPIサーバーへの通信です。
Twilioの番号に着信があるたびにAPIサーバーとの通信が発生するので、サーバーに負荷がかかるのは頂けない・・・
なので、Twilioの番号にかかってきて、Webhook飛ばす前の時点でのフィルタリング機能があるといいですね。
やり方はブラックリスト方式でもいいですし、ホワイトリスト方式でもいいですし。
ホワイトリスト方式ならSDKでサービス登録時にTwilio側にも登録できる仕組みにしたいな〜
あとは機械学習とかでおかしな挙動してる番号をブロックとかでもありがたいです。
Twilio側でのフィルタリング機能は見つけられてないので、もし知ってる方がいらっしゃいましたら教えて下さいｗ
コメント