ถูกแฮ็ก ต้องการที่จะเข้าใจว่า


40

บางคนมีครั้งที่สองผนวกท้ายจาวาสคริปต์ไปยังเว็บไซต์ที่ฉันช่วยเรียกใช้ จาวาสคริปต์นี้จะจี้ Google Adsense ใส่หมายเลขบัญชีของตนเองและติดโฆษณาทั้งหมด

รหัสจะถูกผนวกเข้าด้วยกันเสมอในหนึ่งไดเรกทอรีเฉพาะ (หนึ่งที่ใช้โดยโปรแกรมโฆษณาของบุคคลที่สาม) ส่งผลกระทบต่อจำนวนไฟล์ในไดเรกทอรีจำนวนหนึ่งภายในโฆษณานี้ (20 หรือมากกว่านั้น) และถูกแทรกในเวลาประมาณเดียวกันข้ามคืน เวลา. บัญชี Adsense เป็นของเว็บไซต์จีน (ตั้งอยู่ในเมืองไม่ถึงหนึ่งชั่วโมงจากที่ฉันจะอยู่ในประเทศจีนในเดือนหน้าบางทีฉันควรไปหัว ... ล้อเล่น, ประเภทของ), btw ... นี่คือข้อมูลเกี่ยวกับ เว็บไซต์: http://serversiders.com/fhr.com.cn

ดังนั้นพวกเขาจะต่อท้ายข้อความในไฟล์เหล่านี้ได้อย่างไร มันเกี่ยวข้องกับการอนุญาตที่ตั้งไว้ในไฟล์ (ตั้งแต่ 755 ถึง 644) หรือไม่? สำหรับผู้ใช้เว็บเซิร์ฟเวอร์ (อยู่ใน MediaTemple ดังนั้นควรปลอดภัยใช่ไหม) ฉันหมายความว่าหากคุณมีไฟล์ที่มีการอนุญาต 777 ฉันยังคงไม่สามารถเพิ่มรหัสได้ตามต้องการ ... พวกเขาจะทำสิ่งนี้ได้อย่างไร

นี่คือตัวอย่างของรหัสจริงเพื่อความสุขในการรับชมของคุณ (และอย่างที่คุณเห็น ... ไม่มากนักเคล็ดลับที่แท้จริงคือวิธีที่พวกเขามีมันอยู่ในนั้น):

<script type="text/javascript"><!--
google_ad_client = "pub-5465156513898836";
/* 728x90_as */
google_ad_slot = "4840387765";
google_ad_width = 728;
google_ad_height = 90;
//-->
</script>
<script type="text/javascript"
src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script>

