Messages posted by: mfeng

Bạn tìm hiểu thêm về federation identity & một số triển khai & chuẩn như SAML, OpenID, OAuth, WIF. Ngoài ra có thể tự thiết kế thử nghiệm 1 protocol đơn giản dùng cookies có hoạt động tương tự được.

Bạn cần phải biết các khái niệm, kiến thức & kỹ thuật unpacking. Nên tìm kiếm trong box này trước khi hỏi, vd xem ở đây: /hvaonline/posts/list/23682.html

Encode bằng Base64.

WISeKey SA
http://www.wisekey.com

WISeKey is a leading information security and identity management company, and provides specialized security technologies for data protection, and effective identification and authentication of people and objects, over physical infrastructures, networks and the internet to ensure secure communications and e-transactions, without compromising trust.

Position

Senior Developer (ref code WK-SD01)

Job description

Reports to Project Manager.
Provide knowledge and development expertise in the given application domain
Assists to the Project Manager to create application architecture code mapping solution
Implements application modules
Conducts developers on group: controls and coordinates development activities of the group
Maintains up-to-date project development documentation
Is responsible for maximizing development results reusability: informs project Team Leader about useful solutions implemented by the team
Participates in knowledge sharing meetings
Implements designed by Development team shared libraries and development techniques
Provides quality assurance measures such as regular code revisions within the development team to assure that all project team developers know and follow coding standards.
Informs Project Manager about discovered issues and helps to address them.

Job Requirement

Candidate must possess at least Bachelor's/College Degree in Computer Science/Computer Engineering or equivalent.
At least 3 year(s) of working experience in the related field is required for this position.
Requires an understanding of software development processes and software quality assurance procedures in a Microsoft development environment and 3+ years of related work experience.
Knowledge of software products utilizing various Microsoft Windows operating systems is strongly preferred.
Experience with .Net, Desktop/Web applications, databases is required.
Experience with test automation tools is a plus. Knowing PKI/Cryptography is a plus.
Candidate must have good communication/writing skills in English.

General Information

Job Type: Full-Time Permanent
Location: Ha Noi
Salary: 600 - 1000 USD per month

Contact

Preferred language for received applications:English.
The application should be sent to kblackma@wisekey.com before Feb 28th, 2010.

Theo mình biết thì khi trình duyệt kết nối với một https webserver, mặc định các trình duyệt hiện nay (xem http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol#Browser_Support) đều kiểm tra tình trạng của certificate đó xem đã bị revoked hay chưa thông qua 2 con đường:
- OCSP: Nếu trong certificate có chỉ định giá trị CRL Distribution Points trong X509 Ext, trình duyệt sẽ sử dụng tham chiếu này để kiểm tra tự động; có thể thay đổi cấu hình này.
- CRL: được cập nhật bằng tay.

Nếu cert đã bị revoked mà web browser không thực hiện kiểm tra khi kết nối, coi như cert đó vẫn hợp lệ.

Nghe nói d/c pr0f đang làm việc ngon lắm mà, không biết có ý định sang CK cho đổi gió không smilie

Tớ nộp trưc tiếp ở HN á smilie

. Kể ra không xin được số ĐT cũng là sơ xuất (cần rút kinh nghiệm!), vì 2 vòng trước, cứ đều đặn sau 1 tuần thì có thông báo cả bằng mail & phone, đến vòng thứ 3, sau khi kết thúc được hứa miệng rằng sẽ có thông báo kết quả sớm, nhưng mà đợi không thấy smilie

)

Tớ pvan đợt đầu tháng 7.

quanta wrote:

mfeng wrote:

Đợt trc tớ đi pvan IBM về 1 vị trí tương tự như thế này, qua 1 vòng test + 2 vòng interview thì thấy mất tăm, không có notification gì thêm cả

Thế xong bạn có gọi điện (hoặc mail) lại hỏi bọn nó không?

Có chứ

. Mail không nhận được reply. Điện thoại không gọi được vì không biết số smilie

(do IBM gọi đến handphone bằng cách gì đó giấu được số).

