タグ

DNSとsecurityに関するitochanのブックマーク (20)

  • 黒塗りのDNS

    黒塗りのDNS (萎縮編) ~共用サービスの闇~ Apr 23, 2019 ssmjp E-ONTAP.COM 鈴木常彦 (@tss_ontap) ある日の我が職場 (恥) 私(TEL) 「m.chukyo-u.ac.jp 見てみれ! 中華料理屋に乗っ取られてるぞ www」 情報システム 「え!...これは...調べます...」 後日 「レンタルサーバ返した後 A レコード削除申請がなかったようです!」 危険な忘れ物 - Floating Domainname 借りたサーバ (IPアドレス) にリソースレコードを向けたまま解約してはいけない Subdomain Takeover Attack 放置された CNAME の先は狙って再登録されうる、、、 old-service.example.jp IN CNAME orphan.cdn.example.com fan.football.son

    itochan
    itochan 2019/04/30
    共有DNSサーバの脆弱性。
  • DNS毒入れ擬似体験

    itochan
    itochan 2018/12/25
    DNSキャッシュにサブドメインの毒を入れられて何が問題なのか→cookie monster https://mobile.twitter.com/tss_ontap_o/status/1077187333277896705
  • ユーザの近くにある偽DNSサーバの話:Geekなぺーじ

    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

    itochan
    itochan 2017/11/02
    185.100.209.117 は、 United Arab Emirates (AE) とのこと。国の監視?(これは同じ? http://www.geekpage.jp/blog/?id=2014/3/31/1
  • Is the DNS' security protocol a waste of everyone's time and money?

    Internet security experts are arguing over whether a key protocol for protecting the internet's naming systems should be killed off. DNSSEC was developed in 1994 but it wasn't taken seriously until 2008 when a bug in the domain name system's software made it possible for someone to imitate any server – from websites or email hosts – though "cache poisoning." After a decade of DNSSEC use (and five

    itochan
    itochan 2015/03/20
    (ぶくませざるを得ない)
  • JPRS DNS 関連技術情報

    このページは DNS に関連する技術情報を提供するページです。 [ 最終更新:2024年03月21日 更新履歴はこちら] [ RSS ] ■ トピックス L4 グルーレコードについて改めて考える ~ランチのおともにDNS~(「Internet Week 2023」での発表資料[PDF]) DNSを用いたドメイン名の管理権限確認を使用する際の注意点(IETF 116 Host Equipment Demosでの配布資料[PDF]) Important Notes of Using Domain Name Ownership / Control Verification by DNS (Distributed on IETF 116 Host Equipment Demos[PDF]) L6 DNSの弱点を振り返り、今後の針路について考える ~ランチのおともにDNS~(「Internet We

  • オープンリゾルバー確認サイト

    JPCERT/CCでは、オープンリゾルバー(外部の不特定のIPアドレスからの再帰的な問い合わせを許可しているDNSサーバー)となっているDNSサーバーが日国内に多く存在していることを確認しています。 オープンリゾルバーは国内外に多数存在し、大規模なDDoS攻撃の踏み台として悪用されているとの報告があります。 また、DNSサーバーとして運用しているホストだけではなく、ブロードバンドルーターなどのネットワーク機器が意図せずオープンリゾルバーになっている事例があることを確認しています。 確認サイトでは、お使いのPCに設定されているDNSサーバーと、確認サイトへの接続元となっているブロードバンドルーターなどのネットワーク機器がオープンリゾルバーとなっていないかを確認することが可能です。 サイトの詳細についてはこちらをご参照ください。 ただいま処理中です。しばらくお待ちください。 ※判定処理

  • #oscnagoya 浸透いうな~DNSセキュリティ概論~ 2013年6月22日 - Yukarin'Note

    中野さん:通常は、インターネット安全教室などで、広く、来ていただけるように、周知したりしております。今日の手元にパンフレットが。4Fのブースにてお待ちしております。 #oscnagoya #5f_1

    itochan
    itochan 2013/06/22
    now reading つだりまとめ
  • インターノット崩壊論者の独り言 - 訊いてみるもんだ - ハイジャックの危険性のあるドメイン名へのJPRSの対処

    EPIC2014 Google Public DNS (8.8.8.8, 8.8.4.4) 経由ではサイトにアクセスできないよう措置させて頂いております。 DNSに関していろいろ危険な調査結果が私の手元にあるわけですが、今朝(10/1)ふと思い立って以下のメールをJPRSへ送ってみました。 市民の鈴木と申します。 以下の JP ドメインにハイジャックの危険性があります。 この手の問題についてはこれまで独自に連絡をしていましたが、こういうのは JPRSさんに対応をお願いできないものかと思い、まず連絡させて頂いた次第です。 JPRS さんという存在がありながら IPA に廻すのも忍びないものがあります。 ドメイン名登録者への連絡等、対応可能であればお願いしたいと思いますが、いかがなものでしょうか。 (以下、某大学ドメイン名のDNS設定に関する調査結果...省略) すると、思いのほか早い返事が

    itochan
    itochan 2012/10/04
    JPドメインの問題を見つけたら(IPAよりも)JPRSの対応が早いらしい
  • さくらDNSにサブドメインハイジャックを許す脆弱性

    さくらインターネット株式会社のDNSサービスにセキュリティ上の問題がありましたが、改修されましたので報告します。 DNSサービスへのドメイン登録時における不具合について 障害内容 : 当社の提供するネームサーバサービスにおいて、既に登録されているドメインのサブドメインが、他の会員IDの方に登録できる状態となっておりました。この障害により、悪意のある第三者がドメインの一部を乗っとれる脆弱性につながる危険性がありました。 問題につきましては現在は解消されており、全ての登録について不正がないかの調査を行っております。 この問題の発見者は前野年紀氏で、私はさくらインターネット株式会社に問題を通告し、改修を促すための連絡などでお手伝いをしました。 (12:00追記)なお、この脆弱性が混入したのは6月8日頃で、さくらインターネットは6月11日から修正を開始し、昨日(6月13日)には改修されましたので

    さくらDNSにサブドメインハイジャックを許す脆弱性
    itochan
    itochan 2012/06/15
    クッキー、なりすましサイト(フィッシング)、なりすましメールアドレス / >私自身、さくらDNSの利用者でしたので、他人事ではありません。とりあえず、さくらDNSで運用していたhash-c.co.jpドメインは引っ越しました
  • 「DNS浸透問題」は脆弱性だった!「幽霊ドメイン名脆弱性」:Geekなぺーじ

    「浸透いうな!」という掛け声が一部界隈で有名な「DNS浸透問題(もしくは、DNS浸透いうな問題)」ですが、今年2月にDNS浸透問題の原因の一つとなっている現象と同じものに起因する新たな脆弱性が発表されました。 その名は「幽霊ドメイン名脆弱性(ghost domain names)」です。 一見、DNS浸透問題とは全く別の問題のように思える「幽霊ドメイン名脆弱性」ですが、それが発生する原因と状況をよく見ると、「あ!これってDNS浸透問題で言ってた話と同じ原因だよね!?」とわかります。 実際、後述する通り、幽霊ドメイン名脆弱性の発想をDNS浸透問題と組み合わせることで、他人のDNS引っ越しを妨害するDoS攻撃も可能になります。 そう考えると、問題発生原因を調べずに「DNSの浸透をお待ち下さい」で済ませてしまうのは脆弱性の放置であるという考え方もできそうです(*1)。 ここでは、幽霊ドメイン名脆

    itochan
    itochan 2012/03/22
    古い方も設定すればOKぽい ということなら、DNSの問題なのか 設定作業者の問題なのかってことになるような。 / という説明あった http://internet.watch.impress.co.jp/docs/event/iw2011/20111201_494798.html
  • DNSSECを破る ("Breaking DNSSEC" 日本語訳)

    ("Breaking DNSSEC" 日語訳) D. J. Bernstein University of Illinois at Chicago 1993年11月 Galvin: 「ある朝、DNSワーキンググループにおけるDNSセキュリティチームの メンバーがヒューストンのIETFで会った」 1994年2月 Eastlake-Kaufman、 dns-security メーリングリストでの数ヶ月の議論のあと 「DNSSEC」プロトコル仕様が作られる。 DNSSECの調査研究に、百万ドル単位の政府予算が使われる: たとえば DISA から BIND company へ、 NSF から UCLA へ、 DHS から Secure64 Software Corporation へ。 現在のインターネットには、 およそ 80000000個の *.com ドメインがある。 2008年8月20日:

  • United States

    Microsoft has a fix for preventing the next CrowdStrike fiasco, but is it a good one?Maybe giving security firms access to the Windows isn’t the best idea, but freezing them out could be worse.

    United States
    itochan
    itochan 2010/03/18
    ケータイのあれは防げないから重大問題だったけど、PCではきちんとやtれば防げるはず ではどうやって、が知りたい
  • セキュリティ情報 - iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性

    iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性 HASHコンサルティング株式会社 公開日:2009年11月24日 概要 iモードブラウザ2.0のJavaScriptDNS Rebinding問題の組み合わせにより、iモードIDを利用した認証機能(以下かんたんログイン)に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。 背景携帯電話のかんたんログインとは、ケータイブラウザ(たとえばiモードブラウザ)に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送

    itochan
    itochan 2009/11/24
    ケータイ本体のブラウザがセキュリティアップデート可能なのなら、旧機種のケータイ本体のブラウザの機能アップデートもやってくれればいいのに…
  • Turks hijack Kiwi MSN via DNS cracks

  • One in ten DNS servers still vulnerable to poisoning

    itochan
    itochan 2008/11/12
    全DNSのうち安全なのは90%だけ
  • OpenIDにフィッシングの危険発覚

    DNSキャッシュポイズニングの脆弱性の影響で、「OpenID」の認証システムが危険にさらされているという。 最近問題になっているDNSキャッシュポイズニングの脆弱性に関連して、シングルサインオンに使われる認証システム「OpenID」の弱点が指摘されている。 Sun Microsystemsのロビン・ウィルトン氏は、ブログでこの問題について解説。OpenIDはDNSシステムに依存しているため、根幹となるDNSインフラがキャッシュポイズニング攻撃を受けると、OpenIDの発行や認証を担う「OpenIDプロバイダー」(OP)と、OpenID対応サイトの「Relying Parties」(RP)の間で正規サイトと偽サイトの区別ができなくなるだろうと指摘した。 Googleセキュリティ担当者ベン・ローリー氏とケンブリッジ大学の研究者リチャード・クレイトン氏も、この問題についてアドバイザリーを公開し

    OpenIDにフィッシングの危険発覚
    itochan
    itochan 2008/09/16
    「さまざまなOPのTLSサーバ証明書で暗号強度の弱い鍵が使われている」のが原因で、「こうした弱いTLS認証に対応する非公開鍵を攻撃者が見つけ、(OPの)偽サイトを開設」できるんだそう。  OPがまともなら問題なし
  • DNSの危機に対応を

    DNSの危機に対応を! 〜キャッシュ毒入れ新手法 Kaminsky Poisoning 〜(8/28 脅威についての説明追記) 2008年7月、セキュリティ技術者 Dan Kaminsky 氏が考案したDNSに対する新たな攻撃手法が明らかになり、8月6日、Kaminsky氏による発表がセキュリティ関連の国際会議 Black Hatで行われました。 これはDNSキャッシュサーバに偽の情報を注入(毒入れ/Poisoning)するものです。DNSは原理的にキャッシュへの毒入れ脆弱性を持ち合わせており、特に脆弱な実装のDNSサーバソフトウェアでは過去に何度か対応が図られてきました。今回あきらかになった手法は従来手法よりはるかに効率的に、状況によってはほぼ確実に毒入れができるというもので、大変危険なものです。 すでに攻撃コードも公開されており、被害も発生していることが報告されています。 まず、以下の

  • DNSサーバーに存在するぜい弱性の詳細情報が流出

    McAfee Avert Labs Blog 「“The-Cat-is-Out-of-The-Bag” DNS Bug」より July 23,2008 Posted by Ravi Balupari ダン・カミンスキー氏は先ごろDNSサーバーに存在するセキュリティ・ホールを発見したが,多くの情報を伏せていた。そしてIT業界に広く働きかけた結果,複数のDNS関連ベンダーが修正パッチを公開してきた。ところが,同氏はセキュリティ・ホールの技術的詳細を公開していないにもかかわらず,関連情報が誤って米マタサノ・セキュリティのブログから大量に漏れてしまったらしい(関連記事:DNSサーバーに見つかったぜい弱性の詳細が公開,すぐにパッチの適用を)。 編集部注:このDNSサーバーのぜい弱性について,カミンスキー氏は8月に開催されたBlack Hatで情報を公開した(関連記事:カミンスキー氏,DNS脆弱性につ

    DNSサーバーに存在するぜい弱性の詳細情報が流出
  • 詳細が明かされたDNSキャッシュ・ポイズニングの新手法

    2008年7月から世界的に話題になっているDNSキャッシュ・ポイズニングを効率的に実現する手法について,発見者であるダン・カミンスキー氏が,Black Hat 2008の席上でプレゼンテーションを行いました(8月6日)。このキャッシュ・ポイズニングのぜい弱性については,いろいろ動きがありましたので,ぜい弱性に関連するイベントを追いかけておきましょう。 ■キャッシュ・ポイズニングのぜい弱性の対応経過 まずは,ぜい弱性に代表的なイベント一覧です。他の関連イベントについては, Status Tracking Note TRTA08-190B:複数の DNS 実装にキャッシュ・ポイズニングのぜい弱性 を参照してください。 2008年7月8日 BINDを含む複数のDNSサーバーが,ダン・カミンスキー氏が指摘するキャッシュ・ポイズニングを効率的に実現する手法に対してぜい弱であったことから,対策版がリリ

    詳細が明かされたDNSキャッシュ・ポイズニングの新手法
  • ptlabo.net

    ptlabo.net 2018 Copyright. All Rights Reserved. The Sponsored Listings displayed above are served automatically by a third party. Neither the service provider nor the domain owner maintain any relationship with the advertisers. In case of trademark issues please contact the domain owner directly (contact information can be found in whois). Privacy Policy

    itochan
    itochan 2007/07/17
    セルクマ。
  • 1