เนื่องจากมีคนจำนวนมากได้กล่าวถึงนี่คือสิ่งที่ฉันได้ตรวจสอบ (และโดยการตรวจสอบฉันหมายถึงฉันดูเวลาที่ไฟล์ถูกแก้ไขสำหรับความแปลกประหลาดใด ๆ และฉัน greiled ไฟล์สำหรับคำสั่ง POST และการสำรวจไดเรกทอรี:

  • access_log (ไม่มีสิ่งใดในเวลายกเว้นการรับส่งข้อมูลบ็อต msn ปกติ)
  • error_log (ไม่มีอะไรนอกจากไฟล์ปกติไม่มีข้อผิดพลาดสำหรับไฟล์ที่ดูไม่น่ากลัว)
  • ssl_log (ไม่มีอะไรนอกจากปกติ)
  • Messages_log (ไม่มีการเข้าถึง FTP ยกเว้นที่นี่)

* ปรับปรุง: ** ตกลงแก้ไขได้ แฮกเกอร์จากประเทศจีนได้วางไฟล์ไว้ในเว็บไซต์ของเราเพื่อให้พวกเขาทำสิ่งต่าง ๆ ในการบริหารจัดการ (การเข้าถึงฐานข้อมูลลบและสร้างไฟล์และ dirs คุณตั้งชื่อพวกเขาเข้าถึงได้) เราโชคดีที่พวกเขาไม่ได้ทำอะไรที่เป็นอันตรายมากกว่านี้ ไม่มีสิ่งใดในไฟล์บันทึก apache ปกติ แต่ฉันพบชุดไฟล์บันทึกอื่นในตัววิเคราะห์บันทึกการใช้เว็บเซิร์ฟเวอร์และมีหลักฐานอยู่ในนั้น พวกเขากำลังเข้าถึงไฟล์นี้ด้วยชื่อผู้ใช้และรหัสผ่านของตนเองจากนั้นแก้ไขสิ่งที่ต้องการบนเซิร์ฟเวอร์ ไฟล์ของพวกเขามี "apache" ตั้งเป็นผู้ใช้ในขณะที่ไฟล์อื่น ๆ ทั้งหมดในเว็บไซต์ของเรามีชื่อผู้ใช้ที่แตกต่างกัน ตอนนี้ฉันต้องหาวิธีที่พวกเขานำไฟล์นี้เข้าสู่ระบบของเรา ฉันสงสัยว่าการถูกตำหนิในครั้งนี้จะอยู่กับผู้ให้บริการพื้นที่เว็บของเรา (Media Temple)


6
ฉันไม่รู้คุณให้รหัสผ่านของคุณกับใครบางคน?

4
หากคุณทราบว่าเกิดเหตุการณ์นี้ขึ้นอย่างแน่นอนให้ค้นหา access_log ของคุณสำหรับทุกสิ่งที่ผิดปกติในช่วงเวลานี้ จดบันทึกคำขอ POST ทั้งหมดโดยเฉพาะ: พวกเขาจะไปที่ไหนพวกเขาทำอะไร
sanmai

3
ขอบคุณ WhirlWind ... มีประโยชน์มาก
Lothar_Grimpsenbacher

2
ที่จริงถ้าคุณรู้จักพวกเขาทำไมไม่วางรายละเอียดที่อยู่ลงในเว็บไซต์ต่อต้านสแปม ให้ตาข่าย "พูด" กับพวกเขาและให้พวกเขาได้ลิ้มรสยาของพวกเขาเอง :-)

4
@ gaoshan88 - มีประโยชน์มากกว่านี้แล้วคุณอาจคิดว่า เวกเตอร์โจมตีหนึ่งตัวคือโทรจันที่ดักรหัสผ่านจากไคลเอนต์ ftp ของนักพัฒนา
เควนติน

คำตอบ:


9

ก่อนอื่นchmod 744มันไม่ใช่สิ่งที่คุณต้องการ จุด chmod คือการเพิกถอนการเข้าถึงบัญชีอื่น ๆ ในระบบ chmod 700อยู่ไกลความปลอดภัยมากกว่า 744chmod อย่างไรก็ตาม Apache ต้องการเพียงบิตประมวลผลเพื่อรันแอปพลิเคชั่น php ของคุณ

chmod 500 -R /your/webroot/

chown www-data:www-data -R /your/webroot/

www-data ถูกใช้เป็นบัญชีของ Apache ซึ่งใช้ในการดำเนินการ php คุณสามารถเรียกใช้คำสั่งนี้เพื่อดูบัญชีผู้ใช้:

`<?php
print system("whoami");
?>`

FTP นั้นไม่ปลอดภัยอย่างน่ากลัวและมีโอกาสมากที่คุณจะถูกแฮกจากวิธีนี้ การใช้ FTP คุณสามารถทำให้ไฟล์เขียนได้จากนั้นติดเชื้ออีกครั้ง ตรวจสอบให้แน่ใจว่าคุณใช้โปรแกรมป้องกันไวรัสในทุกเครื่องที่มีการเข้าถึง FTP มีไวรัสที่ตรวจจับการรับส่งข้อมูลภายในสำหรับชื่อผู้ใช้และรหัสผ่าน FTP จากนั้นเข้าสู่ระบบและติดเชื้อ หากคุณสนใจเรื่องความปลอดภัยคุณจะใช้ SFTP ซึ่งเข้ารหัสทุกอย่าง การส่งซอร์สโค้ดและรหัสผ่านบนสายในข้อความที่ชัดเจนคือความบ้าคลั่งทั้งหมด

