สอดแนมเซิร์ฟเวอร์ IIS แบบทั้งสนุกทั้งเสี่ยงติดคุก

 (mll.sh)
2 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หน้าเริ่มต้นมาตรฐานของ IIS ไม่ใช่ทางตัน แต่เป็น จุดเริ่มต้นของการสอดแนมสำหรับบั๊กบาวน์ตี โดยสามารถใช้ Shodan, Google dork และ response header เพื่อค่อย ๆ จำกัดขอบเขตเซิร์ฟเวอร์ที่เปิดเผยอยู่และ vhost ที่ซ่อนอยู่ได้
  • คำขอ HTTP/1.0, HTTPAPI 2.0 404, ใบรับรอง SSL และการ brute-force Host header เป็น เบาะแสตั้งต้น สำหรับหา IP ภายใน, hostname ของ Exchange และ virtual host
  • การทำ tilde shortname enumeration ของ IIS ซึ่งอิงกับ DOS 8.3 สามารถเปิดเผยชื่อไฟล์และไดเรกทอรีแบบสั้นได้ แม้จะปิด directory listing อยู่ก็ตาม และใช้ GitHub search, BigQuery, LLM และ crunch เพื่อเดาชื่อเต็มที่เป็นไปได้
  • การ fuzzing ที่เจาะจง IIS/.NET ควรเล็ง พาธและนามสกุลไฟล์มูลค่าสูง อย่าง web.config, trace.axd, elmah.axd, appsettings.*.json, .aspx/.ashx/.asmx/.config ก่อน
  • การเปิดเผย web.config, การ normalize path ของ cookieless session, reverse proxy path confusion, NTFS alternate data stream, การ bypass นามสกุลอัปโหลด และ HPP แสดงให้เห็นว่า การตั้งค่าผิดพลาดและพฤติกรรมแบบ legacy สามารถกลายเป็นพื้นผิวโจมตีได้

วิธีสอดแนมเพื่อค้นหาเซิร์ฟเวอร์ IIS

  • เป้าหมายที่เป็น IIS มักหาเจอได้ก่อนจาก search engine และบริการค้นหาทรัพย์สินบนอินเทอร์เน็ต
  • การ query ใน Shodan ใช้วิธีผสมระหว่างใบรับรอง SSL ของโดเมนเป้าหมาย, ชื่อองค์กร และ http.title:"IIS" เพื่อค่อย ๆ จำกัดขอบเขตเซิร์ฟเวอร์ IIS
    • ตัวอย่างเป้าหมายอาจรวมถึงเซิร์ฟเวอร์ staging, แผงผู้ดูแลระบบที่ถูกลืม, และเครื่องมือภายในที่เปิดออกสู่อินเทอร์เน็ต
    • นอกจาก Shodan ยังมี fofa, censys, netlas และ odin ที่ให้ดัชนีอินเทอร์เน็ตคนละชุดกัน
  • Google dorking ใช้เพื่อหาหน้าที่ถูกทำดัชนีและมีร่องรอยของ IIS
    • โฟลเดอร์ aspnet_client และ _vti_bin ถือเป็นสัญญาณของ IIS
    • ext:aspx ใช้ค้นหาหน้า ASP.NET และบ่งชี้ว่าด้านล่างน่าจะเป็น IIS
    • การค้นหาแบบ wildcard อย่าง site:*.target.com, site:*.*.target.com ใช้หา subdomain ซ้อนที่การ enumerate subdomain ทั่วไปอาจพลาดไป
  • Response header เป็นเบาะแสที่ง่ายที่สุดในการระบุ IIS
    • Server: Microsoft-IIS/10.0
    • X-Powered-By: ASP.NET
    • หากต้องตรวจสอบในวงกว้าง สามารถใช้ httpx หรือ nuclei เพื่อสร้างรายการเป้าหมายที่เป็น IIS ได้

เบาะแสตั้งต้นหลังยืนยันว่าเป็น IIS

  • การตั้งค่า IIS บางแบบ โดยเฉพาะ ฝั่งหน้า Exchange หรือ OWA อาจเปิดเผยข้อมูลภายในเมื่อได้รับคำขอ HTTP/1.0
  • ใน Location header อาจมี IP ภายใน อย่าง https://192.168.5.237/owa/
  • X-FEServer header อาจเปิดเผย hostname ภายในของเซิร์ฟเวอร์ Exchange
  • ข้อมูลเหล่านี้นำไปสู่ การรั่วไหลของข้อมูล ที่ใช้ต่อยอดได้ในขั้นถัดไป

