SSORC.tw

怎麼有那麼明顯的漏洞的詐騙信件

ssorc — Tue, 02 Jun 2026 01:25:47 +0000

現在正逢西元 2026 年、民國 115 年的三、四月發票的對獎時間

這封那麼明顯有漏洞的詐騙信件實在是不用心

月份不對、發票號碼不對，寄件/收件者不對，連結也不對

這篇文章怎麼有那麼明顯的漏洞的詐騙信件最早出現於 SSORC.tw。

gitlab 安裝設定 pages

ssorc — Sat, 23 May 2026 00:59:35 +0000

pages 是用來存放純 html / js /css 網頁

gitlab 是一個控管 git 庫 (放程式檔案) 的地方

gitlab 與 pages 搭配起來就是當我開發程式或檔案，上傳到 gitlab 後，它會自動佈署到 pages，就可以直接透過網頁瀏覽內容

又或是你的專案是 npm 開發內容，它會自動轉成瀏覽器可讀的 js

首先

環境是 ↓

gitlab 連結 : git.ssorc.tw

pages 連結: pages.ssorc.tw

gitlab 上的群組與專案:

/

cross/testpages

如要 clone 它就長這樣子

git clone https://git.ssorc.tw/cross/testpages/

而 pages 連結可以是

.pages.ssorc.tw/

或

pages.ssorc.tw//

↑ 要這方式就 gitlab 要多加這條設定 (不是再一個子網站的方式)

gitlab_pages['namespace_in_path'] = true

底下設定為↑ 方式

# 開始設定 gitlab.rb

vi /etc/gitlab/gitlab.rb

external_url "https://git.ssorc.tw"

nginx['enable'] = true
nginx['redirect_http_to_https'] = true
nginx['ssl_certificate'] = "/etc/gitlab/ssl/server.crt"
nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/server.key"


pages_external_url "https://pages.ssorc.tw"

gitlab_pages['enable'] = true
# 使用 pages.ssorc.tw 而不是 *.pages.ssorc.tw
# false 的話就要使用 cross.pages.ssorc.tw/testpages
gitlab_pages['namespace_in_path'] = true
# 如會有 pages 會找不到 git.ssorc.tw，要加這個
gitlab_pages['internal_gitlab_server'] = "http://127.0.0.1:8080"
# 如會有 ssl 驗證問題，加這個
gitlab_pages['internal_gitlab_server_cert'] = "/etc/gitlab/ssl/ca.crt"

pages_nginx['enable'] = true
pages_nginx['redirect_http_to_https'] = true
pages_nginx['ssl_certificate'] = "/etc/gitlab/ssl/server.crt"
pages_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/server.key"

讓 gitlab 設定套用起來

sudo gitlab-ctl reconfigure

sudo gitlab-ctl restart

# 如果 80/443 不 ok，測一下 nginx

# 單純 test nginx config 有沒有問題

sudo /opt/gitlab/embedded/sbin/nginx -t -c /var/opt/gitlab/nginx/conf/nginx.conf

# pages 需要搭配 runner

# 確認 GitLab Runner 可用

## Pages 需要 GitLab CI/CD pipeline 成功執行，所以你要有 Runner

### 到 GitLab 後台或專案確認：

Admin Area > CI/CD > Runners

### 或專案：

Settings > CI/CD > Runners

↑ 兩個的差別是各自專案可以自行建立 runner ，而 admin 是可以給大家用，但都要進 ssh console 註冊 runner

所以 gitlab 上要先安裝 runner

# 安裝 CI Runner

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | bash

apt update

apt-get install gitlab-runner

# 或

# install gitlab runner

# Download the binary for your system
sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

# Give it permission to execute
sudo chmod +x /usr/local/bin/gitlab-runner

# Create a GitLab Runner user
sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash

# Install and run as a service
sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
sudo gitlab-runner start

# 註冊 CI Runner (shell)

# 純 html

gitlab-runner register --url https://git.ssorc.tw --token glrt-xxxxxxxxxxxxxxxxxx.01.1801pgcp4 \
--executor shell \
--tls-ca-file /etc/gitlab/ssl/server.crt


# 使用 docker / npm
# tags global,pages,npm

gitlab-runner register --url https://git.ssorc.tw --token glrt-xxxxxxxxxxxxxxxxxxxx.01.121u6vnn2 \
--executor docker \
--docker-image node:20 \
--description "global-pages-npm-runner" \
--tls-ca-file /etc/gitlab/ssl/server.crt


sudo systemctl restart gitlab-runner

接著在 gitlab 上建立 group/project

然後 clone 到本機

