Lỗ hổng bảo mật tồi tệ nhất bạn từng thấy? [đóng cửa]

Lỗ hổng bảo mật tồi tệ nhất bạn từng thấy là gì? Có lẽ là một ý tưởng tốt để giữ chi tiết hạn chế để bảo vệ tội lỗi.

Để biết giá trị của nó là gì, đây là câu hỏi về việc cần làm nếu bạn tìm thấy lỗ hổng bảo mật và một lỗ hổng khác câu hỏi với một số câu trả lời hữu ích nếu một công ty không (dường như) trả lời.

Từ những ngày đầu của các cửa hàng trực tuyến:

Được giảm giá 90% bằng cách nhập .1 vào trường số lượng của giỏ hàng. Phần mềm đã tính toán chính xác tổng chi phí là .1 * chi phí và con người đóng gói đơn đặt hàng chỉ đơn giản là "lẻ". Trước số lượng để đóng gói :)

Lỗ hổng bảo mật ít được tha thứ nhất, và thật không may, một lỗ hổng rất phổ biến và dễ tìm thấy ở đó, đó là Google hack . Trường hợp tại điểm:

http://www.google.com/search?q=inurl%3Aselect+inurl%3A%2520+inurl%3Afrom+inurl%3Awhere

Thật đáng ngạc nhiên khi có bao nhiêu trang trên Internet, đặc biệt là các trang web của chính phủ, chuyển một truy vấn SQL thông qua chuỗi truy vấn. Đây là hình thức tiêm SQL tồi tệ nhất và hoàn toàn không mất công tìm kiếm các trang dễ bị tấn công.

Với các chỉnh sửa nhỏ, tôi đã có thể tìm thấy các bản cài đặt phpMyAdmin không được bảo vệ, các bản cài đặt không được bảo vệ của MySQL, các chuỗi truy vấn có chứa tên người dùng và mật khẩu, v.v.

Kỹ thuật xã hội:

<Cthon98> hey, if you type in your pw, it will show as stars
<Cthon98> ********* see!
<AzureDiamond> hunter2
<AzureDiamond> doesnt look like stars to me
<Cthon98> <AzureDiamond> *******
<Cthon98> thats what I see
<AzureDiamond> oh, really?
<Cthon98> Absolutely
<AzureDiamond> you can go hunter2 my hunter2-ing hunter2
<AzureDiamond> haha, does that look funny to you?
<Cthon98> lol, yes. See, when YOU type hunter2, it shows to us as *******
<AzureDiamond> thats neat, I didnt know IRC did that
<Cthon98> yep, no matter how many times you type hunter2, it will show to us as *******
<AzureDiamond> awesome!
<AzureDiamond> wait, how do you know my pw?
<Cthon98> er, I just copy pasted YOUR ******'s and it appears to YOU as hunter2 cause its your pw
<AzureDiamond> oh, ok.

Từ bash.org

Câu chuyện có thật từ những ngày đầu của tôi tại Microsoft.

Bạn chưa biết sợ hãi cho đến ngày bạn thức dậy và thấy dòng tiêu đề trên ZDNet.com sáng hôm đó là " Lỗ hổng bảo mật Internet Explorer tồi tệ nhất từng được phát hiện trong 'Blah' " trong đó 'Blah' là mã bạn đã tự viết sáu tháng trước .

Ngay lập tức khi đi làm, tôi đã kiểm tra nhật ký thay đổi và phát hiện ra rằng ai đó trong nhóm khác - người mà chúng tôi tin tưởng để thay đổi sản phẩm - đã kiểm tra mã của tôi, thay đổi một loạt các cài đặt khóa đăng ký bảo mật mà không có lý do chính đáng, kiểm tra lại và không bao giờ nhận được mã đánh giá hoặc cho bất kỳ ai biết về nó. Cho đến hôm nay tôi không biết anh ta nghĩ anh ta đang làm gì trên trái đất; Anh rời công ty ngay sau đó. (Theo ý của anh ấy.)

