Trang chủ » Hacking and Security » Những cuộc đối thoại với rookie - Phần 14

5 thg 11, 2012

Những cuộc đối thoại với rookie - Phần 14


17. Những điều xem chừng vụn vặt: 
Dạo này bọn tôi, 'cuti', 'haothu', 'docco', 'ccxx' và tôi ít có dịp trò chuyện như trước. Có lẽ mấy cô cậu phải vùi đầu vào sách vở và phần tôi cũng không kém phần căng thẳng. Hàng loạt dự án đã được phê chuẩn và ông trưởng dự án nào cũng muốn dự án của mình có ưu tiên cao nhất. Nói thế tôi hy vọng bạn hình dung được nổi thống khổ của một kẻ 'làm công cho thiên hạ'. 


Đã gần một tháng trôi qua, tôi chỉ nhận được một e-mail từ 'docco' hỏi thăm tình hình công việc một cách chung chung. Tôi quyết định sẽ lấy 1, 2 ngày nghỉ bù (vì đã làm quá nhiều giờ). Nhẩm tính chiều thứ năm tới tôi sẽ rảnh ranh, để hỏi thăm đám 'cuti' có rảnhh không thì tụ lại đà khía một chặp cho vui. Thế là tôi gởi mail đến bốn trự. Mãi chiều hôm kế tiếp tôi mới nhận được thư hồi báo của cả bọn. Thế là chúng tôi hẹn nhau chiều thứ năm. 

Một giờ hai mươi lăm trưa, tôi log vào YIM. 
'docco' đang "vàng khè" online. Tôi không muốn bị "oanh tạc" nên đã cẩn thận logon ở dạng ẩn cho nên 'docco' vẫn không biết tôi đã logon. Tôi gởi cu cậu một thông điệp: 
"Hù... vào lâu chưa em?" 

'docco' không kém phần dí dỏm: 
"Oái oái, có ma, có ma.... hì hì. Khoẻ không anh? dạo này bọn em phê quá, bài vở nhiều hơn trước. Với lại em ráng tìm hiểu những chi tiết mấy anh em mình đà khía và càng tìm hiểu em càng thấy mênh mông."

Tôi đáp: 
"Ừa, lúc đầu thường bị cảm giác choáng ngợp đó em. Từ từ sẽ dễ dàng hơn thôi. Mấy đứa kia đâu rồi em?" 

'docco' trả lời: 
"Tụi thằng Hưng, con Như nói là tụi nó sẽ vào chặng này nhưng em chưa thấy đâu. Để em gọi di động cho tụi nó thử. Còn thằng quái vật Khoa thì biến mất hút. Em nghe mấy đứa bạn nói là dạo này nó đắm chìm vào game. Kiểu này chắc hết học với hành (" 

Tôi chắc lưỡi, đáp: 
"Ừa, sao dạo này anh thấy game nở rộ, đi đâu cũng game, thậm chí lên báo om sòm. Chơi game không có gì sai hết nhưng chơi quên ngày giờ, quên học hành, quên mọi sinh hoạt khác thì kẹt lắm." 

Ngay khi đó, 'ccxx' vào. Cô bé nhanh nhảu gởi một thông điệp: 
"Tụi em đây. Ông Hưng đang ở nhà em, tụi em chat chung hén?" 

Lần này tôi gởi một request để thảo luận và cả bọn cùng vào conference. 'ccxx' lên tiếng: 
"Anh ui, em tìm nát nước mà không thấy có thông tin gì về SE hết anh?" 

Tôi đáp: 
"SE gì em? Software Engineering đó hả?" 

'ccxx' trả lời: 
"E hèm... anh đúng là già rồi nên lẫn ). Thì cái TCP flag SE lần trước em thắc mắc đó?" 

Tôi cười phì: 
"Mô phật... làm sao anh nhớ cho xuể em. Mà anh nhớ thằng Hưng thắc mắc vụ này mà? Đâu phải em đâu Như?" 

'ccxx' cười: 
"Hì hì, em đây, Hưng đây. Tụi em chat chung mà ). Em vừa thắc mắc chớ hổng phải Như đâu." 

Tôi đáp: 
"Mèn ơi... vậy thì em nên dùng H: hay N: để anh phân biệt đứa nào là đứa nào không thì lộn tùng phèo lên hết. OK, cái vụ SE nếu em chưa tìm ra thì anh cho cái RFC để mà xem. Thử tìm rfc3168 mà đọc nha em. Nó có một phần nói về SE trong đó." 

'cuti' than thở: 
"H: ặc ặc, anh đúng là ác thiệt là ác (. Hẹn cho đã rồi thảy cho cái RFC bắt phải đọc nữa." 

