Công việc của mình chủ yếu là hacking suốt ngày. 

b.3 Scan virus + pattern matching nội dung file sẽ attach để tránh các nội dung xấu

b.4 size limit & time limit cho việc download
 

b3. Scan & pattern matching có thể bị buf overflow hoặc dùng escape string để by pass nên chỉ có tác dụng một phần, không phải là giải pháp chắc chắn 100%

b4. Như jinx9 có nói, nếu yêu cầu gmail down về 1 file mà trúng server config tarpit rule thì sẽ tốn network resource để maintain connection. Hoặc là netcat /dev/random thì biết chừng nào mới down xong -> nếu để time limit thì sẽ hạn chế được long download. Trường hợp target server cố ý chỉ support http 1.0 nên gmail serrver không biết được lúc nào mới hết file.

Trường hợp target server support range (http 1.1) thì hạn chế size down để hạn chế disk usage cho server gmail.

Ý của mrro trong trường hợp 1 là để gmail scan port của chính gmail? hoặc các internal server của google?
 

1. Cho một cái URL dạng live streaming, máy chủ google cứ tải cái file đó hoài và crash vì hết đĩa

2. Cho 1 cái URL để download một cái file có tên là \..\..\..\..\..\boot.ini chẳng hạn, nếu có có dùng AV để quét hoặc gì đó hoặc attachfile lên cho mềnh thì ngon.

3. URL nó hỗ trợ protocol nào thì mình test cái đó, VD mình nhập file:///etc/passwd chẳng hạn, file attach mình nhận đc sẽ là file /etc/passwd của google.

vấn đề giờ là lúc này gmail coi như là 1 client và đang "duyệt web" của attacker(vì attackers đang bắt gmail phải chạy những URL mà mình input vào ), tiếp theo là:

4. Tui cho gmail vô cái link http://gamma-dep-trai.com và sniff lại thử coi gmail đang dùng "cái gì" để __browse__ vô web của tui. Việc thứ 2 là coi "browser" của gmail nó có chạy được mấy cái scripting language ở client như js, vb, flash ... như những browser khác hay ko. Nếu con crawler thông minh quá có thể chạy đc cả js chẳng hạn thì có nhiều chuyện để nói lắm nha

5. Khi tui biết cái ip của con crawler gmail rồi thì vấn đề tiếp theo tui sẽ ráng dùng những patterns có sẵn của để tấn công webserver, web app, etc và bắt crawler của gmail đập vào những ip cùng subnet với nó (nhiều khả năng là những server khác của google).

6. thử test coi gmail có download 1 file nhiều lần hay ko? (có thể để tối ưu hoá thời gian ngồi chờ, nó thấy file nào nó đã down rồi thì ko down nữa). Nghĩa là nếu nó checksum nếu thấy cái file đó trong db rồi thì ko cần down nữa mà lấy file cũ attach lên ... khi đó có thể đoán xem nó checksum file bằng cách nào (md5, sha-1) để làm một file khác bị collision với file cũ và sẽ tồn tại 1 url mà gmal sẽ ko bao giờ thèm download ...
 

2a. làm sao khiến máy chủ GMail tải về một cái file có tên như thế?
 

4a. làm sao để xác định được GMail dùng "cái gì" để tải file về?

4b. làm sao để xác định cái đó có hỗ trợ Javascript hay không? nếu có thì có những chuyện gì để nói?

4c. ngoài ra nếu đã xác định được GMail dùng "cái gì" để tải file về, thì về nguyên tắc chúng ta nên làm gì tiếp theo để có thể tấn công vào máy chủ GMail?
 

b3. cái vụ bo này thì tui chỉ tạm biết là nếu giờ cho load file đủ lớn chứa toàn là AAAA hay gì đó, nếu gmail temporarily out of service sau khi attach -> crash service -> có khả năng stack/mem bị overwrite ở đâu đó -> rồi ROP hay gì đó nữa.

chi tiết hơn tui phải nghiên cứu thêm về RoP và đọc thêm về BO mới rõ được, còn trên chỉ là nguyên lý tui nhớ mang máng

@gamma95: ý 2&3 rất hay -> sẽ phải sanitize user input. Mà thường nguyên lý là không bao giờ tin user input nên việc kiểm tra bad url sẽ được thực hiện đầu tiên -> việc malicious server host valid url sẽ có hiệu quả hơn.

nhân tiện đặt thêm câu hỏi: url valid trong trường hợp này sẽ là gì? nếu kiểm tra valid url (http/https only, no port, no user@pass) thì có thể fix được một số vấn đề đang thảo luận hay không?
 

4a. làm sao để xác định được GMail dùng "cái gì" để tải file về?

4b. làm sao để xác định cái đó có hỗ trợ Javascript hay không? nếu có thì có những chuyện gì để nói?
 

4a. Cho GMail request đến server của mình, ở server mình cho sniff để lấy những thông tin của kết nối đó, sau đó dựa vào những thông tin đó để "đoán" (nhưng chắc là đoán không ra vì nhiều khả năng Gmail sử dụng công cụ riêng của họ)

4b. Để kiểm tra thì chỉ càn cho nó "xem" một đoạn javascript có chức năng gửi một request đến server mình và cho sniff thôi.
có request => đoạn js được thực thi => "cái gì đó" hiểu được js

--->Vấn đề này có thể nảy sinh nhiều vấn đề bảo mật khác, có thể áp dụng khai thác XSS, CRSF ... vào js mà
 

@jin9x

