The requested URL was rejected. Please consult with your administrator. Your support ID is: 721119603503596949 [Go Back]
crt.sh Certificate Search Enter an Identity (Domain Name, Organization Name, etc), a Certificate Fingerprint (SHA-1 or SHA-256) or a crt.sh ID: Advanced... © Sectigo Limited 2015-2024. All rights reserved.
こんにちは。技術部の池田です。 この記事では、Github Actions上に「強い」AWSの権限を渡すために以下のことを行います。 App Runnerでお手軽にGoogle ID Token 取得するためのWeb Applicationを動かす。 Web Applicationから取得できるGoogle ID Tokenを信頼するIAM RoleにAssumeRoleする。 AssumeRoleによって得られた一時的な強い権限で、強い権限を要求する作業(Deploy, Terraform Apply)をGithub Actionsで行う。 これにより、Github Actions上にAWSのアクセスキーを置かずに、ある程度安全な方法でAWS上での強い権限を要求する操作を実行できます。 そのため、例えばGithub Repositoryに不正アクセスされてしまったとしても、AWSの本番環
2020年4月13日、Classi(以下Classi社と記載)は同社のクラウドサービス「Classi」が不正アクセスを受け、IDや暗号化されたパスワード文字列などが閲覧された可能性があると発表しました。ここでは関連する情報をまとめます。 corp.classi.jp 2時間で122万人のIDなどが閲覧された可能性 不正アクセスの概要 Classiへの不正アクセスは4月5日 日曜日の昼過ぎから夕方にかけ発生。発生時間は2時間14分。 社内のデータベースで異常発生が検知されたことが発端。データベースが直接被害を受けていたのかは報じられていない。 Classi社の発表に「外部専門会社の協力を得て不審ファイルや通信ログを解析したところ」とあり、Classi上に何らかのファイルが蔵置されていた可能性がある。 第三者に閲覧された可能性のある情報は次の通り。 閲覧された可能性のある情報 Classi社は
« Microsoft Word を Markdown に変換するコマンド「docx2md」を作った。 | Main | VimConf 2019 を終えて » Linux の sudo に root 権限を奪取できるバグが見つかった。 Linuxの「sudo」コマンドにroot権限奪取の脆弱性。ユーザーID処理のバグで制限無効化 - Engadget 日本版 この脆弱性は、sudoコマンドのユーザーIDに-1もしくは4294967295を指定すると、誤って0(ゼロ)と認識して処理してしまうというもの。0(ゼロ)はrootのユーザーIDであるため、攻撃者は完全なrootとしてコマンドを実行できることになります。 https://japanese.engadget.com/2019/10/14/linux-sudo-root-id/ 既に Ubuntu 等にはパッチが配布され始めているらしい
送信元表記が送信者IDのケース SMSのメッセージを受信した際に表示される送信元には、電話番号の代わりに任意の英数字も表記できる。この英数字の送信元表記を「送信者ID(Sender ID)」という。JC3の図では 通信事業者A が送信者IDに当たる。 なお送信者IDの利用可否は受信側の通信事業者の対応状況によって異なる。Twilioの販売パートナーであるKWCの説明によると、日本国内ではNTT DOCOMOとSoftBankが送信者IDに対応し、KDDIは対応していないとのこと²。私はKDDIの回線を所有していないため、受信側がKDDIの電話番号を使用している場合の挙動は検証できていない。 まずはiOSの公式メッセージアプリに届いていたAmazonからのメッセージのスレッドで偽装を試みる。送信者IDは Amazon となっているため、TwilioでSMSを送信する際のFromの値に Ama
他人のIDやパスワードを使って不正アクセスし、携帯電話の決済システムを使ってインターネットで商品購入を繰り返したとして福井県警に逮捕された女が、名前や誕生日を示すアルファベットと数字を適当に組み合わせてIDやパスワードを探し当てていたことが9月11日、福井地裁での初公判で分かった。全国に被害者がおり、福井地検は追起訴する方針。 検察側が冒頭陳述で明らかにした。システムは「キャリア決済」と呼ばれるもので、インターネットなどで購入した商品の代金を携帯電話料金と合算して支払う仕組み。 被告は、不正アクセス禁止法違反と電子計算機使用詐欺の罪に問われた岐阜県の無職女(20)=犯行当時(19)。人の名前を示すアルファベットの文字列に続き、01~12と01~31を組み合わせた数字4桁を適当に入力し単純なID、パスワードを探し当てていた。 起訴状によると2018年12月~19年4月、自分のスマートフォンか
備考 2018/09/21 22:15 追記 2018/09/20 12:10 に公開した「どうして JWT をセッションに使っちゃうわけ?」というタイトルが不適切だとご指摘をいただいています。 その意見はもっともだと思いますので、現在、適切となるようにタイトルを調整しています。 ご迷惑およびお騒がせをして大変申し訳ございません。 本文の表現についても改善の余地は大いにありそうですが、こちらは (すでにご意見を頂戴している関係で、) 主張が変わってしまわないように配慮しつつ慎重に調整させていただくかもしれません。 はあああ〜〜〜〜頼むからこちらも忙しいのでこんなエントリを書かせないでほしい (挨拶)。もしくは僕を暇にしてこういうエントリを書かせるためのプログラマーを募集しています (挨拶)。 JWT (JSON Web Token; RFC 7519) を充分なリスクの見積もりをせずセッシ
県警でサイバー犯罪を担当している人から話を聞いた時のメモが出てきたので下記にまとめる。 メモは2年ほど前のもので、現在の警察の見解とは異なっている可能性がある。 IDとパスワードの管理について同じIDとパスワードを複数のWebサービスで使い回している人は非常に多い。定期的にパスワードを変更することは使い回しの温床になるので推奨していない。IDとパスワードの使い回しを狙って、不正取得したIDとパスワードを複数のサービスに1回ずつ入力して侵入を試みる手口が増えている。1回ずつしか試みられないので不正検知が難しい。フィッシングやスパイウェア等によるtechnicalな不正アクセス事案は全体の4割程度であり、残り6割はパスワード設定管理の甘さや知人・友人にパスワードを漏らしたことによるソーシャルな手口である。10代のオンラインゲームの不正操作事案が急増傾向にある。不正アクセス禁止法について不正アク
2014年11月19日、20都道府県警の合同捜査本部が国内で違法にプロキシサーバーを運営する全国8業者へ一斉捜索をかけました。ここではその関連情報をまとめます。 タイムライン 大光・SUNテクノ関連 日時 出来事 2013年4月〜8月 AmebaへSUNテクノのサーバーから不正ログインが行われた可能性。 2014年1月 愛知県警が偽サイトのIPアドレスからSUNテクノを割り出し。*1 2014年2月頃 SUNテクノのサーバーに大手銀行(MUFJ?)のフィッシングサイトが開設。*2 2014年3月頃 SUNテクノのサーバーに大手銀行(MUFJ?)のフィッシングサイトが設置され当月だけで約1万3千件のアクセス。*3 2014年8月 大光とSUNテクノが捜索を受ける。 その後 大光と他1社がISPから不正行為に関わったとして契約を解除。 その後 大光、SUNテクノが他人のIDを使ってインターネッ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
こんにちは、技術部の福森 (@sora_h) です。 最近は環境変数に API トークンや credential といった認証情報を入れる事が増えてきています。 たとえば、AWS を利用するツールでは AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY といった環境変数にだいたいの場合で対応しています。 そのため、~/.bashrc や ~/.zshrc などシェルの設定に export を書いておき常に使える状態にしている方も多いと思いますが、 それって実は危険ではないでしょうか? 例えば、下記のようなリスクが考えられます: 意図せず情報が利用されて意図しない副作用が発生してしまう危険性 本番に変更を与えるつもりはなかったけれど事故を起こしてしまう等 悪意のあるスクリプトを実行した際に環境変数を送信などされてしまう危険性 事故や漏洩を防ぐためにも、筆者はかな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く