Tôi đáp: 
"Khì khì, vậy mà ác sao em? anh đưa cho em chính xác RFC để em tìm mà đọc là rút ngắn cho em khối thời gian để tìm rồi đó, vậy mà còn than với thở. Em không cần phải đọc liền, chỉ ghi chú ở đâu đó rồi lúc nào thanh thản hẵng tìm mà đọc không thì bội thực ráng chịu )." 

'ccxx' xen vào: 
"N: Ổng lúc nào cũng vậy đó anh. Thấy cái gì cũng ham. Lúc nào cũng ôm đồm đủ thứ rồi nản. Em nói hoài không chịu nghe. Hồi trước thấy thiên hạ đua nhau sưu tầm e-book cũng bắt chước thức khuya thức hôm để download cho được. Mang về cả gi -2- rồi có bao giờ đụng tới đâu? Vô mấy cái forum, thấy người ta kháo cái ngôn ngữ lập trình nào là hăm hở về lục đục cả đêm, Python cũng cài, Ruby cũng đặt, lại còn php, đèo bồng thêm Java rồi khệ nệ bưng cả đống CD mua ngoài tiệm về cho mấy cái .NET gì đó... Vậy mà em chưa thấy ổng code cho ra một cái gì cho rõ ràng hết. Tụi em cãi nhau hoài về chuyện này anh ơi (." 

Tôi cười, chậm rãi đáp: 
"Thế này.... 
Cu Hưng nó thích táy máy, cái thì thấy, nghe cũng ham là chuyện tốt, có thông minh mới có như thế. Nếu nó thụ động, chẳng ham cái gì thì mới nguy. Việc cần làm là 'đốc' làm sao để nó thực hiện một công trình nho nhỏ nào đó. Khi nó bắt tay vào công trình đó, tự nhiên đống e-book kia sẽ hữu dụng và tự nhiên nó sẽ master một ngôn ngữ lập trình nó chọn. Em nên khuyến khích nó, đừng cãi làm chi cho.... rắc rối thêm )." 

'ccxx' trả lời: 
"N: Em đâu muốn cãi với ổng, em chỉ góp ý để tốt cho ổng thôi mà ổng bướng thầy chạy luôn á. Với lại cái gì em cũng phải nhắc ổng, có bao giờ ổng quan sát mà nhắc em cái này cái kia đâu anh? Bữa nay nhân dịp này em muốn anh can thiệp dùm em cái. Hay là anh ra bài gì cho ổng làm đi anh? Ổng chỉ nghe lời anh thôi." 

Tôi cười phá lên và đáp: 
"Ha ha, đến giờ này anh đã lấy vợ mười mấy năm mà bà xã anh vẫn nhắc anh đủ chuyện, có bao giờ anh nhắc bà xã anh cái gì đâu em? Đàn ông, con trai vậy là bình thường thôi em. Để anh thử xem cu Hưng nó thích làm cái gì đã." 

'ccxx' nguýt: 
"N: Hứ... mấy ông con trai cứ hở ra là bênh nhau thôi. Em chỉ thấy ổng biết lung tung thứ nhưng hầu hết là những thứ lặt vặt, chắp vá. Mai mốt ra trường, đi kiếm việc người ta hỏi có khả năng gì, biết làm gì? Chả lẽ khai ra mấy cái kinh nghiệm mạng lặt vặt sao anh?" 

Tôi đáp: 
"Hì hì, em nói chí lý lắm bé Như. Anh không bênh cu Hưng chuyện này đâu. Để xem cu Hưng nghĩ sao. Nè, ku Hưng, em nghĩ là em muốn làm gì hở?" 

"cuti" lên tiếng: 
"H: Đó, bả ỷ có anh ở đây nên ăn hiếp em túi bụi. Tại vì em chỉ muốn tìm hiểu xem mình thích hợp với cái gì rồi mới quyết định thôi mà anh. Em nghĩ là em thích cả quản lý mạng và lập trình. Làm sao mình trau dồi được cả hai hở anh?" 

Tôi trầm ngâm, tìm cách trả lời 'cuti'. Sau một đỗi, tôi đáp: 
"Thế này... anh thấy trong mạng có lập trình và trong lập trình có mạng. Tuy nhiên, trong quá trình đi sâu và master mỗi nhánh này, nó đòi hỏi một số điểm chung và điểm riêng. 