การทำอัตโนมัติและการหา virtual host ที่ซ่อนอยู่

  • หลังจากได้รายการเป้าหมาย IIS แล้ว สามารถรัน nuclei ด้วยแท็กอย่าง microsoft, windows, asp, aspx, iis, azure, config, exposure เพื่อลดงานซ้ำ ๆ ได้
  • HTTPAPI 2.0 404 อาจไม่ได้แปลว่าไม่มีอะไรอยู่จริง
    • อาจเป็นเพราะ instance ของ IIS ถูก bind กับ virtual host บางตัว และ Host header ในคำขอไม่ตรง จึงตอบกลับเป็น 404
  • วิธีหา vhost ที่ซ่อนอยู่มีสองแบบ
    • หา hostname ที่ต้องใช้จาก subject หรือฟิลด์ SAN ของใบรับรอง SSL
    • ถ้าใบรับรองไม่ช่วย ก็ใช้ ffuf พร้อม wordlist ของ Host header เพื่อ brute-force vhost
  • เมื่อเจอ hostname ที่ถูกต้อง แอปพลิเคชันจริงอาจตอบกลับมาแทน 404 ปกติ

IIS tilde shortname enumeration

  • IIS มีพฤติกรรมสืบทอดจากกฎการตั้งชื่อไฟล์แบบ DOS 8.3 แบบเก่า ทำให้สามารถ enumerate ชื่อสั้นของไฟล์และไดเรกทอรีด้วยคำขอพิเศษได้
  • แม้จะปิด directory listing ก็ยังอาจเผย fragment อย่าง WEB~1.CON, GLOBAL~1.ASA, SITEBA~1.ZIP, ADMIN~1
  • shortscan ใช้เป็นเครื่องมือ enumerate shortname ของ IIS
  • burp’s IIS Tilde Enumeration Scanner ก็ใช้เป็นทางเลือกได้เช่นกัน
  • มีหลายวิธีในการแปลง shortname ให้กลับเป็นชื่อไฟล์เต็ม
    • LLM: สร้าง candidate ของชื่อไฟล์ที่เป็นไปได้ซึ่งมี fragment ของ shortname อยู่
    • GitHub code search: ค้นหาชื่อไฟล์จริงจาก 6 ตัวอักษรแรกก่อน ~1 และนามสกุลไฟล์
    • GSNW: รับ fragment ของ shortname แล้วรวบรวมชื่อไฟล์ที่ตรงกันจาก GitHub code search
    • GitHub-IIS-Shortname-Generator: สร้าง wordlist ด้วยแนวทางคล้ายกัน
    • shortnameguesser: สอบถามหลายแหล่งจากผลลัพธ์ของ scanner เพื่อสร้าง wordlist เฉพาะเป้าหมาย
  • แนวทาง BigQuery ใช้ public GitHub dataset บน Google BigQuery เพื่อหาพาธไฟล์ที่ตรงกับแพตเทิร์นของ shortname
  • หาก LLM, GitHub และ BigQuery ไม่สำเร็จ ก็ใช้ crunch สร้าง wordlist ของชุดอักขระที่เหลือ แล้วลองด้วย ffuf
    • ควรลองรูปแบบชื่อไฟล์หลายแบบ เช่น ขีดกลาง, ขีดล่าง, ช่องว่างที่เข้ารหัสแบบ URL, หรือไม่มีตัวคั่นเลย
    • Windows อนุญาตให้มีช่องว่างในชื่อไฟล์ และ IIS ก็อาจให้เข้าถึงไฟล์เหล่านั้นได้

