Ensuring security of deserializing data using Protobuf-net

I cannot answer questions #1 or #2, but I can speak a bit to question #3.  First, a quick overview of protobuf-net.

On the wire, Google's protocol buffers are a messaging format not a serialization format.  Messages consist of sequences of key/value pairs, where values can be primitive data types or nested sequences.  It's somewhat similar to JSON, except that the keys are integers rather than name strings.  The format is language-independent (and thus contains no language-specific type information) and sufficiently self-documenting that values of unexpected properties can be skipped and data types for primitive values can be inferred.

protobuf-net is a contract based serializer for .NET types that serializes from and to the protocol buffer format.  "Contract based" means that the serializer builds a map (a.k.a. "contract") between message properties and .Net properties, then uses that contract to construct and deserialize .Net objects.  The "root" object to deserialize is specified by the call to deserialize, e.g.

var rootObject = ProtoBuf.Serializer.Deserialize<RootObjectType>(stream)

Basic instructions for its use can be found here and here.

protubuf-net makes only limited use of unsafe code - currently only for efficient deserialization of floating point values I believe.  This can be disabled by building with FEAT_SAFE defined.  Thus the possibility of a malformed message overwriting the heap or stack is minimized.  Protobuf-net does not share a code base with the Google implementation of protocol buffers.

So, how does protobuf-net construct its contract (the RuntimeTypeModel) for mapping .Net types to messages?  Since message keys are integers rather than strings, the canonical choice of using the .Net public property or field name does not work.  Instead, there are the following options:

The type can be annotated with with [ProtoContract] and [ProtoMember()] attributes, like this example from the docs:

[ProtoContract]
class Person {
    [ProtoMember(1)]
    public string Name {get;set:}
    [ProtoMember(2)]
    public Address Address {get;set;}
}
[ProtoContract]
class Address {
    [ProtoMember(1)]
    public string Line1 {get;set;}
    [ProtoMember(2)]
    public string Line2 {get;set;}
}

The properties and fields marked with [ProtoMember] will be discovered using reflection and serialized.  Others will not.
The contract can be constructed programmatically, as shown here.
protobuf-net contract generation is opt-in by default.  I.e., only the specified properties and fields are serialized.  However, this can be overridden by setting ProtoContractAttribute.ImplicitFields to one of the following values:

public enum ImplicitFields
{
    /// <summary>
    /// No members are serialized implicitly; all members require a suitable
    /// attribute such as [ProtoMember]. This is the recmomended mode for
    /// most scenarios.
    /// </summary>
    None = 0,
    /// <summary>
    /// Public properties and fields are eligible for implicit serialization;
    /// this treats the public API as a contract. Ordering beings from ImplicitFirstTag.
    /// </summary>
    AllPublic= 1,
    /// <summary>
    /// Public and non-public fields are eligible for implicit serialization;
    /// this acts as a state/implementation serializer. Ordering beings from ImplicitFirstTag.
    /// </summary>
    AllFields = 2
}

protobuf-net can also use data contract serializer and XmlSerializer attributes for automatic contract creation.  This can be disabled via the property ProtoContractAttribute.UseProtoMembersOnly.
While protobuf-net was originally designed as a code-first serializer (you define your types, then define how to serialize them) it does have support for c# code generation from message prototypes.  See here for details.

Thus, as you can see, the possibility for unwanted types and code to be injected during serialization is limited by design since the contract, rather than the message, controls the types of constructed objects.  This can be further limited via the following recommendations:

Do not use [ProtoMember(DynamicType = true)].

protobuf-net implements an extension to the standard allowing the .Net type to be deserialized to be specified in the message itself - breaking the relative safety of of the out-of-the-box standard.  This is disabled by default but can be enabled by setting DynamicType = true.  Do not use this functionality, as this is the most obvious way for an unexpected object to be injected during deserialization.

If you are concerned that some other developer on the team might use this functionality (as it does make serializing polymorphic types extremely easy), you can set an event on TypeModel.DynamicTypeFormatting that throws an exception whenever the serializer tryies to resolve a dynamic type, or a dynamic type name, e.g.:

    ProtoBuf.Meta.TypeFormatEventHandler handler = (o, e) => { throw new NotSupportedException("Dynamic typing is not allowed."); };
    ProtoBuf.Meta.RuntimeTypeModel.Default.DynamicTypeFormatting += handler;

Be sure to set the event on the typemodel you are actually using, as is pointed out here.
Be careful with inheritance.  protobuf-net does support inheritance.  Take care not to allow unwanted derived types to creep into the contract.  E.g., given the following:

[ProtoContract]
[ProtoInclude(7, typeof(ValidatedSqlQuery))]
[ProtoInclude(8, typeof(DebugSqlCommand))]
public abstract class SqlCommand
{
}

/// <summary>
/// Represents a fully validated, parameterized SQL query
/// </summary>
[ProtoContract]
public class ValidatedSqlQuery
{
}

/// <summary>
/// For testing purposes, execute any command against the database.
/// </summary>
[ProtoContract]
class DebugSqlCommand
{
}

It's possible for a DebugSqlCommand to get constructed in a List<SqlCommand> via an appropriate message, possibly causing damage down the line.
Serialize properties, not fields.  Do not use ImplicitFields.AllFields.  Avoid using ImplicitFields.AllPublic whenever possible.
Validate data in all property setters.  You can use serialization-specific setters if you don't want to do the validation on the "normal" setters, e.g.:

[ProtoContract]
class Contact {
    public string Email { get; set; }

    [ProtoMember(1)]
    string SerializedEmail {
        get { return Email; }
        set
        {
            // Make sure the email is well-formed, throw an exception if not
            ValidateEmail(value);
            Email = value;
        }
    }
}

In complex validation scenarios, you can validate multiple related properties in an [OnDeserialized] callback.
Finally, your deserialization code is only as safe as the objects you deserialize!  Do not serialize objects containing or using unsafe code.  Do not allow debug objects to be serialized.


Does License check response needs further obfuscation to make it more secure?

Answer No to "Does X need obfuscation to make it more secure?" for any given X

If you want something to really be more secure, obfuscation won't provide it.


NGO Joomla! site: Infected with malware? JavaScript injection?

Support for Joomla 1.5 LTS ended in Dec 2012. This usually means that no more security patches (or any other maintenance patches) will be released.

The "solution" is to migrate content from a known good backup to a supported Joomla version, or some other current Content Management System.

Even if someone here were able to figure out a fix, you would have to migrate anyway, because Joomla 1.5 is out of support - so you might as well do it now.


If you're running a website that's under attack, you should consider a service such as Cloudflare.

Cloudflare and other CDNs are designed with DDoS attacks in mind - traffic passes through Cloudflare's network before it reaches yours. Since Cloudflare will filter DDoS traffic, only clean traffic will reach you.

On the other hand, if the attack is small enough to not saturate your port, and you feel comfortable enough dealing with it on your own, look into running Nginx as a reverse proxy in front of your Apache instance. Nginx is designed to handle floods a lot better than Apache can, due to the epoll architecture.

The way that services such as Cloudflare work are by 1) Mitigation appliances and 2) Having lots of capacity.

A mitigation appliance looks at anomalies in traffic, and matches traffic with known attack signatures in the past in order to distinguish legitimate traffic from DDoS traffic. The "dirty" traffic is dropped, while the clean traffic is passed on.

The best mitigation in the world doesn't help if your port is being saturated (Imagine sending 11gbps to a target who can only handle 10gbps). No matter how good your filtering is, you will go offline because your port is not capable of handling more than 10gbps. Services such as CloudFlare (any CDN or DDoS mitigation provider really) buy tons of capacity from transit providers in order to deal with huge volummetric floods - things that couldn't be handled at the server level because of the massive amounts of traffic (think 50gbps+)


Foxit Reader - disable JavaScript / Safely read PDF

I studied this question a bit. I can say there is no way for a PDF to run malware by itself. The PDF is just bytes in a certain format. There is a very few amount of security risks if not none in the applications used to open PDFs. I would not use Firefox but Adobe to open PDF files. Firefox simply didn't implement the whole PDF specification. I use Firefox because it is open source but not for PDFs (unless you are on Linux).
If it was that easy to just run some JavaScript in a browser and put some malware in the computer, every website you visit would be a security risk. I think you can say that PDFs are secure.
Where it becomes a security risk is the icon. We are so used to the icons that we see that you will often launch a PDF without looking at the extension or info about the file. If the file is an executable, nothing prevents someone from specifying a PDF icon to an executable and mimick a PDF. This is how I would do it myself. So I would simply tcheck the PDF before opening it.
That is to say you should trust people enough to be sure there is no malware in a teacher's PDF and in downloadable books. Especially, if you use these books on a foxit reader which is hard to hack.
When you launch software on Windows or Linux, the OS tcheks the extension of the file and uses the default app this extension is associated to. It then puts the file path onto the stack of the new process which the app uses to parse the file. Unless there is a problem in the app used to launch the PDF or the PDF is an exe with a fake icon, I doubt it can do any harm.
I'm not saying it isn't a security risk to download stuff on Internet. But I think among the most secure files are the PDFs especially if they come from trusted sources like a teacher. I would not call a classmate a trusted source though.
If you want to be sure. You can always open documents on the cloud which is very secure because it is limited by the Internet browser which are very secure today.


It has graduated to crazytown:

http://www.reddit.com/r/badbios

However, there was a research implementation that proved functionality:

http://www.theregister.co.uk/2013/12/05/airgap_chatting_malware/