(CẬP NHẬT: Một vài phản hồi cho các vấn đề được nêu trong các ý kiến:

Đầu tiên, lưu ý rằng tôi chọn đảm nhận vị trí từ thiện rằng các thay đổi khóa bảo mật là vô ý và dựa trên sự bất cẩn hoặc không quen thuộc, thay vì ác ý. Tôi không có bằng chứng bằng cách này hay cách khác, và tin rằng thật khôn ngoan khi gán những sai lầm cho sự sai lầm của con người.

Thứ hai, hệ thống checkin của chúng tôi mạnh hơn rất nhiều so với mười hai năm trước. Ví dụ, hiện không thể kiểm tra mã mà không có hệ thống đăng ký gửi email danh sách thay đổi cho các bên quan tâm. Đặc biệt, những thay đổi được thực hiện muộn trong chu kỳ tàu có rất nhiều "quy trình" xung quanh chúng, đảm bảo rằng những thay đổi phù hợp đang được thực hiện để đảm bảo tính ổn định và bảo mật của sản phẩm.)

Dù sao, lỗi là một đối tượng KHÔNG an toàn được sử dụng từ Internet Explorer đã vô tình được phát hành là được đánh dấu là "an toàn cho kịch bản". Đối tượng có khả năng ghi các tệp nhị phân - thực tế là các thư viện kiểu OLE - vào các vị trí đĩa tùy ý. Điều này có nghĩa là kẻ tấn công có thể tạo một thư viện kiểu chứa các chuỗi mã thù địch nhất định, lưu nó vào một đường dẫn là một vị trí thực thi đã biết, cung cấp cho nó phần mở rộng của thứ gì đó sẽ khiến tập lệnh chạy và hy vọng rằng bằng cách nào đó người dùng sẽ sẽ vô tình chạy mã. Tôi không biết về bất kỳ cuộc tấn công "thế giới thực" thành công nào đã sử dụng lỗ hổng này, nhưng có thể tạo ra một khai thác hoạt động với nó.

Chúng tôi đã chuyển một bản vá khá nhanh chóng cho cái đó, để tôi nói với bạn.

Tôi đã gây ra và sau đó đã sửa nhiều lỗ hổng bảo mật hơn trong JScript, nhưng không ai trong số họ từng có bất kỳ nơi nào gần nơi công khai mà người ta đã làm.

Tôi hy vọng bạn có thể phát hiện ra những gì sai ở đây. (Thực sự sai lầm, trên thực tế):

String emailBody = "";

for (int i = 0; i < subscribers.Count; i++)
{
    emailBody += "Hello " + subscribers[i].FirstName + ",";
    emailBody += "this is a reminder with your account information: \n\n:";
    emailBody += "Your username: " + subscribers[i].Username + "\n";
    emailBody += "Your password: " + subscribers[i].Password + "\n";
    emailBody += "Have a great day!";

    emailDispatcher.Send(subscribers[i].EmailAddress, emailBody);
}

Người nhận cuối cùng là hạnh phúc nhất;)

Các thiết bị đầu cuối câm System System 36 cũ của IBM có tổ hợp bàn phím bắt đầu ghi macro. Vì vậy, khi một thiết bị đầu cuối không được đăng nhập, bạn có thể bắt đầu ghi macro và để nó ở vị trí đó. Lần tới khi ai đó đăng nhập, tổ hợp phím sẽ được ghi trong macro và quá trình ghi sẽ tự động kết thúc khi các phím được phép tối đa được ghi. Chỉ cần quay lại sau và phát lại macro để tự động đăng nhập.

Lỗ hổng bảo mật tồi tệ nhất tôi từng thấy thực sự được mã hóa bởi bạn và khiến Google Bot xóa toàn bộ cơ sở dữ liệu của tôi.

