森永乳業の情報漏洩、正確な情報が少ない訳
森永乳業は2018年5月9日、同社の通販サイト会員の情報が漏洩した可能性があると公表した。だが、被害人数が報道によって2万3000人だったり、12万人だったりと大きく異なる。また、漏洩した可能性のある情報はセキュリティコードを含むカード情報としているが、会員のメールアドレスやパスワード、住所、電話番号などが含まれているかどうかを明らかにしていない。 同社は、クレジットカード会社から不正利用の被害が発生していると4月24日に指摘を受けて事態を把握していた。そこから既に2週間が経過しているのに、どうしてもっと正確な情報が出てこないのか。 被害人数の2万3000人は森永乳業による推測 森永乳業は、クレジットカード会社から指摘を受けた4月24日にセキュリティ会社に調査を依頼。最終結果は5月末日までに報告されることになっているが、「公表した5月9日時点では、被害の範囲や漏洩経路に関する中間報告を受け
「VPS」サービスにおけるMeltdownおよびSpectreへの対応について | さくらのサポート情報
検索対象 すべて サポート情報 よくあるご質問 動画マニュアル 個人情報保護のため、お名前や連絡先、会員IDを入力しないでください。サイト内検索について
パスワードに依存しない認証「WebAuthn」をChrome/Firefox/Edgeが実装開始、W3Cが標準化。Webはパスワードに依存しないより安全で便利なものへ
Google、Mozilla、マイクロソフトが「WebAuthn」の実装を開始。これによって「FIDO2」の普及が期待され、Webブラウザから指紋認証や顔認証などで簡単にWebサイトへのログインや支払いの承認といった操作が実現されそうだ。 多くのWebアプリケーションは、ユーザーの認証にユーザー名とパスワードの組み合わせを用いています。 しかしユーザー名とパスワードの組合わせを用いる方法にはさまざまな問題が指摘されています。身近なところでは、安全なパスワードを生成することの手間や、安全性を高めるためにパスワードの使い回しを避けようとした結果発生する多数のパスワードを管理することの手間などがあげられます。 そしてこうしたパスワードの不便さが結果としてパスワードの使い回しを引き起こし、いずれかのサイトで万が一パスワードが流出した場合にはそれを基にしたリスト型攻撃が有効になってしまう、などの状況
弊社WEB予約サービスに対する不正アクセスに関する最終報告｜九州商船
2018年3月30日 お客様 各位 九州商船株式会社 代表取締役社長 美根 晴幸 この度、弊社WEB予約サービスに対する不正アクセスにつきましては、お客様に多大なるご心配とご迷惑をお掛けいたしましたこと、深くお詫び申し上げます。 弊社では、今回の不正アクセスにつきまして、社外の専門家により構成される調査委員会を設置し、本件不正アクセスの事実関係の調査、原因究明、お客様情報漏えいの蓋然性の評価、再発防止策の提言について調査、検討してまいりましたが、この度、最終的な報告書を受領いたしましたので、下記の通りご報告させて頂きます。 １．不正アクセスに関する調査について WEB予約サービスに対して第三者による不正アクセスが行われたことが判明しております。 今回、不正アクセスの対象となったサーバーは、WEB予約サービスを提供しているサーバーです。 本システムでは、お客様情報はWEBサーバーには保存せず
九州商船の「弊社WEB予約サービスに対する不正アクセスに関する最終報告」は全てのエンジニアに読んでほしい - orangeitems’s diary
最終報告書を読む 九州商船株式会社のWEB予約サービスに対する不正アクセスについて、最終報告書が公開されました。報告書を読ませていただきましたが、その内容に関して大変勉強となることが多く含まれています。 弊社WEB予約サービスに対する不正アクセスに関する最終報告｜九州商船 ※ITmediaでニュースにもなっていましたので追記しておきます。 japan.zdnet.com 不正アクセスの目的は、linuxに不正侵入し仮想通貨マイニングを行うというものです。データを盗み出すのではなくマイニングというところが2018年っぽいです。ただCPUが100%に張り付くのですぐに見つかってしまっていますが。 この報告書について考察してみます。 原因についての考察 原因はvsftpdで使っているFTPプロトコルをANYで開けていて、ブルートフォースでパスワードが割れてしまったこと。かつ、OS/ミドルウェアの
CPU攻撃の新たな手法「BranchScope」、Intel製CPUで実証
CPU攻撃の新たな手法「BranchScope」、Intel製CPUで実証：カーネギーメロン大学などの研究チームが発表 米カーネギーメロン大学などの研究チームが発表した「BranchScope」では、1月に発覚した「Spectre」と同様に、サイドチャネル攻撃を仕掛けてセンシティブなデータを流出させる。 米カーネギーメロン大学などの研究チームが、IntelなどのCPUの脆弱性を突く新たな攻撃手法「BranchScope」に関する論文を発表した。1月に発覚した「Spectre」と呼ばれる脆弱性と同様の仕組みで、IntelのCPUや、セキュリティ機能の「Software Guard Extensions（SGX）」に対して攻撃が通用することを実証したとしている。 論文によると、BranchScope攻撃では、現代のCPUが性能向上のために実装している分岐予測ユニット（Branch Predic
GraphQL運営で考えるべきセキュリティ | NTT Communications Developer Portal
単一のエンドポイントで、クライアント側で指定することで任意のデータを取得できるGraphQLですが、ビジネスで利用する際に必ず注意しなければならないのがセキュリティでしょう。GraphQLを利用、提供する上での注意点を紹介します。 認証 GraphQLではサーバサイドのデータベースのようにID/パスワードのような仕組みは用意されていません。他のAPIと同様に、認証技術と組み合わせることができます。例えばOAuth2であったり、トークン認証になります。これらは自分で実装する必要があります。 そのため、REST APIとGraphQLの共存は難しいことではありません。取得（GET）についてはGraphQLを、データの追加/更新/削除はREST APIといった具合に使い分けることもできます。その際、どちらも同じ認証データを用いられるでしょう。 ネスト GraphQL特有の問題として、関連データの
RPCに特化したGoogleのセキュリティ通信ALTSとは何か - ぼちぼち日記
はじめに 昨年、Googleから Google Cloud Platform に関するWhitePaperがいくつか公開されました。その中でGoogleのサービス内部で使われている新しいALTSというプロトコルを説明した文書「Application Layer Transport Security」は、読んでみると非常に面白く、セキュアなサービス間通信には本当に何が必要なのか、といったことを改めて深く考えさせられるものでした。物理的なマシンからサービス運用まで、ALTSがカバーする範囲は幅広い領域に渡り、あの巨大なGoogleのサービスをよくここまでまとめ上げたものだとホント感心させられます。 以前から、Googleはデータセンタ内のサービス通信までも暗号化を進めていると言われていました。それは、2013年にエドワード・スノーデンが暴露した資料が、Googleのデータセンタ内部の通信データ
今なぜHTTPS化なのか？インターネットの信頼性のために、技術者が知っておきたいTLSの歴史と技術背景
【変更履歴 2018年2月15日】当初の記事タイトルは「いまなぜHTTPS化なのか？ 技術者が知っておきたいSEOよりずっと大切なこと ― TLSの歴史と技術背景」でしたが、現行のものに変更しました。現在GoogleではWebサイトのHTTPS対応と検索結果の関係を強調しておらず、本記事の趣旨の一つにも本来は独立した問題であるSEOとHTTPS化を関連付けるという根強い誤解を解くことがありますが、当初のタイトルではかえってSEOとHTTPSを関連付けて読まれるおそれがあり、また同様の指摘もいただいたことから変更いたしました。 HTTPとHTTPSは、共にTCP通信上で動作します。したがって、いずれもTCPハンドシェイクで通信を開始します。 HTTP通信の場合には、このTCPハンドシェイク直後に、HTTPリクエストとレスポンスのやり取りが始まります。このHTTPのやり取りは平文通信であり、途
memcachedの開放ポート(11211/tcp, 11211/udp)をサクっと確認する - ろば電子が詰まつてゐる
昨日(2018/02/27)に、JPCERTからmemcached のアクセス制御に関する注意喚起が出ていました。 ということでmemcachedのポート(11211/tcp, 11211/udp)が開放されていないかの確認方法についてメモしておきます。 memcached開放により起きる問題 はじめに、memcachedのポートを外部から接続可能にしてしまうと何が問題か整理しましょう。 内部情報の漏洩 1つはすぐに思い付くことですが、内部情報の漏洩です。memcachedは認証の無いプロトコルであるため(正確にはあるけど、誰も(?)使ってない)、外部から接続できれば即キャッシュ上の値を取得することができます。 たとえばphp.iniで以下のように設定していれば、 session.save_handler = memcached session.save_path = "localhost
GitHubに過去最大級のDDoS攻撃--「memcached」を悪用
GitHubが、過去最大規模とみられるDDoS攻撃を受けたことを明らかにした。 GitHubに対する最初の攻撃は最大1.35Tbpsに達し、2度目の攻撃は400Gbpsだった。つまり、これは記録されている限り過去最大のDDoS攻撃ということになる。これまで、最大の攻撃はおよそ1.1Tbpsだった。 GitHubは開発者向けブログで、GitHub.comがDDoS攻撃の影響で協定世界時28日17時21分から17時26分まで利用できなくなり、17時26分から17時30分までは断続的に利用不可となっていたことを明らかにした。 GitHubは、この攻撃で「ユーザーのデータの機密性や完全性が危険にさらされる」ことは全くなかったとしている。 「2月28日17時21分から17時30分までの間、われわれは膨大な量のDDoS攻撃を検知し、これに対処した。この攻撃は、数万に及ぶ固有のエンドポイントにわたる10
エンジニアなら脆弱性情報を読めるようになろう | Tech Blog
こんにちは、アドテクスタジオでセキュリティエンジニアをしている岡崎です。 皆様、年末年始はゆっくりできましたでしょうか。私は年始に公開された「Meltdown and Spectre」のお陰で年始早々、情報整理に追われてました。 今回は、先日「Meltdown and Spectre」の脆弱性のこともあり、脆弱性情報の見方と脆弱性情報API活用について、書かせていただきます。 １，脆弱性情報の見方 エンジニアの方であれば、脆弱性情報を確認する中でCVEやCVSSなどを目にすることが多いと思います。それぞれどのような意味を持ち、どのように見るのかを知っておきましょう。 先日あった「Meltdown and Spectre」を例に見ていきましょう。 https://meltdownattack.com/ https://spectreattack.com/ まず、このような脆弱性情報が公開され
aws-vault でアクセスキーを安全に - FLINTERS Engineer's Blog
あけましておめでとうございます。河内です。 数ヶ月前に aws-vault を使い始めて安全の高まりを感じるので紹介します。 AWSのサービス上では IAM Role をできるだけ使ってアクセスキーを使わないようにしていますが、ローカルでの開発時にIAMのアクセスキーを利用することはあります。 アクセスキーが漏れると困ったことになります。 本番環境で利用している AWS アカウントで漏れると、付与している権限次第では機密情報が漏洩したりサービスが壊される可能性があります。 また開発環境としてのみ利用しているAWSアカウントであっても、ビットコインのマイニングなどで容赦なくリソースを消費され高額な請求が来たりする可能性ががあります。 そのようなことが起きないようにアクセスキーは安全に管理する必要があります。 通常はAWS SDK のデフォルト参照先である ~/.aws/credentials
AWSもSpectreとMeltdownの対策完了を報告。対策後、Amazon EC2で性能の低下は見られないと
Amazon Web Services（AWS）は、「Spectre」および「Meltdown」と名付けられたCPUの脆弱性に関して同社の対応をまとめたWebページ「Processor Speculative Execution Research Disclosure」において、すでに脆弱性対策が済んだことを報告しています。 AWSがこうした特設ページを設けるのは珍しいことで、本件の重要性と緊急性の高さがうかがえます。 ただ、Googleが脆弱性の詳細な報告と対策の経緯などを詳細にブログで開示したのに対し、AWSの情報提供は実務的であっさりしたものになっています。 Amazon EC2のワークロードに性能低下は見られない 下記はAmazon EC2に関する報告を引用したものです。すべての対策が済んだと報告されています。また、OSのアップデートが推奨されています。 All instances
Googleが発見した「CPUの脆弱性」とは何なのか。ゲーマーに捧ぐ「正しく恐れる」その方法まとめ - 4Gamer.net
Googleが発見した「CPUの脆弱性」とは何なのか。ゲーマーに捧ぐ「正しく恐れる」その方法まとめ ライター：米田 聡 一般メディアにもニュースとして取り上げられたので，2017年末からにわかに騒がれだした「CPUの脆弱性」については，4Gamer読者も多くが聞き及んでいることだろう。海外では，「Spectre」（スペクター）や「Meltdown」（メルトダウン）といったおどろおどろしい名前が付いているので，そちらを目にしたという読者もいると思う。 「Intel製のCPUだけが持つ脆弱性で，AMD製のCPUなら問題ない」から始まって，「いやいやAMD製のCPUも同様の脆弱性を抱えている」，さらには「メモリページング方式の仮想記憶を使うCPUのすべてが持つ脆弱性である」などと，情報が錯綜しているので，何を信じたらいいのか分からないという人も多いのではなかろうか。そもそも，メモリページング方式
SIPとcronの不具合を利用しmacOS 10.13.1 High Sierraで非rootユーザーがroot権限を得られる脆弱性が発見されたもよう。
SIPとcronの不具合を利用しmacOS 10.13.1 High Sierraで非rootユーザーがroot権限を得られる脆弱性が発見された様です。詳細は以下から。 イギリスPosixOne Ltdのエンジニアでセキュリティ研究者のMark Wadhamさんはあるソフトウェアのセキュリティ調査を行っていた際、macOS 10.13.1でセキュリティ整合性保護機能(SIP:通称rootless)で保護されていないファイルに非rootユーザーで書き込めてしまう不具合を発見したそうで、書き込みを行ったファイルは所有者がrootから変更されてしまうようですが、 Getting root on macOS High Sierra 10.13.1 (via insecure cron system) : https://t.co/i3EKDzdrP9 cc @m4rkw — Binni Shah
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コンテナを守る技術2018/container-security-20180310
ComputerworldとCIO Magazineは閉鎖しました
SIOS Tech. Lab - エンジニアのためになる技術トピックス
セキュリティの都市伝説を暴く