1) nếu em chọn mạng làm sở trường, em đi sâu vào việc học và làm quen các thiết bị mạng, các ứng dụng software chuyên về mạng, các giao thức mạng và các kỹ năng phân tích + thiết kế môi trường mạng. Chọn lựa này không đòi hỏi kỹ năng lập trình sâu và chuyên như nhánh lập trình. Tuy nhiên, em cần khả năng lập trình để hỗ trợ công việc quản trị mạng này. Ví dụ, em cần thiết lập một hệ thống theo dõi các nodes trong mạng, hoặc thu thập logs của các services để phân tích tình trạng hoạt động của mạng, em không nhất thiết phải lập trình ở mức độ chuyên để tạo ra một software đa năng, mạnh mẽ, ít bugs mà em chỉ cần code bằng ngôn ngữ nào đó dễ học, gọn nhẹ để thực hiện mục đích. Tất nhiên, nếu em có thời gian và khả năng để code một công cụ thật chuyên thì càng tốt hơn. Mạng ở đây là cung cấp phương tiện giao chuyển thông tin một cách hiệu suất, ổn định bằng các thiết bị, môi trường cho phép. 

2) nếu em chọn lập trình làm sở trường, em đi sâu vào việc học và làm quen với tính logic, khả năng lập luận, phân tích, cú pháp của ngôn ngữ lập trình, API em dùng và thậm chí cả cơ chế làm việc của một hệ điều hành hoặc một chuỗi hệ thống. Mạng sẽ dính đến lập trình ở một lúc nào đó bởi về không có hệ thống nào ngày nay mà không đụng đến mạng. Tuy nhiên, biên độ mạng ở đây không trực tiếp và cụ thể đến từng thiết bị của từng hãng nào đó mà nó thường nằm ở tầng thấp hơn (socket) hoặc tầng cao hơn (application xuyên qua API). 

'docco' xen vào: 
"Em cũng đã hình dung lờ mờ những điểm ở trên và cảm thấy những ham muốn 'cả hai' là những ham muốn hơi quá trớn bởi vì không thể thực hiện một cách vẹn toàn được. Cái gì cũng muốn, cái gì cũng quơ quào thì một hồi sẽ lõng bõng thôi." 

Tôi đáp: 
"Đúng đó em. Anh nghĩ, khởi đầu nên đi vào chiều sâu. Khi đã vững thì tự nhiên nó sẽ mở ra chiều rộng. Nếu sâu không đủ mà rộng không tới thì chắc chắn sẽ bị 'lõng bõng' như em nói." 

'cuti' chống chế: 
"H: Em không đồng ý. Chớ anh thì sao? Anh cũng làm về mạng, cũng lập trình được vậy? Em muốn làm theo kiểu anh làm thôi." 

Tôi đáp: 
"Thật sự mà nói, nói về mạng, anh không phải là tay thật chuyên về mạng, nói về lập trình, anh cũng chẳng phải là một tay chuyên chú lập trình. Bởi thế, anh vẫn học thêm vào đào sâu từng mảng kiến thức mỗi ngày đó thôi. Anh đi vào ngành này không được chính quy, có trường lớp như bọn em nên sự thể như thế cũng không đáng ngạc nhiên. Nếu em muốn làm theo 'kiểu anh làm' thì cực nhọc lắm đó vì em phải chuyên cần và kiên nhẫn." 

'cuti' nhấm nhẵng: 
"H: Được rồi, được rồi, em nhất định sẽ chuyên cần và kiên nhẫn." 

'ccxx' châm thêm: 
"N: Ừa, thì làm đi rồi hẵng nói. Lần nào cũng 'em sẽ thế này, em sẽ thế kia' nhưng được ba bữa là đâu lại vào đấy thôi." 

'cuti' nói: 
"H: Em thấy mấy anh em mình bàn càng lúc càng xa khỏi biên độ hacking và security hay sao đó. Mình nói chuyện cụ thể hơn được không anh?" 

Tôi cười, đáp: 
"Cụ thể thế nào em? Anh nhớ có lần mình đã đồng ý với nhau rằng, hacker là một user có kiến thức sâu dày, hiểu rõ và nắm rõ những gì anh ta muốn hack và cần hack rồi mà. Cho đến chừng nào em thật sự có kiến thức sâu dày, hiểu rõ và nắm rõ những gì em muốn hack và cần hack thì tự nhiên em thấy nó hết sức cụ thể. Những kiến thức bao quanh cái gọi là 'sâu dày', cho đến nay em vẫn chưa đạt tới thì làm sao mình nói chuyện cụ thể?" 

'cuti' cụt hứng: 
"H: Ờ hén... em cứ bị vướng víu chuyện này mãi. Ý em nói là sau khi mình xác định được foot print đầy đủ hết rồi, mình sẽ làm gì nữa anh?" 