Moreover, there has been documentation showing similar work has been deployed in the intelligence community:

http://www.pcworld.com/article/2087893/forget-badbios-nsa-turns-to-pirate-radio-to-target-air-gapped-computers.html


Is there any reason I shouldn't use SHA1 of salt + website name + master password for my password in websites?

Yes, there's a very good reason, it's called KeePass. It's a free and open source password management application. It can automatically generate a rock-solid password for you, pair it to certain website, and store it in a securely encrypted database for which you have the key in a form of a master password.

Other than for learning purposes, don't play a crypto pro and write your own security-related programs.


Identifying suspicious encrypted traffic

The domain is 1e100.net but the whois entry you show is for le100.net, with an l, not a 1 (if these appear to be the same for you, then choose a better font).

The 1e100.net domain is a lot more legitimate, and its name is some sort of joke. Indeed, if you do a whois request on it, you get:

Domain Name: 1e100.net
Registry Domain ID:
(...)
Registrant Organization: Google Inc.
Registrant Street: 1600 Amphitheatre Parkway
Registrant City: Mountain View
Registrant State/Province: CA

which means that the domain is registered by none other than Google themselves. The joke is a reference to the Googol, a term for the huge integer 10100, which would be written in so-called scientific notation "1e100".

That the domain is used by Google is documented by Google, there. Basically, you are observing a Google product (say, Chrome) trying to talk to its home base, possibly to know if there is a new version available, or as part of some mechanism of Google search / Google+ / whatever. That's not a malware.


Router administration page is served over HTTP

Context: I'm going to assume that you use your wireless router in a home setting. If you use this router in an enterprise setting, get a different router.

Know your threat model!

Obviously, plain HTTP communication is bad. But why? Because it doesn't guarantee the authenticity, integrity or confidentiality of your data. So who could have access to your data? Anyone who can listen to the communication between you and your router.

Depending on how you communicate with the router, the list of devices that can do that becomes very small.

Direct Connection

This is the simplest setup and looks like this:

+----------------+                +----------------------+
|                |                |                      |
|  Your Computer +<-------------->+ Your Wireless Router |
|                |                |                      |
+----------------+                +--+-------------------+
                                     ^
                                     |
                                     |
+----------------+                   |
|                |                   |
| Other Devices  +<------------------+
|                |
+----------------+

It's a wired connection between you and your router. An adversary would need to be able to physically tap the cable to be able to intercept (and possibly modify) your communication between the router and your computer. In most cases, this is an absolute non-issue.

Switched Connection

This is a more complex setup and something you would typically encounter in larger apartments, or in situations where you want more wired connections than your router physically offers.

+----------------+                +-----------------+                +----------------------+
|                |                |                 |                |                      |
|  Your Computer +<-------------->+ Ethernet Switch +<-------------->+ Your Wireless Router |
|                |                |                 |                |                      |
+----------------+                +-+---------------+                +-+--------------------+
                                    ^                                  ^
                                    |                                  |
                                    |                                  v
+----------------+                  |                                +-+--------------+
|                |                  |                                |                |
| Other Devices  +<-----------------+                                | Other Devices  |
|                |                                                   |                |
| (May be evil)  |                                                   +----------------+
|                |
+----------------+

In this example, some devices connect directly to your router (they may be physically close, for example), while others connect via a Switch. In this example, your computer is connected to the router via a switch.

A malicious device, marked here as "May be evil", might employ an attack called MAC Flooding, which targets the Ethernet Switch. The switch would then basically act like a hub, forwarding traffic not only to the intended partner like it would under normal operating conditions, but forwarding the traffic on all ports (except the source port).

This would potentially allow an attacker to listen to your communication with the router's admin page and potentially sniff the admin password.

Is this feasable? This is for you to decide, but I personally would assume that if a device in my home has become infected, I have different worries.

Connection over W-LAN without any Security

This is a situation you definitely want to avoid.

                                                                Unencrypted W-LAN

           ((( O )))                                               ((( O )))
               |                                                       |
               |                                                       |
+--------------+-+                                                   +-+--------------------+
|                |                                                   |                      |
|  Your Computer |                                                   | Your Wireless Router |
|                |                          ((( O )))                |                      |
+----------------+                              |                    +-+--------------------+
                                                |                      ^
                                 +--------------+-+                    |
                                 |                |                    v
                                 | Other Devices  |                  +-+--------------+
                                 |                |                  |                |
                                 | (May be evil)  |                  | Other Devices  |
                                 |                |                  |                |
                                 +----------------+                  +----------------+

Communicating wirelessly without any encryption is the same as yelling any and all of your data at the top of your lungs, constantly. Any script kiddy "advanced persistent nuisance" in your neighborhood who ever watched "üb3rh4x0rZ 1337 guid3 t0 wifi haxxing" can sniff your data, connect to your network, and in general be nasty to you.

Don't do this. Please.

Connection over W-LAN with Encryption

This situation isn't as bad, but potentially dangerous.

                                                                Encrypted W-LAN

           ((( O )))                                               ((( O )))
               |                                                       |
               |                                                       |
+--------------+-+                                                   +-+--------------------+
|                |                                                   |                      |
|  Your Computer |                                                   | Your Wireless Router |
|                |                          ((( O )))                |                      |
+----------------+                              |                    +-+--------------------+
                                                |                      ^
                                 +--------------+-+                    |
                                 |                |                    v
                                 | Other Devices  |                  +-+--------------+
                                 |                |                  |                |
                                 | (May be evil)  |                  | Other Devices  |
                                 |                |                  |                |
                                 +----------------+                  +----------------+

If your "encryption" is based on WEP, then there might not be any at all. WEP is broken beyond repair, and the "advanced persistent nuisance" we spoke about in the last section can crack your key in a matter of minutes.

If your encryption is WPA2-PSK (using AES, not TKIP) with a long, random password and a unique SSID, then you should be fine. The situation is still not ideal, because sensitive data is still transmitted over the air and any wireless device knowing your key could potentially listen to it.

What does this mean? What should I do?

Simply put, connect to your router directly and you should be fine in the vast majority of realistic cases. You will probably not connect to your router's admin page that often, maybe to add a new port forwarding configuration, or to reboot it remotely if the network is bad again.

Other than that, you have the options of using open-source software such as DD-WRT. If your router is supported, then flashing it should be relatively easy. This might void your warranty, so be careful.

Finally, you can just buy a different router. Most stores are required to take it back within a certain period of time for any reason. If you say "the thing doesn't do what I need it to do", then that's reason enough.


Best way to report a foreigner attacker's ip to authorities?

There's always an "Abuse" email address on the whois of a netblock for reporting misuse of an IP address.

You can use http://whois.domaintools.com/ to do a whois lookup to get the address.

Is it worth your time? That's your call. Will it lead to anything? Nothing you'll ever see. But many of the sites I fix come from people who were first alerted of the problems on their server by someone sending the hosting company an "abuse" notification email. So it definitely can make a difference.

Note that the IP address you track down is almost never the attacker himself but rather a hacked server or computer that he's using as a relay. So keep that in mind. You're not alerting the authorities on the whereabouts of a miscreant; you're notifying someone that his computer has been compromised.

EDIT TO ADD

You give the information you have to the appropriate authority, and then you're done. That it. As a rule, hosting companies will not share personal information of their clients unless you are local law enforcement with the appropriate warrant or court order. It's their liability if they do otherwise.

Don't expect a follow-up report from them, don't expect names or arrests or anything more than an acknowledgement that they heard you -- sometimes not even that. These companies often deal with dozens of these reports a week or more. Their abuse team will deal with it, and they appreciate your assistance as they want to keep their network clean, and your report will probably trigger several days worth of activity. But they have a clear-cut policy that they follow to the letter for liability reasons, and it intentionally doesn't include reporting back the original reporter. Nothing against you specifically.

Also, remember that though you found the hacker, It's almost certainly not his account on the server.


How to read certificate chains in OpenSSL

0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority

  ...
  Which is the Root Certificate? The first one listed or the last?

None of these. It only shows which certificates are sent by the server, i.e. the leaf certificate and the intermediate (chain) certificates. The root certificate is usually not sent (and would be ignored if sent) since the whole idea of trusted path validation is that the root is trusted because it is locally known.

In this case the trust path can be validated if the user has the certificate for 'Equifax Secure Certificate Authority' as a local trusted certificate and if this certificate can be used to validate the signature of certificate#2 (GeoTrust Global CA), then certificate#2 can be used to verify signature of certificate#1 and certificate#1 to verify signature of certificate#0. Note that trust path is only one part of the certificate validation. You also need to add validation of the subject (i.e. matches the subject www.google.com the URL you've tried you access) and checks for expiration and revocation.


What's eating my entropy? Or what does entropy_avail really show?

First, the claim that "/proc/sys/kernel/random/entropy_avail simply gives you the number of bits that can currently be read from /dev/random" is false.

The entropy_avail field reads the input_pool.entropy_count, the "output" pool refers to the pool used for urandom (non-blocking pool) and random (blocking pool).

As mentioned in this answer, spawning new processes consumes entropy for things like ASLR. The watch program spawns a new process for every invocation, perhaps the monitoring tool does the same (possibly via one of the other monitoring sources that have to invoke an external program to obtain the status?).

For monitoring the entropy pool without draining it you can try the entropy-watcher program (see linked answer).