การ fuzzing ที่เจาะจง IIS/.NET

  • การใช้ wordlist ทั่วไปเพียงอย่างเดียวอาจพลาดไฟล์และ endpoint เฉพาะของ ecosystem IIS/.NET
  • เป้าหมาย มูลค่าสูง ที่ควรตรวจสอบก่อนมีดังนี้
    • /web.config, /web.config.bak, /web.config.old, /web.config.txt
    • /global.asax
    • /trace.axd
    • /elmah.axd
    • /connectionstrings.config
    • /appsettings.json, /appsettings.Development.json, /appsettings.Staging.json, /appsettings.Production.json, /appsettings.Local.json
    • /secrets.json
    • /WS_FTP.LOG
    • /_vti_pvt/service.cnf
  • trace.axd คือ ASP.NET trace viewer และหากเปิดใช้งานอยู่ อาจเปิดเผยบันทึก request/response พร้อม header, cookie และบางครั้งรวมถึงข้อมูลรับรอง
  • elmah.axd อาจหลงเหลือเป็น debug endpoint ที่นักพัฒนาไม่ได้ปิด และแสดง error log ได้
  • นามสกุลไฟล์ที่ควร fuzz แบบเจาะจง IIS ได้แก่ .asp, .aspx, .ashx, .asmx, .wsdl, .wadl, .config, .xml, .zip, .txt, .dll, .json
  • wordlist ที่น่าใช้มีดังนี้
    • secLists IIS.txt: รวมพาธ IIS พื้นฐาน, handler ทั่วไป และไฟล์ legacy
    • orwa’s iis.txt: แนะนำว่าเป็นรายการ IIS ที่ใช้จริงในโปรแกรมบั๊กบาวน์ตี
    • orwa’s aspx.txt: เน้นรายการของ endpoint .aspx
    • wfuzz iis.txt: รายการขนาดเล็กที่โฟกัสพาธ IIS ที่มีช่องโหว่เป็นที่รู้จัก
    • dirbuster-ng iis.txt: รายการแบบ compact ที่เจาะจุดอ่อนเฉพาะ IIS
    • Assetnote wordlists: สร้างอัตโนมัติจากข้อมูล crawl จริง อัปเดตรายเดือน และแนะนำรายการ ASP กับ ASPX
    • OneListForAll: onelistforallshort.txt เหมาะกับการรันแบบเจาะเป้าหมาย ส่วนรายการเต็มเหมาะกับการรันระยะยาว
  • เนื่องจาก IIS ไม่แยกตัวพิมพ์เล็กใหญ่ wordlist แบบ mixed-case จึงอาจทำให้เกิดคำขอซ้ำซ้อน
    • จึงมักใช้รายการตัวพิมพ์เล็ก หรือ normalize ด้วย tr '[:upper:]' '[:lower:]' | sort -u

การเปิดเผย web.config และโค้ด

  • หากสามารถอ่าน web.config ได้ผ่าน path traversal, ไฟล์สำรองที่ถูกเปิดเผยผิดพลาด, หรือการค้นพบผ่าน shortname ผลกระทบต่อเป้าหมาย IIS อาจสูงมาก
  • ใน web.config ของ IIS อาจมี machine keys ที่ใช้สำหรับการเซ็นและเข้ารหัส ViewState
  • หากมี machine keys ก็อาจปลอมแปลง ViewState payload สำหรับการ deserialize แบบอันตราย จนนำไปสู่ remote code execution ผ่าน deserialization ได้
  • ysoserial.net เป็นเครื่องมือที่ช่วยสร้าง payload เมื่อมี key แล้ว
  • หากมีพารามิเตอร์สำหรับดาวน์โหลดหรืออ่านไฟล์ ก็มักจะต่อยอดไปเป็นการลอง ../../web.config และรูปแบบที่เข้ารหัส URL
  • ฟีเจอร์ cookieless session แบบ legacy ของ ASP.NET สามารถใส่ session token รูปแบบ (S(X)) ลงในพาธ URL ได้
    • IIS อาจลบ segment นั้นออกระหว่างการ normalize path ทำให้ bypass การบล็อกการเข้าถึงไดเรกทอรี /bin ได้
    • Newtonsoft.Json.dll เองเป็นไลบรารีพื้นฐาน จึงอาจไม่ได้มีความลับของแอปพลิเคชันอยู่ภายใน
    • แต่หากดาวน์โหลด DLL ของแอปจริงมาได้ ก็สามารถ decompile ด้วย dotPeek หรือ dnSpy เพื่อดูข้อมูลรับรองที่ hardcode, API key, logic ของ endpoint ภายใน, และการทำ authentication แบบ custom ได้

