RE: [AKO Content Warning - Attachments] An interesting packet inspection problem

[Stephen Villano <stephen.villano () us army mil>]

Interestingly, the file was blocked from being received here as well by the
military. "Attachment dropped due to NETCOM 2004-11 restrictions."
I rather suspect that some malware was going over the net with that
extension or possibly filename.
OR the file is matching a viral signature...

> -----Original Message-----
> From: funsec-bounces () linuxbox org [mailto:funsec-bounces () linuxbox org] On
> Behalf Of Drsolly
> Sent: Sunday, January 15, 2006 12:51 AM
> To: funsec () linuxbox org
> Subject: [AKO Content Warning - Attachments] [funsec] An interesting
> packet inspection problem
>
> I'm having a very strange problem. I'm enclosing a test file, zipped
> (you'll see why).
>
> The file duff.12, is blocked somehow, and has been for the last two days
> or so. It's a 43 byte file:
>
> This is a test file
> xxxxxx
> End of the file
>
> But the x's are hexadecimal bc, six of them, and that's the "active
> ingredient".
>
> Because the blocking problem depends on the content of the file (files
> without the "active ingredient" transfer just fine), I'm thinking it's
> related to some kind of packet inspection, and that puts it into the
> security area, probably. The string of 6 bc hex, might not be the only
> possible "active ingredient", but it is one that I've narrowed down to.
>
> I have three locations, call them Watford, Chesham and Vodafone. Watford
> is my colocation (run by Cable and Wireless), Chesham is my home (ISP is
> Nildram) and Vodafone is a laptop connected via the Vodafone network,
> using GPRS over a mobile. I also have an AOL account.
>
> When the file is blocked, it's blocked using ftp, http and telnet. It
> isn't blocked if I Zip the file, or send it via ssh (because then the
> "active ingredient" isn't there, it's encrypted).
>
> Vodafone -> Watford   OK
> Watford  -> Vodafone  Blocked
> AOL      -> Watford   OK
> AOL      -> Chesham   OK
> Watford  -> Chesham   Blocked
> Chesham  -> Watford   Blocked
> Vodafone -> Chesham   OK
> Chesham  -> Vodafone  Blocked
>
> Watford  -> Some guy in America - OK
> Watford  -> Some guy in Switzerland - Blocked
>
> I put a server on the Watford location without any Firewall. Still
> blocked. So it isn't my firewall (I didn't think it was, but it's good to
> eliminate).
>
> It's pretty strange that A -> B is blcoked, while B -> A isn't. Using the
> Vodafone data, I can prove that it must be watford, but I can also prove
> that it must be Chesham. Well, this implies that the problem is at *both*
> Watford and Chesham, and must therefore be something that both Nildram and
> Cable&Wireless use, but the only thing I can think of there, is the London
> Interchange (Link), and I cannot believe that they would do any kind of
> packet inspection, the volumes are simply ginormous.
>
> The tech support people at Cable and Wireless (who seem to be Clueful)
> are baffled, and I don't blame them.
>
> With the data above, you can exponerate (or blame) Chesham and Watford.
>
> Of course, that isn't the only file that gets blocked. It's a minimalist
> test file.
>
> My feeling is there's some box floating around, that's doing packet
> inspection, and blocks anything that includes a sequence of six bc hex.
>
> You can access my server in Chesham.
>
>
> http://www.webinfosecurity.com/good.12 shows you a good file; that lets
> you check that there's nothing blocking your access to my server
>
> http://www.webinfosecurity.com/duff.12  is the 43 byte file that gets
> blocked.
>
>
> If anyone can suggest a solution to this, I'd be very happy. As in "Oh, I
> know what that is, it's the Furzewangle Carflugner, configured to prevent
> Bagpeller attacks". But I'm not optimistic that anyone might.
>
> But what I'd like people to do, is try to access the duff file, and if
> their access fails, to send me a traceroute to www.webinfosecurity.com
>
> As a reward, if I ever find out what is causing this rather interesting
> (and for me, intensely frustrating) problem, I'll post it here.
>
> Thanks
>
>
>
> The sender of the message sent the following files that are not allowed by
> NETCOM guidance 2004-11:
> duff.zip
>
> In accordance with NETCOM guidance 2004-11,
> AKO has begun stripping files with the following extensions:
>  .b64, .bat, .bhx, .ceo, .ce0, .cpl, .dbx, .dll, .dot, .eml, .exe, .hqx,
> .lnk, .mim, .nch, .ocx,
>  .pi, .pif, .scr, .sct, .uue, .uu, .vbe, .vbs, .wsc, .wsf, .wsh, .xxe, and
> .zip.
>
> Since this is an Army policy, AKO will not be able to grant exceptions.
>
> You may view the NETCOM guidance at
> https://www.us.army.mil/suite/doc/1773343
>
> The guidance includes instructions on how the sender should send the files
> that are restricted.


_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.