Quay lại khi tôi lần đầu tiên học Classic ASP, tôi đã mã hóa ứng dụng blog cơ bản của riêng mình. Thư mục chứa tất cả các tập lệnh quản trị đã được NTLM bảo vệ trên IIS. Một ngày nọ tôi chuyển đến một máy chủ mới và quên bảo vệ lại thư mục trong IIS (rất tiếc).

Trang chủ blog có một liên kết đến màn hình quản trị chính và màn hình quản trị chính có LIÊN KẾT XÓA cho mỗi bản ghi (không có xác nhận).

Một ngày tôi tìm thấy mọi bản ghi trong cơ sở dữ liệu bị xóa (hàng trăm mục cá nhân). Tôi nghĩ rằng một số độc giả đã đột nhập vào trang web và xóa dữ liệu mọi bản ghi.

Tôi đến để tìm hiểu từ nhật ký: Google Bot đã thu thập dữ liệu trang web, theo liên kết quản trị viên và tiến hành theo tất cả các LIÊN KẾT XÓA, do đó xóa mọi bản ghi trong cơ sở dữ liệu. Tôi cảm thấy mình xứng đáng với giải thưởng Dumbass of the Year khi vô tình bị Google Bot xâm phạm.

Rất may tôi đã sao lưu.

Lỗ hổng tồi tệ nhất tôi từng thấy là một lỗi trong ứng dụng web, nơi cung cấp tên người dùng và mật khẩu trống sẽ đăng nhập bạn với tư cách quản trị viên :)

Một khi nhận thấy điều này trên URL của một trang web.

http://www.somewebsite.com/mypage.asp?param1=x&param2=y&admin=0

Thay đổi tham số cuối cùng thành admin = 1 đã cho tôi quyền quản trị. Nếu bạn sẽ tin tưởng một cách mù quáng vào đầu vào của người dùng thì ít nhất đừng điện báo rằng bạn đang làm điều đó!

Tôi đã thấy cái này trong WTF hàng ngày .

<script language="javascript">
<!--//
/*This Script allows people to enter by using a form that asks for a
UserID and Password*/
function pasuser(form) {
    if (form.id.value=="buyers") { 
        if (form.pass.value=="gov1996") {              
            location="http://officers.federalsuppliers.com/agents.html" 
        } else {
            alert("Invalid Password")
        }
    } else {  
        alert("Invalid UserID")
    }
}
//-->
</script>

Không có gì có thể đánh bại IMHO này.

Tại một trường đại học không kém, sẽ vẫn không tên, họ có tất cả các truy vấn hành động của họ được chuyển qua URL thay vì mẫu được đăng.

Điều này đã làm việc một điều trị cho đến khi Google Bot xuất hiện và chạy qua tất cả các URL của họ và xóa sạch cơ sở dữ liệu của họ.

Ngạc nhiên không có ai đưa lên kỹ thuật xã hội, nhưng tôi đã nhận ra một bài báo .

Tóm tắt: người dùng độc hại có thể mua vài chục ổ đĩa flash, tải chúng bằng virus hoặc trojan tự động, sau đó rắc các ổ đĩa flash trong bãi đậu xe của công ty vào đêm khuya. Ngày hôm sau, mọi người xuất hiện để làm việc, vấp ngã trên phần cứng sáng bóng, hình kẹo, không thể cưỡng lại và tự nói với mình "oh wow, ổ đĩa flash miễn phí, tôi tự hỏi những gì trên đó!" - 20 phút sau, toàn bộ mạng của công ty bị hos.

"Pedo mellon a minno" , "Nói bạn và vào", trên cổng Moria.

Microsoft Bob
(Tín dụng: Phần mềm từ bỏ thế kỷ 20 của Dan )

Nếu bạn nhập mật khẩu không chính xác lần thứ ba, bạn sẽ được hỏi nếu bạn quên mật khẩu.

http://img132.yfrog.com/img132/8397/msbob10asignin15.gif

Nhưng thay vì có bảo mật, như tiếp tục nhắc nhập mật khẩu chính xác cho đến khi nó nhập hoặc khóa bạn sau một số lần thử không chính xác, bạn có thể nhập bất kỳ mật khẩu mới nào và nó sẽ thay thế mật khẩu ban đầu! Bất cứ ai cũng có thể làm điều này với bất kỳ mật khẩu "được bảo vệ" tài khoản Microsoft Bob.

Không có xác thực trước cần thiết. có nghĩa là User1 có thể thay đổi mật khẩu của riêng họ chỉ bằng cách nhập sai mật khẩu ba lần rồi nhập mật khẩu mới lần thứ tư - không bao giờ phải sử dụng "thay đổi mật khẩu".

Điều đó cũng có nghĩa là User1 có thể thay đổi mật khẩu của User2, User3 ... theo cùng một cách. Bất kỳ người dùng nào cũng có thể thay đổi bất kỳ mật khẩu người dùng nào khác chỉ bằng cách nhập sai ba lần rồi nhập mật khẩu mới khi được nhắc - và sau đó họ có thể truy cập vào tài khoản.

http://img132.yfrog.com/img132/9851/msbob10asignin16.gif

Tôi đã có địa chỉ nhà cũ của Joe X, và cần biết địa chỉ hiện tại mới hơn của anh ta trong cùng thành phố, nhưng không có cách nào để liên lạc với anh ta. Tôi hình dung anh ta đang nhận được đống danh mục đặt hàng qua thư hàng ngày thông thường, vì vậy tôi tự ý gọi số 800 cho Kẹo của See (trái ngược với Victoria's Secret, hoặc Thuộc địa Thụy Sĩ, hoặc bất kỳ người gửi thư lớn nào khác):

Tôi: "Xin chào, tôi là Joe X. Tôi nghĩ rằng bạn đã đưa tôi vào danh sách gửi thư của bạn hai lần, ở cả địa chỉ cũ và địa chỉ mới của tôi. Máy tính của bạn hiển thị cho tôi tại [địa chỉ cũ] hoặc tại [địa chỉ giả] ? "

Nhà điều hành: "Không, chúng tôi chỉ cho bạn tại [địa chỉ mới]."

Cho 1 = 1 vào hộp văn bản liệt kê tất cả người dùng trong hệ thống.

Là một nhà tư vấn bảo mật ứng dụng để kiếm sống, có rất nhiều vấn đề phổ biến cho phép bạn có được quản trị viên trên một trang web thông qua một cái gì đó. Nhưng phần thực sự thú vị là khi bạn có thể mua tất trị giá một triệu đô la.

Đó là một người bạn của tôi làm việc trong buổi biểu diễn này, nhưng điều quan trọng là giá của các mặt hàng trong một cuốn sách trực tuyến rất phổ biến hiện nay (và mọi thứ khác) đã được lưu trữ trong chính HTML dưới dạng một trường ẩn. Quay trở lại những ngày đầu lỗi này rất nhiều cửa hàng trực tuyến, họ mới bắt đầu tìm hiểu web. Nhận thức bảo mật rất ít, ý tôi thực sự là ai sẽ tải xuống HTML, chỉnh sửa trường ẩn và gửi lại đơn đặt hàng?

Đương nhiên, chúng tôi thay đổi giá thành 0 và đặt mua 1 triệu đôi vớ. Bạn cũng có thể thay đổi giá thành âm nhưng thực hiện điều này đã khiến một phần bộ đệm phần mềm thanh toán phụ trợ của họ bị tràn kết thúc giao dịch.

Nếu tôi có thể chọn cái khác thì đó sẽ là vấn đề chuẩn hóa đường dẫn trong các ứng dụng web. Thật tuyệt vời khi có thể làm foo.com?file=../../../../etc/passwd

Cam kết mật khẩu gốc cơ sở dữ liệu để kiểm soát nguồn một cách tình cờ. Nó khá tệ, bởi vì nó là kiểm soát nguồn trên Sourceforge.

Không cần phải nói mật khẩu đã thay đổi rất nhanh.

Không thay đổi mật khẩu quản trị viên khi nhân viên IT chủ chốt rời khỏi công ty.

Mặc dù đây không phải là lỗ hổng bảo mật tồi tệ nhất tôi từng thấy. Nhưng đây ít nhất là điều tồi tệ nhất mà tôi tự khám phá:

Một cửa hàng trực tuyến khá thành công dành cho audiobook đã sử dụng cookie để lưu trữ thông tin nhận dạng của người dùng hiện tại sau khi xác thực thành công. Nhưng bạn có thể dễ dàng thay đổi ID người dùng trong cookie và truy cập các tài khoản khác và mua chúng.

Ngay khi bắt đầu kỷ nguyên .com, tôi đã làm việc cho một nhà bán lẻ lớn ở nước ngoài. Chúng tôi đã theo dõi rất quan tâm khi các đối thủ của chúng tôi đã khai trương một cửa hàng trực tuyến trước chúng tôi. Tất nhiên, chúng tôi đã đi thử ... và nhanh chóng nhận ra rằng giỏ hàng của chúng tôi đang bị xáo trộn. Sau khi chơi với chuỗi truy vấn một chút, chúng tôi nhận ra rằng chúng tôi có thể chiếm quyền điều khiển các phiên của nhau. Với thời gian tốt, bạn có thể thay đổi địa chỉ giao hàng nhưng chỉ để lại phương thức thanh toán ... tất cả chỉ sau khi đã lấp đầy giỏ hàng với các mặt hàng yêu thích của bạn.

Khi tôi mới gia nhập công ty mà tôi hiện đang làm việc, sếp của tôi đã xem qua trang web thương mại điện tử hiện tại của một khách hàng mới tiềm năng. Điều này là trong những ngày đầu tiên của cả IIS và thương mại điện tử, và bảo mật, theo chúng tôi, sẽ ít hơn nghiêm ngặt.

Để cắt ngắn một câu chuyện dài, anh ta đã thay đổi một URL (vì tò mò) và nhận ra rằng việc duyệt thư mục không bị tắt, vì vậy bạn chỉ cần cắt tên trang ở cuối URL và xem tất cả các tệp trên máy chủ web.

Chúng tôi đã kết thúc việc duyệt một thư mục chứa cơ sở dữ liệu Access mà chúng tôi đã tải xuống. Đó là toàn bộ cơ sở dữ liệu khách hàng / đơn hàng thương mại điện tử, được hoàn thiện với hàng ngàn số thẻ tín dụng không được mã hóa.

Mọi người đăng mật khẩu của họ trên các trang web công cộng ...

Khi tôi 13 tuổi, trường tôi mở một mạng xã hội cho học sinh. Thật không may cho họ, tôi đã tìm thấy một lỗi bảo mật nơi bạn có thể thay đổi URI thành một ID người dùng khác như "? UserID = 123" và đăng nhập cho người dùng đó. Rõ ràng tôi đã nói với bạn bè của tôi, và cuối cùng, mạng xã hội của trường học tràn ngập khiêu dâm.

Sẽ không đề nghị nó mặc dù.

Tôi nghĩ rằng trường tên người dùng / mật khẩu trống để truy cập siêu người dùng là điều tồi tệ nhất. Nhưng một trong những tôi đã thấy bản thân mình là

if (password.equals(requestpassword) || username.equals(requestusername))
{
    login = true;
}

Quá tệ một nhà điều hành làm cho một sự khác biệt lớn như vậy.

Của tôi sẽ là cho một ngân hàng mà tôi là một khách hàng. Tôi không thể đăng nhập, vì vậy tôi đã gọi cho dịch vụ khách hàng. Họ hỏi tôi tên người dùng và không có gì khác - không hỏi bất kỳ câu hỏi bảo mật nào hoặc cố gắng xác minh danh tính của tôi. Sau đó, thay vì gửi lại mật khẩu cho địa chỉ email họ có trong hồ sơ, họ hỏi tôi địa chỉ email nào để gửi. Tôi đã cung cấp cho họ một địa chỉ khác với những gì tôi có trong hồ sơ và có thể đặt lại mật khẩu của mình.

Vì vậy, về cơ bản, tất cả tin tặc cần là tên người dùng của tôi và sau đó anh ta có thể truy cập vào tài khoản của tôi. Điều này là cho một ngân hàng lớn mà ít nhất 90% người dân ở Hoa Kỳ đã nghe nói đến. Điều này đã xảy ra khoảng hai năm trước. Tôi không biết đó là một đại diện dịch vụ khách hàng được đào tạo kém hay đó là quy trình chuẩn.

Tôi sẽ chia sẻ một cái tôi đã tạo. Loại.

Nhiều năm và nhiều năm trước, công ty tôi đang làm việc muốn lập chỉ mục trên trang web ASP của họ. Vì vậy, tôi đã đi và thiết lập Máy chủ Index, loại trừ một vài thư mục quản trị và tất cả đều tốt.

Tuy nhiên tôi không biết ai đó đã cho một nhân viên bán hàng truy cập ftp vào máy chủ web để anh ta có thể làm việc tại nhà, đây là ngày quay số và đó là cách dễ nhất để anh ta trao đổi các tệp .... và anh ta bắt đầu tải lên mọi thứ, bao gồm các tài liệu chi tiết đánh dấu trên các dịch vụ của chúng tôi .... máy chủ chỉ mục nào được lập chỉ mục và bắt đầu phục vụ khi mọi người tìm kiếm "Chi phí".

Nhớ trẻ em, danh sách trắng không danh sách đen.

Một trong những cách đơn giản nhất nhưng thực sự đáng giá là:

Các hệ thống thanh toán sử dụng các công cụ như PayPal có thể bị lỗi do phản hồi từ PayPal sau khi thanh toán thành công không được kiểm tra như mong muốn.

Ví dụ:

Tôi có thể truy cập một số trang web mua CD và thêm một số nội dung vào giỏ hàng, sau đó trong giai đoạn thanh toán thường có một biểu mẫu trên trang được điền các trường cho paypal và nút gửi đến "Thanh toán" ..

Sử dụng Trình soạn thảo DOM, tôi có thể chuyển sang dạng "trực tiếp" và thay đổi giá trị từ £899.00thành£0.01 và sau đó nhấp vào gửi ...

Khi tôi đứng về phía PayPal, tôi có thể thấy rằng số tiền là 1 xu, vì vậy tôi trả số tiền đó và PayPal chuyển hướng một số tham số đến trang web mua ban đầu, người chỉ xác nhận các tham số như payment_status=1 , v.v., v.v. xác thực số tiền đã trả.

Điều này có thể tốn kém nếu họ không đăng nhập đủ hoặc sản phẩm được tự động gửi đi.

Loại trang web tồi tệ nhất là các trang web cung cấp ứng dụng, phần mềm, âm nhạc, v.v.

Còn về trình quản lý tài liệu trực tuyến, cho phép đặt mọi quyền bảo mật mà bạn có thể nhớ ...

Đó là cho đến khi bạn vào trang tải xuống ... download.aspx? DocumentId = 12345

Có, documentId là ID cơ sở dữ liệu (tự động tăng) và bạn có thể lặp từng số một và bất kỳ ai cũng có thể nhận được tất cả các tài liệu của công ty.

Khi được cảnh báo về vấn đề này, phản hồi của người quản lý dự án là: Ok, cảm ơn. Nhưng không ai nhận thấy điều này trước đây, vì vậy hãy giữ nó như hiện tại.

Một giao bánh pizza Na Uy có một lỗ hổng bảo mật, nơi bạn có thể đặt hàng số lượng pizza âm tính tại cổng internet mới và sáng bóng của họ và nhận chúng miễn phí.