ความเป็นไปได้อีกอย่างหนึ่งคือคุณกำลังใช้ไลบรารีหรือแอปพลิเคชันเก่าอยู่ เยี่ยมชมเว็บไซต์ของผู้จำหน่ายซอฟต์แวร์และตรวจสอบให้แน่ใจว่าคุณใช้เวอร์ชันล่าสุด


6
+1 หลีกเลี่ยง FTP อย่างเช่นกาฬโรค โทรจันดมกลิ่นรหัสผ่านสามารถติดคอมพิวเตอร์ของคุณและใช้ข้อมูลประจำตัวของคุณเพื่อเปลี่ยนไฟล์ หรืออาจติดเราเตอร์ของคุณ หรือคอมพิวเตอร์ของเพื่อนบ้านที่ netcafe ด้วยเครือข่าย wifi ที่ไม่ปลอดภัย การส่งรหัสผ่านใน clearext เป็นความคิดที่ไม่ดี
Tgr

1
FTP นั้นมาพร้อมกับ SSL คุณรู้ไหม
grawity

1
@grawity คนส่วนใหญ่ไม่ใช้ "ftps" แต่นั่นจะทำให้คุณไม่ถูกแฮ็ก SFTP เป็นที่นิยมมากขึ้น
โกง

2
www-data ไม่ควรเป็นเจ้าของไฟล์ในเว็บไดเรกทอรีของคุณ ทุกสิ่งที่www-dataสามารถปรับปรุงได้โดยสคริปต์ที่เขียนไม่ดีบนเซิร์ฟเวอร์
Zoredache

9