Tôi đáp: 
"Em muốn đóng vai trò em là tester hay đóng vai trò em là perpetrator?" 

'cuti' đáp: 
"H: Em không biết nữa anh. Miễn sao em hiểu được các bước thâm nhập gồm có cái gì để thoả mãn cái tò mò là được." 

Tôi đáp: 
"E hèm... vắng mặt mới có một tháng mà nó đã quên hết ráo. Không có các bước thâm nhập nào hết đâu em. Một ngàn hệ thống có một ngàn tính chất khác nhau. Ngay cả cũng chính hệ thống đó, ngày hôm trước có thể khác ngày hôm sau. Bởi thế, không thể có 'các bước' cụ thể nào cả. Vả lại, trước giờ mình bàn về cái nhìn từ hai phiá bảo mật + thâm nhập chớ chưa bao giờ mình nói đến chuyện 'các bước' nào hết." 

'cuti' tiếp tục: 
"Ùm... nhưng em ức ở chỗ sao nhiều người có thể dạo một vòng, làm cái gì đó là có ngay 'hacked by xyz...', rồi nào là hack local, nào là up shell... Em hỏi mà chả có ai thèm trả lời em hết." 

Tôi đáp: 
"À, ra thế. Nếu em thắc mắc những chuyện đó thì anh sẽ cố gắng giải thích trong giới hạn cho phép. Tuy nhiên, em cần xác định rõ là những gì mình trao đổi bấy lâu nay không phải để hướng về những chuyện như thế." 

'cuti' hớn hở: 
"Dạ em biết mà. Anh giải thích dùm em mấy cái đó là cái gì đi?" 

Tôi đáp: 
"Sở dĩ một ai đó có thể vào site của một ai khác để trưng lên dòng 'hacked by...' là vì hắn có đủ chủ quyền để thay đổi nội dung một trang nào đó trên web site này. Em còn nhớ lần anh em mình cá độ và em chịu thua không? Nguồn gốc vấn đề nằm ở chỗ thư mục có chứa file mang nội dung 'hacked by... " kia cho phép một ai đó có chủ quyền thích ứng thay đổi nội dung file như thế." 

'cuti' đáp: 
"Em biết rồi, nhưng làm sao có thể đổi ngang xương như vậy anh? Em thử ngay chính con Linux của em rồi mà không được. Ví dụ thư mục đó chứa index.html và do B làm chủ, em là A, em chỉ có quyền đọc nó thôi, không có quyền chỉnh nó." 

Tôi đáp: 
"Anh nghĩ em nên nhớ lại những gì mình trao đổi trước đây, có lẽ em quên khá nhiều rồi đó. Nếu em là A, em không thể thay đổi nội dung file do B làm chủ. Để có thể thực hiện hành động thay đổi nội dung đó, em có thể: 
- biến mình thành B 
- biến mình thành C nếu C thuộc nhóm với B và có cùng chủ quyền 
- biến mình thành X nếu X có chủ quyền hơn cả B 

Em nghĩ xem, trên Linux server của em đó, em là A, B là chủ của thư mục, vậy C là ai và X là ai?" 

'cuti' ngần ngừ: 
"H: Em chẳng biết nữa (.... để em coi lại thử." 

Tôi nói thêm: 
"Trên *nix, tổng quát mà nói, một thư mục có A làm chủ, có nhóm users gán cho thư mục ấy và có chủ quyền rwx. Một file trong thư mục cũng tương tự. Nếu A là owner thì A có thể làm bất cứ điều gì mình muốn đến thư mục và file trong thư mục ấy. Nếu thư mục và files có ấn định là nhóm users gán cho nó có cùng chủ quyền thì mọi người trong nhóm đều có thể thực hiện công việc y hệt như A. Ngoài ra, root cũng có thể làm tương tự. Đây là kiến thức căn bản không thể thiếu được." 

'cuti' cãi lại: 
"H: Em không tin là mấy đứa trên mạng có đầy đủ các kiến thức như vậy đâu anh. Hổm bữa em chat với một thằng, nó biểu diễn cho em coi nhưng em hỏi nó về Linux thì nó nói là nó không biết gì nhiều về Linux hết. Vậy sao nó vẫn làm được?" 

Tôi hỏi: 
"Nó làm những gì, nó có cho em biết không?" 

'cuti' đáp: 
"Dạ, nó dấu nghề mà anh. Làm gì cho em biết. Nó chỉ nói thao thao nào là up shell, rồi đổi index... cái gì, cái gì đó... Em rối tung, rối mù lên." 

