Wednesday, May 29, 2019

Know Your Limitations

At cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 end of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 1973 Clint Eastwood movie Magnum Force, after Dirty Harry watches his corrupt police captain explode in a car, he says "a man's got to know his limitations."

I thought of this quote today as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 debate rages about compromising municipalities and ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r information technology-constrained yet personal information-rich organizations.

Several years ago I wrote If You Can't Protect It, Don't Collect It. I argued that if you are unable to defend personal information, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n you should not gacá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r and store it.

In a similar spirit, here I argue that if you are unable to securely operate information technology that matters, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n you should not be supporting that IT.

You should outsource it to a trustworthy cloud provider, and concentrate on managing secure access to those services.

If you cannot outsource it, and you remain incapable of defending it natively, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n you should integrate a capable managed security provider.

It's clear to me that a large portion of those running PI-processing IT are simply not capable of doing so in secure manner, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y do not bear cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 full cost of PI breaches.

They have too many assets, with too many vulnerabilities, and are targeted by too many threat actors.

These organizations lack sufficient people, processes, and technologies to mitigate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 risk.

They have successes, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are generally due to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 heroics of individual IT and security professionals, who often feel out-gunned by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir adversaries.

If you can't patch a two-year-old vulnerability prior to exploitation, or detect an intrusion and respond to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 adversary before he completes his mission, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n you are demonstrating that you need to change your entire approach to information technology.

The security industry seems to think that throwing more people at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 answer, yet year after year we read about several million job openings that remain unfilled. This is a sign that we need to change cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 way we are doing business. The fact is that those organziations that cannot defend cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365mselves need to recognize cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir limitations and change cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir game.

I recognize that outsourcing is not a panacea. Note that I emphasized "IT" in my recommendation. I do not see how one could outsource cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 critical technology running on-premise in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 industrial control system (ICS) world, for example. Those operations may need to rely more on outsourced security providers, if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y cannot sufficiently detect and respond to intrusions using in-house capabilities.

Remember that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 vast majority of organizations do not exist to run IT. They run IT to support cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir lines of business. Many older organizations have indeed been migrating legacy applications to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud, and most new organizations are cloud-native. These are hopeful signs, as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 older organizations could potentially  "age-out" over time.

This puts a burden on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud providers, who fall into cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 "managed service provider" category that I wrote about in my recent Corelight blog. However, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 more trustworthy providers have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 people, processes, and technology in place to handle cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir responsibilities in a more secure way than many organziations who are struggling with on-premise legacy IT.

Everyone's got to know cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir limitations.

Thursday, May 09, 2019

Dissecting Weird Packets

I was investigating traffic in my home lab yesterday, and noticed that about 1% of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 traffic was weird. Before I describe cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 weird, let me show you a normal frame for comparison's sake.


This is a normal frame with Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet II encapsulation. It begins with 6 bytes of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 destination MAC address, 6 bytes of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 source MAC address, and 2 bytes of an Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rtype, which in this case is 0x0800, indicating an IP packet follows cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet header. There is no TCP payload as this is an ACK segment.

You can also see this in Tshark.

$ tshark -Vx -r frame4238.pcap

Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
    Encapsulation type: Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet (1)
    Arrival Time: May  7, 2019 18:19:10.071831000 UTC
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1557253150.071831000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 66 bytes (528 bits)
    Capture Length: 66 bytes (528 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rtype:ip:tcp]
Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet II, Src: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb), Dst: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)
    Destination: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)
        Address: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb)
        Address: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.4.96, Dst: 52.21.18.219
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 52
    Identification: 0xd98c (55692)
    Flags: 0x4000, Don't fragment
        0... .... .... .... = Reserved bit: Not set
        .1.. .... .... .... = Don't fragment: Set
        ..0. .... .... .... = More fragments: Not set
        ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0x553f [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.4.96
    Destination: 52.21.18.219
Transmission Control Protocol, Src Port: 38828, Dst Port: 443, Seq: 1, Ack: 1, Len: 0
    Source Port: 38828
    Destination Port: 443
    [Stream index: 0]
    [TCP Segment Len: 0]
    Sequence number: 1    (relative sequence number)
    [Next sequence number: 1    (relative sequence number)]
    Acknowledgment number: 1    (relative ack number)
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x010 (ACK)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...1 .... = Acknowledgment: Set
        .... .... 0... = Push: Not set
        .... .... .0.. = Reset: Not set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: ·······A····]
    Window size value: 296
    [Calculated window size: 296]
    [Window size scaling factor: -1 (unknown)]
    Checksum: 0x08b0 [unverified]
    [Checksum Status: Unverified]
    Urgent pointer: 0
    Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - No-Operation (NOP)
            Kind: No-Operation (1)
        TCP Option - Timestamps: TSval 26210782, TSecr 2652693036
            Kind: Time Stamp Option (8)
            Length: 10
            Timestamp value: 26210782
            Timestamp echo reply: 2652693036
    [Timestamps]
        [Time since first frame in this TCP stream: 0.000000000 seconds]
        [Time since previous frame in this TCP stream: 0.000000000 seconds]