Đợt trc tớ đi pvan IBM về 1 vị trí tương tự như thế này, qua 1 vòng test + 2 vòng interview thì thấy mất tăm, không có notification gì thêm cả smilie

Một số phân tích kĩ thuật thêm về bug này:
Lỗi này nằm tại file js3250.dll. Đoạn mã khai thác lỗi cho phép điều khiển giá trị eax và ecx tại đoạn lệnh sau

Code:

0038695C 83E1 F8 AND ECX,FFFFFFF8
0038695F 8B11 MOV EDX,DWORD PTR DS:[ECX]
00386961 8B02 MOV EAX,DWORD PTR DS:[EDX] ; <-- EAX bị sửa đổi ở đây
00386963 83C3 FC ADD EBX,-4
00386966 53 PUSH EBX
00386967 6A 00 PUSH 0
00386969 51 PUSH ECX
0038696A 8B48 20 MOV ECX,DWORD PTR DS:[EAX+20] ; <-- Dùng kỹ thuật heap spray để chèn đoạn padding & shellcode vào vùng bộ nhớ eax + 20.
0038696D 57 PUSH EDI
0038696E FFD1 CALL ECX ; <-- Shellcode được gọi từ đây

Theo http://www.us-cert.gov/current/index.html#mozilla_firefox_3_5_vulnerability, Javascript engine của FF 3.5 hiện có thể bị khai thác thực thi mã độc khi người sử dụng mở trang web có nhúng mã khai thác. Đoạn mã khai thác đã được phát tán rộng rãi trên internet.

Giải pháp hiện tại: Tắt tính năng Javascript hoặc làm theo hướng dẫn của US-CERT tại http://www.us-cert.gov/reading_room/securing_browser/#Mozilla_Firefox.

Bổ sung: Có hai biện pháp giải quyết tạm thời
- Dùng addons NoScript của Firefox hoặc
- Tắt chức năng JIT của Javascript: trong about:config, đặt [color="red"]javascript.options.jit.content= false[/color]

Sẽ có FF 3.5.1 trong tháng này nhằm vá lỗi của javascript và http://blog.internetnews.com/skerner/2009/07/firefox-35-at-risk-from-0day-j.html của FF 3.5.
---
Sửa đổi bổ sung phần giải pháp tạm thời

- Nmap có chạy được trên windows.
- Nmap quét conficker dựa vào các cổng: 135, 139, 445.

Quái nhỉ, sao RE cứ gắn với đầu lâu xương chéo là sao?

Bạn tham khảo về cách thức kiện toàn TCP/IP Stack để hạn chế SYN attack:
http://www.securityfocus.com/infocus/1729

Do kết quả lệnh netstat không cho thấy các kết nối đang ở SYN_RECV nên chưa có kết luận được gì về nguồn tấn công.

Windows size liên quan tới khái niệm Congestion Control và Flow Control. Thông thường nếu mỗi một segment gửi đi xong mà sender mà chờ ACK từ receiver rồi mới gửi segment tiếp theo, thì throughput sẽ quá thấp so với bandwidth. Vì vậy mới cần giải pháp pipeline, mà Window size có thể coi là số lượng segment gửi đi liên tục theo pipeline trước khi nhận được ACK.

TIME_WAIT là trạng thái cuối cùng của một kết nối tcp trước khi đóng kết nối chủ động (chủ động gửi FIN). Hiện tượng nhiều TIME_WAIT thực ra không phải lỗi của OS hay TCP/IP stack mà nguyên nhân thường bắt nguồn từ tốc độ mở socket mới quá nhanh so với tốc độ giải phóng socket: mỗi socket sẽ đợi ở tình trạng TIME_WAIT 1 khoảng thời gian là 2 *MSL (thông thường là 120s, trên CentOS là 60s).

Để khắc phục vấn đề này có các hướng sau:
- Điều chỉnh tcp/ip stack nhằm giảm thời gian time_out để đóng socket time_wait và tái sử dụng socket: như quanta và secmask đang làm.

