2013年10月28日，我聯(lián)系了Linkedin的安然團隊，并會在近期發(fā)布修復補丁來解決下面的標題問題。這個修復法度合用于隨機生成ID的styling法則，同下面介紹的基于class的styling有所辨別。
我其實不是CSS專家，所以或許有其他技能可以繞過這個限制和刪除內(nèi)容(乃至只是隱躲或籠蓋它)————假定你知道，請email通知我!我將繼續(xù)與Linkedin的安然團隊合作來修復任何我們能找到的BUG。而用戶需要寄望的是世上沒有完美的解決方案，即便在郵件中你所看到的這些數(shù)據(jù)也不克不及明白證實發(fā)送人的合法性。
我還要感激Linkedin的安然團隊，他們快速且有效地措置了這些標題問題。
有關“Intro”
10月23日，Linkedin推出一個名為"Intro"的利用法度。法度的運行前提很簡單：承諾iPhone用戶看到本機Mail App里發(fā)件人的具體信息。這跟iPhone Mail App的Rapportive差不多，這兩個app在本質(zhì)上一樣(且由不異的人所開辟)。
但是，在看Intro最初的介紹中，有一個處所引發(fā)了我的寄望:
“David說Crosswise很想和你合作。這是垃圾郵件，仍是真實郵件?
經(jīng)由過程Intro，您可以當即看到David長甚么模樣，他在哪兒，他是干甚么的。你可以看到，他是Crosswise的首席履行官。這是真實的生意?！?/P>
這就像Linkedin說“我們放了一個鎖住的照片在你的email里，所以你知道它必定是安然的”這類環(huán)境一樣。Linkedin簡單地給用戶一種子虛的安然感。在這篇文章中，我們將一路來看一看Linkedin在用戶的郵件中事實是如何做的，和我們?nèi)艉文笤爝@一信息，完全節(jié)制Intro所揭示給用戶的信息。
Linkedin會對你的Email做些甚么
為了更好地不雅察Intro的行動，今朝我正對其進行更深進的闡發(fā)研究，并很快就會發(fā)布。而此刻我們只是看看Intro工作的根本常識，看看它具體是若何對用戶email進行把持的。
Intro起首獲得一個OAuth拜候令牌來治理你的電子郵件。因為Google利用的OAuth和談?chuàng)纬諫mail的IMAP和SMTP，所以它們無需驗證你的郵箱暗碼便可獲得授權。然后Linkedin便可以拜候你的email并在你的iPhone上安裝一個安然建設文件，該安然建設文件的最較著特點就是，它會安裝一個新的email賬戶指向Linkedin的IMAP和SMTP辦事器。我不知道若何從iPhone本身恢復email賬戶暗碼，但經(jīng)由過程代辦署理反對發(fā)送到iPhone的建設文件，我們可以看到這個email賬戶看起來像如許：
經(jīng)由過程反對該建設文件，我們可以獲得用于登錄到Linkedin的IMAP(imap.intro.Linkedin.com)和SMTP(smtp.intro.Linkedin.com)辦事的用戶名和暗碼。用戶名是base64編碼的字符串，暗碼是一個32個字符的hash。
這里有一個圖揭示這是若何工作的:
此刻，我們已有了這郵件賬戶利用的用戶名和暗碼，讓我們抓取第一個電子郵件，看看Linkedin的IMAP代辦署理注進了甚么內(nèi)容。我們可利用OpenSSL來做到這一點哦。
# openssl s_client -connect imap.intro.Linkedin.com:143 -starttls imap -crlf -quiet
depth=2 C = US， O = "thawte， Inc."， OU = Certification Services Division， OU = "(c) 2006 thawte， Inc. - For authorized use only"， CN = thawte Primary Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
. OK More capabilities after LOGIN
a LOGIN username_redacted password_redacted
* CAPABILITY IMAP4rev1 IDLE NAMESPACE ID CHILDREN UIDPLUS COMPRESS=DEFLATE
A OK [email protected] Test Account authenticated (Success)
b SELECT INBOX
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)] Flags permitted.
* OK [UIDVALIDITY 1] UIDs valid.
* 4 EXISTS
* 0 RECENT
* OK [UIDNEXT 5] Predicted next UID.
* OK [HIGHESTMODSEQ 1049]
b OK [READ-WRITE] INBOX selected. (Success)
c FETCH 4 BODY[]
* 4 FETCH (FLAGS (\Seen) BODY[] {36510}
email_content_here
事實證實，Linkedin注進了相當多的內(nèi)容到你的電子郵件中往。根基的布局看起來像如許：
User specified CSS (if any)
Injected Linkedin Intro HTML Content
Original Message
你可以在這里找到完全的電子郵件(一些鏈接和一些未被刪掉落的東西)。此刻我們知道Linkedin對該email做了些甚么了吧，讓我們再看看若何利用它來讓我們的垂釣郵件看起來是合法的。
設置釣餌
就像設置一個棍騙性的網(wǎng)站一樣，我們可以簡單地復制Linkedin所供給的現(xiàn)有CSS和HTML布局，并按照我們的需要來利用它。起首我們想要做的是找到除往Intro現(xiàn)稀有據(jù)的編制。我們可以把現(xiàn)有Intro塊的CSS設置為display:none;。很不幸的是， Linkedin明顯也想到了這一點，因為CSS凡是是插進到head標簽后面，他們相當細心地為display，height等設置了!important關頭詞，以進步指定樣式法則的利用優(yōu)先權。
但仍然不敷詳實，假定我們看CSS，可以發(fā)現(xiàn)到其法則合用于#rapportive.iphone元素。假定我們細心不雅察，就會發(fā)現(xiàn)，其實我們想要隱躲的HTML有一個完全的規(guī)范#rapportive.rapportive.topbar.iphone。是以，我們可以簡單地設置以下樣式的隱躲:
就是這么簡單。
此刻，我們已刪除現(xiàn)有的Intro數(shù)據(jù)，我們可以自由注進我們本身的數(shù)據(jù)了。要做到這一點，我們可以復制Linkedin供給的現(xiàn)有HTML。若要確保我們的數(shù)據(jù)不會被我們之前的CSS隱躲，我們可以簡單地從root中刪除topbar類，因為它不會影響樣式。最后我們想要做的是斷根Linkedin在本來信息上設置的邊距，和把實際數(shù)據(jù)本身改成任何我們想要的數(shù)據(jù)。別的，我復制了一些CSS和HTML，點竄了主動生成的Id。這將確保我們的模板始終一致。
“垂釣”往啦
為達講授目標，我已成立了一個根基的PoC模板。若要利用它，你只需拜候你要棍騙的那小我的Linkedin建設文件，填寫所需的CSS信息。抱負環(huán)境下，將來可改進成主動擦除此信息并查抄確保Intro數(shù)據(jù)只在移動設備上顯示等。此刻，它是根基可用的，讓我們看看假定我對Linkedin本來顯示的信息實施棍騙會是如何。(諒解一下，這不是IOS7————我沒有見過IOS7系統(tǒng)會有這么多標題問題):
這就是當我打開Intro選項時所看到的具體信息(它們是可以自定義的，我讓它們揭示了一下我確切節(jié)制了其內(nèi)容)：
明顯，這是一個不具歹意的例子。當然，要添加歹意文件、要求敏感信息，也一樣很簡單。
最后的設法
當然Linkedin Intro概況上看起來很有效————只是利用它的話，風險太高了。作為一個社會工程師，我?？次业姆结樖抢肐ntro。Linkedin Intro的利用，為用戶營建了一種子虛的安然感，這使得我和廣大年夜社工人員的工作便捷良多。