0000  fc ec da 49 e0 10 38 ba f8 12 7d bb 08 00 45 00   ...I..8...}...E.
0010  00 34 d9 8c 40 00 40 06 55 3f c0 a8 04 60 34 15   .4..@.@.U?...`4.
0020  12 db 97 ac 01 bb e3 42 2a 57 83 49 c2 ea 80 10   .......B*W.I....
0030  01 28 08 b0 00 00 01 01 08 0a 01 8f f1 de 9e 1c   .(..............
0040  e2 2c   

You can see Wireshark understands what it is seeing. It decodes cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 IP header and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 TCP header.

So far so good. Here is an example of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 weird traffic I was seeing.



Here is what Tshark thinks of it.

$ tshark -Vx -r frame4241.pcap
Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
    Encapsulation type: Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet (1)
    Arrival Time: May  7, 2019 18:19:10.073296000 UTC
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1557253150.073296000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 66 bytes (528 bits)
    Capture Length: 66 bytes (528 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:llc:data]
IEEE 802.3 Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet
    Destination: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)
        Address: Ubiquiti_49:e0:10 (fc:ec:da:49:e0:10)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb)
        Address: IntelCor_12:7d:bb (38:ba:f8:12:7d:bb)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Length: 56
        [Expert Info (Error/Malformed): Length field value goes past cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 end of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 payload]
            [Length field value goes past cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 end of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 payload]
            [Severity level: Error]
            [Group: Malformed]
Logical-Link Control
    DSAP: Unknown (0x45)
        0100 010. = SAP: Unknown
        .... ...1 = IG Bit: Group
    SSAP: LLC Sub-Layer Management (0x02)
        0000 001. = SAP: LLC Sub-Layer Management
        .... ...0 = CR Bit: Command
    Control field: U, func=Unknown (0x0B)
        000. 10.. = Command: Unknown (0x02)
        .... ..11 = Frame type: Unnumbered frame (0x3)
Data (49 bytes)
    Data: 84d98d86b5400649eec0a80460341512db97ac0d0be3422a...
    [Length: 49]

0000  fc ec da 49 e0 10 38 ba f8 12 7d bb 00 38 45 02   ...I..8...}..8E.
0010  0b 84 d9 8d 86 b5 40 06 49 ee c0 a8 04 60 34 15   ......@.I....`4.
0020  12 db 97 ac 0d 0b e3 42 2a 57 83 49 c2 ea c8 ec   .......B*W.I....
0030  01 28 17 6f 00 00 01 01 08 0a 01 8f f1 de ed 7f   .(.o............
0040  a5 4a                                             .J

What's cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem? This frame begins with 6 bytes of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 destination MAC address and 6 bytes of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 source MAC address, as we saw before. However, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 next two bytes are 0x0038, which is not cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rtype of 0x0800 we saw earlier. 0x0038 is decimal 56, which would seem to indicate a frame length (even though cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 frame here is a total of 66 bytes).

Wireshark decides to treat this frame as not being Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet II, but instead as IEEE 802.3 Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet. I had to refer to appendix A of my first book to see what this meant.

For comparison, here is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 frame format for Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet II (page 664):

This was what we saw with frame 4238 earlier -- Dst MAC, Src MAC, Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rtype, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n data.

Here is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 frame format for IEEE 802.3 Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet.


This is much more complicated: Dst MAC, Src MAC, length, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n DSAP, SSAP, Control, and data.

It turns out that this format doesn't seem to fit what is happening in frame 4241, eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r. While cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 length field appears to be in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ballpark, Wireshark's assumption that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 next bytes are DSAP, SSAP, Control, and data doesn't fit. The clue for me was seeing that 0x45 followed cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 presumed length field. I recognized 0x45 as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 beginning of an IP header, with 4 meaning IPv4 and 5 meaning 5 words (40 bytes) in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 IP header.

If we take a manual byte-by-byte comparative approach we can better understand what may be happening with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se two frames. (I broke cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 0x45 byte into two "nibbles" in one case.)

Note that I have bolded cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 parts of each frame that are exactly cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same.


This analysis shows that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se two frames are very similar, especially in places where I would not expect cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m to be similar. This caused me to hypocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365size that frame 4241 was a corrupted version of frame 4238.

I can believe that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 frames would share MAC addresses, IP addresses, and certain IP and TCP defaults. However, it is unusual for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m to have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same high source ports (38828) but not cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same destination ports (443 and 3339).  Very telling is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 fact that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same TCP sequence and acknowledgement numbers. They also share cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same source timestamp.

Notice one field that I did not bold, because cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are not identical -- cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 IP ID value. Frame 4238 has 0xd98c and frame 4241 has 0xd98d. The perfectly incremented IP ID prompted me to believe that frame 4241 is a corrupted retransmission, at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 IP layer, of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same TCP segment.

However, I really don't know what to think. These frames were captured in a Linux 16.04 VirtualBox VM by netsniff-ng. Is this a problem with netsniff-ng, or Linux, or VirtualBox, or cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Linux host operating system running VirtualBox?

I'd like to thank cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 folks at ask.wireshark.org for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir assistance with my attempts to decode this (and ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r) frames as 802.3 raw Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet. What's that? It's basically a format that Novell used with IPX, where cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 frame is Dst MAC, Src MAC, length, data.

I wanted to see if I could tell Wireshark to decode cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 odd frames as 802.3 raw Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet, racá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r than IEEE 802.3 Ecá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rnet with LLC headers.

Sake Blok helpfully suggested I change cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 pcap's link layer type to User0, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n tell Wireshark how to interpret cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 frames. I did it this way, per his direction:

$ editcap -T user0 excerpt.pcap excerpt-user0.pcap

Next I opened cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 trace in Wireshark and saw frame 4241 (here listed as frame 3) as shown below:


DLT 147 corresponds to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 link layer type for User0. Wireshark doesn't know how to handle it. We fix that by right-clicking on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 yellow field and selecting Protocol Preferences -> Open DLT User preferences:

Next I created an entry fpr User 0 (DLT-147) with Payload protocol "ip" and Header size "14" as shown:

After clicking OK, I returned to Wireshark. Here is how frame 4241 (again listed here as frame 3) appeared:


You can see Wireshark is now making sense of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 IP header, but it doesn't know how to handle cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 TCP header which follows. I tried different values and options to see if I could get Wireshark to understand cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 TCP header too, but this went far enough for my purposes.

The bottom line is that I believe cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re is some sort of packet capture problem, eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 softare used or cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 traffic that is presented to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 software by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bridged NIC created by VirtualBox. As this is a lab environment and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 traffic is 1% of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 overall capture, I am not worried about cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 results.

I am fairly sure that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 weird traffic is not on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 wire. I tried capturing on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 host OS sniffing NIC and did not see anything resembling this traffic.

Have you seen anything like this? Let me know in a comment here on on Twitter.

PS: I found cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 frame.number=X Wireshark display filter helpful, along with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 frame.len>Y display filter, when researching this activity.

Monday, April 08, 2019

Troubleshooting NSM Virtualization Problems with Linux and VirtualBox

I spent a chunk of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 day troubleshooting a network security monitoring (NSM) problem. I thought I would share cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem and my investigation in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hopes that it might help ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rs. The specifics are probably less important than cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 general approach.

It began with ja3. You may know ja3 as a set of Zeek scripts developed by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Salesforce engineering team to profile client and server TLS parameters.

I was reviewing Zeek logs captured by my Corelight appliance and by one of my lab sensors running Security Onion. I had coverage of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same endpoint in both sensors.

I noticed that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SO Zeek logs did not have ja3 hashes in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ssl.log entries. Both sensors did have ja3s hashes. My first thought was that SO was misconfigured somehow to not record ja3 hashes. I quickly dismissed that, because it made no sense. Besides, verifying that intution required me to start troubleshooting near cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 top of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 software stack.

I decided to start at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bottom, or close to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 bottom. I had a sinking suspicion that, for some reason, Zeek was only seeing traffic sent from remote systems, and not traffic originating from my network. That would account for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 creation of ja3s hashes, for traffic sent by remote systems, but not ja3 hashes, as Zeek was not seeing traffic sent by local clients.

I was running SO in VirtualBox 6.0.4 on Ubuntu 18.04. I started sniffing TCP network traffic on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SO monitoring interface using Tcpdump. As I feared, it didn't look right. I ran a new capture with filters for ICMP and a remote IP address. On anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r system I tried pinging cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 remote IP address. Sure enough, I only saw ICMP echo replies, and no ICMP echoes. Oddly, I also saw doubles and triples of some of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 ICMP echo replies. That worried me, because unpredictable behavior like that could indicate some sort of software problem.

My next step was to "get under" cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 VM guest and determine if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 VM host could see traffic properly. I ran Tcpdump on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Ubuntu 18.04 host on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 monitoring interface and repeated my ICMP tests. It saw everything properly. That meant I did not need to bocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r checking cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 switch span port that was feeding traffic to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 VirtualBox system.

It seemed I had a problem somewhere between cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 VM host and guest. On cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same VM host I was also running an instance of RockNSM. I ran my ICMP tests on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 RockNSM VM and, sadly, I got cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same one-sided traffic as seen on SO.

Now I was worried. If cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem had only been present in SO, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n I could fix SO. If cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem is present in both SO and RockNSM, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem had to be with VirtualBox -- and I might not be able to fix it.

I reviewed my configurations in VirtualBox, ensuring that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 "Promiscuous Mode" under cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Advanced options was set to "Allow All". At this point I worried that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re was a bug in VirtualBox. I did some Google searches and reviewed some forum posts, but I did not see anyone reporting issues with sniffing traffic inside VMs. Still, my use case might have been weird enough to not have been reported.

I decided to try a different approach. I wondered if running VirtualBox with elevated privileges might make a difference. I did not want to take ownership of my user VMs, so I decided to install a new VM and run it with elevated privileges.

Let me stop here to note that I am breaking one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 rules of troubleshooting. I'm introducing two new variables, when I should have introduced only one. I should have built a new VM but run it with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same user privileges with which I was running cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 existing VMs.

I decided to install a minimal edition of Ubuntu 9, with VirtualBox running via sudo. When I started cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 VM and sniffed traffic on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 monitoring port, lo and behold, my ICMP tests revealed both sides of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 traffic as I had hoped. Unfortunately, from this I erroneously concluded that running VirtualBox with elevated privileges was cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 answer to my problems.

I took ownership of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 SO VM in my elevated VirtualBox session, started it, and performed my ICMP tests. Womp womp. Still broken.

I realized I needed to separate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 two variables that I had entangled, so I stopped VirtualBox, and changed ownership of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Debian 9 VM to my user account. I cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n ran VirtualBox with user privileges, started cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Debian 9 VM, and ran my ICMP tests. Success again! Apparently elevated privileges had nothing to do with my problem.

By now I was glad I had not posted anything to any user forums describing my problem and asking for help. There was something about cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 monitoring interface configurations in both SO and RockNSM that resulted in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 inability to see both sides of traffic (and avoid weird doubles and triples).

I started my SO VM again and looked at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 script that configured cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 interfaces. I commented out all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 entries below cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 management interface as shown below.

$ cat /etc/network/interfaces

# This configuration was created by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Security Onion setup script.
#
# The original network interface configuration file was backed up to:
# /etc/network/interfaces.bak.
#
# This file describes cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network interfaces available on your system
# and how to activate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m. For more information, see interfaces(5).

# loopback network interface
auto lo
iface lo inet loopback

# Management network interface
auto enp0s3
iface enp0s3 inet static
  address 192.168.40.76
  gateway 192.168.40.1
  netmask 255.255.255.0
  dns-nameservers 192.168.40.1
  dns-domain localdomain

#auto enp0s8
#iface enp0s8 inet manual
#  up ip link set $IFACE promisc on arp off up
#  down ip link set $IFACE promisc off down
#  post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done
#  post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6

#auto enp0s9
#iface enp0s9 inet manual
#  up ip link set $IFACE promisc on arp off up
#  down ip link set $IFACE promisc off down
#  post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done
#  post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6

I rebooted cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 system and brought cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 enp0s8 interface up manually using this command:

$ sudo ip link set enp0s8 promisc on arp off up

Fingers crossed, I ran my ICMP sniffing tests, and voila, I saw what I needed -- traffic in both directions, without doubles or triples no less.

So, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re appears to be some sort of problem with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 way SO and RockNSM set parameters for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir monitoring interfaces, at least as far as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y interact with VirtualBox 6.0.4 on Ubuntu 18.04. You can see in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network script that SO disables a bunch of NIC options. I imagine one or more of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 culprit, but I didn't have time to work through cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m individually.

I tried taking a look at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network script in RockNSM, but it runs CentOS, and I'll be darned if I can't figure out where to look. I'm sure it's cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re somewhere, but I didn't have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 time to figure out where.

The moral of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 story is that I should have immediately checked after installation that both SO and RockNSM were seeing both sides of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 traffic I expected cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m to see. I had taken that for granted for many previous deployments, but something broke recently and I don't know exactly what. My workaround will hopefully hold for now, but I need to take a closer look at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 NIC options because I may have introduced anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r fault.

A second moral is to be careful of changing two or more variables when troubleshooting. When you do that you might fix a problem, but not know what change fixed cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 issue.

Thursday, March 28, 2019

Thoughts on OSSEC Con 2019

Last week I attended my first OSSEC conference. I first blogged about OSSEC in 2007, and wrote ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r posts about it in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following years.

OSSEC is a host-based intrusion detection and log analysis system with correlation and active response features. It is cross-platform, such that I can run it on my Windows and Linux systems. The moving force behind cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 conference was a company local to me called Atomicorp.

In brief, I really enjoyed this one-day event. (I had planned to attend cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 workshop on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 second day but my schedule did not cooperate.) The talks were almost uniformly excellent and informative. I even had a chance to talk jiu-jitsu with OSSEC creator Daniel Cid, who despite hurting his leg managed to travel across cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 country to deliver cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 keynote.

I'd like to share a few highlights from my notes.

First, I had been worried that OSSEC was in some ways dead. I saw that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Security Onion project had replaced OSSEC with a fork called Wazuh, which I learned is apparently pronounced "wazoo." To my delight, I learned OSSEC is decidedly not dead, and that Wazuh has been suffering stability problems. OSSEC has a lot of interesting development ahead of it, which you can track on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir Github repo.

For example, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 development roadmap includes eliminating Logstash from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 pipeline used by many OSSEC users. OSSEC would feed directly into Elasticsearch. One speaker noted that Logstash has a 1.7 GB memory footprint, which astounded me.

On a related note, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 OSSEC team is planning to create a new Web console, with a design goal to have it run in an "AWS t2.micro" instance. The team noted that instance offers 2 GB memory, which doesn't match what AWS says. Perhaps cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y meant t2.micro and 1 GB memory, or t2.small with 2 GB memory. I think cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y mean t2.micro with 1 GB RAM, as that is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 free tier. Eicá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r way, I'm excited to see this later in 2019.

Second, I thought cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 presentation by security personnel from USA Today offered an interesting insight. One design goal cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y had for monitoring cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir Google Cloud Platform (GCP) was to not install OSSEC on every container or on Kubernetes worker nodes. Several times during cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 conference, speakers noted that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 transient nature of cloud infrastructure is directly anticá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365tical to standard OSSEC usage, whereby OSSEC is installed on servers with long uptime and years of service. Instead, USA Today used OSSEC to monitor HTTP logs from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 GCP load balancer, logs from Google Kubernetes Engine, and monitored processes by watching output from successive kubectl invocations.

Third, a speaker from Red Hat brought my attention to an aspect of containers that I had not considered. Docker and containers had made software testing and deployment a lot easier for everyone. However, those who provide containers have effectively become Linux distribution maintainers. In ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r words, who is responsible when a security or configuration vulnerability in a Linux component is discovered? Will cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 container maintainers be responsive?

Anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r speaker emphasized cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 difference between "security of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud," offered by cloud providers, and "security in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud," which is supposed to be cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 customer's responsibility. This makes sense from a technical point of view, but I expect that in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 long term this differentiation will no longer be tenable from a business or legal point of view.

Customers are not going to have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 skills or interest to secure cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir software in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud, as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y outsource ever more technical talent to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud providers and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir infrastructure. I expect cloud providers to continue to develop, acquire, and offer more security services, and accelerate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir competition on a "complete security environment."

I look forward to more OSSEC development and future conferences.

Wednesday, March 13, 2019

Thoughts on Cloud Security

Recently I've been reading about cloud security and security with respect to DevOps. I'll say more about cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 excellent book I'm reading, but I had a moment of déjà vu during one section.

The book described how cloud security is a big change from enterprise security because it relies less on IP-address-centric controls and more on users and groups. The book talked about creating security groups, and adding users to those groups in order to control cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir access and capabilities.

As I read that passage, it reminded me of a time long ago, in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 late 1990s, when I was studying for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 MCSE, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n called cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Microsoft Certified Systems Engineer. I read cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 book at left, Windows NT Security Handbook, published in 1996 by Tom Sheldon. It described cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 exact same security process of creating security groups and adding users. This was core to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 new NT 4 role based access control (RBAC) implementation.

Now, fast forward a few years, or all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 way to today, and consider cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security challenges facing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 majority of legacy enterprises: securing Windows assets and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 data cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y store and access. How could this wonderful security model, based on decades of experience (from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 1960s and 1970s no less), have failed to work in operational environments?

There are many reasons one could cite, but I think cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following are at least worthy of mention.

The systems enforcing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security model are exposed to intruders.

Furcá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365rmore:

Intruders are generally able to gain code execution on systems participating in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security model.

Finally:

Intruders have access to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 network traffic which partially contains elements of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security model.

From cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se weaknesses, a large portion of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security countermeasures of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 last two decades have been derived as compensating controls and visibility requirements.

The question cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n becomes:

Does this change with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud?

In brief, I believe cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 answer is largely "yes," thankfully. Generally, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 systems upon which cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security model is being enforced are not able to access cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 enforcement mechanism, thanks to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 wonders of virtualization.

Should an intruder find a way to escape from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir restricted cloud platform and gain hypervisor or management network access, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y find cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365mselves in a situation similar to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 average Windows domain network.

This realization puts a heavy burden on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud infrastructure operators. They major players are likely able to acquire and apply cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 expertise and resources to make cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir infrastructure far more resilient and survivable than cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir enterprise counterparts.

The weakness will likely be cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir personnel.

Once cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 compute and network components are sufficiently robust from externally sourced compromise, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n internal threats become cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 next most cost-effective and return-producing vectors for dedicated intruders.

Is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re anything users can do as cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y hand cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir compute and data assets to cloud operators?

I suggest four moves.

First, small- to mid-sized cloud infrastructure users will likely have to piggyback or free-ride on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 initiatives and influence of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 largest cloud customers, who have cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 clout and hopefully cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 expertise to hold cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud operators responsible for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 security of everyone's data.

Second, lawmakers may also need improved whistleblower protection for cloud employees who feel threatened by revealing material weaknesses cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y encounter while doing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir jobs.

Third, government regulators will have to ensure no cloud provider assumes a monopoly, or no two providers assume a duopoloy. We may end up with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 three major players and a smattering of smaller ones, as is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 case with many mature industries.

Fourth, users should use every means at cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir disposal to select cloud operators not only on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir compute features, but on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir security and visibility features. The more logging and visibility exposed by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud provider, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 better. I am excited by new features like cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Azure network tap and hope to see equivalent features in ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r cloud infrastructure.

Remember that security has two main functions: planning/resistance, to try to stop bad things from happening, and detection/respond, to handle cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 failures that inevitably happen. "Prevention eventually fails" is one of my long-time mantras. We don't want prevention to fail silently in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud. We need ways to know that failure is happening so that we can plan and implement new resistance mechanisms, and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n validate cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir effectiveness via detection and response.

Update: I forgot to mention that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 material above assumed that cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud users and operators made no unintentional configuration mistakes. If users or operators introduce exposures or vulnerabilities, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n those will be cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 weaknesses that intruders exploit. We've already seen a lot of this happening and it appears to be cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 most common problem. Procedures and tools which constantly assess cloud configurations for exposures and vulnerabilities due to misconfiguration or poor practices are a fifth move which all involved should make.

A corollary is that complexity can drive problems. When cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 cloud infrastructure offers too many knobs to turn, cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365n it's likely cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 users and operators will believe cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are taking one action when in reality cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365y are implementing anocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r.

Saturday, February 09, 2019

Forcing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Adversary to Pursue Insider Theft

Jack Crook pointed me toward a story by Christopher Burgess about intellectual property cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ft by "Hongjin Tan, a 35 year old Chinese national and U.S. legal permanent resident... [who] was arrested on December 20 and charged with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ft of trade secrets. Tan is alleged to have stolen cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 trade secrets from his employer, a U.S. petroleum company," according to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 criminal complaint filed by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 US DoJ.

Tan's former employer and cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 FBI allege that Tan "downloaded restricted files to a personal thumb drive." I could not tell from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 complaint if Tan downloaded cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 files at work or at home, but cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 thumb drive ended up at Tan's home. His employer asked Tan to bring it to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir office, which Tan did. However, he had deleted all cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 files from cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 drive. Tan's employer recovered cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 files using commercially available forensic software.

This incident, by definition, involves an "insider threat." Tan was an employee who appears to have copied information that was outside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 scope of his work responsibilities, resigned from his employer, and was planning to return to China to work for a competitor, having delivered his former employer's intellectual property.

When I started GE-CIRT in 2008 (officially "initial operating capability" on 1 January 2009), one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 strategies we pursued involved insider threats. I've written about insiders on this blog before but I couldn't find a description of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 strategy we implemented via GE-CIRT.

We sought to make digital intrusions more expensive than physical intrusions.

In ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r words, we wanted to make it easier for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 adversary to accomplish his mission using insiders. We wanted to make it more difficult for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 adversary to accomplish his mission using our network.

In a cynical sense, this makes security someone else's problem. Suddenly cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 physical security team is dealing with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 worst of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 worst!

This is a win for everyone, however. Consider cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 many advantages cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 physical security team has over cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 digital security team.

The physical security team can work with human resources during cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 hiring process. HR can run background checks and identify suspicious job applicants prior to granting employment and access.

Employees are far more exposed than remote intruders. Employees, even under cover, expose cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir appearance, likely residence, and personalities to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 company and its workers.

Employees can be subject to far more intensive monitoring than remote intruders. Employee endpoints can be instrumented. Employee workspaces are instrumented via access cards, cameras at entry and exit points, and ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r measures.

Employers can cooperate with law enforcement to investigate and prosecute employees. They can control and deter cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ft and ocá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365r activities.

In brief, insider cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ft, like all "close access" activities, is incredibly risky for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 adversary. It is a win for everyone when cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 adversary must resort to using insiders to accomplish cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir mission. Digital and physical security must cooperate to leverage cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se advantages, while collaborating with human resources, legal, information technology, and business lines to wring cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 maximum results from this advantage.

Tuesday, January 29, 2019

Fixing Virtualbox RDP Server with DetectionLab

Yesterday I posted about DetectionLab, but noted that I was having trouble with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 RDP servers offered by Virtualbox. If you remember, DetectionLab builds four virtual machines:

root@LAPTOP-HT4TGVCP C:\Users\root>"c:\Program Files\Oracle\VirtualBox\VBoxManage" list runningvms
"logger" {3da9fffb-4b02-4e57-a592-dd2322f14245}
"dc.windomain.local" {ef32d493-845c-45dc-aff7-3a86d9c590cd}
"wef.windomain.local" {7cd008b7-c6e0-421d-9655-8f92ec98d9d7}
"win10.windomain.local" {acf413fb-6358-44df-ab9f-cc7767ed32bd}

I was having a problem with two of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 VMs sharing cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 same port for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 RDP server offered by Virtualbox. This meant I could not access one of cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365m. (Below, port 5932 has cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 conflict.)

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>"c:\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo logger | findstr /I vrde | findstr /I address
VRDE:                        enabled (Address 0.0.0.0, Ports 5955, MultiConn: off, ReuseSingleConn: off, Aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication type: null)
VRDE property               : TCP/Address  = "0.0.0.0"

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>"c:\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo dc.windomain.local | findstr /I vrde | findstr /I address
VRDE:                        enabled (Address 0.0.0.0, Ports 5932, MultiConn: off, ReuseSingleConn: off, Aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication type: null)
VRDE property               : TCP/Address = "0.0.0.0"

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>"c:\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo wef.windomain.local | findstr /I vrde | findstr /I address
VRDE:                        enabled (Address 0.0.0.0, Ports 5932, MultiConn: off, ReuseSingleConn: off, Aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication type: null)
VRDE property               : TCP/Address = "0.0.0.0"

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>"c:\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo win10.windomain.local | findstr /I vrde | findstr /I address
VRDE:                        enabled (Address 0.0.0.0, Ports 5981, MultiConn: off, ReuseSingleConn: off, Aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication type: null)
VRDE property               : TCP/Address = "0.0.0.0"

To fix this, I explicitly added port values to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 configuration in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Vagrantfile. Here is one example:

      vb.customize ["modifyvm", :id, "--vrde", "on"]
      vb.customize ["modifyvm", :id, "--vrdeaddress", "0.0.0.0"]
      vb.customize ["modifyvm", :id, "--vrdeport", "60101"]

After a 'vagrant reload', cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 RDP servers were now listening on new ports, as I hoped.

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>"c:\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo logger | findstr /I vrde | findstr /I address
VRDE:                        enabled (Address 0.0.0.0, Ports 60101, MultiConn: off, ReuseSingleConn: off, Aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication type: null)
VRDE property               : TCP/Address  = "0.0.0.0"

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>"c:\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo dc.windomain.local | findstr /I vrde | findstr /I address
VRDE:                        enabled (Address 0.0.0.0, Ports 60102, MultiConn: off, ReuseSingleConn: off, Aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication type: null)
VRDE property               : TCP/Address = "0.0.0.0"

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>"c:\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo wef.windomain.local | findstr /I vrde | findstr /I address
VRDE:                        enabled (Address 0.0.0.0, Ports 60103, MultiConn: off, ReuseSingleConn: off, Aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication type: null)
VRDE property               : TCP/Address = "0.0.0.0"

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>"c:\Program Files\Oracle\VirtualBox\VBoxManage" showvminfo win10.windomain.local | findstr /I vrde | findstr /I address
VRDE:                        enabled (Address 0.0.0.0, Ports 60104, MultiConn: off, ReuseSingleConn: off, Aucá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ntication type: null)
VRDE property               : TCP/Address = "0.0.0.0"

This is great, but I am still encountering a problem with avoiding port collisions when Vagrant remaps ports for services on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 VMs.

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>vagrant status
Current machine states:

logger                    running (virtualbox)
dc                        running (virtualbox)
wef                       running (virtualbox)
win10                     running (virtualbox)

This environment represents multiple VMs. The VMs are all listed
above with cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365ir current state. For more information about a specific
VM, run `vagrant status NAME`.

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>vagrant port logger
The forwarded ports for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 machine are listed below. Please note that
cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se values may differ from values configured in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Vagrantfile if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365
provider supports automatic port collision detection and resolution.

    22 (guest) => 2222 (host)

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>vagrant port dc
The forwarded ports for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 machine are listed below. Please note that
cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se values may differ from values configured in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Vagrantfile if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365
provider supports automatic port collision detection and resolution.

  3389 (guest) => 3389 (host)
    22 (guest) => 2200 (host)
  5985 (guest) => 55985 (host)
  5986 (guest) => 55986 (host)

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>vagrant port wef
The forwarded ports for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 machine are listed below. Please note that
cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se values may differ from values configured in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Vagrantfile if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365
provider supports automatic port collision detection and resolution.

  3389 (guest) => 2201 (host)
    22 (guest) => 2202 (host)
  5985 (guest) => 2203 (host)
  5986 (guest) => 2204 (host)

root@LAPTOP-HT4TGVCP C:\Users\root\git\detectionlab\DetectionLab\Vagrant>vagrant port win10
The forwarded ports for cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 machine are listed below. Please note that
cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365se values may differ from values configured in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Vagrantfile if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365
provider supports automatic port collision detection and resolution.

  3389 (guest) => 2205 (host)
    22 (guest) => 2206 (host)
  5985 (guest) => 2207 (host)
  5986 (guest) => 2208 (host)

The entry in bold is cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 problem. Vagrant should not be mapping port 3389, which is already in use by cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 RDP server on cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Windows 10 host, such that it tries to be available to cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 guest.

I tried telling Vagrant by hand in cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Vagrantfile to map port 3389 elsewhere, but nothing worked. (I tried entries like cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 following.)

    config.vm.network :forwarded_port, guest: 3389, host: 5789

I also searched to see if cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365re might be a configuration outside cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 Vagrantfile that I was missing. Here is what I found:

ds61@ds61:~/DetectionLab-master$ find . | xargs grep "3389" *
./Terraform/Method1/main.tf:    from_port   = 3389
./Terraform/Method1/main.tf:    to_port     = 3389
./Packer/vagrantfile-windows_2016.template:    config.vm.network :forwarded_port, guest: 3389, host: 3389, id: "rdp", auto_correct: true
./Packer/scripts/enable-rdp.bat:netsh advfirewall firewall add rule name="Open Port 3389" dir=in action=allow protocol=TCP localport=3389
./Packer/vagrantfile-windows_10.template:    config.vm.network :forwarded_port, guest: 3389, host: 3389, id: "rdp", auto_correct: true

I wonder if those Packer templates have anything to do with it, or if I am encountering a problem with Vagrant? I have seen many people experience similar issues, so I don't know.

It's not a big deal, though. Now that I can directly access cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 virtual screens for each VM on Virtualbox via cá cược thể thao bet365_cách nạp tiền vào bet365_ đăng ký bet365 RDP server, I don't need to RDP to port 3389 on each Windows VM in order to interact with it.

If anyone has any ideas, though, I'm interested!