Tôi cười đáp: 
"À, anh hiểu rồi. Mấy cái 'shell' mà em nói ở đây không phải OS's shell thông thường -3- mà chỉ là những script được viết bằng Perl hay Python hay thậm chí php. Nó có khả năng thực thi một số công việc định sẵn và nó chạy ở trên web service được tạo bằng Apache chẳng hạn. Tất nhiên là những cái shell này chỉ có thể làm việc nếu cấu hình của Apache cho phép và tất nhiên chúng chỉ có thể chạy với chủ quyền tối đa là chủ quyền admin đã ấn định cho Apache. Anh nghĩ nếu em thích thì em nên xem cách những cái shell này được viết thế nào để hiểu chúng làm việc thế nào thì mới lý thú và đáng thời gian bỏ ra. Còn nếu chỉ dùng một cái 'shell' do ai đó viết để xem files, delete files hay làm những chuyện khác trong giới hạn có thể được thì em chỉ dừng lại ở mức độ người dùng mà thôi, thậm chí còn kém hơn người dùng bởi vì người dùng cần shell để quản lý hệ thống, còn em cần 'shell' để phá hệ thống." 

'cuti' rên rỉ: 
"H: đó đó, ông thầy ổng lại lên lớp rồi đó. Em chỉ muốn biết thôi mà (." 

Tôi đáp: 
"Thì anh đã nói, em muốn biết thì nên sưu tầm vài cái 'shell', chúng có đầy trên web đó. Tải về và xem chúng được viết thế nào. Nếu muốn biết chúng làm việc thế nào thì cài lên cái Linux server của em mà vọc. Anh đâu có cản gì đâu? Anh chỉ muốn nhắc em là đừng sa đà vào những trò vớ vẩn bởi vì upload một cái shell lên server của người khác rồi delete files, rồi thay thế index.html có nội dụng 'hacked by cuti' thì chẳng có gì vui và sáng tạo cả. Mấy cái trò này dành cho những đừa 'teen' -4- dư thời gian và thiếu định hướng mà thôi. Em đã qua cái thời này rồi thì đừng nên đi thụt lùi lại." 

'docco' xen vào: 
"Em có một thắc mắc với câu ở trên của anh. Anh nói là Tất nhiên là những cái shell này chỉ có thể làm việc nếu cấu hình của Apache cho phép và tất nhiên chúng chỉ có thể chạy với chủ quyền tối đa là chủ quyền admin đã ấn định cho Apache là sao anh?" 

Tôi cười và trả lời: 
"À... có lẽ em chưa dùng Apache nhiều nên thắc mắc. Câu ở trên có hai phần riêng biệt trong đó. 

- phần một: Apache có một directive gọi là AddType dùng để phủ định một loại MIME nào đó đã được ấn định trong file "mime.types". Nếu trong file "mime.types" không có ấn định nào cho php chẳng hạn và cũng không có ấn định nào từ directive AddType trong cấu hình của Apache thì một file php nào đó, khi được access trên trình duyệt, nó sẽ được hiển thị như một text file bởi vì Apache cho rằng nó là một text file và cung cấp nó đến trình duyệt như một text file. Ở tình trạng này, cái 'shell' php đó không thể thực thi gì cả. 

- phần hai: Nếu php được ấn định cụ thể ở một AddType directive nào đó, khi người dùng access nó bằng trình duyệt, nó sẽ thực thi các function có trong file này và nó chạy bằng chủ quyền y hệt như chủ quyền đã ấn định cho Apache." 

'docco' ậm ừ: 
"Ùm... à... em hơi hiểu hiểu rồi đó. Chỉ có phần chủ quyền ấn định cho Apache em chưa hiểu." 

Tôi cười và đáp: 
"Khì khì, lại có màn 'hơi hiểu hiểu' nữa hả? Em thắc mắc phần chủ quyền ấn định cho Apache là một thắc mắc rất lý thú. Nó gắn liền với những cơ chế sâu xa trên hệ điều hành đó. Điều em cần nắm là nguyên tắc tạo ra một process trên hệ điều hành. Ở đây mình giới hạn trên Linux để tránh lan man. 

Ở những phiên bản sơ khai của Apache, khi em khởi động Apache, nó tạo ra một process do root làm chủ. Sở dĩ em phải khởi động Apache ở chế độ là root là vì Apache sẽ tạo một LISTENING port 80. Port 80 là port nằm trong chuỗi "low ports" (dưới 1024) và để tạo một port trong chuỗi này em phải là root thì mới tạo được. Sau này Apache hình thành cơ chế 'chuyển quyền' sau khi khởi động. Nói một cách nôm na là sau khi khởi động và tạo xong port 80 ở tình trạng LISTEN, nó hạ chủ quyền từ root xuống thành chủ quyền của một account nào đó em gán trong cấu hình của Apache. Em biết lý do tại sao không?" 

