- 1. JavaScriptの問題 「DOM Based Xss / Webストレージの不適切な使用」
- 2. Linuxセキュリテイ対策 ホストの侵入検知（chkrootkit/rkhunter/maldetect）
- 3. ID インフラストラクチャをセキュリティ保護する 5 つのステップを読み解く
- 4. IAMベストプラクティスにほぼほぼ準拠したIAMユーザ・グループ作成と、MFA デバイスの自己管理を許可するポリシーの取り扱い注意点
- 5. AWS Well-Architected Framework「セキュリティ」
- 6. Linuxの監査システム Auditについて理解する
- 7. リモートワークする時に気を付けている事。（自宅編）
- 8. ウェブアクセスをドメイン名で任意のインターネット接続回線へ振分ける（Mac上の仮想マシンに色々試行できるUTM的な環境を作って遊んでみる）
- 9. 新しく利用するドメインやIPアドレスが闇サイトの使いまわしでないことを確認するには
- 10. [月次配信] Oracle WebLogic RCE脆弱性(CVE-2019-2890)の分析及び対応方法
- 11. Gmailを無料で使わせていただいている限り手厚いサポートは受けられないという小話
- 12. DFIR用のツール「Velociraptor」を使用してみる
- 13. MFAを設定するときは別の手段で復旧できることを確認しよう
- 14. あえてセキュリティエンジニアをオススメできない理由をまとめてみた
- 15. Azure Sentinel のセキュリティ プレイブックを作成し、リスク検知時に Teams にメッセージを投稿する
- 16. Azure Sentinel に Azure AD と Identity Protection のログを取り込んで可視化してみる
- 17. Process Hackerを利用した自動アンパックの手順
- 18. IoT@Loft #8 スマートホームのセキュリティ脅威と対策 を受講したよ!（2020年2月19日実施）
- 19. SSL証明書でIPアドレスからホスト名が漏れる
- 20. 安全な廃棄のために使用すべきストレージの機能(2/2)
JavaScriptの問題 「DOM Based Xss / Webストレージの不適切な使用」
JavaScriptにまつわる脆弱性について。
「DOM Based Xss」と「Webストレージの不適切な使用」について記載する。[JavaScript | MDN](https://developer.mozilla.org/ja/docs/Web/JavaScript)
#DOM Based Xs
1. 概要
2. 攻撃手法と影響
3. 脆弱性が生まれる原因
4. 対策##概要
JavaScriptが原因で発生するXXSをDOM Based Xssと呼んでいる。
XXSはサーバ側のプログラムの不備が原因で発生するが、クライアントサイドで動作するJavaScriptの記述の不備で発生するケースもある。
このケースがDOM Based Xssに該当する。##攻撃手法と影響
###影響
通常のXSSと同じ。具体的な被害としてはフィッシング詐欺、セッションハイジャック、ウェブサイトの改ざんなど。– クッキー値の盗み出し
– その他のJavaScriptによる攻撃
– 画像の書き換え###攻撃手法
– innerHTMLプロパティ
– document.writeメ
Linuxセキュリテイ対策 ホストの侵入検知（chkrootkit/rkhunter/maldetect）
# はじめに
本記事はLinuxのセキュリティ対策として、ホストの侵入検知について記載しています。ホストの侵入検知の目的は、ルートキットの存在やマルウェアを検知することです。
本記事では以下のツール（※）を扱います。
– chkrootkit
– rkhunter
– maldetect（※）バージョンについては本記事執筆時点の最新バージョンを使用
## chkrootkit
chkrootkitはルートキットの存在を検知するためのツールです。
CentOSの標準リポジトリには、Ubuntuのようにchkrootkitのパッケージは含まれていません。chkrootkitは[chkrootkit.org](http://www.chkrootkit.org/)の[Download](http://www.chkrootkit.org/download/)からダウンロードできます。
本記事ではCentOS 7を例にchkrootkitの導入手順について解説します。なお、chkrootkitは以下のコマンドを使用します。既に改ざんされた後では意味がないため、導入時には考
ID インフラストラクチャをセキュリティ保護する 5 つのステップを読み解く
#はじめに
今から書く内容は、Microsoft の公開情報である「ID インフラストラクチャをセキュリティ保護する 5 つのステップ」の内容をかみ砕いて書いています。-参考情報
ID インフラストラクチャをセキュリティ保護する 5 つのステップ
URL:https://docs.microsoft.com/ja-jp/azure/security/fundamentals/steps-secure-identity以下の設定を施したからといって、セキュリティ保護が万全になるわけではありません。
逆に以下の設定を必ずしもすべて設定しないといけない、というわけでもありません。この記事を書いた意図としては、ID を正しく保護するための方法が複数用意されているので、ご利用の環境に合わせて選択していただくための一助にして欲しいからです。
下記 Microsoft 公開情報にベストプラクティスとして書かれている記事がありますので、そちらも参考にしてみてください。
-参考情報
Azure の ID 管理とアクセス制御セキュリティのベスト プラクティス
URL:https://doc
IAMベストプラクティスにほぼほぼ準拠したIAMユーザ・グループ作成と、MFA デバイスの自己管理を許可するポリシーの取り扱い注意点
# 1. はじめに
* AWS マネジメントコンソール作業で使用するIAMグループ や IAMユーザーの設計や作成フローを、[IAM ベストプラクティス](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html) を参考にして見直してみる。
* けど、IAMグループ や IAMユーザー の作成に関する [IAM ベストプラクティス](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html) をすべて採用するのは窮屈なので、採用するものを決めて My IAM プラクティスを作成してみる。
* そして、My IAM プラクティスに準拠したIAM グループ、IAMユーザーの作成フローを構築してみる。
* 例として、新規に参画したAWS マネジメントコンソール作業者で、開発チームのAさんの IAM ユーザーを作成してみる。
* あと、IAMポリシーとIAMグ
AWS Well-Architected Framework「セキュリティ」
セキュリティの柱の7つの設計原則をざっくりまとめてみたいと思います。
この内容はnoteのほうで投稿したものと同じ内容になります。
「[②最重要項目：セキュリティ](https://note.com/yoriasanuma/n/n9df28ba45578)」####1, 強力なアイデンティティ基盤の実装
アカウントの用途によって与える操作権限を分けましょう。システムを管理するためのアカウントには設定変更・リソースの追加・削除ができる権限を与え、その他のアカウントには設定値やリソースの使用状況の参照のみできる権限を与えるなど、必要最低限の権限のみ与えるようにします。また、多要素認証（自分で設定したパスワード＋一時的に発行される認証コードなど）を利用することでセキュリティを向上できます。権限を一元管理し、認証情報も適切に管理しましょう。
####2, トレーサビリティの実現
だれが、いつ、どんな操作をしたかを常に監視し、ログとして記録しましょう。AWSサービスを組み合わせて、不正なアクセスやリソースの状態の変化をリアルタイムで検知し、自動でアクションを実行させることができます。
Linuxの監査システム Auditについて理解する
# はじめに
本記事はLinuxの監査システムであるAuditについて記載しています。AuditはLinuxの監査システムとして、監査ルールを定義し、システムで発生したセキュリテイに関するイベントをログファイルに出力します。
ログファイルに出力されたメッセージを監視することで、セキュリテイに関するイベントを検知することができます。
Auditでは以下の監査ルールが設定可能です。
– 制御ルール
– システムコールルール
– ファイルシステムルール## Auditの概要
Auditはauditdデーモンとして起動し、カーネルから受け取った監査結果をログファイルに出力します。全般的な設定は`/etc/audit/auditd.conf`ファイルで設定します。
– /etc/audit/auditd.conf
“`text
#
# This file controls the configuration of the audit daemon
#local_events = yes
write_logs = yes
log_file = /var/log/audi
リモートワークする時に気を付けている事。（自宅編）
###はじめに
こんにちは。K’s Software Designです。よろしくお願いします。
さて、以前は喫茶店やカフェでリモートワークをする場合の注意点など書かせて頂きました。今回は自宅からリモートワークする場合に注意しているポイントを書かせて頂きたいと思います。
自宅でリモートワークする場合も喫茶店・カフェ編で書いたポイントは有効だと思います。VPNを使ったりハードディスクを暗号化したりですね。自宅ならではのポイントを幾つかまとめてみました。###Wifi（無線LAN）のSSIDは変更しましょう。
SSIDを初期値のまま使用している家が多いと思います。多くの機器は初期値のままですと、メーカー名や商品名を特定することが出来ると思います。取り扱い説明書、マニュアルを入手して初期パスワードで機器に悪戯ができるかもしれません。機器に脆弱性があった場合、その脆弱性が利用されるかもしれません。ご利用の機器のメーカー名・商品名が簡単にわからない為にも変更する事をお勧めします。
私はハッシュ値をSSIDとして設定したら、周りから変態扱いされました。（笑）ハッシュはやりすぎですね。
ウェブアクセスをドメイン名で任意のインターネット接続回線へ振分ける（Mac上の仮想マシンに色々試行できるUTM的な環境を作って遊んでみる）
いわゆるVPNサービスを利用していると、時々接続できないサイトかあります。全くダメなら良いのですが、サービスへ認証が成功した瞬間に不審なアクセスと見なされて、いきなりサービスへのアクセスをBANされることもあります。回復には電話したり･されたり等々で、大変手間がかかることが多いです。
– 都度手元端末のプロキシ除外リストへ登録したくない。
– 手元端末のVPNクライアントで同じようなことができない。
– どうせなら色々サイバーなツールを検証できる環境が欲しい。ということで、「ウェブアクセスをドメイン名で任意のインターネット接続回線へ振分けたい、それならUTMっぽくしたMac上の仮想マシンで何とかしてみよう」と思い、色々やってみた次第です。以下、全体的に粗い記述で恐縮ですが「こんなやり方でVPN使う・使わないの制御ができたよ」ということで公開します。
#1. 環境
– 親機
– MacOS 10.15.3 Catalina
– 子機
– Debian 10 (Paralles Desktop 15.1.2 で稼働）#2. 手順
##(1)親機Macの準備
新しく利用するドメインやIPアドレスが闇サイトの使いまわしでないことを確認するには
# 概要
新しくウェブサイトを立ち上げたりメールサービスを利用開始する場合に必ず必要になるのが**独自ドメイン**や**IPアドレス**です。インターネットが一般的になってから既に25年が経過して、[IPv4アドレスは枯渇](https://ja.wikipedia.org/wiki/IP%E3%82%A2%E3%83%89%E3%83%AC%E3%82%B9%E6%9E%AF%E6%B8%87%E5%95%8F%E9%A1%8C)していて、多くの人が取得したい人気のある独自ドメインも、誰かの使いまわしである可能性が高いです。そのために、新しく取得した独自ドメインやIPアドレスを使ってウェブサイトやメールを使い始めたときに、過去に闇サイトやスパム送信で使われていて、セキュリティソフトからブロックされてしまう、といったリスクもあります。
セキュリティソフトで引っかかった例:
の分析及び対応方法
#概要
Oracle社が提供しているOracle Fusion MiddlewareのWebLogic Serverから逆直列化(Deserialization)を迂回し、特定の権限で悪意的なT3プロトコルの要請を通じてリモートコマンドが実行できる脆弱性(CVE-2019-2890)が発見された。脆弱性はWebLogic Severがデータを受信する際にバイナリタイプに変換されたデータを元のタイプに変換する逆直列化の過程で入力値の有効性検証が不足しているため発生する。
CVEリストには2019年10月16日に公開され、同月にOracleの緊急パッチアップデートのリストに含まれ、セキュリティパッチが完了された。
今回はこの脆弱性の動作仕組み及び分析、対処について紹介する。#脆弱性分析
##影響を受けるソフトウェア| CVE | 脆弱バージョン | 危険度 |
|:————-:|:————————————————
Gmailを無料で使わせていただいている限り手厚いサポートは受けられないという小話
現在の状況：通常の使い方ではないと機械判定されGoogleアカウントへのログインをブロックされた。
（unusually usageなんちゃらというメッセージが表示された気がする）原因：短期間にメールマガジンを大量掃除
2010年春に作成したGmail由来のGoogleアカウントでしたが、
– 楽天市場から大量に送信された過去のメールマガジン
– タワーレコードから大量に送信された過去のメールマガジン容量的には合計1GB程度を1日目夕方20分、翌日午前20分程度、検索→ゴミ箱→ゴミ箱全消去の作業を行っていたところ
Googleのセキュリティデーモンにより普通ではないと判定され以後ログインをブロックされました。一応ブロック数分前に連携済みメールアドレスに「削除多すぎ～危ないよ。保護してください」
というメールが来ていたようでしたが作業中につき気づけませんでした。たしかに不正ログインされているような行為と言われても仕方ないです。
不正ログイン・不正削除から一般市民を守るサービス提供側としての言い分も当然あるでしょう。くれぐれも皆さんはGmailの短時間大量消去はおや
DFIR用のツール「Velociraptor」を使用してみる
#Velociraptor とは
アーティファクトを収集し、指定したサーバにアップロードする
?[公式サイト](https://www.velocidex.com/)
開発者SANSの講師っぽい
## 一般的なデジタルフォレンジックの一例
保全した端末でアーティファクトを収集するツールを実行し、HDD/SSD等の外部記憶媒体または、クラウドストレージにコピーし、調査用のPCで解析を行う
## Velociraptor の場合
予め生成したコンフィグをもとに実行ファイルを保全PC内で実行し、Veloci
MFAを設定するときは別の手段で復旧できることを確認しよう
先日ふとしたきっかけでスマートフォンを初期化したのですが、仮想MFAデバイスの「Google認証」が入っているにもかかわらず何も準備せずに初期化してしまったため、(SMS以外の)MFAが設定してあるすべてのサービスにログインできなくなってしまいました:innocent:
## TL;DR
– MFA設定時には、紛失したときに復旧できる手段が正しく動くことを確認する
– 入力時にverifyのチェックが入らない連絡情報は注意する
– AWSの連絡先情報の電話番号は国コード付きのものにする## Googleアカウントは自力で復旧できた
Googleアカウントは復旧用に電話番号の設定をしバックアップコードを控えていたので安心です。
まず電話番号による認証を試したところ、かかってきた電話で読み上げられたPINコードを入力することによって復旧できました。
もし何かしらの事情で電話番号が使えなくなってもバックアップコードによる復旧ができます。## AWSアカウントは自力で復旧できなかった
AWSはMFA紛失時にメールアドレスと電話番号の2ステップによる認証で復旧できるのですが、なぜ
あえてセキュリティエンジニアをオススメできない理由をまとめてみた
#はじめに
企業が情報セキュリティに力を入れるようになり、セキュリティエンジニアの需要がどんどん高まっています。それに伴ってやたらセキュリティエンジニアを勧める記事を見受けられるようになりましたが、それらの大半がセキュリティ関係の仕事をしたことない人たちが書いた内容だと思われます。そのためメリット中心でデメリットについてほとんど書かれていないものが多いです。そこでセキュリティ監視を行っている筆者が、あえてセキュリティエンジニア（特にセキュリティ監視や分析業務）をオススメしない理由をまとめてみたいきます。
（※セキュリティエンジニアになるのはやめた方がいいというのではなく、あくまでもメリット・デメリットをしっかり押さえた上でなって欲しいという趣旨でやってます。メリットしか記述してない記事も多く、デメリットは知らないという状態は良くないので書かせていただきました。）#①深夜作業や休日出勤がある可能性が高い
セキュリティインシデントが原因で機密情報や顧客情報が漏れてしまった場合、信用の失墜など経営の存続に関わる大きな問題につながりかねません。被害を最小限に抑えるため、迅速な対応を求められ
Azure Sentinel のセキュリティ プレイブックを作成し、リスク検知時に Teams にメッセージを投稿する
#はじめに
Azure Sentinel はクラウドネイティブの SIEM (Security Information and Event Management ) です。
Azure 上の サービスだけでなく、AWS CloudTrail や F5 のアプライアンスなど、Syslog エージェントを介して、ログを集約し、多次元的に分析が可能なツールです。Azure Sentinel の基本的なセットアップ手順は以下にまとめていますので参考にしていただけると幸いです。
-参考情報
Azure Sentinel に Azure AD と Identity Protection のログを取り込んで可視化してみる
URL:https://qiita.com/Shinya-Yamaguchi/items/7b4e30065857be797c82今回は、Azure AD Identity Protection で検知したリスクを Teams のチャネルに自動通知する方法を検証してみました。
通知を含むワークフローの機能は、Azure Sentinel の「プレイブック」で実現可能です。
Azure Sentinel に Azure AD と Identity Protection のログを取り込んで可視化してみる
#はじめに
Azure Sentinel は 2019 年 9 月にリリースされた新しい Azure のサービスで、クラウトネイティブの SIEM (Security Information and Event Management ) ソリューションです。セキュリティ に関するログは、ファイアウォールや WAF やコンピューター単位など、様々なサービス、機器単位で出力されています。
それらのログを製品カットで監視、運用していくのは非常にコストのかかる作業なので、ログを集約、可視化して一括管理しましょう、というのが Azure Sentinel の主な役割の一つです。
また、SIEM の物理製品は高価で、既存のシステムに NW 的に組み込むのも大変、というイメージをお持ちの方もいるかと思いますが、Azure Sentinel はログを収集する Log Analytics ワークスペース に取り込まれた***データ量で課金される従量課金制***なので、スモール スタートできるという意味でもメリットがあります。
-参考情報
Azure Sentinel の価格
URL:https
Process Hackerを利用した自動アンパックの手順
アンチウイルス製品の検知回避を目的として、多くの攻撃者は独自のパック処理を施したマルウェアを利用することが多くあります。
タイトル記載の「自動アンパック」についてですが、
本記事では「実行後にアンパックされたメモリをダンプして解析する」方法について説明しており、「静的解析を行わない」という意味で「自動アンパック」と表記しています。「もっといい方法があるよ〜〜」というアドバイスがあればいただけると嬉しいです！
#そもそもパックとは？
パックの詳細につきましてはここでは割愛しますが、下記の論文がわかりやすかったのでぜひ読んでみてください。
[マルウェア検知におけるパッカーの役割についての検討](https://www.jstage.jst.go.jp/article/fss/28/0/28_619/_pdf/-char/ja)#パッカーの判別方法
[Ditect It Easy](https://forest.watch.impress.co.jp/docs/review/752838.html)のような判別ツールを利用する方法がもっとも容易です。
ただし、多くの攻撃者は独自のパ
IoT@Loft #8 スマートホームのセキュリティ脅威と対策 を受講したよ!（2020年2月19日実施）
IoT@Loft #8 スマートホームのセキュリティ脅威と対策を受講したよ!
###セキュリティ対策にはOTA(DFU)が大事今回は、コロナウィルスの影響で懇親会が中止となりました。
それもあってか、ちょっと軽めなセミナーでした。##LT1 – Zero Touch Provision for AWS IoT
マイクロチップ・テクノロジー・ジャパン株式会社
篠崎 雅和 氏少量でもセキュリティチップを製作可能
https://www.microchip.com/promo/zero-touch-secure-provisioning-kit-forAWSIoT
#LT2 – 非IoTスマートロックをIoT化する製品とそのバックエンド/セキュリティについて
株式会社ビットキー
山本 寛司 氏スマートロックの脆弱性が見つかっても
SSL証明書でIPアドレスからホスト名が漏れる
# IPアドレスからWebサーバの名前がわかるよー
下の結果は、`curl` でIPアドレスにHTTPSでアクセスしただけです。
“`
% curl -v https://198.51.100.15/
* Trying 198.51.100.15…
* TCP_NODELAY set
* Connected to 198.51.100.15 (198.51.100.15) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* T
安全な廃棄のために使用すべきストレージの機能(2/2)
# はじめに
[前回の記事](https://qiita.com/ken-yossy/items/c2b0b8c389327b50d587)では、2019年末に報じられた「個人情報が保存された自治体のHDDが、廃棄処理委託先業者の従業員によって、データ復元可能な状態のまま転売された」という事件を題材に、ストレージを安全に廃棄するために行うべき対策としてストレージのロックと難読化を挙げ、SATAおよびNVMeストレージのロックの具体的な方法をまとめました。同じく前回の記事で指摘した通り、**「データ流出」に対する根本的な対策は「難読化」です**。そこで今回の記事では、この**難読化**についてまとめます。
難読化には、「物理的破壊」、「記憶媒体を消去状態にする」、「複数回データを上書きする」といった従来から広く行われている方法や、暗号化機能を利用した「暗号的消去(Cryptographic Erase)」まで、様々な方法があります。
この記事では、まずストレージ廃棄時の難読化に関する国内外のガイドラインを概観し、その後難読化の具体的な方法として、HDDだけでなくNANDフ