再建立一個 .gitlab-ci.yml (就是靠它讓 gitlab 知道要 build 什麼)

也可以參考 https://gitlab.com/pages/plain-html

目錄結構會長這樣子 ↓

my-project/
├─ public/
│  └─ index.html
└─ .gitlab-ci.yml

# public/index.html (瀏覽 pages.ssorc.tw/cross/testpages/ 時看到的內容)



  
    
    GitLab Pages Test
  
  
    Hello GitLab Pages

# .gitlab-ci.yml (讓 gitlab ci/cd 靠它知道要怎麼做事)

image: busybox
pages:
  tags:
    - pages
  stage: deploy
  script:
    - echo "The site will be deployed to $CI_PAGES_URL"
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

↑ 編輯完後， git push 到 gitlab

就可在 gitlab 的 build > pipelines 重確認有沒有佈署成功

成功的話在 pages.ssorc.tw/cross/testpages 上可以看到佈署的網頁

Q
Running handlers:
[2026-05-17T19:08:01+08:00] ERROR: Running exception handlers
There was an error running gitlab-ctl reconfigure:

letsencrypt_certificate[git.ssorc.tw] (letsencrypt::http_authorization line 6) had an error: RuntimeError: acme_certificate[staging] (letsencrypt::http_authorization line 60) had an error: RuntimeError: ruby_block[create certificate for git.ssorc.tw] (letsencrypt::http_authorization line 112) had an error: RuntimeError: [git.ssorc.tw] Validation failed, unable to request certificate, Errors: [{url: https://acme-staging-v02.api.letsencrypt.org/acme/chall/293165773/1336776933/zmrQwg, status: invalid, error: {“type”=>”urn:ietf:params:acme:error:dns”, “detail”=>”DNS problem: NXDOMAIN looking up A for git.ssorc.tw – check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for git.ssorc.tw – check that a DNS record exists for this domain”, “status”=>400}} ]

Running handlers complete
[2026-05-17T19:08:01+08:00] ERROR: Exception handlers complete
Infra Phase failed. 5 resources updated in 14 seconds
[2026-05-17T19:08:01+08:00] FATAL: Stacktrace dumped to /opt/gitlab/embedded/cookbooks/cache/cinc-stacktrace.out
[2026-05-17T19:08:01+08:00] FATAL: —————————————————————————————
[2026-05-17T19:08:01+08:00] FATAL: PLEASE PROVIDE THE CONTENTS OF THE stacktrace.out FILE (above) IF YOU FILE A BUG REPORT
[2026-05-17T19:08:01+08:00] FATAL: —————————————————————————————
[2026-05-17T19:08:01+08:00] FATAL: RuntimeError: letsencrypt_certificate[git.ssorc.tw] (letsencrypt::http_authorization line 6) had an error: RuntimeError: acme_certificate[staging] (letsencrypt::http_authorization line 60) had an error: RuntimeError: ruby_block[create certificate for git.ssorc.tw] (letsencrypt::http_authorization line 112) had an error: RuntimeError: [git.ssorc.tw] Validation failed, unable to request certificate, Errors: [{url: https://acme-staging-v02.api.letsencrypt.org/acme/chall/293165773/1336776933/zmrQwg, status: invalid, error: {“type”=>”urn:ietf:params:acme:error:dns”, “detail”=>”DNS problem: NXDOMAIN looking up A for git.ssorc.tw – check that a DNS record exists for this domain; DNS problem: NXDOMAIN looking up AAAA for git.ssorc.tw – check that a DNS record exists for this domain”, “status”=>400}} ]

A
# 不要讓 GitLab 自動申請 Let’s Encrypt
letsencrypt[‘enable’] = false

Q
為什麼使用了 https 但是 pages 卻 502 Whoops, something went wrong on our end.

A
gitlab-pages 無法驗證 GitLab 主站憑證

sudo tail -n 100 /var/log/gitlab/gitlab-pages/current

看到類似：

x509: certificate signed by unknown authority

或：

failed to connect to internal Pages API

就加這個設定：

gitlab_pages[‘internal_gitlab_server’] = “https://git.ssorc.tw”
gitlab_pages[‘internal_gitlab_server_cert’] = “/etc/gitlab/ssl/ca.crt”

# 或
gitlab_pages[‘internal_gitlab_server’] = “http://127.0.0.1:8080”

這篇文章 gitlab 安裝設定 pages 最早出現於 SSORC.tw。

wordpress 支援 php 版本

ssorc — Fri, 22 May 2026 23:52:31 +0000

PHP support clarification, spring 2026 edition

WordPress 6.9 和 7.0 的文檔現已明確表明其完全支援 PHP 8.5。
WordPress 6.8 及更高版本現已明確完全支援 PHP 8.4。
WordPress 6.4 及更高版本現已明確完全支援 PHP 8.3。

支援的最低 PHP 版本是什麼？
推薦的最低PHP 版本仍為 8.3。自 WordPress 7.0 起，支援的最低PHP 版本為 7.4。

這篇文章 wordpress 支援 php 版本最早出現於 SSORC.tw。

就是一個這麼簡單的問題 ?

ssorc — Tue, 19 May 2026 09:13:59 +0000

我有 plesk 系統來管理網站
會用 api 去抓取 domain 等內容

# ↓ 基本 curl 範例：查詢支援的 XML API 版本

cat > request.xml <<'EOF'

    
        
    

EOF

curl -k -sS \
    -X POST "https://PLESK_HOST:8443/enterprise/control/agent.php" \
    -H "Content-Type: text/xml" \
    -H "HTTP_AUTH_LOGIN: admin" \
    -H "HTTP_AUTH_PASSWD: your_password" \
    --data-binary @request.xml

正常的話應該回

但偏偏是 Wrong request

   error 1003 Wrong request

想不通 ?
網路問題 ? 但偏偏就剛好是同一網段，其它網段卻沒有問題，查到快吐血!
問過原廠，但也只會叫我更新版本、或給他們最高存取權限
各大網路都找不到相關問題，在 ai 還沒出來之前的事了
像下面有提到 curl 301 會換成 GET 而不是 POST，誰會去想到是 hostname 的問題 !

ai 跟我說 ↓

1003 Wrong request 通常代表 Plesk 收到的 XML request body 不符合 XML API 格式，不是單純帳密錯。Plesk 官方文件說 XML API 要把「操作 XML」放在 HTTP body，並送到 https://:8443/enterprise/control/agent.php，同時用 HTTP_AUTH_LOGIN / HTTP_AUTH_PASSWD headers 帶認證資訊。

你這裡還有一個可疑點：packet version=”0.0.0.0″。這通常不是正常 request 應該使用的版本。官方範例常見是省略 version，或使用支援版本，例如 1.6.x.x；也可以先用 server/get_protos 查詢支援版本。

請特別檢查這幾點：

不要送空 body
很常見的是 curl 指令少了 –data-binary @request.xml，Plesk 就會回 Wrong request。
不要把 response 當 request 再送回去
你貼的這段是 Plesk 的錯誤 response，不是可以拿來送的 request。
先移除 version=”0.0.0.0″

確認 XML 裡有合法 operator

用 –data-binary，不要用 -d 處理複雜 XML

等等

後來我把 curl 加入 -L -v ，然把完整訊息給 ai 看

問題幾乎確定出在 -L 跟 301 redirect。

你原本打的是：

https://33.33.33.33:8443/enterprise/control/agent.php

Plesk 回：

HTTP/2 301
location: https://xxx33-33.wow.com:8443/enterprise/control/agent.php

然後因為你用了 -L，curl 會跟著 redirect 到新網址。對 301/302/303 redirect，curl 可能會把後續 request 改成 GET，或至少不保證完整保留原本的 POST body；這會讓 Plesk 收到「沒有 XML body 的錯誤 request」，所以回 1003 Wrong request。curl 官方文件也說明，301/302/303 redirect 後可能切換成 GET；若要保留 POST method，要用 –post301、–post302、–post303。

請直接改打 redirect 後的 hostname，不要用 IP + -L

所以結論就是 curl 要直接打 -L 最後看到 301 redirect 的 host
就是一個這麼簡單的問題

這篇文章就是一個這麼簡單的問題 ? 最早出現於 SSORC.tw。

大漏洞時代開啟

ssorc — Sat, 16 May 2026 08:17:22 +0000

大漏洞時代開啟

之前看到 curl 不再發漏洞獎金

現在看到 linux 從 copy fail 到 Dirty frag 的漏洞 (讓伺服器強制隔隔週重開機一次)

現在又看到 ssh-keysign-pwn (CVE-2026-46333)

bind dns 也說 Prepare for more frequent BIND security updates

請做好迎接更頻繁的 BIND 安全性更新的準備

至少在 2026 年剩餘時間內，應計劃更頻繁地進行 BIND 安全性更新。

大型語言模型 (LLM) 的出現大大降低了開源軟體漏洞的發現難度，降低了研究人員和惡意攻擊者的門檻，導致我們以及許多開源專案收到了大量的漏洞報告。目前，我們正在以超過歷史水準十倍的速度處理漏洞報告，這些報告既包括外部報告者提供的，也包括我們本身基於 LLM 分析的報告。

這篇文章大漏洞時代開啟最早出現於 SSORC.tw。

台灣高鐵列車被駭新聞的後續分析

ssorc — Tue, 12 May 2026 05:53:39 +0000

Taiwan’s train cyber-trauma reveals a global system that’s coming off the tracks

觀點：對於任何了解這三個字含義的人來說，它們足以令人心跳加速：關鍵基礎設施韌性。如果您經營這些基礎設施，或者一個國家依賴這些基礎設施，那麼您就需要確保能源、通訊和交通系統能夠抵禦網路攻擊。

如果這個國家距離一個鐵腕無情、實力超群、誓要入侵你的敵人只有五分鐘的飛彈射程，情況就更糟了。這個敵人正以最快的速度建造和裝備軍隊，其目的只有一個。這個敵人還擁有地球上最具侵略性和最肆無忌憚的國家級駭客攻擊能力。

因此，台灣整個高鐵系統被一名未知的攻擊者癱瘓近一個小時，這的確是個糟糕的一天。更糟的是，攻擊者並非海峽對岸那些冷酷無情、資源雄厚的國家行為體，而是一位對無線電感興趣、從網路上購買了一些設備的大學生。一方面，看到年輕駭客在臥室裡製造混亂的「優良傳統」得以延續固然令人欣慰。但另一方面，這究竟是怎麼回事？

台灣當局公佈的資訊細節不多，但足以大致確定事件真相。這不僅對台灣，而且對100多個同樣使用TETRA雙向無線電標準的國家和地區來說都是壞消息，這些標準通常用於緊急服務。在許多情況下，TETRA是未加密的FM雙向無線電的預設替代品，它增加了加密、靈活性和網路安全功能。這些功能在1980年代和1990年代TETRA開發時是當時最先進的——而且正如你所料，在2026年仍然適用。哎呀。

已經進行了一些升級，尤其是在2023年漏洞揭露之後，改進計畫更是加速推進。在全球範圍內，大量已安裝的設備老舊，缺乏安全更新，無論如何，對任何政府機構或公共服務機構來說，購買新無線電設備通常都是最不重要的支出。只有情況變得非常糟糕才會採取行動。或許，情況已經如此糟糕了。

(其它省略)

GPT 分析 ↓

以下是對 The Register 這篇文章的重點分析。

一句話結論

這不是單純的「大學生惡作劇」事件，而是老舊關鍵基礎設施通訊系統、低成本 SDR 無線電工具、弱化/過時認證機制、以及營運安全流程高度耦合後產生的典型風險案例。真正值得關注的是：攻擊者不必入侵 IT 系統，也可能透過無線電協定層觸發實體營運中斷。

事件摘要

The Register 指出，台灣高鐵在 2026 年 4 月 5 日發生約 48 分鐘中斷，原因是高鐵系統收到疑似偽造的「General Alarm」總警報訊號，導致列車依程序停駛。後續調查指向一名 23 歲學生，警方查扣無線電設備、筆電、手機，以及疑似 SDR 相關設備。

The Register 的評論文進一步推論，這起事件可能不是傳統網路入侵，而是透過 TETRA 無線電通訊系統進行訊號複製或重放，讓系統誤以為警報來自合法站務設備。文章強調，這類風險不只影響台灣，因為 TETRA 被許多國家用於警消、交通、能源、工業與公共安全通訊。

技術核心：問題可能在「訊號可信任模型」

文中最關鍵的技術判斷是：攻擊者可能擷取合法 TETRA 終端或系統訊號，然後重送、模擬或改寫成可被系統接受的警報訊息。The Register 稱這類手法為 replay attack，也就是「重放攻擊」。

重放攻擊本質上代表系統沒有充分驗證「這個訊息是不是當下由合法設備新鮮產生」。成熟的防禦通常會用 nonce、時間戳、遞增序號、挑戰回應、訊息認證碼、短週期金鑰或 session binding 來避免舊訊號被再次使用。若一個總警報級別訊息可以被低成本設備重放而成功觸發，問題通常不只是「有人違法發射」，而是系統沒有把高風險指令當成高風險指令來驗證。

不過要注意：The Register 文章也承認，台灣官方公開細節有限，因此它對 HackRF、SDR filter、訊號是否被修改等判斷，有一部分是根據公開資訊與無線電安全常識做出的推論，而非完整鑑識報告。

為什麼 TETRA 是關鍵？

TETRA 是一套長期用於任務關鍵通訊的專業無線電標準，常見於警消、運輸、工業與關鍵基礎設施。2023 年 Midnight Blue 公開 TETRA:BURST 研究，指出多個 TETRA 弱點可能造成即時解密、事後解密、訊息注入、使用者去匿名化或 session key pinning 等風險。

ETSI 與 TCCA 對 2023 年研究也有正式回應，表示標準維護與強化已在進行，且 2022 年已發布修訂標準；TCCA 的研究揭露頁面也提到，2023、2024、2025 年仍有後續研究與標準強化工作。這表示 TETRA 生態不是沒有補救方向，但現場部署、設備汰換、相容性與成本才是最大落差。

這篇文章的觀點是否合理？

大方向合理，但語氣偏評論化。

合理之處在於，它抓到三個真問題：

第一，SDR 民用化降低了攻擊門檻。以前需要昂貴實驗室與專業射頻設備的事，現在可以用相對便宜的 SDR、筆電與開源工具完成相當多的接收、分析與發射測試。The Register 對 HackRF 的描述雖然語氣誇張，但「通用 SDR 讓無線電攻擊門檻下降」這點成立。

第二，關鍵基礎設施常被老舊嵌入式系統綁住。無線電終端、基地台、調度系統、列車營運程序通常生命週期很長，且不能像一般 SaaS 一樣頻繁更新。文章提到許多舊設備缺乏 OTA 安全更新能力，這是交通、工業控制與公共安全通訊很常見的現實問題。

第三，安全機制不能只靠管制設備。禁止 code grabber 或限制 SDR 買賣，對高動機攻擊者效果有限；真正的防線應該在協定、金鑰管理、訊息認證、異常偵測與營運流程分層驗證。文章這點判斷很準。

但文章也有需要保留的地方：它把「TETRA 老舊/有已知弱點」和「本案實際成功原因」連得很緊，可是目前公開資訊不足以證明本案一定利用了 TETRA:BURST 中的特定 CVE。較嚴謹的說法應是：本案疑似暴露了 TETRA 部署、金鑰管理、終端認證或警報訊息驗證上的弱點；是否對應特定已知漏洞，仍需官方或鑑識報告確認。

對台灣高鐵與關鍵基礎設施的治理啟示

這起事件最重要的不是「抓到一個人」，而是要回答以下問題：

警報訊息是否有端到端完整性驗證？
General Alarm 這類高影響指令不應只因為「看起來來自某台合法無線電」就被接受。
TETRA 金鑰是否長期未輪替？
若金鑰多年未換，且多個終端共享或可被複製，任何一次暴露都會變成系統性風險。
是否有訊號異常偵測？
例如同一終端 ID 在不合理位置發射、訊號特徵與既有設備不符、警報在非預期時間或非授權角色觸發，應該能產生二次驗證或降級處置。
營運流程是否允許單一無線電事件造成大範圍停駛？
安全優先是正確的，但高影響訊號可以設計成「先進入受控降速/人工確認/區域隔離」而不是一律擴散成全域停擺。這要小心設計，不能犧牲行車安全。
是否有紅隊測試與射頻安全稽核？
很多資安稽核只看 IT 網路、帳號權限與伺服器漏洞，卻忽略 RF、OT、ICS、調度通訊與實體流程交界。

對企業資安的延伸意義

這篇文章對一般企業也有警示：資安邊界不只在雲端、端點、帳號與 API。凡是企業依賴無線電、門禁、IoT、倉儲自動化、車隊、工廠設備、監控系統、告警系統，都可能存在類似問題。

尤其要避免三種假設：

「這是專用系統，所以安全。」
「攻擊者買不到設備，所以安全。」
「只要不是網際網路暴露面，就不算資安風險。」

這三個假設在 SDR 普及、開源工具成熟、舊協定長期服役的環境下都不可靠。

我的判斷

The Register 這篇文章的技術主張大致可信，尤其是對 SDR、重放攻擊、老舊 TETRA 部署與關鍵基礎設施韌性的連結。但它是評論文，不是官方事故報告；因此對「到底用了哪個漏洞、是否修改訊息、是否因金鑰未輪替或協定弱點造成」仍應保留。

真正的結論應該是：

這起事件證明，關鍵基礎設施的通訊安全不能只靠封閉標準、專用設備與行政管制。高影響控制訊息必須具備現代密碼學保護、可稽核的金鑰生命週期、異常偵測與分層營運驗證。否則低成本無線電工具就可能把「訊號」變成實體營運中斷。

這篇文章台灣高鐵列車被駭新聞的後續分析最早出現於 SSORC.tw。