'ccxx' reo lên: 
"N: Em biết, em biết. Có phải đây là lý do an toàn không anh? Nếu Apache chạy ở chủ quyền root và ai đó load một con 'shell' nào đó lên thì con shell này cũng sẽ chạy với chủ quyền root, phải không anh?" 

Tôi đáp: 
"Em thông minh lắm. Lý do chính xác là như thế. Trên *nix, root là account có quyền hạn tuyệt đối và nếu một dịch vụ nào đó cho phép một script nào đó... 'chạy ké' như mấy con 'shell' mà cu Hưng thắc mắc ở đây ở quyền hạn tuyệt đối như thế thì bảo mật coi như là con zero to tướng. Này Duy, nếu em thích đào sâu, em có thể tìm thông tin về 'process forking' trên *nix để nghiên cứu thêm. Riêng với phần 'hạ chủ quyền' thì em có thể tìm thông tin về setuid mà đọc." 

'cuti' xuýt xoa: 
"E hèm... em hỏi rùa rùa mấy con shell vậy mà cũng có chuyện thật là lý thú. Cũng không phí anh nhỉ? )" 

Tôi đáp: 
"Ừa, bất cứ điểm nhỏ bé nào đi chăng nữa, khi mình nhìn nó một cách cẩn thận và ngọn ngành để có thể hiểu rõ về nó thì anh tin rằng lúc nào cũng có chuyện lý thú cả." 

'ccxx' trầm ngâm: 
"Có ai ngờ mấy cái 'directive' nhỏ bé và đơn giản của Apache mà lại quan trọng đến thế." 

Tôi đáp: 
"Tất cả các chức năng, ấn định trên một ứng dụng đều có vai trò của chúng. Nếu không, chúng không tồn tại và những gì không cần thiết hoặc không đúng chức năng thì từ từ sẽ bị biến mất. Đối với những chương trình cung cấp dịch vụ, người quản lý cần biết lý do tại sao chúng tồn tại và chúng làm việc thế nào, người bảo mật hay tấn công chẳng những nắm vững những điều người quản lý nắm mà còn đi sâu hơn để biết mặt yếu của chúng." 

'cuti' lên tiếng: 
"Quay trở lại mấy cái shell, anh nói là mấy cái đó không có gì đáng để học sao?" 

Tôi trả lời: 
"Em dùng thanh trượt để kéo lên phía trên xem lại đi em. Những 'con' script đó có điểm đáng để học là nội dung của nó, cách nó được code chớ không phải là cách cài nó và dùng nó. Mục đích nó được code ra để làm việc tốt hay việc xấu mình không bàn nhưng nó được code như thế nào thì đáng để học hỏi. Anh thấy đọc code cũng là một cách học rất hay bởi vì xuyên qua code, mình không những học được những góc độ kỹ thuật trong đó mà còn học được cách tư duy, logic, sắp xếp của người đã code." 

'cuti' gỡ gạc: 
"H: Nhưng mình cài nó lên rồi quậy quậy tí tí cũng vui mà anh. Em biết ý anh nói gì rồi. Ý anh là tụi em học thêm Perl, Python hay cái gì gì nữa phải không? )" 

Tôi đáp: 
"Ừa, để em có thể đọc được code do ai đó viết và nhất là 'cảm' được cái hay của nó, em phải thông thạo ngôn ngữ được dùng để viết nó ra." 

'docco' hỏi tiếp: 
"Anh có thể cho em một đoạn code minh hoạ được không anh?" 

Tôi đáp: 
"Code minh hoạ thì có đầy dẫy trên mạng mà em. Nhưng được rồi, chờ anh một tí. 

Tôi lục lọi trong mớ "disclosed exploit" nhận được từ newsgroup và trả lời: 
"Hãy thử xem một đoạn cho vui, đoạn này anh lấy từ newsgroup do Matthew Murphy viết: 

Code:
$f = IO::Socket::INET->new(Proto=>"tcp", PeerAddr=>"127.0.0.1");
print STDOUT "Exploiting a proxy server \[Y/N\]? ";
$line = <STDIN>;
$char = mychomp($line);
if ($char == "Y" || $char == "y") {
print $f "GET / HTTP/1.1\x0d\x0a";

 for ($i = 0; $i < 10; $i++) {
print $f "Host: ".("A"x2000)."\r\n";
}
if (defined($base64)) {
print $f "Proxy-Authorization: Basic ".$base64."\r\n";
}
print $f "\r\n";
} else {
print STDOUT "What resource should be probed: ";
.........
}