การ normalize path, NTFS, การอัปโหลด และการหลบ WAF

  • เมื่อ IIS อยู่หลัง reverse proxy หรือทำหน้าที่เป็น reverse proxy เอง ความต่างในการ normalize path อาจนำไปสู่การ bypass access control
    • proxy อาจมองพาธที่เข้ารหัสว่าเป็นทรัพยากรอีกตัวหนึ่งแล้วส่งต่อ แต่ IIS อาจ decode %2f เป็น / และตีความ traversal จนเข้าถึงพาธที่ควรป้องกันไว้ได้
  • IIS 7.5 และเวอร์ชันใกล้เคียง อาจ bypass basic authentication ได้จากพฤติกรรมของ NTFS alternate data streams และ index allocation
    • โมดูล authentication อาจไม่มองว่าเป็นพาธที่ได้รับการป้องกัน แต่ file system กลับตีความเป็นไดเรกทอรีจริงได้
  • ในฟังก์ชันอัปโหลดไฟล์ แม้จะบล็อก .aspx, .asp ไว้ ก็ยังอาจเกิด stored XSS ได้ผ่านนามสกุลที่ IIS เสิร์ฟเป็น HTML โดยปริยาย
    • ตัวอย่างนามสกุลที่ render เป็น HTML: .cer, .hxt, .htm
    • ตัวอย่างนามสกุลสำหรับ XSS แบบอิง XML: .dtd, .mno, .vml, .xsl, .xht, .svg, .xml, .xsd, .xsf, .svgz, .xslt, .wsdl, .xhtml
  • IIS มีพฤติกรรมตัดจุดท้ายชื่อไฟล์ออก จึงอาจ bypass ตัวกรองการอัปโหลดด้วยชื่ออย่าง shell.aspx., shell.aspx.., shell.aspx...
  • สำหรับเป้าหมาย server-side includes มีการแนะนำนามสกุล .stm, .shtm, .shtml
  • หาก WAF บล็อก payload สามารถใช้ HTTP Parameter Pollution แบ่ง payload ไปใส่ในพารามิเตอร์ซ้ำกันได้
    • IIS และ ASP.NET โดยปริยายจะเชื่อมค่าของพารามิเตอร์ที่ซ้ำกันด้วยเครื่องหมายจุลภาค ทำให้ payload อาจถูกประกอบกลับหลังผ่าน WAF