@mrro
b3. việc phát biện bộ quét virus có thể sử dụng 1 cách đơn giản là sử dụng các mẫu đặc biệt mà 1 engine này phát hiện, nhưng engine khác không phát hiện (virustotal?). Không dễ, nhưng tui nghĩ là khả thi. Về phía defense, sử dụng 2 engine hoặc là sử dụng 1 engine, nhưng hiển thị cho user là engine khác cũng có 1 ít tác dụng (ví dụ yahoo nói sử dụng Norton, nhưng sao biết chắc là nó sử dụng Norton?)

regex viết nhanh (chưa đầy đủ) của url /^https?:\/\/[a-zA-Z0-9_\.-]+\/[a-zA-Z0-9_\.-\/~]+/
biểu thức chính quy vẫn có rủi ro đối với bản thân parser & execution engine của regex (lỗi BO?) . Còn một vấn đề nữa là hình như url giờ có utf8 (non-English) nên regex sẽ khá phức tạp nếu muốn user có thể sử dụng được dịch vụ ở mọi nơi.

tui có 1 ý nghĩ là sao ko dùng các technique của AI: machine learning, pattern recognition (neuron network, empirical analysis, ....) để cho điểm và đánh giá nội dung attachment. Ví dụ sau khi phân tích, ta có điểm 4/10 -> hiện ra visual notification cho user là attachment này likely - unlikely harmful để tự bản thân user chọn -> adjust điểm (giống crowd sourcing)
 

b) Làm sao để đảm bảo an toàn cho một tính năng như thế?
 

Request URL:https://mail.google.com/mail/channel/bind?VER=8&at=AF6bupPWZqn_VPaWtTjjINbu01b7AgGRzQ&it=2070&SID=6DEF817EE40C411A&RID=82527&AID=37&zx=xyobxx4yuyse&t=1
Request MethodOST
Status Code:200 OK
Query String Parametersview URL encoded
VER:8
at:AF6bupPWZqn_VPaWtTjjINbu01b7AgGRzQ
it:2070
SID:6DEF817EE40C411A
RID:82527
AID:37
zxyobxx4yuyse
t:1
Request Payload
count=1&ofs=62&req0_type=cf&req0_focused=0&req0__sc=c
Response Headersview source
cache-control:no-cache, no-store, max-age=0, must-revalidate
content-length:11
content-type:text/plain; charset=utf-8
date:Sun, 21 Aug 2011 14:06:37 GMT
expires:Fri, 01 Jan 1990 00:00:00 GMT
pragma:no-cache
server:GSE
status:200 OK
version:HTTP/1.1
x-content-type-options:nosniff
x-xss-protection:1; mode=block 

try{Q(N.Ja(),"lb");function Uad(b,a){return b.aa.xw("SELECT 1 FROM SQLITE_MASTER WHERE TYPE=? AND NAME=?","table",a)!=l}function Vad(b){this.Pa=b;this.ha=!!Gn("GMAIL_BAK")}function A5(b,a){a&&(dd(a,"$a",b.aa,!1,b),a.Ha())}
function Wad(b){if(!kza())return!1;var a=ep();if(!a||!a.hasPermission)return!1;a=0;try{var c=new Sq(sk,dw+"-b","lsb");H(c,"$a",b.aa,!1,b);if(!Uad(c.ia,"Messages"))return A5(b,c),!1;a=c.xw("SELECT count(*) FROM Messages");if(a==0)return A5(b,c),!1}catch(d){return A5(b,c),!1}A5(b,c);try{var e=new Sq(sk,dw,"lsb");H(e,"$a",b.aa,!1,b);if(!Uad(e.ia,"PendingHistory")||!Uad(e.ia,"History"))return A5(b,e),!0;var f=e.xw('SELECT count(*) FROM (SELECT MessageId from History WHERE HandledTime IS NULL AND (Action="ls-svmsg" OR Action="ls-sndmsg") UNION SELECT MessageId FROM PendingHistory WHERE Action="ls-svmsg" OR Action="ls-sndmsg")');
A5(b,e);return a>f}catch(g){}A5(b,e);return!0}function Xad(){};w(Vad,Nb);Vad.prototype.ea=l;
Vad.prototype.ia=function $2Cd(){if(this.ea==!1)return l;this.ea=Wad(this);if(!this.ea)return kxa("GMAIL_BAK"),l;var a;if(this.ha)a=l;else{a={href:"html/en/lsdisplaymsgs.html#dbname="+encodeURIComponent(sk+"-"+dw)};var c=new T;c.append("There seems to have been a failure to sync some of your drafts or sent messages. "+('<a target=_blank href="'+a.href+'">Recover pending messages</a>   <span id="link_backup_hide" idlink tabindex="0" role="link">Hide</span>'));a=new eh(c.toString(),
1,-1)}return a};Vad.prototype.Bk=function $3Cd(a){return a=="backup_hide"?(this.ha=!0,Dn("GMAIL_BAK"),!0):!1};Vad.prototype.aa=function $4Cd(a){Ho.aa(a.ia,a.ha,a.aa,a.ea)};w(Xad,Oe);Qe(Se(N.Ja(),"lb"),Xad);Xad.prototype.ed=function $5Cd(a){Zf(a,"Ta",function(a){return new Vad(a)})};O(N.Ja(),"lb");R(N.Ja(),"lb");}catch(e){_DumpException(e)}
// Copyright 2002-2011 Google Inc.

//@ sourceURL=?ui=2&view=jsm&name=lb&ver=IQRmh2PhfnM.en.&am=!Ck1jWlssh0j7gv37BXTUQ8fRnde3xWGyMOOvSd45T82VmatF-RGsQEjImVrwRSDs