" 

Tôi hỏi tiếp: 
"Nếu quen với Perl, em sẽ thấy đoạn code trên hết sức đơn giản nhưng cái lý thú là Perl được dùng để exploit một chỗ hở của Apache một cách dễ dàng và gọn gàng. Em xem cho biết." 

Cả ba im lặng hồi lâu. Rốt cuộc 'docco' lên tiếng: 
"Em thì bó tay rồi đó anh vì em chẳng biết perl. Chắc hai đứa kia cũng vậy thôi (. Anh giải thích một tí được không anh?" 

Tôi đáp: 
"Đại khái là thế này. Exploit trên nhằm qua mặt cơ chế giới hạn số lượng và kích thước của HTTP header mà Apache (giả định đã) kiểm soát. Nó in ra 9 dòng ($i = 0; $i < 10; $i++) "Host: AAAAA...." mỗi dòng có 2000 chữ A. Với kích thước này, phiên bản Apache bị lỗi sẽ crash vì giới hạn header chỉ là 8190 bytes." 

'cuti' xuýt xoa: 
"H: Ái chà, chỉ có vài dòng đơn giản như thế mà crash được cả apache server thì quả là đỉnh ), nhưng làm sao người viết đoạn script này biết được ngay cái chỗ để ngoáy vào cho nó chết vậy anh?" 

Tôi đáp: 
"Tay Matt này không trình bày quá trình test cụ thể của mình nhưng anh đoán có ít nhất hai hướng để test và tìm lỗi: 

1) thử dạng 'blackbox': bằng cách chọc ngoáy vào cái HTTP header cho đến khi Apache có "thái độ" khác thường. Cách này thì lâu và càng lâu hơn nếu không nắm được giao thức HTTP và cách làm việc của nó. 

2) thử dạng rà code: mã nguồn của Apache là mã nguồn mở. Nếu muốn máy mó thì download nó về mà soi. Tuy nhiên để làm được chuyện này, ngoài việc nắm vững giao thức HTTP, em còn phải rất rành C thì mới rà được." 

'ccxx' hỏi tiếp: 
"Ùm... em hơi bị lơ mơ rồi đây (. Làm sao mình có thể xác định khu vực hoặc thu hẹp khu vực có tiềm năng bị hở mà khai thác anh? Em nghĩ một soft như Apache chắc phải có vài trăm nghìn dòng code là ý. Dò như vậy chắc chết." 

Tôi cười, đáp: 
"Em nói đúng. Không mấy ai dò từng dòng một, ngoại trừ người dò đó là tay lo về quality assurance cho code của Apache ). Dẫu tay ấy có rà kiểu như vậy, cơ hội bị sót hoặc không nhận ra chiều sâu của lỗ hổng bảo mật rất cao. Theo kinh nghiệm anh rút tỉa được, những điểm nhận INPUT và kiểm soát, xác thực, giới hạn giá trị INPUT của một software là điểm đầu tiên nên được xét bởi vì ở những điểm này, dữ liệu có tính chất và kích thước nằm ngoài giới hạn dự tưởng nhất định sẽ tạo 'thái độ' bất bình thường cho software đó. Đối với một ứng dụng cung cấp dịch vụ web như Apache, điểm nhận INPUT quan trọng là mớ HTTP header. RFC cho giao thức HTTP có những quy định tổng quát nhưng bỏ ngỏ nhiều điểm tùy vào người ứng dụng. Bởi thế, điển hình là Apache quyết định giới hạn tối đa của header field có kích thước là 8190 bytes mặc dù RFC tiêu chuẩn không ép buộc giới hạn này." 

Tôi ngừng lại một chút rồi hỏi tiếp: 
"Em theo kịp không Như?" 

'ccxx' đáp: 
"Dạ kịp anh. Có gì em lưu lại nội dung chat này để về đọc offline thêm. Anh an tâm )." 

Tôi nói tiếp: 
"Giả sử anh là người lo về việc kiểm tra tính bảo mật và chất lượng cho code của Apache, hoặc anh có ý định thử nghiệm để exploit Apache, anh bèn lôi tài liệu kỹ thuật của Apache ra mà ngâm, so sánh các ứng dụng của nó với RFC, tìm và rà những đoạn code liên quan đến những điểm INPUT, liên quan đến HTTP header. Sau đó xoáy sâu và cụ thể vào từng điểm một của cơ chế quản lý và kiểm soát dữ liệu nhập. Ví dụ, Apache ấn định mỗi header field chỉ tối đa là 8190 bytes, cái này thì đã rõ nhưng.... cơ chế nào kiểm soát chuyện này và nó kiểm soát như thế nào? có cách nào lừa nó để đi quá giới hạn đã ấn định hay không?.... Sau đó mới thử nghiệm bằng tay để xác định." 