Watching the entropy-watcher numbers closely it seems that you lose about 64 bits of entropy at intervals. Based on the analysis in the other answer, this seems to be the result of moving entropy to an "output pool" to avoid wasting it. This is observed on Linux v4.6, future implementations may be different.

Based on the source code (drivers/char/random.c in v4.6), I can see that reading the output pools (/dev/{u,}random or get_random_bytes()) invokes extract_entropy{,_user} which calls xfer_secondary_pool and account. The blocking pool has the property limit set (r->limit == 1) which affects both functions:

For account() it will return no data from the blocking pool if its entropy is too low. For the non-blocking output pool, the remaining entropy will be consumed but data is still returned.
xfer_secondary_pool() ensures that enough entropy is available in the output pool. If the blocking output pool has insufficient entropy, it will take some from the input pool (when possible).
xfer_secondary_pool() for the non-blocking output pool behaves specially according to the /proc/sys/kernel/random/urandom_min_reseed_secs parameter. If this value is non-zero, entropy is only taken from the input pool if at least urandom_min_reseed_secs seconds have elapsed since the last transfer. By default this value is set to 60 seconds.

The last point finally explains why you see an entropy drain in the input pool every 60 seconds. If some consumer requests random bytes from the non-blocking output pool (TCP sequence numbers, ASLR, /dev/urandom, getrandom(), ...), then 128 bits will be consumed from the input pool to reseed the non-blocking output pool.


George has a good answer with some great information regarding this, however one thing you need to think about with all of this is your user experience, and attack theater. If it's on someone's phone, who would be the one to get that data?

Local:  A person with physical access to that device. With physical access to the device they can wait to watch the memory for any sort of encryption to be loaded into memory and pull the hash that way. In that case they have the hash. That's one of the issues with physical device access.
Remote data exploit: If all they have is a copy of the file that contains the hash(possibly through a DB dump), as long as it's encrypted well on top of hashed it will be a long time before they can decrypt the hash and start trying to get the password out of that hash.

There should be several ways to do this. Choose the one that best fits whatever attack scenarios you're worried about and good luck keeping it(the encryption secret(s) and the hash) safe.


How to prevent spam when sender email is never the same?

Spam is a security concern because it can contain various phishing and malware attacks. This should be really concerning because the more spam you get the greater chance you will click a link thinking it's legitimate and get hacked.

Once you get on the spam lists, there is nothing you can do to get off of them. It now becomes a question of how important that account is to you?

Hotmail/Outlook is notoriously bad a spam filtering. Contrast that with Gmail or iCloud which have such good spam filtering that I NEVER see spam. "Google says less than 0.1 percent of email in the average Gmail inbox is spam while wanted mail in spam folders is under 0.05 percent." here

So, my recommendation would be to open a Gmail or iCloud account and start to gradually migrate your contacts/mailing lists over to that account.

But if you insist on staying with your current account, there are a few things you can do to mitigate some of that spam:

Instead of deleting spam, mark it as 'junk'. There should be a button for that. That will better tweak the algorithms.
There is an Outlook mail setting 'Block attachments, pictures, and links from anyone not in my Safe senders and domains list' checkbox. Then add the senders and domains you trust to this list.
Don't reply to spam or unsubscribe from spam messages. Don't even look at it as the sender can have a tracker that shows you opened it.
Never tried a spam plugin myself, but these may be worth a shot: Top Anti-Spam Add-Ins for Outlook

Alternatively, you can forward your mail to Gmail and take advantage of its spam filters. You even have the option of sending and receiving Hotmail from a Gmail account. See here


How to know which output length to request from PBKDF2?

The output length for PBKDF2 is what you need. But there are details.

PBKDF2 is a Key Derivation Function: it produces a sequence of bytes of configurable length, whose intended purpose is to be used as keys for some symmetric encryption algorithm (or a MAC). So a first response is: if you want to use a symmetric encryption algorithm which expects, say, a 19-byte key, then you want 19 bytes out of PBKDF2.

Now for the details:

PBKDF2 has a drawback, which is that it produces data by blocks, and has a cost which is proportional to the number of blocks that you are asking from it. For instance, if you use PBKDF2 with HMAC/SHA-1 as inner PRF (that's the usual case), then you get bytes by blocks of 20. If you want, say, 24 bytes, then PBKDF2 will need to produce two blocks, and this will be twice as expensive as if you wanted 20 bytes or less.

This is unfortunate because PBKDF2 is intentionally slow, in order to defeat exhaustive search on the password. However, depending on how you use the PBKDF2 output, the attacker might be able to "test" a password on the first block of PBKDF2 output only; in effect, this may give a x2 or x3 performance boost to the attacker, which is counterproductive.

The suggested work-around is to produce one block of output with PBKDF2 (say, 20 bytes), then expand these 20 bytes with another, fast KDF, into as many bytes as you need. HKDF is a fast KDF with good repute.
PBKDF2 is often abused into password hashing. With password hashing, you don't really use the output, you just store it for ulterior comparison. For such a use, you need to store sufficiently many bytes so that attackers don't "get lucky": finding an output matching what was stored should be overwhelmingly improbable. If you use PBKDF2 for password hashing, then 12 bytes of output ought to be fine, with a non-negligible security margin.


... but how can someone determine which hash is which "programming wise" or just by the eyes. Or is there really no way to know for sure?

Both hash algorithms simply output bytes. There is no visible inherent structure in these bytes and no magic bytes or similar which could be used to detect the algorithm. In fact you would not be able to distinguish between MD4, MD5 or just 128 bit of random data just from looking at the output of the hash.


Does plain text mode offer complete protection against e-mail malware?

Before HTML and Javascript were even invented, attackers were using ANSI escape codes in email bombs.

Silly: such as turning your terminal into a blinking rainbow of text

Annoying: gunking up the terminal so badly it couldn't be used without a reset

Embarrassing: nobody wants to be that guy in the lab whose VT-100 won't shut up

I don't know that code execution was ever a product, but don't underestimate the damage somebody with a termcap man page can do.


From a high level perspective, three things have to happen:

The client has to prove that it is the proper owner of the client certificate.  The web server challenges the client to sign something with its private key, and the web server validates the response with the public key in the certificate.
The certificate has to be validated against its signing authority  This is accomplished by verifying the signature on the certificate with the signing authority's public key.  In addition, certificate revocation lists (CRLs) are checked to ensure the cert hasn't been blacklisted.
The certificate has to contain information which designates it as a valid user of the web service.  The web server is configured to look at specific items in the certificate (typically the subject field) and only allow certain values.


JavaScript Injection using Man in the Middle Attack

The ISP (here, the WiFi hotspot) is what delivers pages to you. It's of course trivial for an ISP to read unsecured traffic:

Let's now consider a case where the credential submission is secured with HTTPS (so the ISP cannot sniff them right off the wire), but the HTTPS log-in page loads an unsecured script, helper.js. The ISP can inject any behavior into that non-HTTPS script before it finally serves the script to the browser. For example, the ISP can inject the instructions, "When this page submits credentials, send a copy of them to evil.example.com." The diagram below shows secured requests and responses in green and insecure requests/responses in other colors:

When your browser requests helper.js over HTTP, the malicious ISP responds with a resource that has the wrong content. Your browser has no idea what helper.js should look like, and without any integrity validation measure (like HTTPS), the browser has no idea anything is wrong. Your browser assumes it has correctly been served http://tmail.com/helper.js, because that's what it asked for and the ISP sent back a response without any complaint (e.g., the response was an HTTP 200 for /helper.js). The fact that what your browser got is different from what the real server sent is totally irrelevant, because your browser has no way to detect that this difference occurred.

Based on your comments, you seem to think that modifying a resource can only be done by redirecting the browser to another resource. This is incorrect. Consider Bob the browser, Iggy the ISP, and two servers, Alice and Mallory.

First, consider the honest case:

Bob wants to know Alice's favorite food.

Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
Iggy asks Alice about her favorite food. Alice tells him, "Pizza, but with no onions, because I hate onions."
Iggy comes back to Bob and says "Hey, I have that response for your GET /favoritefood from alice.com! She says she loves pizza, but not onions."

Now let's consider a dishonest case:

Bob wants to know Alice's favorite food.

Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
Iggy comes back to Bob and says, "301 Moved Permanently -- ask Mallory about Alice's favorite food instead"
Bob then sends Iggy to GET /favoritefood from mallory.com instead. It's a different resource, and Bob knows it's a different resource from the one he originally asked for.

In this case, the browser's address bar would be different from what you originally typed in: mallory.com/favoritefood instead of alice.com/favoritefood.

Now consider this case instead:

Bob wants to know Alice's favorite food.

Bob says to Iggy, "Hey, Iggy, please send a GET /favoritefood to alice.com."
Iggy asks Alice about her favorite food. Alice tells him, "Pizza, but with no onions, because I hate onions."
Iggy comes back to Bob and says "Hey, I have that response for your GET /favoritefood from alice.com! She says she loves to eat lots and lots of onions."

There's no other resources involved. http://alice.com/favoritefood is the only resource being fetched here; Iggy simply lied about what the contents of the resource were. There is no way for Bob to detect that Iggy is lying, because there is no integrity-validating system in place.

One final attempt at explanation: suppose the ISP is honest but mistakenly flipped a single bit when delivering the contents of the HTML file. Surely you would not expect such a mistake to cause the web page to load under a different domain. Now suppose that the honest ISP mistakenly flipped two bits instead of just one: again, such a mistake would never cause the domain or resource path to change. Now suppose the ISP flipped two thousand bits by honest mistake (perhaps the ISP has a faulty switch some place, or the WiFi router was hit by cosmic rays): again, no need for the domain to change. Now suppose the change was done maliciously instead of by mistake: again, the change in intent causes no change in what is actually happening. The resource path and origin, as identified in the browser's address bar, remains unchanged, while the ISP is free to change the contents of the resource (honestly or dishonestly) without detection.


Understanding OpenWRT LuCI Firewall Routing with VPN

To answer question 1, I don't think either setting is as secure as you ought to be.  Option 1 leaves masq turned on for the WAN when it doesn't need to be.  Option 2 sets up a default accept rule for the WAN when it doesn't need to be.

To answer question 2 and fill in the blanks on question 1: The input/output rule settings in OpenWRT are the default behavior for traffic.  Specific rules can then be added to deviate, for example if you set the WAN to input reject (which is the default), you then need to go in and specifically allow things to happen (like masquerading to do NAT which is there by default, or an accept rule to allow incoming SSH which is not there by default and hence no SSH can come from the WAN to the router). When you turned of Masquerade and left the WAN config at reject, there was no way for anything to get in that didn't fit into an allow rule (even OpenVPN traffic).  If you then went to the firewall traffic rules and specifically allowed the OpenVPN traffic through (1194 UDP by default), it would work in reject mode.  This is a better choice since leaving the WAN in accept means any services on your router (like ssh or SMB) are left to fend for themselves against incoming (possibly malicious) traffic.  It's best practice to deny everything and then poke just what you need through.


MITM attacks are effectively thwarted by HTTPS.

Since transport-level security can effectively protect you against eavesdropping and malicious interception, you should use TLS as your transport and focus your on securing the data at rest.

Group 2 was an popular about 20 years ago; it got some traction in the mail authentication world for a time, but with the popularity of SSL has declined significantly.

Group 1 is what everybody does today. In fact, it's a requirement of many standards.


Is there any virus that can cause physical damage?

In older times, virus could be damaging to the hardware in the following way:

Playing with video signal rates, so as to exceed the tolerance ranges of CRT monitors. Post-1995 CRT monitors included safety mechanisms (and LCD panels are inherently protected), but older monitors have died that way.
Reflashing the BIOS. This does not permanently kill the hardware, but resurrecting it can be hard; e.g. some motherboards can be reflashed after such a junk flashing only by reading the BIOS from... a floppy disk. Who has a floppy disk nowadays ?
Causing overheating by blocking fans. This works only when the fan speed is controlled from the motherboard itself. However, hardware which allows for a variable fan rotation speed also includes thermometers, and safety circuits which forcibly cut off power in case of overheating, before permanent damage occurs.

Though I know of a motherboard that did melt an ethernet card once (the chip turned completely black and the plastic partially collapsed). Strangely enough, the motherboard was fine afterwards.
Laptop batteries can be permanently damaged from software.

However, wanton destruction is often deemed useless by virus writers, who now prefer silently installation and remote control. Modern virus try hard not to damage the computer.


Is it possible to crack a PIN / PUK code on a phone SIM card?

Karsten Nohl had a nice presentation at Blackhat 2013 (https://www.blackhat.com/us-13/briefings.html#Nohl) claiming that many SIM cards are rootable.

The crux of his attack is based on the Over-The-Air (OTA) software updates for these cards, which are typically sent via "secure" binary SMS directly to the SIM.  He claims that in ~25% of the cases, the SIM will respond with a signed error message to an invalid attempt to update its code, and that for about 50% of the SIMs on the market, the signature will be encrypted with the very old and crackable Digital Encryption Standard (DES).  Worse yet, the signature is signed with the same key as is used to sign code, so that once it is broken offline it can be used to send a software update to the SIM.

This software update does not, in itself, provide access to the PUK, but by utilizing an unspecified memory vulnerability, Nohl claims to have been able to break out of the SIMs Java sandbox and get access to this key.

If you believe Nohl (and I have no reason not to), this demonstrates that:

It is possible to get the PUK for many SIMs on the market,
especially old ones.
It is not something that an average user can do right now.


Does the auth server have to be separate from the resource server when using OAuth 2.0?

OAuth is like any other auth scheme with regard to its functional purpose. You send creds to it, and it returns user info (even if it's only success/fail messages).

Usually a standards based auth server is used by multiple applications so you really want it isolated to it's own functional domain, code base and host. You don't want changes made to an application to impact an auth server that other applications use. That could be disastrous in a production environment and adds more QA than you should need for changes to the app.

If it will never be used by other applications there's no reason to add that layer of complexity that OAuth will add to the mix.

So yea separation should be there if OAuth is planned. In fact your OAuth server should be it's own project.


Hydra brute-force login with a timestamp

It depends on the desired timestamp format.
If your format is supposed to look like 2020-07-12 07:52:01 for example, then you could use (assuming that you run your command from some kind of Linux/Unix):
hydra -l admin -P passwords.txt -V 192.168.0.1 http-post-form "/goform/formLogin:login_n=^USER^&login_pass=^PASS64^&curTime=$(date '+%Y-%m-%d+%H:%M:%S' | sed s/:/%3A/g):S=Logout"

Adjust the date format string to your needs.


Sourcing hardware that is least likely to contain backdoors

Your questions is about preventing the inclusion of hardware that contains intentionaly created backdoors, but I suggest that in addition to prevention you consider detection, mitigation, and response.

There are different levels of sophistication in creating and detecting hardware backdoors. So, in part you need to understand your own level of expertise in detecting intentional hardware vulnerabilities. Doing design analysis is a good place to start. The general architecture should make sense and be familiar. A true from scratch hardware design is quite rare. Therefore look for the components of the design that deviate from previous revisions and other design for similar components.

Perform your own hardware security testing. Using your system security design create tests for the given piece of hardware and attempt to determine whether it passes or fails your security model for the intended system.

Mitigation of hardware security issues include strategies such as treating as much hardware as possible as untrusted and only investing trust in hardware that is critical to the secure operating of your system.

Only do business with people you trust in jurisdictions where harms done by companies and individuals may be fairly adjudicated.


What is the difference between data owner, data custodian and system owner?

Real example:

Data Owner - the administrator/CEO/board/president of a company

Data custodian - the ones taking care of the actual data - like IT staff (generally) or HR staff (for HR-related data)

System owner is the individual that is in charge of one or more systems, which may contain and operate data owned by various data owners.

Example, from a pure CISSP perspective: the IT servers staff. They are responsible for creating information plans together with data owners, the system administrator and end users. They must maintain the system security plan by the pre-agreed security requirements and he in involved in many security aspects of all systems that hold the data.

Limited Example: a HR employee that has a PC with company data on it is in theory a system owner, but not a data owner. He will operate on the data but the data does not belong to him. So the system owner may be considered an operator in such a limited case. Although in most cases such employees should be just users, in many cases they are not only that, therefore they can be put under this category.


How to decrypt Diffie-Hellman in wireshark?

The traffic itself does not contain enough information to decrypt it (if it did, a malicious WiFi hotspot could decrypt TLS making TLS worthless). You need the ephemeral (single-use) private key for the DHE or ECDHE (has nothing to do with a certificate), either the client's or the server's. Alternatively, you need the resulting shared secret. Either the client or the server can write it to log, but only as long as they have it - after the connection is closed, it is gone. There is a standard for such logging for browsers (to produce logs) and for wireshark (to consume logs), called SSLKEYLOGFILE.

See Mozilla docs for NSS Key Log Format and a blog post with screenshots for using it.


I can't execute commands through proxychains

Socks proxies TCP and UDP, while ping sends ICMP packets. So you need to test using another protocol. If you want it lightweight and stateless like ping you can try to resolve a DNS name for testing UDP. Otherwise try to load a website for testing TCP connectivity.


Well, you say:

  the certs are proper in server and client

But at least one of the systems disagrees:

Received fatal alert: certificate_unknown

This message means that one party (you don't say whether you are showing client-side or server-side logs) received an explicit alert message from the server, of class "fatal" and value 46 (0x2E, aka "certificate_unknown"). As specified in the TLS 1.0 standard:

certificate_unknown
    Some other (unspecified) issue arose in processing the
    certificate, rendering it unacceptable.

The "other" means that it is not a problem of the certificate being expired or revoked, or using an unsupported cryptographic algorithm. There can be many causes for a received certificate being "unacceptable", foremost of which being the impossibility of building a valid chain from an a priori known trusted root CA down to the certificate itself (normally, systems should send an "unknown_ca" alert in that case, but many do not have such precision in reporting errors with certificates).

To further investigate the issue, you should:

Activate full logging on both client and server. You show logs from the system who received the alert message; you should have a look at the logs from the other system, who sent the alert message;
Verify the configuration of both systems, in particular, for the one who sent the alert message (i.e. not the one which threw the "received fatal alert" exception, but the other one) what trust anchors it is using to validate the peer's certificate;
Check what certificate chains the systems are actually sending. Since this occurs before the encryption is activated, the certificates ought to be visible to some network monitoring tool à la Wireshark. Notably, check the order: in SSL/TLS, the end-entity certificate comes first, then the CA which issued it, then the CA which issued that CA, and so on.

Remember too that client certificates make sense only as authentication, not as authorization. Even if the client sends a certificate that the server can validate with regards to a trusted root, this only tells to the server who is at the other end of the line. It is still up to the server to decide whether that specific client should be allowed to proceed or not. This normally entails mapping the client certificate to an identity or a role, e.g. by extracting some specific field from the certificate. This process is completely outside of the scope of TLS itself, but must still occur, so there is some software and, crucially, some configuration on the server side that you probably wish to check.

In the other direction (validation of the server's certificate by the client), the rules are specified in RFC 2818, at least in the context of HTTPS: the intended server name (as extracted from the target URL) should appear in the server's certificate. Outside of HTTPS, it is up the each client application to decide whether the certificate they got from the server is the right one, i.e. that the certificate is valid (properly issued by a trusted CA and so on), but also that the identified server is indeed the one the client should be talking to. There again, configuration.


How secure is it to send credit card information partially over email and text?

Technically not secure, although as a result of a push by Google in the last couple of years, most (90 % ish) server-to-server email relays now use an encrypted connection, but it's still clear text on each server.

If you're going to provide the info, doing so by a voice call is probably as practical as possible.

Since you're already considering email for a piece, I suggest simply encrypting the email.

Ideally all parties would be familiar with using PGP/GPG for encryption, but unfortunately this is unlikely. Instead, put it in a file and ZIP it with a password. Most people know how to handle ZIP files. You still need to deliver the password out-of-band but you can do that with a voice call or depending upon the relationship with a cryptic reference common to you both.


Inputstick : AES-128 encryption (CBC mode) over Bluetooth connection

The first thing I would check is what is the entropy source in this device. There is no such thing as strong cryptography without a good entropy source (and also usually a good CPRNG).

Then you need to check how keys and IVs are generated and handled. Keys need to be securely transmitted or negotiated (using something like Diffie-Hellman) this in turn requires authentication to defend against active attackers (MITM). How does the device knows it talks to a legitimate user and not an attacker?


Using hidden form fields to modify prices on a website

According to my knowledge, hidden form fields are an alternative for HTTP's stateless nature. They act as a session token, much like cookies do. How can one use hidden values to modify prices?

Hidden form fields cause some data to be sent with a form. For example:

<form method="POST" action="/post_answer">
    <textarea name="answer"></textarea>
    <input type="hidden" name="question_id" value="161719">
</form>

This way, if I type an answer in the textarea, the server knows that this answer is for question 161719.

This is different from a session token. A session token is stored in a cookie and identifies the session. What you perhaps mean is that the question ID could  be stored in the session instead. That is true, with a slight change in behavior: if I visit multiple questions in multiple tabs and answer them out of order, the question id in the session will be incorrect. The one posted with the answer in the hidden form field will still be correct.

So, how can you modify prices? If the form looks like this:

<form method="POST" action="/finish_order">
    Enter your shipping address: <textarea name="address"></textarea>
    <input type="hidden" name="price_to_pay" value="$123.45">
    <input type="hidden" name="order_id" value="6789">
</form>

Here the price_to_pay is sent to finish_order, and you are charged with $123.45. However, you can easily modify this value to be charged less. Whether this works and whether your order still ships depends on the implementation of the website, and the procedurial checks in place.


PHP - 4.2.1 - CVE - Or see the Anders answer.
TOMCAT - Before 6.0.37 / 7.0.30 - CVE

Since CRLF Injection is directly related to HTTP response splitting attacks, I recommend you to read the question I asked, here. The answer was above my expectation.

EDIT

For some reasons, I needed to test some PHP header injections today. @Anders is right, the exploit I linked in the CVE is much more difficult to execute than the exploit stated in his answer below.


Relative security of 'offline' vs 'online' password managers

One possible problem with online password managers is that your adversary could guess passwords to the password manager from anywhere in the world, while you need to have physical access to brute force on a local password manager. Also, if the KeePass DB is in cloud storage, the adversary needs to get the password to the cloud storage.


Hardware token vs Fingerprint based software token

short: I'd go for the Hardware token.

Long version: First things first: People have proven that it is possible to tamper with fingerprints in multiple ways. Probably the most common way is to recreate it from a fingerprint with a printer, but there are more options. You can see some of them in the article 7 ways to beat fingerprint biometrics. There is a lot more than that though.

But also HW tokens have been proven "crackable". Its a little hard to tell from the little information we have. It really depends on the token.
The much more important bit in this consideration (at least for me) is this: If your HW token's seed gets stolen, you can change it. In case your fingerprint (or its digital representation) becomes publicly available your options are pretty limited.

If it really uses the fingerprint to authenticate at the system this should be your consideration. But if this is used on your phone it might just really be a token that is in your phone and secured by the OS using the fingerprint reader to replace the password. In this case your phone is your HW token but it has no proper read protected memory such as the token (should have).
In this case: I'd go for the HW token as well.


Benign, Malicious Domains and Definitions

Was the intent behind the registration of the domain name to harm others? Then it's a "malicious domain" by definition.

But can the intent be so clear from the start?

"Benign domain" sets up perhaps a poor dichotomy. A domain with good intent may be compromised to act with bad intent. Is it still a "benign" domain?

You appear to me to set up the correct model at the start of your question: "domains used for malicious purposes". It makes it about what it did, which is easier to define and delineate. You can shorten this to "malicious domain". It also allows you to define those domains that have been compromised to perform malicious acts: "compromised domains". "Benign domains", then, can be defined as those domains that are not known to have acted maliciously. That last one gives you some room to be unsure about their intent or use.

It does depend a lot on how you are defining "malicious" and "benign" for the purposes of your paper.


Experience shows that if a site like this is on the public Internet and gets popular enough, it becomes a big target and has a high likelihood of disastrous compromise.  Note well the responses in this extensive discussion (about a somewhat different goal):

How should I ethically approach user password storage for later plaintext retrieval? - Stack Overflow

If you choose to go ahead, make sure you warn your users of the very real risks.  Defense-in-depth is mandatory - keep the actual password storage machine off the web, accessed thru the firewall with a very simple interface, built on the most secure platform you can find, with lots of hardening and monitoring, a good IDS, etc etc.


Why don't popular web services mask the CVV?

Most likely answer:

They don't have to (it's not a PCI requirement)
It's better from a UI/support standpoint

Let's keep this in perspective.  This is the number that's printed, on the back of the card, right where minimum-wage cashiers are instructed to visually inspect when performing a POS transaction.  Absolute secrecy from physical bystanders is clearly not the intended control for the CSC!

Pay attention rather to the aggressive controls the PCI DSS imposes to ensure it's never stored by anyone in the processing chain.  They are not concerned with onesie-twosies being shoulder-surfed, they're concerned with the people who steal credit card databases getting away with the CSC too.


There is no guarantee with any computational system that it can't be broken/manipulated.

Here is a list of vulnerabilities in QEMU, its up to you to determine if your specific version is vulnerable or not, and how "easy" it is to be targeted.

As a side note: we tend to avoid absolutisms in infosec because there usually is no guarantee of anything, what is bullet proof today is a swiss cheese tomorrow.


How does X-XSS-Protection: "0" affect the security of my website?

If you disable XSS protection via header, the attacker will be able to inject victim some code into your site if you use dynamic site with inputs where the risk has not been mitigated another way. You can get more information about XSS attacks on Wikipedia

If you want to mitigate this risk and do not use the header, you must secure every single input by methods like htmlspecialchars($value); (in PHP). More about mitigating XSS on W3Schools


Facebook achieves this with a HTTP Strict Transport Security (HSTS) policy.

This is delivered over HTTPS and informs the browser to automatically "rewrite" HTTP requests to HTTPS for that domain. The max-age parameter specifies how long the browser will honour the policy for.

It is also possible to list your site in the HSTS preload list. This list is shipped with browsers. The advantage of the list is that the site does not require the first (insecure) visit to be made in order for the policy to be set.


How does winrar know I typed the right key?

WinRAR does not check a password at all. It passes a password through the hash function to set a 128/256 Bit AES encryption key and then uses this key to encrypt the file data valid until RAR 4.x format. The new RAR 5.x format detects wrong passwords even before starting extraction and does not extract garbage. RAR 5.x stores a special password hash generated by one way hash function. Consequently the knowledge of this hash does not allow to know a password of the encryption key. When password is entered RAR compares its hash to stored hash in case of no match it rejects the wrong password early. This one way hash function is intentionally slow and based on PBKDF2, therefore it does not allow to increase the brute force attack performance noticeably.

Here is the source.


Arduino to Android secure bluetooth connection

You have the right idea, namely a shared secret that is never transmitted from one device to the other.  If you do that, you should not need to worry about MAC addresses or MITM attacks.  You are vulnerable only if attacker can get that shared secret.

Since the shared secret is the {ahem} key, you need to be confident that it cannot be generated independently.  One way to do that is to generate it with a cryptographically secure pseudo-random number generator (CSPRNG).  You might also consider using Diceware words, which are somewhat more human-friendly, but will need a longer string to get equal entropy.

Now, about the actual algorithm: SipHash is new to me, but a little reading tells me it's a keyed hash function.  That is, it's not invertible, so step 4. will not work as  you have written it.

If SipHash is a given, then Step 3 is "The Android hashes the string with a shared secret key and sends it back to the Arduino."

Step 4 is the real difference: "The Arduino computes the same hash and verifies it matches the hash received from Android; if it does it it goes ahead and connects/continues with locking or unlocking."

Alternatively, you could use symmetric encryption, such as AES.  A little Googling around finds AES libraries for Arduino and I know that they exist for Android.


Is there a tool allowing me to store some encrypted data in an image file?

I don't know of any website that would allow you to do that, purely for security reasons. The point of steganography (what you're trying to do here) is to obscure the fact that there's content embedded inside other content at all.

Also, when you upload unencrypted content to a website, you are no longer the only person who has it. That makes it less secure, and as a result, you should always encrypt locally.

I recommend steghide for what you are asking.


Encrypt and Data-Integrity: h=CRC-8(m) and c=Encrypt(k,m) then send (h,c) over a channel. Secure?

Both of your schemes are flawed, and that is not because of CRC. If you replace the CRC with a cryptographic hash function, then your schemes are still insecure.

hash(m) + Encrypt(m, k)
One is the purposes of encryption is to ensure confidentiality of the plaintext message. A message can only be revealed by cracking the 128-bit key. In contrast, the hash is independent of the key. If the number of possible plaintexts is limited, then an attacker can easily brute-force the plaintext.

Since the hash function does not take the key as input, and AES is secure against known-plaintext attacks, there is no way to gain any information about the key from the hash.
hash(Encrypt(m, k)) + Encrypt(m, k)
The hash function here does not guarantee the authenticity of the ciphertext, because anyone can calculate the hash. Unlike the previous scheme, this hash does not reduce the security of the encryption.

If your objective is authenticity, modify the second scheme by using HMAC instead of CRC.
Or don't use a separate MAC and use AES in GCM mode instead of CTR.


Modifying shell code to bypass Windows Firewall

You are mistaken in your approach entirely, since you are exploiting IE which is a lower privileged process by default you will not be able to disable the firewall. furthermore when attacking with a client side exploit you can make no assumptions about network configurations, there might be more than one firewall between the host and you, a NAT might block your shell connection, and the port you end up listening on might not be open.

my suggestion is to go for a reverse shell payload, this complements client side exploitation limitations and supports more use cases. furthermore default windows firewall configurations allow outbound traffic without any limitations, meaning that essentially windows firewall is "bypassed" - as in not blocking your shell.


A port itself cannot be hacked, rather, it comes down to if the service running on that port contains any vulnerabilities. If you're running a web service on port 80 that contains no known vulnerabilities, your chances of being hacked are low depending on your situation. If you're running a vulnerable service on port 80, you're at risk to be popped by an attacker or botnet.

Port 80 is not open by default on most operating systems, you will need to manually launch a service that utilizes that port. Also, no, an attacker is generally not required to pose as another host in order to compromise your computer externally.


Evil Twin attack: How to make client send WPA2-PSK password when asked for AP-password?

This is impossible without knowing the password (WPA prevents this). However, you can set up an open fake accesspoint and use a captive portal to get the password in clear text. This would require you to social engineer the target into connecting to your accesspoint. You can for example keep sending deauth requests to the real AP and let the captive portal on your fake AP be a fake update page.


Can non-malicious faults provoke malicious faults?

I may have found an interesting example by combining some references.

Assume that we have a low assurance function that is related to a high assurance one (they share the same memory). This makes sense in a car, where infotainment functions (low assurance) may interact with perception functions (high assurance) to display data to the user.

Because the low assurance function is, well, of low assurance, the designer decided to put a low of security mechanisms for this function, to avoid an attacker to use it to access the memory and then to access the high assurance function.

However, the low assurance function is subject to dangling pointers fault, that is a common fault due to incompetence / not attentive developer.  A dangling pointer appears when an object is destroyed, but the point still references the memory address used by this object. Hence, this pointer may be used to access data that should not be accessed (i.e., privilege escalation).
The attacker has to wait for the dangling pointer to reference a data structure of the high assurance function to break into it.

Consequently, the occurrence of a fault in the low assurance component can lead an attacker to break through the high assurance one.


Amazon RDS MySQL SSL connection, is the password sent in clear?

If you look at the MySQL Internals Documentation, you can see that the protocol initialises SSL/TLS after the initial handshake packet, but before the authentication step:

The two paths shown from the first state are based on whether SSL/TLS is enabled or not. As such, if SSL/TLS is enabled, the authentication occurs after the secure channel is created, and the credentials are not sent in plaintext.

The key thing about the wording of the documentation you quoted is that it says "should not be relied on for authenticating the DB Instance itself", and not "authenticating to the DB instance itself". I suspect the point they're making is that, since each DB instance has an auto-generated certificate, you shouldn't rely upon this for verifying that you're speaking to the database instance you requested.


How "scrambled" is the data on a RAID5 disk?

Raid 5 stripes the data across the disks but the blocks used for striping are typically pretty big. At the very least they will bewhole sectors but normally they will much larger than that. For example madm defaults to half-megabyte chunks. Even one sector is big enough that you are likely to find recongisable chunks of text and with typical chunk sizes it is quite likely entire recognisable files will be present on the individual drives from the array.


Securely detecting and correcting time drift for TOTP

RFC 6238 recommends “that the validator be set with a specific limit to the number of time steps a prover can be "out of synch" before being rejected.”  It doesn't recommend a resynchronization algorithm, although it does mention that one could be applied.
In general, the way people usually handle this is to require the TOTP generator to have time synchronization with a reliable source instead of applying a resynchronization algorithm.  Because these days most TOTP clients are mobile phones and mobile phones are synchronized to the phone network timestamps by default, this is usually sufficient with a standard ±1 offset.
There are a wide variety of other cases in which having a clock which significantly deviates from standard time is a problem, notably TLS certificate rotation, and users will generally find that not having their device properly synchronized (which, again, even most computers do automatically these days) will cause them serious problems beyond TOTP.  Your resynchronization proposal is therefore probably not necessary.


DHCP Starvation Attack doesn't work in my virtual lab

Yersinia sends the DISCOVERY packet to exhaust the ip pool. The request packet is sent only after an offer is sent by the server. Here is a picture about how it works:

If you want more info about type of DHCP packets: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Operation

It is suppossed after a Discovery packet is sent, the server response is an offer and then Yersinia should send the request packet but it will only request the packet if the offer is received.

Possible troubleshooting and suggestions:

Try it on other different DHCP server to compare results.

Maybe there is a problem on your DHCP server.

It is supossed to be working. Maybe in other environment could be some kind of protection by the switch (Port Security, DHCP Snooping, Dynamic ARP inspection (DAI), etc). But you said you configured it on your NAT VirtualBox network so there is no protection at all.

Check your network settings, be pretty sure about you are well configured on the right network and check if everything is (virtually) connected as it is supposed to be.


ASP.NET Web Forms is not generating a new session ID if a user logs out and logs back in

We should make one thing clear before we move one:

Depending on the setup: Session IDs are not the same as session data

This doesn't mean it's safe, but it also doesn't mean it's unsafe.

Now let's work through the state machine of user sessions throughout the entire transaction and see what happens with the data in the session:

Session begins

Computer navigates to web service, gets session id=X and session data gets stored in DB as id = X, session_data = {"User": null, "IP_address":..., "Mac":..., "Other_device_specific_info":...}

User logs in

User logs in and session data in the database gets updated like UPDATE sessions SET session_data->user = Y WHERE id = X;. The session has been updated to reflect changes and permission changes, but the session ID doesn't need to be updated because it's the same machine, on the same visit.

User does stuff

User does some stuff and the session_data gets updated again, setting other values in it they want to track.

User logs out

Now the user logs out, and the session destroys the data, but keeps the id and makes a new fresh session with that same id because it's the same machine on the same visit and it now looks like id = X, session_data = {"User": null, "IP_address":...} which is identical to the original, non user session.

A different user logs in

Now a different user logs in and we do the same things again.

Eventually the person closes the window/tab

Since the session ID was ephemeral/times out eventually it will get destroyed, and then when that machine visits again it will have a new session ID.

As you can see, as long the back end has been designed correctly, using the same session ID isn't a problem at all. IT(both it and IT) would be a problem if the same session data was reused.

The Bad News

This all assumes that the session data, and id, are tracked correctly and the web service is not vulnerable because of the session ID being associated to the machine and not the user.

Realistically it should change at some point

Things to make sure of

Sessions are set up safely
Session flow makes sense
Session ID != Session data
Session data is stored securely

Extra information

Sessions are really more of a method and guidelines for storing state based information in some place
They can be setup infinitely many safe ways
They can be setup infinitely many unsafe ways
You're really trusting someone else to have done it right when you use their services, so there are no guarantees

Just because a session ID is linked to a machine and not a user, doesn't mean it's been setup wrong. It just means they're probably also tracking what users have used what machines, for how long for metric purposes.

Things to be aware of just in case

You should probably Google these terms just to make sure your setup is safe

Session Fixation
Replay Attacks
MITM attacks
Unsafe connections
Forever Sessions
Ephemeral Sessions
Cookie Session
Database Session
Redis Session
Stateless Web App


Using SSL-port (443) for non-SSL traffic, bad idea?

That doesn't sound terribly easy to me.  Clients (and I assume we're talking about browsers here) expect http traffic to be served over port 80, and https traffic over 443.  In order to change this to http over 443, that's going to require that you change your URL scheme to http, and then explicitly specify the port on each URL.

So, for an https URL like this:  https://example.com/some-resource you will have to change it to: http://example.com:443/some-resource.

It seems to me that if you want to remove the SSL requirement, it would be easier to leave http running on port 80 so the only change you have to make to your URLs would be to remove the s from the scheme.

If you're wondering if you can serve http traffic directly to a client that is making an https request, allowing you to leave the URL the same, no, that should not work.   The client is going to try to initiate a TLS handshake and when it doesn't get a TLS response, the connection will fail.


Using identifiers in URLs to authenticate users

If you can actually perform actions as the other user, it's called "really bad authentication". If it just takes you to their profile page, it's just a link - some systems will allow profile views even to unregistered users who have the appropriate link, even if it is normally restricted to logged in users.

Either way, be careful with experimenting in this way - following a link is probably fine, but modifying it can land you in trouble in some jurisdictions.


Is it still not advisable to use recent versions of EncFS >1.7 to encrypt Dropbox?

This depends on who you are trying to secure it against. The most common scenario is you want to prevent identity theft or/and keep information a secret from your room-mate or relative.

An identity thief will not be spending hours of his time cracking files of one individual considering slim chances of success and questionable outcome. That's way too much effort for them. Unless you are a multimillionaire which I doubt considering you are here :)

As long as you relatives are not security researchers they shouldn't be an issue.

However if you are a person of interest for FBI / NSA / CIA etc then I'd recommend solutions that provide plausible deniability in conjunction with a good lawyer :D


Client authentication vs. user authentication

The client is a network concept: the data is transported between two machines, the server and the client. The client is the one who initiates the conversation; the server is the one who is sitting all day, waiting for clients to connect.

The user is the biological entity (presumed human) who controls the client. Authentication is about the server making sure that whatever it receives originates from a specific user. However, the server is not talking to the user (the human being) but to the client (the user's computer). When a server authenticates the user by way of a stored HTTP cookie, it is really authenticating the client: since the cookie value was previously sent to a specific client, only that client may show the exact cookie value. The server then assumes that a given client is under exclusive control of its purported human owner, and then feels content that the human user has been involved.

The distinction between client and user becomes apparent when the user's machine is subverted (e.g. infected by malware). The machine will begin to do things outside of the control of the human user.

To make an analogy, if you have a dog and that dog bites me, then I will sue you, not the dog, because the dog is supposed to be under your control. Even if the dog contracts rabies (explaining its vindicative behaviour), it is still your responsibility. In that sense, authenticating the dog is as good as authenticating you (in the eyes of my lawyers, at least) and it is up to you to make sure that your dog is really under your exclusive control.

With Web applications and "API", the picture can become more complex, because the server can also behave as a client with regards to another server. That secondary server may want to make sure of the identity of either the first server, or the human user who initiated the whole process, or both. The terminology can be source of confusion if the same terms are reused.

When using public/private key pairs, the private key owner (the machine which contains the private key) uses it to perform some computation which links to another computation which involves the public key. For instance, with digital signatures, the private key owner generates a signature over a given message (a sequence of bytes); the signature can be verified by using the public key. Digital signatures are a good tool for authentication: by computing a signature on a challenge sent by a verifier, the private key owner demonstrates to that verifier its mastery of the private key. The verifier thus obtains a guarantee that it is really talking to "whoever controls the private key corresponding to a given public key". The interesting part of the process is that the verifier needs not know the private key for that, so it is possible to verify a signature without having the power to generate signatures.


Why would an organization like the DoD prefer to use its own Root Certificate(s)?

They do rely on generally available CA root certs for sites that are expected to be generally avaiable to the public over HTTPS.  See https://www.army.mil for one prominent example.

However, the DoD has a significant internal CA infrastructure and they perfer to leverage that instead for sites that either aren't intended to be served over HTTPS at all (like your https://mrmc.amedd.army.mil/ example, where HTTPS requests are simply 30x'ed back to http) or sites that are designed for internal use by folks on DoD equipment like http://www.dau.mil (which requires a CAC [DoD-issued smartcard] for authentication as well) or http://www.forge.mil/.


Fake lock screen in full screen browser window

It's pretty common already for malware to inject fake popups asking for a password so this seems like a valid variation of that attack path but isn't really related to the lock screen at all.

See this example in metasploit.


Can my ISP see what sites I visit if I use a private DNS provider?

Yes, your ISP can see what websites you are visiting. They can do this whether the sites are using HTTPS or not. They can do this whether you use their DNS servers or not. And they can link these to a specific account. Basically, your data is going over their network, and they need to route it to the correct location. All an alternative DNS provider offers is a different lookup between a domain name and an IP address - the IP data still goes through your ISP, along with your request headers, which have to include the domain name (although no specific URLs).

They can't do it if you use a VPN or TOR - both of these would show as a single connection to a different computer. They could still see how much data you were sending and receiving, although there are ways to hide that too. However, the VPN provider would be able to see what sites you were connecting to, as would a TOR exit node provider. In the case of a VPN provider, this might be linked to a specific account, or source IP, in a way that could be tracked - you have to trust them. In the case of TOR, the exit node shouldn't be able to link data back to a specific source IP.


Why are some cookies/data changes (e.g. via Burp) persistent and some are not?

I stumbled upon this answer from stack exchange regarding why some cookies can be altered and some cannot.

Some are "signed" cookies. They use a hash and other information to prevent tampering.

https://stackoverflow.com/questions/11897965/what-are-signed-cookies-in-connect-expressjs#11898142


Is it safe to run a flask server in a development environment?

My understanding is Flask is not recommended for production because of stability rather than security. With WSGI or Gunicorn, you can utilize multi-thread/multi-proc more effectively, and serve multiple requests simultaneously.

If you're a beginner it can be daunting to go from Flask to WSGI (Gunicorn is slightly easier, but still has a learning curve). If this is just for a few hours to demo something to your class -- I'd say just go for exposing Flask, with the following caveats.

Ensure the port you're exposing to the internet is sufficiently
random (don't use 80 or 8080), try something like 48982, or 13892,
etc -- this reduces your attack probability immensely :)
Don't run flask as a root user, preferably create a scoped down user, that only has access to the files you wish to expose

Hope that helps.


is deleted data immediately overwritten with new data in hard drives

In general, no, you cannot expect recently deleted hard drive blocks to be the first used for writing new data.

In the case of traditional platter disks, the performance read/write for individual files is affected by where (physically) on the platters the data is written.  Some operating systems, and some utilities, will choose where to write data based on complex optimization algorithms (often during Defragmentation).  So there are factors other than "what got recently freed up" that go into deciding where to write data.

With newer SSD drives, the problem gets even worse - the hardware controller on the drive itself does the same thing, choosing write locations according to algorithms designed to maximize coverage and minimize rewrites.  As a result, you can't even be guaranteed to overwrite the entire disk by filling the disk - you must use ATA Secure Erase to clear the data.

If you're concerned about deleted files being recovered, you need to be proactive:

Use a secure file wipe program on files instead of deleting them - shred, sdelete, PGP wipe, etc.
Use whole disk encryption; that way, if the disk is swiped, an attacker can't simply pull (plaintext) raw disk blocks off the drive.
If on a platter disk, wipe slack space on a disk (e.g, Windows cipher /w:c:) regularly


How to tunnel all network communication?

You can indeed use tun/tap tunneling. The easiest way I know of to do so is using OpenVPN. There are graphical clients for that for most OSs.

If you use 'tap' tunneling, your laptop will show up on the remote LAN, since layer 2 network traffic is also sent through the tunnel. Using 'tun' tunneling however, which occurs at layer 3, only your IP traffic is routed to the remote LAN.


That section of the RFC also states:

  The value handshake_messages includes all handshake messages starting
  at ClientHello up to, but not including, this Finished message.  This
  may be different from handshake_messages in Section 7.4.8 because it
  would include the CertificateVerify message (if sent).  Also, the
  handshake_messages for the Finished message sent by the client will
  be different from that for the Finished message sent by the server,
  because the one that is sent second will include the prior one.

The client sends its Finished message first, and then the server sends its message, including the previous Finished message from the client.

  But won't be the hash too long ?

A cryptographic hashing algorithm always outputs hashes of the same length. Adding more length to the input does not increase the output length.


With SSL Bump, Squid runs a Man-in-the-Middle attack between the client and the server; it poses as a fake server with a fake certificate when talking to the client, and as a fake client when talking to the true SSL server. Squid thus obtains all the data. If you want to see what Squid sees, then it seems that the best option would be to simply ask Squid to send you a copy. Apparently, this is at least theoretically feasible through the ICAP feature: it is a way for Squid to do just that. Antivirus software links to Squid through ICAP, and inspect both the HTTP message contents and the headers.

Otherwise, if you do not have the help of Squid, then you must understand what occurs at the SSL level. In particular, tools ssldump can decrypt captured SSL traffic only if the following conditions are all true:

The decrypting tool is given a copy of the server private key.
The decrypting tool supports the cryptographic algorithms used for the connection.
The cipher suite selected by the server (based upon what the client supports and prefers) uses an RSA-based key exchange. With "DHE" cipher suites, the actual key exchange uses ephemeral Diffie-Hellman keys, and the server private key is used only for signatures; having a copy of that private key would not help here.

In your case, there are two SSL connections, one between the client and Squid, the other between Squid and the genuine server. If you have a copy of the server key, then you can concentrate on the latter, and forget everything about SSL Bump and Squid. However, in a more general case, as the sysadmin of Squid you control Squid, not the target server.

With SSL Bump, Squid generates a fake server certificate when talking to the client. If you can get a copy of the private key for that fake certificate, then you should be able to apply ssldump on the client-to-Squid connection. As described here, the tool that Squid uses to generate fake certificates is configurable, so you could use your own, which generates the certificate (e.g. with OpenSSL) and records the private key somewhere, so that a captured trace can be decrypted later on.

For the cipher suite, this seems to be doable with the Squid https_port directive, which accepts a "cipher=" parameter. As said here, the value of that parameter is passed directly to the underlying SSL library that Squid uses, and that's OpenSSL.

See also this forum thread where someone is apparently trying to do the same thing as you.


There is a program called dir-buster developed by the OWASP project which i believe will do exactly what you want, to brute-force file and folder names
To quote the site:

DirBuster is a multi threaded java application designed to brute force
directories and files names on web/application servers. Often is the
case now of what looks like a web server in a state of default
installation is actually not, and has pages and applications hidden
within. DirBuster attempts to find these.

And you should be aware that:

Tools of this nature are often as only good as the directory and file list they come with.
Just make sure that you've updated this list with any data you can to assist it in finding these folders.

Hope that helps answer your question!


Assuming UAC is enabled, does a non-administrator account offer any security improvements?

The DFIR Blog has a great summary of UAC

In the article, the author recommends the Always Notify approach, especially for administrators and critical servers. Besides social-engineering attacks such as the exploits/windows/local/ask module in the metasploit-framework, there are also tens of UAC bypasses. The author covers the techniques and tools to bypass UAC better than most.

The author does not make mention to, and I do not know of a tool or technique to bypass Always Notify -- however, escalation of privilege -- especially to the SYSTEM account -- may be possible through a privilege-escalation exploit and/or a misconfiguration issue (although any-given privesc exploit must not require administrator privileges, which is not necessarily rare, but a condition that must exist for some exploits to work). Misconfigurations typically include UNC path and/or file/folder/service permission issues. Typically, these privilege escalation techniques require an advanced understanding of the Windows environment that even most NT administrators do not posses, however, again, some are available in the metasploit-framework and other exploitation engines (or bundled with exploit kits) -- thus lowering the barrier to entry to anyone with adversarial intent. Other times, admins or admin tools simply leave password in cleartext (or an easily-reversible format) in files on the operating system, on a sticky note, or other lowered-care OPSEC.

Most end users will revolt against Always Notify, but perhaps not the next-lower setting, the medium-integrity process (which many UAC-bypass techniques work against).

As for local or domain administrator accounts for end user machines, it's very bad practice, as users can simply right click any executable and choose "Run As Administrator" to elevate privileges and destroy the power of UAC (N.B., this can also be done via cmd.exe if a separate admin account password is known by any end user). A lot of malware, especially persistence techniques, rely on administrator access (e.g., for Windows service installation). If UAC must be set to something lower than Always Notify, the best strategy is to also disallow any administrator access (privileged access) and provide additional protections against end-user app installation. My favorite platform for Privileged Identity Management is STEALTHbits and this can be combined with BeyondTrust and other privilege-management solutions.

As an additional protection for non-administrator accounts, the permissions on the user-specific AppData\LocalLow folders also allow malware to activate and persist. Another one to look out for is that some orgs will set the AlwaysInstallElevated registry key to allow non-admins to install applications. However, MSI's elevated privileges can be abused and there is even a metasploit-framework module to do so (i.e., exploits/windows/local/always_install_elevated).

Another distinction to make is for elevation prompts (apps can be written to automatically prompt, but UAC behavior can override/preempt this capability). The book Least Privilege Security for Windows 7, Vista and XP covers this and says:

  Microsoft recommends that in corporate environments, system administrators should configure UAC to automatically deny elevation requests using the User Account Control: Behavior of the elevation prompt for standard users local or Group Policy setting. This ensures that malware can't intercept an elevation prompt and harvest the credentials of an admin account.


What you are describing is multi-factor authentication, the first factor being the proximity of the 2 devices. Therefore it does not violate established principles, but rather is becoming standard practice rather than as a response to a high profile attack. The devices involved need to know that the communication is being performed when only the user wants it to be, and that they are indeed the devices they say they are. This is achieved through secure protocols and methods to detect legitimate user interaction.

Proximity can be faked on some devices with improperly designed protocols through relay, the most public being those on keyfobs (signal amplification) and garage door openers (jam/steal 2 and replay 1st, storing 2nd for later).

Adding a second factor is not difficult, it is usually a matter of cost. The jam/steal attacks jam the signal from the transmitter to the device while making a copy, twice, then sends the first signal to the device activating it. The second copy is then used to activate the device under the attacker's control. This bypasses both rolling code transmitters and those with cryptographically enhanced incrementing counters. A synchronized time code on both devices and as part of the code generally defeats this attack. Synchronizing a timecode and keeping it that way requires high accuracy (and expensive) clocks on both devices, more power, and additional user effort.

A time code however does not usually help with a signal amplification attack. A better way to detect the proximity helps, such as an accurate measurement of the time it takes to process the device handshake, in order to estimate the distance. An excessive response time may indicate an active attack. My father's 20 year old Mercedes Benz had an IR transmitter on the keyfob in addition to RF, so the car could make sure they keyfob was pointed towards it and not being pressed in a pocket by accident. It also unlocked the specific door (or trunk) at which it was pointed, to prevent someone from sneaking into the car through one of the other doors. This also prevented RF only relay attacks, increasing an attackers equipment cost and effort.

Additional methods to detect legitimate user interaction include time-fencing (as you suggested), geo-fencing, hand detection (using capacitive touch), gesture sensing, temperature sensing (to detect attacks that modify speed of clocks and processors)

A more optimal device protocol would include cryptographically authenticated handshakes with large keys, timecodes, counters, and receipt response of messages. This type of protocol uses large amounts of power for an embedded device, so better power efficiency and higher capacity batteries are required before something like this can be adopted on a large scale. Implementing it on a phone is easy, but not so on ultra low-power devices (BTLE, IOT, smartcards, etc). At least not at the moment, but efficiency is constantly increasing.

The cost of implementation must be weighted against the effort of a successful attack during the lifetime of the device, and against the possible costs from such an attack, in the form of bad PR, lawsuits, etc.

I failed to keep this short and went a little off topic, hopefully all the information should be relevant to the question.

Here is a basic protocol I use for IRC services control, it is short and simple, and can be applied to many use scenarios.

A: Hello B, I am A, I would like you to do X

A: B + A + H_1 + X + T_A + C_A + MAC_A(msg)

B: Hello A, you are authorized for X

B: A + B + H_2 + X + T_B + C_B + MAC_B(msg + Z_A)

A: Thanks B, please do X now, over

A: B + A + H_3 + X + T_A + C_A + MAC_A(msg + Z_B)

B: Ok A, I will do X now, over and out

B: A + B + H_4 + X + T_B + C_B + MAC_B(msg + Z_A)

Where A and B are serial numbers or device identifiers, C_x is an incrementing counter specific to device x, T_x is the current timecode of device x, H_x is an identifier for part x of the handshake, and Z_x is the last MAC response of device x. The messages are encrypted and authenticated with large preshared keys, but for something like a keyfob or garage door opener only the authentication is necessary.


Is the entire ciphertext needed for decryption with key?

First, regarding the encryption algorithm, there are two general types of algorithms, blocks and chains. A block algorithm applies the key to each block of data (e.g. 256 bit blocks), while a chained algorithm uses the previous block to decode the current block, with the key serving as the first block in the chain. For the block algorithm, you can decrypt every block that you have access to. The chain algorithm, however, will not be able to go any further than the first missing block, so if the 60% of the data you have doesn't include the first block, it's not possible to decrypt any of the the data, even with the key.

Next, once you get whatever data you get back, what you can process depends on the file format. For a plain text file, you can read whatever parts you were able to decode. More complicated file formats may or may not be readable. For example, GIF will break as soon as you have a byte you can't decode correctly, while formats like JPEG and MP4 are generally recoverable except for the missing frames, and ZIP can usually recover files as long as the files and some critical data structures are present.

So, there's really three possible outcomes: you can't decrypt the data at all, you can decrypt the data but can't parse it at all, or you can decrypt the data and recover useful information. It really depends on the encryption's algorithm and the payload contained in the data.


Should I shred documents with only name and address details?

You asked: Will shredding documents that only have my name and address details on them protect me against identity theft, or offer any other information security benefit? The bigger question which cannot be truly answered is: "If in the event of identity theft, was it due to you not shredding documents?"

Most of the times when it's time for me to dispose of personal documents, I have not gone as far as shredding, but instead either ripping out that portion of data (names, account #'s, etc) ripping that into little pieces, and disposing of it in entirely different trash bags/bins.

When it comes to dumpster diving, this has mainly been an issue of attackers targeting companies moreso than individuals, however many private investigators do perform dumpster diving, and I am sure there are individuals with malicious intent, doing the same thing. The initial question is: "What can someone do with this information!?" A lot.

Consider the American Postal System. There is a form one can fill out to notify the postman that they have moved to another address. The USPS usually begins sending mail to this location after about 10 days. This is a blessing when one is moving, but a curse to ALL AMERICANS. Fact: If you submit the form in person, you need to show ID (Good). Fact: If you fill out the form and mail it in, the USPS automatically starts forwarding your mail without validating you requested the change of address. (Try it if you'd like, complete a change of address to say your parents home, and mail it)

So, as an attacker, if I targeted you, I don't necessarily need to dumpster dive. Why would I when I can forward all of your mail. Imagine doing something like this to coincide with the last week, and first week of the month (usually when bills arrive). I'd receive your mail, to which I can gather data to escalate an attack without ever touching your garbage can.

There are other methods to obtain your data, it all depends on the skill of the person targeting you, and the level of data they want to get, and why. Think about it, you would have to be targeted for someone to pull this off otherwise, if I am random attacker going this route (dumpster diving), I am going to target big money. Dumpster diving in Alpine NJ, or Beverly Hills.