Kamis, 15 April 2010

Bejtlich on Visible Risk Podcast

My friend Rocky DeStefano from Visible Risk posted the video (streaming) and audio (.mp3, 124 MB) of a discussion he hosted on advanced persisten threat. Myself, Mike Cloppert, Rob Lee, and Shawn Carpenter discussed APT for about an hour on video and about an hour and a half on audio. Let Rocky know what you think as a comment here or via Twitter to @visiblerisk.

One comment -- slightly before the 24:00 mark, Rob made a remark about "what you and I respond to in the Air Force was laughable at this point, compared to what we're seeing today, actual intelligence being pulled back, potential nation state actors, potential organized crime, earning thousands or millions of dollars..." I disagree with part of that comment and agree with part of that comment. For the "disagree" part: Rob was stationed in the 609th, which was not the AFCERT. In the AFCERT we detected and responded to nation state activity of the caliber we see today. I don't know what the 609th dealt with. For the "agree" part: in 1998 it was much rarer to see organized crime operating at the level they do today. I didn't respond during the video because I didn't feel the need to interrupt any time I didn't fully agree with a speaker, and this exchange was mostly between Rob and Mike!

Rabu, 14 April 2010

tcpslice


Tcpslice is a useful tool from LBL network group that allows you to carve up a large pcap file format into time slices. 
To look at the start and finish time stamps of the entire pcap file in various time formats:
tcpslice -r Marchrferrisx.snort.in 
Marchrferrisx.snort.in  Mon Mar  8 11:08:09 2010        Mon Apr  5 09:09:37 2010
tcpslice -t Marchrferrisx.snort.in
Marchrferrisx.snort.in  2010y03m08d11h08m09s660222u     2010y04m05d09h09m37s390876u
tcpslice -R Marchrferrisx.snort.in
Marchrferrisx.snort.in  1268075289.660222       1270483777.390876
To return data from a particular time slice to a file with BPF filters use syntax like this: 
tcpslice 1257347146.060 1257347146.061 inputFile.tcpd | tcpdump -r - -w outputFile.tcpd 'host 192.168.1.175'
(Check out bothunter logs for more examples like this..)
In this example, I want all the packets that are not IPv6 for one date:
/usr/sbin/tcpslice 2010y04m05d Marchrferrisx.snort.in | /usr/sbin/tcpdump -r - 'not(ip6)' | less
reading from file -, link-type EN10MB (Ethernet)
01:06:17.290514 IP 125.141.195.190.35460 > 192.168.0.12.ssh: S 1607742099:1607742099(0) win 65535

01:40:16.181816 IP c-98-247-214-152.hsd1.wa.comcast.net.catchpole > 192.168.0.12.telnet: SWE 498716114:498716114(0) win 5840
01:40:19.172942 IP c-98-247-214-152.hsd1.wa.comcast.net.catchpole > 192.168.0.12.telnet: SWE 498716114:498716114(0) win 5840
01:44:01.423708 IP hn.kd.ny.adsl.x11 > 192.168.0.12.ms-sql-s: S 833421312:833421312(0) win 16384
03:37:06.073237 IP 75.125.252.76.http > 192.168.0.12.48532: S 1175613974:1175613974(0) ack 143375003 win 14420
04:07:03.019711 IP 222.45.112.59.12200 > 192.168.0.12.ssm-els: S 363594672:363594672(0) win 8192 ...
Now I want all ms-sql-s destination packets from the ingress pcap that are not IPv6 for all of March:
/usr/sbin/tcpslice 2010y04m01d 2010y04m31d Marchrferrisx.snort.in | /usr/sbin/tcpdump -r - -n 'dst port(1433)'
reading from file -, link-type EN10MB (Ethernet)
18:33:42.614843 IP 125.46.78.100.x11 > 192.168.0.12.ms-sql-s: S 908984320:908984320(0) win 16384
23:38:50.771853 IP 61.183.172.35.x11 > 192.168.0.12.ms-sql-s: S 47316992:47316992(0) win 16384
03:35:18.351118 IP 121.12.125.7.x11 > 192.168.0.12.ms-sql-s: S 640548864:640548864(0) win 16384
11:09:45.631103 IP 218.61.127.71.x11 > 192.168.0.12.ms-sql-s: S 1613627392:1613627392(0) win 16384
00:47:21.207593 IP 218.90.163.66.x11 > 192.168.0.12.ms-sql-s: S 648937472:648937472(0) win 16384
08:56:05.732622 IP 61.183.172.35.x11 > 192.168.0.12.ms-sql-s: S 47316992:47316992(0) win 16384
18:06:53.798198 IP 59.51.114.39.x11 > 192.168.0.12.ms-sql-s: S 648937472:648937472(0) win 16384 ...
 