บัญชี Media Temple Grid Server ของฉันถูก "แฮ็ค" เช่นนี้หลายครั้ง ความปลอดภัยของพวกเขาแย่มาก ... เริ่มต้นด้วยรหัสผ่านธรรมดาเมื่อปีที่แล้วและยังคงดำเนินต่อไปจนถึงทุกวันนี้ (คุณสามารถโทรหาฝ่ายสนับสนุนด้านเทคนิคและพวกเขาพูดว่า ฉันรู้เพราะฉันได้รับอีเมลรายเดือนเกี่ยวกับวิธีที่พวกเขาได้เปลี่ยนรหัสผ่านบัญชีทั้งหมดของฉันและพวกเขาเข้าไปในและเปลี่ยนรหัสผ่านฐานข้อมูลสำหรับคุณทุกครั้งที่พวกเขาถูกแฮ็ก บริษัท นั้นดูมันวาวราวกับนรกบนพื้นผิว แต่กริดเซิร์ฟเวอร์นั้นยุ่งเหยิง ผมขอแนะนำให้เปลี่ยนทันที

โปรดดูโพสต์นี้เมื่อปีที่แล้วเกี่ยวกับความล้มเหลวดั้งเดิม (คำเตือนมันจะทำให้คุณโกรธ) มันตกต่ำจากที่นั่น ฉันใช้เวลาวันขอบคุณพระเจ้าเมื่อปีที่แล้วอยู่ห่างจากครอบครัวของฉันและลบลิงค์โป๊จากเว็บไซต์ของฉัน น่ารัก

ติดตามความสนุกในหน้าสถานะของพวกเขา: มันจะบอกคุณเกี่ยวกับการหาประโยชน์ล่าสุด (และใช่แน่นอนมี "การหาประโยชน์ที่เป็นไปได้" ตอนนี้)


ฮ่าฮ่า เว็บไซต์ gs ของฉันหมดลงแล้ว ไม่มีอีเมล weblog.mediatemple.net/weblog/category/system-incidents/…
typeoneerror

2

ขึ้นอยู่กับการขาดกิจกรรมในการเข้าถึงบันทึก ฯลฯ และความจริงที่เกิดขึ้นในเวลาเดียวกันก็ดูเหมือนว่าพวกเขาได้ทำลายเซิร์ฟเวอร์และมี shell script ของการเรียงลำดับบางอย่างเพื่อดำเนินการต่อท้าย

คุณได้ตรวจสอบ crontab สำหรับสิ่งแปลก ๆ หรือไม่?

คุณได้ลองเปลี่ยนชื่อไดเรกทอรีและการอ้างอิงไปแล้ว (ซึ่งอาจทำให้เชลล์สคริปต์เสียหาย)


การเปลี่ยนชื่อเป็นความคิดที่ดี ฉันจะลองดูว่าเมื่อฉันเห็นผลกระทบอะไรที่จะมีในเว็บไซต์ Crontab มีสิ่งหนึ่งที่แปลกเล็กน้อยมีรายการเกี่ยวกับเวลาที่ไฟล์ถูกเปลี่ยน แต่มันเป็นตัวจัดการการสำรองข้อมูล Plesk ... แอปพลิเคชั่นที่รวบรวม หากสิ่งนั้นถูกบุกรุก Media Temple มีปัญหาใหญ่ในมือของพวกเขา
Lothar_Grimpsenbacher

1

ใช่มันอาจเกี่ยวข้องกับการอนุญาตไฟล์อย่างแน่นอน เมื่อมีไฟล์ที่สามารถเขียนได้โดยกระบวนการทางเว็บคุณจะเปิดช่องโหว่ด้านความปลอดภัยในเว็บแอปพลิเคชันที่คุณใช้งานอยู่ ล็อคทุกอย่างลงเพื่อให้กระบวนการทางเว็บไม่สามารถอ่านหรือเขียนอะไรได้มากกว่าที่จำเป็น

องค์ประกอบอื่น ๆ กำลังติดตามว่าพวกเขากำลังแก้ไขไฟล์ของคุณอย่างไร การตรวจสอบบันทึกการเข้าถึงของเว็บเซิร์ฟเวอร์เป็นจุดเริ่มต้นที่ดี ตรวจสอบเวลาการเข้าสู่ระบบล่าสุดสำหรับผู้ใช้ที่หลากหลาย นอกจากนี้คุณยังสามารถตั้งค่าสคริปต์ที่ตรวจสอบไฟล์เพื่อทำการดัดแปลงและแจ้งให้คุณทราบเพื่อที่คุณจะได้ลองจับคนร้ายที่เป็นมือแดง!


1

สิ่งนี้ฟังดูคุ้นเคยกับการแฮ็ก Wordpressที่เข้าเยี่ยมชมเว็บไซต์ Network Solutions จำนวนมากเมื่อไม่นานมานี้ เนื่องจากคุณอยู่ใน Media Temple เป็นไปได้ว่าคุณจะปล่อยให้บางไฟล์ที่ผู้ใช้อื่นแชร์เครื่องของคุณสามารถมองเห็นได้ ที่จะอธิบายถึงการขาดการติดตาม POST หรือ eery Apache ที่น่าสนใจ หากเป็นกรณีนี้จะเป็นการง่ายมากที่จะฉีดโค้ดบนบรรทัดคำสั่ง


บันทึกแสดงปริมาณการใช้งานในช่วงเวลาที่มีการแก้ไขไฟล์เหล่านี้ แต่เป็นสิ่งที่ไม่มีอันตรายเช่น: 207.46.13.43 - - [05 / May / 2010: 01: 42: 26 -0700] "GET /oped/bpr.php?edid= 211 & หน้า = 4 HTTP / 1.1 "404 257" - "" msnbot / 2.0b (+ search.msn.com/msnbot.htm ) "
Lothar_Grimpsenbacher

คุณรู้หรือไม่ว่า Wordpress Hack นั้นทำงานอย่างไร อาจบอกวิธีแก้ปัญหาของตัวเองได้
Lothar_Grimpsenbacher

2
ใช่เป็นสิทธิ์ที่ไม่ดีในกล่องที่ใช้ร่วมกันอาจเกิดจากการกำหนดค่าเริ่มต้นที่ไม่ดีในส่วนของ Network Solutions การแก้ไขที่แนะนำคือล็อคการอนุญาตเป็น 755 ในโฟลเดอร์และ 644 สำหรับไฟล์

1

รหัสจะถูกต่อท้ายเสมอในหนึ่งไดเรกทอรีที่เฉพาะเจาะจง

มันเกี่ยวข้องกับการอนุญาตที่ตั้งไว้ในไฟล์ (ตั้งแต่ 755 ถึง 644) หรือไม่? ถึงผู้ใช้เว็บเซิร์ฟเวอร์

คุณอยู่บนเซิร์ฟเวอร์ที่ใช้ร่วมกัน ถ้าเป็นเช่นนั้น (หรือแม้ว่าจะไม่ใช่) บางคนอาจถูกบังคับให้ใช้รหัสผ่าน FTP และอัปโหลดสคริปต์ที่ต่อท้ายไฟล์ใด ๆ

โปรแกรมหนึ่งใช้โดยโปรแกรมโฆษณาของบุคคลที่สาม

หรือบางทีโปรแกรมนี้มีช่องโหว่


ฉันสมมติว่าอาจเป็นเพราะรหัสบุคคลที่สามมีช่องโหว่ มันอยู่บนเซิร์ฟเวอร์ที่ใช้ร่วมกัน แต่ผมจะได้พบสคริปต์ที่อัปโหลดใด ๆ (ยกเว้นกรณีที่พวกเขาอัปโหลดไปใช้มันแล้วลบมัน แต่แม้แล้วฉันจะได้พบบางสิ่งบางอย่างในแฟ้มบันทึกการแสดงการเชื่อมต่อ FTP ของพวกเขา)
Lothar_Grimpsenbacher

1
หากเว็บเซิร์ฟเวอร์สามารถเขียนไฟล์ของคุณได้อาจเป็นไปได้ว่าพวกเขาสามารถอัปโหลดสคริปต์ไปยังเว็บไซต์ใด ๆบนเซิร์ฟเวอร์และเขียนทับไฟล์ของคุณ แต่ฉันก็จะดูอย่างใกล้ชิดกับแอปของบุคคลที่สามนั้น

รหัสของบุคคลที่สาม ... มันเป็นสคริปต์ที่ปฏิบัติการหรือเพียงแค่ข้อมูลโค้ด JavaScript? JavaScript ไม่สามารถแก้ไขไฟล์บนเซิร์ฟเวอร์
Salman

@Salman A - เป็นชุดของสคริปต์ PHP ที่จัดการโฆษณา
Lothar_Grimpsenbacher

ตกลงฉันหวังว่าคุณจะได้ตรวจสอบรหัสนั้นแล้ว
Salman

1

หากคุณมีการเข้าถึงที่เหมาะสม (และการสนับสนุนเคอร์เนล) คุณสามารถลองแส้ daemon การตรวจสอบตามinotifyหรือdnotifyเพื่อดูการเปลี่ยนแปลงไฟล์ของคุณจากนั้น (อย่างรวดเร็ว) ใช้ "lsof" เพื่อดูว่ากระบวนการเปิดไฟล์ใดด้วย สิทธิ์การเข้าถึงเพื่อเขียน คุณอาจสามารถใช้straceเพื่อตรวจสอบได้ ที่ควรให้เบาะแสเกี่ยวกับสิ่งที่ปฏิบัติการถูกใช้ประโยชน์


1

FTP การตรวจสอบบันทึกเป็นจุดเริ่มต้น บันทึกควรมีมากที่สุดหากไม่ใช่กิจกรรมทั้งหมดพร้อมกับการประทับเวลาดังนั้นหากคุณรู้ว่าเวลาใดที่ไฟล์ของคุณถูกแก้ไขคุณสามารถพิจารณาได้ว่าบัญชี FTP ของคุณถูกบุกรุกหรือไม่

ถัดไปอาจเป็นสคริปต์บนเว็บเซิร์ฟเวอร์ของคุณที่ฉีดโค้ดนั้น cat /web/malicious.com/script.js >> /web/innocent.com/index.phpในสถานการณ์โฮสติ้งที่ใช้ร่วมกันผมคิดว่ามันเป็นไปได้ที่จะทำ สิ่งนี้อาจทำงานภายใต้เงื่อนไขบางประการเช่นคำสั่งที่ดำเนินการโดยผู้ใช้ httpd และไฟล์ index.php ก็เป็นเจ้าของ / เขียนได้โดยผู้ใช้นั้น ในกรณีนี้คุณควรมีผู้ให้บริการโฮสต์ของคุณเพื่อติดตามบัญชีที่ใช้ในการฉีดสคริปต์


1

ไฟล์เว็บไซต์ส่วนใหญ่ต้องอ่านโดยเว็บเซิร์ฟเวอร์ บนเว็บไซต์แบบอ่านอย่างเดียวบันทึกเท่านั้นที่ต้องสามารถเขียนได้โดยเว็บเซิร์ฟเวอร์ ตั้งเจ้าของเป็นคนอื่นที่ไม่ใช่เว็บเซิร์ฟเวอร์ ตั้งการป้องกัน 640 ในไฟล์ทั้งหมดยกเว้นสคริปต์ ตั้งค่าสคริปต์และไดเรกทอรี 750 สำหรับไฟล์หรือไดเรกทอรีที่ต้องเขียนโดย websever คุณสามารถเปลี่ยนเจ้าของเป็นเว็บเซิร์ฟเวอร์หรือตั้ง chmod g + 2 ไฟล์หรือไดเรกทอรีที่เกี่ยวข้อง


สคริปต์ที่ไม่ใช่ CGI มักจะมีโหมด 600 หรือ 640 (ขึ้นอยู่กับเจ้าของไฟล์ & กลุ่มและผู้ใช้ที่เว็บเซิร์ฟเวอร์ทำงาน) เนื่องจากสคริปต์หลายตัวถูกส่งผ่านไปยังล่าม
outis

0

มีวิธี zillion ที่เป็นไปได้ในการถอดรหัสเว็บไซต์ พวกเขาอาจใช้ช่องโหว่ในสคริปต์ของคุณขโมยรหัสผ่านของคุณใช้ช่องโหว่ของไซต์ที่โฮสต์ร่วม (หากคุณอยู่ที่โฮสต์ที่ราคาถูก) ใช้ช่องโหว่ของบริการที่ไม่เกี่ยวข้องกับเว็บบนเครื่องเซิร์ฟเวอร์ .

ในขั้นตอนแรกให้ตรวจสอบวันที่แก้ไขไฟล์และตรวจสอบการเข้าถึงข้อผิดพลาดและบันทึก ftp สำหรับกิจกรรมที่น่าสงสัยในเวลานั้น


0

สิ่งเดียวกันเกิดขึ้นกับฉันในขณะที่หลัง Wordpress เป็นซอฟต์แวร์เดียวที่จะทำให้เกิดสิ่งนี้เท่าที่ฉันรู้


Wordpress ไม่มีส่วนเกี่ยวข้องที่นี่
Lothar_Grimpsenbacher
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.