บทเรียนและแหล่งข้อมูลที่น่าจดจำในบั๊กบาวน์ตี IIS

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Hacker News

  • เหตุผลที่ตั้งหน้าแลนดิ้งของ IIS ไว้หน้าทุก honeypot ก็เพราะมันล่อพวก black hat ได้ดี
    แค่คิดว่าพวกนั้นเสียเวลาไล่งับหางตัวเองไปหลายชั่วโมงก็สุขแล้ว

    • อย่าหยุดแค่นั้นเลย น่าจะเอา IIS server จริงมาตั้งไว้ด้านหน้า แล้วซ้อน honeypot เป็นชั้นๆ แบบตุ๊กตาแม่ลูกดก เพื่อดูว่าพวกมันจะเจาะเข้ามาได้ลึกแค่ไหน ก็น่าสนุกดี
    • ถ้าไม่ได้รัน honeypot อยู่ในช่วง IP ขององค์กรที่มีอยู่เดิม สุดท้ายสิ่งที่ได้รับก็มีแต่ bot traffic
      พวก black hat ระดับบนจะไล่เป้าหมายใหญ่ ส่วนระดับล่างก็จะโฟกัสกับเหยื่อง่ายๆ ที่หาได้จาก Shodan หรือไม่ก็ zero-day ของแอปที่ตัวเองเจอ
    • noise นี่เป็นชั้นความปลอดภัยที่ถูกประเมินค่าต่ำไปมากจริงๆ
    • พอเปิดพอร์ต Plex กับ Nintendo Switch ก็มีการสแกนถาโถมเข้ามาแบบบ้าคลั่ง
      ถ้ามีวิธีปั่นหัวพวก port scanner ได้อีกก็อยากรู้เพิ่ม
    • การทำ URL อย่าง aspnet_client/admin.php แล้วให้มันส่งกลับ WebObjects header ก็ดูน่าจะเป็นงานอดิเรกที่ดีเหมือนกัน

  • ประโยคที่ว่า “IIS มีพฤติกรรมแบบ legacy ที่สืบทอดมาจากกฎชื่อไฟล์ DOS 8.3 แบบเก่า” ทำให้นึกสงสัยว่ามันหมายถึงการที่ พฤติกรรมของระบบปฏิบัติการพื้นฐาน ถูกเปิดเผยออกมา เมื่อรวมกับการที่ document root ของ IIS เป็น C:\Inetpub โดยปริยายหรือเปล่า
    บน Windows 10/11 ชื่อไฟล์ 8.3 จะเปิดใช้งานโดยปริยายบนไดรฟ์ C แต่ปิดโดยปริยายบนไดรฟ์อื่น
    PS> (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').DisplayVersion → 24H2
    fsutil 8dot3name query C: ขึ้นว่า 8dot3 name creation is ENABLED, ส่วน fsutil 8dot3name query U: ขึ้นว่า DISABLED

    • พูดนอกเรื่องนิดหนึ่ง แต่ทำให้นึกถึงตอนที่ Windows อัปเดตสร้าง c:\inetpub บนพีซีทุกเครื่องที่ไม่ใช่เซิร์ฟเวอร์ ด้วยเหตุผลกำกวมว่า “เพิ่มการป้องกัน”
      https://www.pcworld.com/article/2684062/why-is-windows-11-la...
    • งานวิจัยต้นฉบับของเรื่องนี้อยู่ที่นี่: https://soroush.me/downloadable/microsoft_iis_tilde_characte...
    • บนเครื่อง Windows 10 คำสั่ง DisplayVersion ไม่ตอบอะไรเลย และดูเหมือนว่าบนรุ่นเก่าอย่าง LTSC ต้องใช้ ReleaseId แบบนี้แทน
      (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion').ReleaseId → 1809

  • สำนวนการเขียน ของบทความนี้ค่อนข้างแปลก

    • อ่านไปหลายรอบก็สงสัยว่า Claude เป็นคนเขียนหรือเปล่า

  • โอ้โห อันนี้ทำให้นึกถึงวันเก่าๆ ขึ้นมาทันที
    ช่วงหนึ่งมี IIS scanner เยอะมากจน log ของเซิร์ฟเวอร์แทบใช้งานไม่ได้เลย
    ตอนนั้นมี ช่องโหว่ directory traversal ที่แค่ URL-encode ../ ก็พอ แล้วมันก็เผาอินเทอร์เน็ตทั้งผืนอยู่หลายเดือน

    • ความพยายาม traversal แบบนั้นจนถึงตอนนี้ก็ยังเห็นบ่อยมากพอๆ กับการโจมตีของพวก script kiddie ที่ไล่ยิง PHP/WordPress

  • ยังมีที่ไหนใช้ IIS อยู่ด้วยเหรอ?

    • ใช้อยู่สิ ถ้าใช้ Windows Server กับ IIS เครื่องนั้นก็จะเข้าร่วมโดเมน และโดยมากจะมี SPN ในรูป HOST/MACHINE.DOMAIN
      บริการของ Windows กับ IIS App Pool Identity จะล็อกอินด้วย (g)MSA หรือบัญชีเสมือน (NT Service*) ทำให้สภาพแวดล้อม Kerberos แบบจัดการได้ทำงานได้ลื่น โดยไม่ต้องมานั่งจัดการการเปลี่ยนรหัสผ่านทุก 30/60/90 วันเอง
      จะล็อกอินเข้า MS SQL Server ด้วย Kerberos หรือจะล็อกอินเข้า OAuth2 flow ของเว็บแอปอื่นด้วย Kerberos ก็ทำงานต่อกันได้อย่างเป็นธรรมชาติ
      WinRM ก็ใช้ได้จากเชลล์ Windows ปกติโดยแทบไม่ต้องตั้งค่าอะไรเพิ่ม และในทางเทคนิคก็ข้าม 2FA ได้ด้วย เพราะมันทำงานแบบนั้นจริงๆ
      ถ้าถามว่าทำบน Linux ได้ไหม ก็ได้แหละ แต่จะตั้งได้ถูกต้องแค่ไหนก็ขึ้นอยู่กับที่ทำงาน และจากประสบการณ์ที่ผ่านมา โอกาสไม่ได้สูงนัก
    • ในแผนก IT ขององค์กรยังใช้กัน เยอะมาก
    • ผมคุยกับคนที่ยังรัน IIS บน Windows Server อยู่บ่อยๆ
      มีแอปเก่าอยู่เยอะจริงๆ และในนั้นก็มีหลายตัวที่สำคัญมาก
    • บางธนาคารก็ยังใช้ IIS
      ถ้าเป็นองค์กรใหญ่พอจะมีอินทราเน็ต ก็แทบจะแน่ใจได้ว่าที่ไหนสักแห่ง หรืออาจจะทั้งระบบ กำลังรัน IIS อยู่
      มันผสานกับ AD ได้ดีมาก จนงานที่ซับซ้อนมากๆ กลายเป็นเรื่องง่ายแบบเหลือเชื่อ
      โลกกำลังย้ายไป AWS ทำให้การใช้งานลดลงก็จริง แต่การไปผูกติดกับผลิตภัณฑ์ผูกขาดของผู้ขายอีกรายหนึ่ง (Amazon) ก็โง่พอกัน ต่างกันแค่ว่าคราวนี้คุณไม่ได้เป็นเจ้าของฮาร์ดแวร์ด้วย
      ฝั่ง IT ภาครัฐชอบ IIS มาก ถ้าดูเว็บภาษีท้องถิ่นหรือเว็บอสังหาริมทรัพย์ ก็มักมีสคริปต์ .aspx เต็มไปหมด
      ผมก็เห็นในเว็บแอปภาครัฐของยุโรปเหมือนกัน และหลายครั้งแอป .NET ที่ทำขึ้นเฉพาะพร้อม backend เป็น SQL Server ก็คอยขับเคลื่อนงานของรัฐบาลท้องถิ่นทั้งหน่วยงาน
      ในเอเชีย โดยเฉพาะจีนกับไต้หวัน ดูเหมือนว่าจะชอบ IIS และใช้โฮสต์สารพัดอย่าง
      โลกส่วนใหญ่ย้ายออกไปแล้วก็จริง แต่ legacy code จำนวนมหาศาลที่ขับเคลื่อนเมืองและองค์กรสำคัญยังคงอยู่บน IIS และคงไม่เปลี่ยนในเร็วๆ นี้
      ถ้าคิดว่านี่แย่ ก็ยังมีที่ที่รัน AS/400, Lotus Notes และ Novell GroupWise อยู่บนเว็บจนถึงทุกวันนี้
    • ใช่ แล้วถ้าถามแบบคนไม่ค่อยรู้ ทุกวันนี้ควรใช้อะไรแทนล่ะ?
      ลองนึกถึงบริษัทเล็กๆ ที่เขียนโค้ด .NET Framework สำหรับองค์กร ใช้ Windows ทั้งระบบ ลูกค้าไม่รับคลาวด์ SOAP ยังเป็นของกระแสหลัก และคน IT คนเดียวก็ไม่มีเวลาสนใจด้วยซ้ำว่าหลังปี 2010 โลกเปลี่ยนไปยังไงบ้าง
      จะรีไรต์ทั้งระบบก็ไม่สมจริง อยากได้ประโยชน์ด้านความปลอดภัยเพิ่ม แต่ก็ไม่มีแรงไปขุดการตั้งค่าลึกๆ และก็ไม่อาจเดิมพันกับความซับซ้อนแบบ Kubernetes ได้

  • อยากเห็น บทวิเคราะห์ แบบนี้กับ nginx บ้างเหมือนกัน

  • ถ้ามองบนเดสก์ท็อปเบราว์เซอร์ทั่วไป ดีไซน์ ดีมาก และเนื้อหาก็ดีมากด้วย

    • ไม่แน่ใจว่าประชดหรือเปล่า แต่บนเดสก์ท็อปเบราว์เซอร์ของผม sidebar มันทับกับแผงเนื้อหา ทำให้ตัวอักษรซ้อนกันบนตัวอักษร
      ถึงอย่างนั้นก็ยังชอบการนำเสนอส่วนอื่นๆ อยู่
    • จะบอกว่า “ยอดเยี่ยม” ก็ดูใจดีกับเนื้อหาระดับ script kiddie ยุคต้นทศวรรษ 2000 ไปหน่อย
      ดูเหมือนผู้เขียนยังต้องเรียนรู้อีกเยอะว่าความศิวิไลซ์ของเราพึ่งพาการที่ผู้คนไม่ใจร้ายใส่กันโดยไร้เหตุผลมากแค่ไหน

  • ไม่รู้ว่าเกิดอะไรขึ้นที่ sidebar ด้านซ้ายมันถึงไปทับกับข้อความเนื้อหา