Something similar, but a little cleaner, can be done with ipsumdump:


/usr/sbin/tcpslice 2010y04m01d 2010y04m31d Marchrferrisx.snort.in | ipsumdump -tsD | grep -w 1433
 
1270172022.614843 125.46.78.100 1433 
1270190330.771853 61.183.172.35 1433 
1270204518.351118 121.12.125.7 1433 
1270231785.631103 218.61.127.71 1433 
1270280841.207593 218.90.163.66 1433 
1270310165.732622 61.183.172.35 1433 
1270343213.798198 59.51.114.39 1433 ...

Sabtu, 10 April 2010

One year anniversary

Today is the one year anniversary of this blog. This is my 48th post in that time period. According to Google Analytics, 1,250 “absolute unique visitors” have provided for 1,566 visits from 781 unique cities from 78 unique countries. 72 page titles were viewed a total of 2,241 times. Here are some of the most popular pages:

Actually, I have no idea what to make of any of these numbers. 

Selasa, 06 April 2010

Defense Security Service Publishes 2009 Report on "Targeting U.S. Technologies"

Thanks to Team Cymru I learned of a new Defense Security Service report titled Targeting U.S. Technologies:
A Trend Analysis of Reporting from Defense Industry
. The report seems to be the 2009 edition, which covers reporting from 2008. I'll have to watch for a 2010 version. From the report:

The Defense Security Service (DSS) works with defense industry to protect critical technologies and information. Defense contractors with access to classified material are required to identify and report suspicious contacts and potential collection attempts as mandated in the National Industrial Security Program Operating Manual (NISPOM). DSS publishes this annual report based on an analysis of suspicious contact reports (SCRs) that DSS considers indicative of efforts to target defense-related information.

The executive summary offers these bullet points:

  • East Asia and Pacific-originated contacts continued to generate the greatest number of suspicious reports attributable to a specific region of origin. For the fifth year in a row, reporting with an East Asia and Pacific nexus far exceeded those from any other region suggesting a continuing, concerted, and growing effort to exploit contacts within United States industry for competitive, economic, and military advantage.

  • Aggressive collection attempts by commercial actors continued to surge. In FY08, commercial entities attempted to collect defense technology at a rate nearly double that of governmental or individual collector affiliations. This trend likely represents a purposeful attempt to make the contacts seem more innocuous, shifting focus from government collectors to commercial or non-traditional entities.

  • Collectors continued bold and overt exploitation of the Internet to acquire information via direct requests. Facilitated by ever increasing world wide connectivity, the ease of inundating industry with overt email requests and webpage submissions made direct requests a premier vehicle for solicitation and/or collection. While not all direct requests for information or services represent organized collection attempts, exploitation of this medium provides collectors an efficient, low-cost, high-gain opportunity to acquire classified or restricted information.

  • Unmanned aerial vehicle (UAV) technology has emerged as a priority target of aggressive collectors from multiple regions. In FY08, DSS noticed a significant increase in exploitation attempts against UAV systems and technologies at CDCs. Targeting of UAVs is non-region specific, broadly based, and spans all phases of research, development, and deployment. It is highly likely that this interest and probable targeting is the direct result of a growing and increasingly competitive world market for UAV systems.


This report is good background and support for your threat-centric security measures.