- Xem xét ở tầng app xem tại sao client sinh ra nhiều socket tới server tới vậy (thường là do lỗi lập trình). Ở đây là kết nối http, thử xem xét vấn đề về keep-alive để tiết kiệm số sockets xem sao.

- Search google: có một số giải pháp ở tầng TCP hoặc HTTP cho phép chủ động đóng bớt TIME_WAIT (Client chủ động gửi RST; thêm method CLOSE ở giao thức HTTP), nhưng có vẻ là khó triển khai với trường hợp này.

Các tiêu chí của một giao thức xác thực cần có sẽ là:
1. Chống sniffer
2. Chống replay
3. Có trao đổi session key.
4. Mutual auth
5. Chống được dictionary-attack dựa trên sniff messages
6. Đảm bảo forward secrecy.
7. Chống được tình huống compromised verifier database (chứa các thông tin bên server để auth).

Theo các tiêu chuẩn trên, tất cả các protocol đang bàn luận này đều không thỏa mãn, nhất là 3 điều kiện cuối cùng, được gọi là "Big-3" của auth. Điều kiện thứ 7 chính là vấn đề mrro nói làm sao để cài đặt giao thức không dùng plaintext-equivalent password.

Ít ra hiện giờ có một giao thức thỏa mãn 7 điều kiện trên, được viết thành RFC 2945. Các bạn thử tìm hiểu và phân tích xem smilie

.

Sau khi kết nối vào wifi (dùng đúng key), thử "lắng nghe" trên mạng đó coi nghe được thông tin bổ ích gì không? smilie

Ờ, lâu không coi lại, giờ xem protocol 5 thế nào nhé smilie

Code:

Protocol 5:
1. Alice tạo cặp khóa Public Key (PR,PU) . Alice gửi M1=E(pw, PU) tới Bob.
2. Bob giải mã M1. Tạo M2= E(PU,sk||nonce) gửi lại Alice
3. Alice gửi E(sk,nonce) cho Bob.

Mục tiêu của giao thức authentication này diễn ra giữa user và server. Ở đây Alice là user, Bob là server có phải không ?.

Vì có trước giả thiết là:
- Hai đầu cuối (usr & server) là tin cậy, không có khả năng bị compromised.
- Đường truyền bị theo dõi & có khả năng bị replay.
Nêu mọi thảo luận sẽ nằm ở an toàn của thông tin trao đổi trên đường truyền chứ không phải thông tin cần lưu trữ, mặc dù điều này khá quan trọng khi cài đặt một giao thức xác thực.

Câu hỏi:

- Step2: Làm sao Bob giải mã được M1 khi không biết thông điệp M1 được gửi từ Alice1 hay Alice2 ?

- Giao thức trên sinh Pub/Priv key, rồi dùng pre-shared password để gửi Pubkey, sau đó dùng lại PubKey để trao đổi session key. Cách làm trên ưu điểm hơn gì so với dùng luôn password để trao đổi session key?. Và vấn đề gì sẽ xảy ra khi mỗi lần gửi đi các PubKey đều dùng lại một key để mã hóa ?

Nhìn chung protocol 5 có vẻ giống một key exchange protocol hơn là một authentication protocol.

Starghost wrote:

Protocol này hay ở chỗ entropy của các messages không phụ thuộc vào password. Thế nên không quan trọng password dài ngắn ra sao, việc bruteforce password là không thể.

Protocol này có sử dụng password làm key để mã hóa PubKey, thức là có phụ thuộc vào password chứ nhỉ smilie

. Nếu xét về khả năng bruteforce M1 thì tại sao lại không có ?

Trước hết:
- Đọc TCP/IP: hiểu rõ TCP, IP là cái gì, protocol là cái gì.
- Học lập trình hệ thống mức cơ bản: read/write files, multi-threading...
- Học lập trình socket: tạo server socket như thế nào, client socket như thế nào, cách gửi thông điệp giữa hai máy tính thông qua socket...
- Đọc giao thức FTP và triển khai: ban đầu là http://www.w3.org/Protocols/rfc959/. Theo mức độ yêu cầu của đề tài, bạn chỉ cần cài đặt một phần tối thiểu giao thức này là được.