Ngừng lại một giây, tôi nói tiếp: 
"Khả năng exploit các HTTP headers trên một ứng dụng tạo dịch vụ web rất rộng bởi vì có một mớ headers và mỗi header mình có thể thử nhiều thứ khác nhau. Ví dụ như tạo một loạt header fields như nhau, kích thước header fields khác nhau, chèn code vào header field, thử nghiệm các dạng encode khác nhau trên header field.... Nói chung, làm những cái này phải kiên nhẫn và có hệ thống để liệt kê những gì đã thử và chưa thử. Hình thành cả một cái test plan hẳn hòi càng tốt )" 

'cuti' lên tiếng: 
"Trời, nghe thấy cực quá vậy anh? Em không ngờ hack lại mất thời gian và phức tạp như vậy." 

Tôi đáp: 
"Hì hì, nếu lấy sẵn script của ai viết để mà 'hack' thì dễ nhưng tự tìm tòi xuyên qua việc nghiên cứu, thử nghiệm để rồi viết code exploit không dễ tí nào. Những điều mình bàn bây giờ thật ra cũng còn đơn giản đó. Đi đến mức độ exploit một dịch vụ bằng shellcode để chiếm chủ quyền chẳng hạn thì còn phức tạp hơn rất nhiều. Bởi thế, 'hack' không phải là dùng code của người khác để mà chạy rồi xem kết quả mà 'hack' là một quá trình tìm tòi, nghiên cứu, thử nghiệm dai dẳng." 

'docco' xen vào: 
"Em muốn hỏi là mỗi script dùng để exploit thường hướng về một phiên bản nào đó của software mà mình muốn exploit thôi phải không anh? Em hỏi câu này là vì em liên tưởng đến vấn đề footprint mà mình đã 'đà khía' trước đây." 

Tôi đáp: 
"Hay lắm, em liên hệ đến footprint và phiên bản có nghĩa là em đã thấm cái gọi là 'giềng mối' rồi đó ). Đúng vậy. Hầu hết các exploit đều nhắm vào một phiên bản hoặc vài phiên bản gần nhau mà thôi bởi vì phiên bản cách xa thì code đã (hoặc chưa) thay đổi và bị dính những cái lỗi đáng bị exploit kia. Nếu em soi kỹ mấy cái exploit scripts / tools, em sẽ thấy rằng, càng nhiều test được thực hiện trong đó, giá trị và cơ hội thành công của chúng càng cao. Lý do là vì chúng loại bỏ những trường hợp không thích hợp và thoát ra nếu thấy kết quả test không thoả mãn đòi hỏi exploit. Điểm lý thú có thể học từ các scripts / tools đó là cách tư duy và cách kết nối, ứng dụng thông tin tìm được từ RFC, từ tài liệu kỹ thuật cụ thể của software đó vào khung exploit." 

'docco' gật gù: 
"Thật tình em chưa bao giờ hình dung những thứ bé nhỏ như mấy cái directive của Apache, mấy cái HTTP header của HTTP mà có thể dẫn đến những tìm tòi, exploit phức tạp và công phu đến thế." 

Tôi đáp: 
"Ừa, và chính vì vậy mà 'hacking' thật sự mới lý thú. Những thứ dường như bé nhỏ, vụn vặt nhưng chúng đều có vai trò riêng. Bất cứ sụp đổ của mỗi điểm 'vụn vặt' đó đều có thể dẫn đến sự sụp đổ trọn bộ của một cơ chế. Nếu phản chiếu giữa hai phía bảo mật và tấn công, em sẽ thấy rằng: cùng một điểm 'vụn vặt' người chống đỡ, kẻ tấn công khai thác cho mục đích khác nhau. Theo anh, diểm lý thú nằm trên con đường tìm tòi và ứng dụng những điều đã được tìm thấy thay vì dùng ứng dụng để thấy kết quả nếu như em muốn trở thành dân bảo mật." 

Nhìn đồng hồ, thấy đã đến giờ phải đi. Tôi chào bộ ba: 
"Thôi, anh phải đi công chuyện. Mấy đứa có rảnh và thích thì hãy tìm hiểu về những cái 'xem chừng như vụn vặt' kia nha. Có gì mình liên lạc sau." 

27/08/2007 
<còn tiếp> 
Nhãn:

Không có nhận xét nào:

Đăng nhận xét