新型コロナウイルス対策として様々な企業で在宅勤務が推奨される中、VPNに関する発言を耳にする機会が増えた。「大勢が使い始めたので速度が落ちた」「社内からの利用申請が急増した」といった恨み言が中心だが、興味深いものもあった。なんでも「グーグルはテレワークにVPNを使っていない」のだという。 米グーグルは従業員が在宅勤務をする際にVPNを一切使っていない。インターネット経由で利用できるSaaS（ソフトウエア・アズ・ア・サービス）の「G Suite」などで業務が完結するから、といった単純な話ではない。開発システムや経理システムといったあらゆる種類の社内アプリケーションが全てインターネット経由で利用できるようになっているため、従業員はそもそもVPNを利用する必要がないのだという。 同社はこうした社内事情を「BeyondCorp」という取り組みとしてWebサイトや論文で公開している。さらに2017年
Vector Art by Vecteezy Man-in-the-Machine: Exploiting Ill-Secured Communication Inside the Computer | USENIX Anoymask(@UXYEA）です。 実は先週、DEFCON 26に参加してきました。 図：DEF CON会場 図：DEF CONの講演 DEF CONに参加する中で、個人的に興味深いな感じた攻撃手法があったので本ブログで紹介したいと思います。 その攻撃手法とは、「Man-in-the-Machine」です。 中間者攻撃を意味する「Man-in-the-Middle」という攻撃手法はご存知かもしれませんが、「Man-in-the-Machine」という攻撃手法については恐らく知らないと思います。 私もDEFCON 26に参加した時、初めて耳にしましたが、どうやら講演したAa
RIPE 75で、DNSへの問い合わせ内容によって、DNSパケットが通過するネットワークが変わってしまうという怪しい挙動の報告がありました。 Babak Farrokhi - A Curious Case of Broken DNS Responses 発表資料(PDF) この発表では、DNSのパケットが途中ネットワークで解析され、そのDNSパケットに含まれる内容に応じて、すぐ近くにある偽のDNS応答が返ってくることがあるというものでした。 DNSパケットを解析するDPI(Deep Packet Inspection)装置＋偽DNS応答機能といった感じでしょうか。 発表者は、偽DNS応答がどこにあるのかを調べるために、DNSの問い合わせを用いたUDPによるtracerouteを実装しています。 偽DNS応答は、特定の名前に対するDNS queryに対してのみ発動するようなので、通常のtra
JPCERT/CCでは2017年2月10日に類似ドメイン名(jpcert.org)を第三者に登録されたことを契機にドメイン名紛争を行い、結果的にこのドメイン名を取り戻しました。不幸にして同様の状況に陥った日本企業においても、所定の手続きを踏むことでドメイン名を取り戻すことができる可能性があることから、対応の一助となることを期待してJPCERT/CCでの事例をご紹介します。 対象読者: 自社・自組織の類似ドメイン名を第三者に登録されてお困りの方 経緯 JPCERT/CCは1996年に正式発足し、それから20年の間jpcert.or.jpというドメイン名を使用してきた。 *iこのドメイン名に似た、jpcert.org（以下「偽JPCERTドメイン名」）というドメイン名が何者かによって登録された。 発端 2017年2月10日に何者かが偽JPCERTドメイン名をPublicDomainRegist
いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。 後は、関連するニュースなどを徒然と。 こんにちは、富士榮です。 明治大学の情報セキュリティ研究室が公開している「OAuthの仕組み丸分かり体験サイト」が話題になっているので、少し内容を見ていこうと思います。 ※決してディスっている訳ではありません。敬遠されがちなOAuthなどの仕組みを簡易に解説しようとする取り組みは非常に大切だと思いますし、私も常に悩むポイントの一つです。 OAuthの仕組み丸分かり体験サイト https://www.saitolab.org/oauth/ 尚、最初の公開後、かなり修正が入っていて誤解を招く部分はかなり減っており、投稿するのをやめようかと思ったのですが、逆に課題認識の部分がぼやけてしまったところもあるので、あえて投稿してみます。 中身ですが、元々は所謂OAuth認証問題です。一番残念
github.com 恥ずかしながらわたし、つい最近まで類似のパスワードを適当に記憶に頼って数種類使い分けるという運用をしていた。しかしながら、次のようなメールが期間をおいていくつか届き、類似のパスワードを使っている他のサービスに被害が及ぶのを恐れて、ランダムにパスワードを生成して保存するツールを作った。 いくつかのECサイト、特に小規模ECサイトは2要素認証が設定できないものが多く*1、あのアマゾンでさえ…と思ったら、いつのまにか2要素認証できるようになっていた。そうはいっても一部のサイトではクレジットカード情報を保存しておきながら2要素認証しないとか不安しかないので、自分でパスワード管理できるプログラムを練習がてら作って運用をまるごと変えることにした。既存のパスワード管理のソフトウェアやサービスがいくつもあるが、以下の理由でやめた 無料サービスは信用できない 有料サービスはちょっと躊躇
はじめに glibcでヤバメな脆弱性キター！ 「glibc」ライブラリに脆弱性、Linuxの大部分に深刻な影響 - ITmedia エンタープライズ Google Online Security Blog: CVE-2015-7547: glibc getaddrinfo stack-based buffer overflow CVE-2015-7547: Critical Vulnerability in glibc getaddrinfo - SANS Internet Storm Center Carlos O'Donell - [PATCH] CVE-2015-7547 --- glibc getaddrinfo() stack-based buffer overflo 内容見るに、getaddrinfoの名前朝解決時に悪意あるDNSレスポンスパケット食わされるとexploit発動
2015年6月頃にみつけた、toolbar.google.com の、少し変わったXSSを2つ紹介します。 The English version is here: http://mksben.l0.cm/2016/01/google-toolbar-xss.html 何が変わっているか このXSSは、Google ToolbarがインストールされているIEでしか動作しません。Google Toolbarがインストールされていると、toolbar.google.com 上に用意されたUIから、ツールバーを操作するコマンドを実行できるようになります。このコマンドを利用することでXSSに繋げるという点が、よくあるものとは異なります。 どのようにコマンドを実行しているか toolbar.google.com 上の次のページをみると、こんなコードを発見できます。 http://toolbar.go
2015-07-21 x86 Linux シェルコード作成 pwn シェルコードとは ソフトウェアの脆弱性攻撃のペイロードであり、バイトコードで記述されます。そのため、CPUやOSのバージョンといったプラットフォーム毎に作成されます。 シェルコードという名称は一般的にシェルを起動することが攻撃者にとって楽にマシン全体の制御を奪う方法であり多用されているからですが、実際のところシェルコードはどのような処理も記述することができます。 x86 Linux シェルコード作成の前提知識 アセンブリ言語 シェルコードのバイトコードは、マシン語命令のアーキテクチャによって異なるため、アセンブリ言語で記述することになります。 Linuxシステムコール OSはカーネル内で入力、出力、プロセス制御、ファイルアセクス、ネットワーク通信と行ったタスクを管理します。 C言語のプログラムは最終的に、こういったタスクを
この記事は考察記事です。 彼と過去に会話した内容から、なぜ身元がバレて逮捕をされたのかを考察しています。 基本的に報道機関は一般人にも分かるように報道するため、ネットに強い人達には情報が少なく詳細を知りたいって方が多いと思ったので記事を書いてみることにしました。 考察の元となった情報源は言えません。信じるか信じないかはあなた次第です。 0chiaki氏のネット環境 彼の自宅にはネット回線がひかれてありません。 だったらどうやってネットにつないでいるかといったら、近くの無線LAN（FON）をタダ乗りしてネットに接続していました。 また、彼は普段使うOSにTails OSという、エドワード・スノーデンも使っていると言われている暗号化OSを利用していました。 このOSは、全ての通信がTor接続となり、またOS自体は暗号化され復号しないと中身が見れないという今あるOSの中では一番秘匿性の高いOSで
Googleに所属するSSL専門家のAdam Langley氏は米国時間12月8日、自身のブログで多くのTLS実装に対して警告を出した。以前明らかになった、SSLバージョン3（SSLv3）に影響する「POODLE（Padding Oracle On Downgraded Legacy Encryption）」攻撃と同じような攻撃につながる脆弱性を含んでいるという。 SSLv3は、CBCモードの暗号でデータのパディングを効果的に特定しない。そのため、ブロック暗号の整合性をきちんと確認できず、「パディングオラクル攻撃」を可能にしてしまう。SSLv3の後、仕様はTLSと改名され、バージョン1になった。TLSv1の変更点の1つとして、パディングオラクル攻撃を防ぐためのパディング処理を改善した。 だが、TLS実装でもパディングバイトのチェックは完全ではないという。多くのTLS実装がSSLv3ソフトウ
yebo blog: TLS 1.0に深刻な弱点が見付かる
2011/09/20 TLS 1.0に深刻な弱点が見付かる セキュリティ研究者のThai Duong氏とJuliano Rizzo氏は、TLS 1.0/SSL 3.0を使っているウェブサイトで、攻撃者にエンドユーザとウェブサイト間に流れるデータを気付かれずに復号化できるという深刻な弱点を発表するそうだ。今のところ、TLS 1.1や1.2は影響はないとのこと。今週、ブエノスアイレスで開催されるekopartyセキュリティ会議で、両氏はBEAST (Browser Exploit Against SSL/TLS)と呼ばれるコードでそのデモを行うそうだ(デモは23日)。Duong氏は、デモではPayPalアカウントにアクセスするために使われる認証用のcookieを復号化すると語っている。このBEASTは、標的となるブラウザにBEASTのクライアント側のJavaScriptコードを埋め込み、中間(
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