BeyondTrust Report on Removing Administrator: Correct?

Last week BeyondTrust published a report titled BeyondTrust 2009 Microsoft Vulnerability Analysis. The report offers several interesting conclusions:

[R]emoving administrator rights will better protect companies against the exploitation of:

  • 90% of critical Windows 7 vulnerabilities reported to date

  • 100% of Microsoft Office vulnerabilities reported in 2009

  • 94% of Internet Explorer and 100% of Internet Explorer 8 vulnerabilities reported in 2009

  • 64% of all Microsoft vulnerabilities reported in 2009


Initially I was pleased to read these results. Then I read BeyondTrust's methodology.

This report uses information found in the individual Security Bulletins to classify vulnerabilities by Severity Rating, Vulnerability Impact, Affected Software, as well as to determine if removing administrator rights will mitigate a vulnerability. A vulnerability is considered mitigated by removing administrator rights if the following sentence is located in the Security Bulletin’s Mitigating Factors section

Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
(emphasis added)

"Could be less impacted?" In other words, BeyondTrust didn't do any testing. They just read Microsoft vulnerability reports, checked for that sentence, and published the results. I would be more comfortable with their conclusions if they conducted exploitation tests against suitable targets to determine if administrator rights made a difference or not.

This doesn't necessarily mean BeyondTrust is wrong. Removing administrator rights does help reduce exposures, but testing is required against modern exploitation methods to determine just how effective that countermeasure is.

Senin, 05 April 2010

More fun with ipsumdump

More fun with ipsumdump. Below, sorting March ingress by COUNT(SIP), COUNT(SPort), Sorted GeoIP location. All very fast.

ipsumdump -s --no-headers  Marchrferrisx.snort.in |
sort -nr | uniq -c | sort -nr | less

    626 75.125.252.73
    384 74.125.19.191
    358 125.45.109.196
    286 66.165.46.165
    242 74.125.127.191
    234 74.125.53.191
    138 67.214.120.156
    138 204.236.155.168
    127 67.228.177.148
    120 74.125.19.19
    107 173.14.243.230
    105 221.195.73.86
    103 221.192.199.35

....

ipsumdump -S --no-headers  Marchrferrisx.snort.in |
sort -nr | uniq -c | sort -nr

   6523 80
   1669 443
   1220 12200
    553 63585
    468 19150
    459 19099
    238 6000
    198 19135
    156 19134
     93 21
     46 110
     34 5242
     30 9875
     21 52079
     21 35356
     20 1935

for i in `ipsumdump -s --no-headers  Marchrferrisx.snort.in |
             sort -nr | uniq |sort -nr`
do 
             echo $i `geoip.sh $i | awk -F: '{print $2$3}'`
done

222.86.62.237 CN, N/A, N/A, N/A, 35.000000, 105.000000, 0, 0
222.59.176.26 CN, 04, Wuxi, N/A, 31.577200, 120.293900, 0, 0
222.59.176.105 CN, 04, Wuxi, N/A, 31.577200, 120.293900, 0, 0
222.45.112.59 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.45.112.221 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.41.8.67 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.37.37.33 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.34.103.72 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.243.14.144 CN, 11, Xupu, N/A, 27.909401, 110.585800, 0, 0
222.219.236.209 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.215.230.49 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.215.230.170 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.214.218.188 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.211.69.13 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.208.183.218 CN, 32, Chengdu, N/A, 30.666700, 104.066597, 0, 0
222.186.25.143 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
222.186.24.37 CN, 22, Beijing, N/A, 39.928902, 116.388298, 0, 0
...

Jumat, 02 April 2010

"One Page Checklist for Securing and Cleaning a Malware Infected Windows PC"


In this process, you are looking for outbound and inbound communication and connection attempts that seem suspicious – data transfers that you can not account for, processes that seem inexplicable, or unsigned files. You may or may not see logon attempts, registry changes, file creation, file access, file permission changes. You may need to correlate Network Monitor logs with network ingress and egress firewall logs. Additional info at: