Does only having one end of a wifi connection patched reduce the risks from KRACK?

TL;TR: It is often (but not always) enough to properly patch the WiFi client. You need to patch the AP to if it provides client functionality (i.e. router) or has fast roaming (802.11r) enabled.

From my understanding it is essential for all the attacks that the client accepts message 3 of the 4-way handshake again and then reinstalls the same encryption key and resets nonce and replay protection.
This means if the client is patched to not accept a message 3 which contains the same key as already installed it will not reinstall the key and not reset nonce and replay protection. This should be sufficient to thwart the attack, no matter if the server is patched or not.

Also, directly taken from the https://www.krackattacks.com:

  What if there are no security updates for my router?

  Our main attack is against the 4-way handshake, and does not exploit
  access points, but instead targets clients. So it might be that your
  router does not require security updates. We strongly advise you to
  contact your vendor for more details. In general though, you can try
  to mitigate attacks against routers and access points by disabling
  client functionality (which is for example used in repeater modes) and
  disabling 802.11r (fast roaming). For ordinary home users, your
  priority should be updating clients such as laptops and smartphones.

Note that you could in theory also patch the AP to not retransmit message 3 of the handshake in case it did not receive message 4. This can be helpful in cases where patching the client is impossible.


Is possible to deliver a dos attack increasing a database table?

Of course. Depending on how the database is configured to handle growth. The database can grow to fill an entire disk or partition, for instance, and that can crash the database, the service, or the entire server.


I find where is the problem, it's the web delivery module of metasploit.
I think that IPS are triggering some HTTP headers of this module.
I bypassed the problem by using multi handler module combine whith a usal apache2 server and it's work! ( you don't need to follow paranoid steps)

If some one know what IPS is exactly triggering and how we can bypass it using web delivery module. Please inform me.

Thanks to all


Minimum acceptable CIS compliance percentage?

I think there is no precise threshold for the CIS compliance. In my company we had to go through this server hardening process. What we did, we addressed all the failed ones. If company policy/standard allowed us to change the config as CIS recommended we did that, otherwise we mentioned the compensating controls against that or treated it as accepted risk. Its is not feasible to comply with all the listed requirements of CIS but failed ones should be appropriately addressed.


Should I obfuscate/disguise (file) names in certificate exams?

The OSCP certification is not about criminal activity. You're excepted to write a detailed report explaining exactly what you did. Hence there is no need to hide anything. If you are sneaky and cause backdoors to be left behind on pentests or red team engagements you are actively lowering the security posture of the systems you are testing which is bad.


Reason for not implementing own algorithms/implementations

No, it doesn't matter. Every algorithm we use today was implemented by someone and then became a standard. The reason why it's not used as a practice is:

Security. A new method of hashing/encrypting/whatever needs a lot of time in order to be tested thoroughly, or even be further developed. It's not safe to launch something new in an instance if you cannot prove its safety against cryptanalysis.
Compatibility. Suppose you are a company owning credit/debit information and you co-operate with bank systems or governance infrastructures through DMZ's and other sort of mechanisms like this. Your way of hashing/encrypting/whatever information is totally different than the one used by the rest of the world, thus making information exchange very difficult when/where needed.

There are a lot of awesome, new, fast and impenetrable algorithms out there, developed by companies, organizations, PhD's, hoping they will become a standard one day. But since all of our infrastructures today are based in things that are proven to work, going the other way is a risk you take on your back, all by yourself.


On Check Point firewall (R77), in the Topology config. section that is
  used for anti-spoofing, is it possible to configure 2 different
  External interfaces ?

It is possible - for example, this document on ISP Redundancy in R77 clearly describes that case:

  If the Security Gateway has two external interfaces in the Topology
  page of the gateway object, you can configure the links automatically.

And this snippet of a CCSA Exam Cram states:

  You can have multiple interfaces defined as external.

  ...In [this] case, the same behavior of calculating external topology
  applies to all externally defined interfaces—that is, any network not
  included on any of the internal interfaces is valid on all external
  interfaces.

However, there may be complications.  For example, there's a specific setting to make it break less stuff: "Support connectivity enhancement for gateways with multiple external addresses".  To quote a portion of it:

  The problem is that the VPN-1 Gateway needs a routing mechanism that
  can route packets, returned to the Office Mode IP addresses, to the
  appropriate external router when the VPN-1 Gateway has two external
  interfaces, based on from which VPN-1 Gateway external IP address the
  SecureClient Office Mode connections came.

  The option "Support connectivity enhancement for gateways with
  multiple external interfaces" addresses this specific need.

There also used to be an issue where an Unlimited license was required for traffic to route across the two external interfaces.  That thread's 10 years old now, though, so take that with a grain of salt.

I haven't had significant CheckPoint console time for 10 years myself, but my recollection is that when I was working with it, I worked a few implementations that had multiple external interfaces, without any particular problems*.

*...due to the multiple interfaces.


OS X 10.6 and known unpatched vulnerabilities

There have been several really big issues like heartbleed (probably only relevant to servers). Try to find some and see what you can do.

Then there is Safari. If users are smart, they install Chrome or Firefox to get updates. But Chrome doesn't support 10.6 anymore.

Anyway, if users use Safari, they are not safe. Think of TLS problems with old certificates.


How to restrict access to the internet for some computers on the network?

you need to start using VLANs and turn off inter vlan routing.

using VLANs you will be able to create multiple LANs within a single network but all of them be independant, all traffic from your router at the moment is most likely tagged as VLAN 1 (even though you do not know it).

you can also use VPN traffic, create VPN access on the network and anyone with the VPN credentials can get through the firewall.

Anything using MacAddress or IP address is pointless, you might as well do nothing.

I would need more details but you can have to WIFI access points in your office, one on a vlan 20 for example... all vlan 20 traffic will be locked down by the fire wall.

There are so many possibilities but VLANs AND/OR VPNs are your best bet.

Trust me I am a network engineer! (so much information I struggle to type ask me more specific questions for more specific answers)


What protections are put in place to prevent ACH scams?

Currently, the only way to protect against ACH are detective controls which should be in place at the business and the bank. Most fraud gets detected after accounts get reconciled or after a customer complains that his account was used without authorization. In case of a bank, if a company only uses it for payroll payments and those payments occur once a month, transactions occuring outside the normal period should be looked into.

Consumers need to alert their institution within 60 days in order to recover funds. Businesses, however, only have as little as one business day. Therefore, monitoring becomes critical. Daily review of the credits and debits of the business is essential in detecting fraudulent activity.

Companies using ACH set up accounts that would either only accept ACH credits or issue them. As ACH expanded past the payroll, social security payment or repetitive bill-pay solution, moving into mainstream transactions, the direct relations were lost between the two parties and this opened a gate for fraud.

Common fraud schemes against the banks include setting up fake companies, getting on the ACH network, issuing lots of transactions to a single account and then emptying that account, leaving the bank behind with the losses. This is called ACH kiting.

Then there's also typical fraud where an attacker gets access to a company's network and just adds transactions in the transaction  file or just executes transactions on behalf of the company.

Note that ACH was never designed to fullfil the task it's currently used for.


Which parts of a credit card can I obfuscate and still have it be valid

If you deface a credit card, you are likely to find it will be rejected for all transactions. The merchant really needs all the info on the card to be valid - it's part of how they protect themselves from fraud.

So my answer would be: none!

Instead of worrying about that, concern yourself more with how the merchants handle your card. In the UK, for example, a customer never needs to let go of the card in most stores now, as contactless is almost ubiquitous. But if you have to hand over your card, watch it like a hawk. Handheld terminals brought to you are safer than letting someone take your card away.

And remember, if the merchant commits fraud, your bank will reimburse you so it's not the end of the world.


Does an unencrypted disk pose a risk to other encrypted disk's data?

You should be safe if the configuration of the system is correct.

General cache, dump files, hibernation, etc should only be configured to be created on the OS drive.

In such a case there's no cache to be done in your gaming drive. Additionally, most games today drop their save-games in local user folders, not the game folder, so not even that would be a risk. Some log files may be created by games (crash logs, parsers, etc) on the games drive, but that does not contain information stored on the other 2 drives.


During the POST, the BIOS traditionally performs a "memory test" which entails writing to and rereading the whole of the physical RAM. However, this process can take a non-negligible amount of time, and is rather bad at detecting bad memory (it reliably detects only very bad memory) so it is disabled in many cases (by the computer vendor, or the user). Thus, one must assume that scraps of the RAM contents prior to the last boot may still linger; how much data thus remains depends on the RAM technology, the power down time before the new boot, and the temperature.

The Linux kernel, like most other modern operating systems (including Windows, excluding the Windows from the "95" line), zeroes out the RAM pages before handing them to applications. Thus, while physical RAM contents might contain interesting remnants of past data, this is accessible only to kernel code; userland only sees zeros.


You should consider what you are trying to accomplish by storing each particular part in some specific location, and then proceed accordingly.

The password database file itself is important but not sensitive, particularly because it is encrypted. In the ideal case, having access to that file does not gain you any particular abilities. It changes often, and thus needs to be backed up regularly; as such, it should be included in your regular backups.

The key file is sensitive as well as important. Without it, the password database file is meaningless, as the key file effectively forms a part of the master passphrase used to unlock the password database. However, it changes very rarely, and can for all intents and purposes be considered static, so doesn't need to be backed up on a particularly regular basis.

The passphrase as entered by the user is sensitive and important, for the same reasons that apply to the key file. It's also not stored on a computer, but rather (hopefully) exclusively in the user's brain. The user can change it if they want to, but they are responsible for making sure that they remember it.

Only all three parts together are actually meaningful. You can't do anything with any one of these without the other two, and you would be hard pressed to do much of anything with any two of these without the third.

It's a bad idea to keep the key file in the same location as the password database, unless of course the password database master password is sufficiently strong that it alone provides good protection against an attacker and the key file is really only icing on the cake. From what you say about using "a simple password", this does not appear to be the case in your situation.

Hence, we can conclude that in your scenario, most of the security is in the key file, which is slightly augmented by the master passphrase. Thus, the key file must be protected to high standards.

Given this, I would probably do pretty much the opposite of what you propose:

Store the password database on the local host, or possibly on a central server. Set up file system and (if applicable) network share ACLs to restrict access to each password database to its owner. Make sure it is included in regular backups.
Store the key file on a central server. Set up file system and (if applicable) network share ACLs to restrict access to each key file to its owner. Make sure it is not included in regular backups. Consider setting up audit logging for both successful and failed access attempts.
Set as high a passphrase key derivation iteration count as your users will tolerate. Aim for several seconds on the client machines, if that is acceptable. Keep in mind that a serious attacker will likely use passphrase hashing implementations that are far more optimized.
Keep backup copies of the key files somewhere. Individual, sealed envelopes in a bank safety deposit box, maybe? (In this case, the bank would keep a separate audit log which can likely be called upon in case of suspicion of unauthorized access. They won't be able to tell you what a person did, but they should be able to tell you who had access.)

This isn't perfect, mainly because the protection offered by what only the owner of the password database has access to (the master password) is so weak. But if your users can't be bothered to use secure master passphrases, it's probably about the best you can do.

Of course, you need some mechanism for handling scenarios where people get run over by a bus. That, however, is outside of the scope of an individual password manager, and is something you need regardless, so I won't discuss that further here.


Protecting data is part of information security. It falls directly under:

confidentiality
integrity
availability

In your case, replication is probably more aimed at availability. In this particular case it would depend how people define secure and protection in terms of data. So in my opinion, if you get such a question, also include your understanding of what security is and protection is.


Is there a way to use VirusTotal.com offline?

You could have a Virtual Machine set up, and buy subscriptions to/download the free versions of all the anti-virus engines you like (for instance, the list VirusTotal has), install them one at a time (making sure to turn off all the automatic features except updating - no on-line scanning, no email integration, no Web Toolbar, no SafeSearch, no URL checking, etc. etc.).

Then you could copy a file to the VM or use shared storage or whatever and scan it with every engine.  The more advanced method, of course, is to automate the scans with each engine - either a batch file, or a program that calls each of them one at a time and reports the results.

You can then bring the VM online and update them all whenever you can/need to; again, automating that will help keep your workload down.  You can also take snapshots of the VM and be able to go back to previous version to see if a particular piece of malware was detected differently some time ago; i.e. to track the change in detection, though that's a bit cumbersome and snapshots will slow down performance and use drive space.


Is (WEP) shared key authentication secure?

The part of WEP you describe isn't really a major weakness because most encryption algorithms in use today are immune to known-plaintext attacks.  Basically, this means that having access to both the encrypted data and the decrypted plaintext will not help you figure out the key in any way - so "figuring out the password from here" would NOT be straightforward.  And since the challenge is different every time, an attacker cannot simply replay a previous solution to the router.

The main weakness of WEP is that to encrypt, it XORs the bits of network traffic with a generated keystream.  This isn't inherently bad, but the same keystream cannot be used twice with this system - and in WEP, the keystream generation process is flawed.  The keystream is generated from a random IV (sent to clients in plaintext) and the network key (the password you type into your computer to connect). The network key is the same every time, of course, so if two packets use the same IV, the keystream will also be the same.  With only 16 million possible IVs, an attacker can easily capture two packets that share an IV on a busy network, making it easy to work out the keystream and then the key.


What's the impact of disclosing the front-face of a credit or debit card?

You don't actually need the CVV to perform transactions, they're just required by most retailers as a means of verifying that you have the physical card in your possession.

From Wikipedia (unsourced):

  It is not mandatory for a merchant to require the security code for making a transaction, hence the card is still prone to fraud even if only its number is known to phishers.

On most EFTPOS systems, it's possible to manually enter the card details. When a field is not present, the operator simply presses enter to skip, which is common with cards that don't carry a start date. On these systems, it is trivial to charge a card without the CVV. When I worked in retail, we would frequently do this when the chip on a card wasn't working and the CVV had rubbed off. In such cases, all that was needed was the card number and expiry date, with a signature on the receipt for verification.


"WICKED" entries in the default nginx vhost's logs

The last two fields by default are the referrer and user agent fields (nginx reference). Normally you'd see something there like a browser (Mozilla), search bot (Googlebot), command line program ("Wget", "curl") etc. there. Whoever is running something against your server is using "WICKED" as a user agent string.


Postfix + MySQL ENCRYPT() encryption method change

i having the same problems. In my case, still use ECRYPT as a method. So, to resolve changes in this way:

$config['password_query'] = 'UPDATE mail.users SET password=ENCRYPT(%p) WHERE email=%u LIMIT 1';

I apologize for the spelling, but I am Brazilian and I need to translate on google translator.


Am I exposing my application to IP address forgery / ip spoofing?

As you have said other, presumably untrusted, computers are on the same network, your concerns are justified. Any of the other machines on the same network could set their IP address to that of server_a and send a request to server_b.

I would suggest using client certificates and server certificates within your ssl configuration see https://www.scriptjunkie.us/2013/11/adding-easy-ssl-client-authentication-to-any-webapp/ for some started tips on why and how to use client certificates. Note some of the aforementioned article does not apply as you are authenticating servers not client to server.


For a low cost, hacked up solution, I'd look at tracking something that someone would be loath to share with someone else or be without. For that, I'd look at their phones.

A simple WiFi access point that registers the MACs and IDs of devices on the network would work in your case, but it also has flaws. MACs and IDs can be modified, but it takes a little technical knowhow. You would also have to register/reregister the devices over time. Stores are starting to use this technique in order to track shoppers, so there is existing thought and technology surrounding this.

Other than that, you might have to look at the old-fashioned method: greet your workers.


Which is the Best Cipher Mode and Padding Mode for AES Encryption?

"Best" is rather subjective - it depends on your requirements. That said, I'll give you a general overview of each mode.

ECB - Electronic Code Book. This mode is the simplest, and transforms each block separately. It just needs a key and some data, with no added extras. Unfortunately it sucks - for a start, identical plaintext blocks get encrypted into identical ciphertext blocks when encrypted with the same key. Wikipedia's article has a great graphic representation of this failure.

Good points: Very simple, encryption and decryption can be run in parallel.

Bad points: Horribly insecure.

CBC - Cipher Block Chianing. This mode is very common, and is considered to be reasonably secure. Each block of plaintext is xor'ed with the previous block of ciphertext before being transformed, ensuring that identical plaintext blocks don't result in identical ciphertext blocks when in sequence. For the first block of plaintext (which doesn't have a preceding block) we use an initialisation vector instead. This value should be unique per message per key, to ensure that identical messages don't result in identical ciphertexts. CBC is used in many of the SSL/TLS cipher suites.

Unfortunately, there are attacks against CBC when it is not implemented alongside a set of strong integrity and authenticity checks. One property it has is block-level malleability, which means that an attacker can alter the plaintext of the message in a meaningful way without knowing the key, if he can mess with the ciphertext. As such, implementations usually include a HMAC-based authenticity record. This is a tricky subject though, because even the order in which you perform the HMAC and encryption can lead to problems - look up "MAC then encrypt" for gory details on the subject.

Good points: Secure when used properly, parallel decryption.

Bad points: No parallel encryption, susceptible to malleability attacks when authenticity checks are bad / missing. But when done right, it's very good.

OFB - Output Feedback. In this mode you essentially create a stream cipher. The IV (a unique, random value) is encrypted to form the first block of keystream, then that output is xor'ed with the plaintext to form the ciphertext. To get the next block of keystream the previous block of keystream is encrypted again, with the same key. This is repeated until enough keystream is generated for the entire length of the message. This is fine in theory, but in practice there are questions about its safety. Block transforms are designed to be secure when performed once, but there is no guarantee that E(E(m,k),k) is secure for every independently secure block cipher - there may be strange interactions between internal primitives that haven't been studied properly. If implemented in a way that provides partial block feedback (i.e. only part of the previous block is bought forward, with some static or weakly random value for the other half) then other problems emerge, such as a short key stream cycle. In general you should avoid OFB.

Good points: Keystream can be computed in advance, fast hardware implementations available

Bad points: Security model is questionable, some configurations lead to short keystream cycles

CFB - Cipher Feedback. Another stream cipher mode, quite similar to CBC performed backwards. Its major advantage is that you only need the encryption transform, not the decryption transform, which saves space when writing code for small devices. It's a bit of an oddball and I don't see it mentioned frequently.

Good points: Small footprint, parallel decryption.

Bad points: Not commonly implemented or used.

CTR - Counter Mode. This essentially involves encrypting a sequence of incrementing numbers prefixed with a nonce (number used once) to produce a keystream, and again is a stream cipher mode. This mode does away with the problems of repeatedly running transforms over each other, like we saw in OFB mode. It's generally considered a good mode.

Good points: Secure when done right, parallel encryption and decryption.

Bad points: Not many. Some question the security of the "related plaintext" model but it's generally considered to be safe.

Padding modes can be tricky, but in general I would always suggest PKCS#7 padding, which involves adding bytes that each represent the length of the padding, e.g. 04 04 04 04 for four padding bytes, or 03 03 03 for three. The benefit over some other padding mechanisms is that it's easy to tell if the padding is corrupted - the longer the padding, the higher the chance of random data corruption, but it also increases the number of copies of the padding length you have. It's also trivial to validate and remove, with no real chance of broken padding somehow validating as correct.

In general, stick with CBC or CTR, with PKCS#7 where necessary (you don't need padding on stream cipher modes) and use an authenticity check (HMAC-SHA256 for example) on the ciphertext. Both CBC and CTR come recommended by Niels Ferguson and Bruce Schneier, both of whom are respected cryptographers.

That being said, there are new modes! EAX and GCM have recently been given a lot of attention. GCM was put into the TLS 1.2 suite and fixes a lot of problems that existed in CBC and stream ciphers. The primary benefit is that both are authenticated modes, in that they build the authenticity checks into the cipher mode itself, rather than having to apply one separately. This fixes some problems with padding oracle attacks and various other trickery. These modes aren't quite as simple to explain (let alone implement) but they are considered to be very strong.


Invalid CSR when using Let's Encrypt web tools

I needed to remove "New" from the text

  -----BEGIN NEW CERTIFICATE REQUEST-----

and

  -----END NEW CERTIFICATE REQUEST-----

The second of the tools was using a Regex which wasn't looking for that word.


It sounds like you're mixing scopes a bit. Angular is a front-end technology, and while you can escape HTML to prevent XSS attacks, any basic templating language can handle that.

When you think about security in a web app, you have to remember that the end user is free to run whatever code they want on the front end, and they can hit your APIs in custom ways you didn't intend. In that sense, the real concern is really around your backend tech and how consciously your app's APIs are written. The front end isn't nearly as large of a concern because the user can do whatever they want anyway.


The SSL handshake includes random data from both client and server. While the attacker might replay the ClientHello which includes only the random data from the client he cannot complete the full handshake by just replaying previously captured data since the messages needed for completion also depend on the server side random data, which will change with each new handshake.


Why do DNSKEY have a RRSIG for themselves?

The RRSIG record is the proof that a certain RRset was published by the holder of a certain key.

When the parent entity publishes a DS record in the parent zone it is basically saying "we have received proof that the entity to which we have done this delegation is also in possession of the key with the hash that we published in our DS record" (kind of a recursive statement but I hope you get it).

This hash must match the DNSKEY found in the child zone for DNSSEC to validate. One might say that a match at this stage would be proof enough that the delegation is valid. But by signing the actual DNSKEY RRset you can also be sure that the data within the DNSKEY response is actually coming from the holder of the key matching the DS record.

Without the signature the DNSKEY data could actually be malicious. I can't really come up with a attack at this point but better to be safe than sorry I guess?


Is Bluetooth 4.0 traffic encrypted by default/design?

I read now a bit in the specification - Volume 3, Part H, Section 3.5.1 Pairing Request and 3.5.2 Pairing Response.

IMHO encryption is mandatory after devices have been paired, as the initiator must send a maximum key size to be used:

  Maximum Encryption Key Size (1 octet)

  This value defines the maximum encryption key size in octets that the device
  can support. The maximum key size shall be in the range 7 to 16 octets.

This ensures my comment also that since 2.1 encryption is mandatory.

So you cannot choose a key size of lets say 0 length, in order to get paired. I don´t know however if there is an ad-hoc mode available which would allow non-paired data exchange (but I don't believe this).

Note that this means only encrypted data stream. Authentication is a different thing. For example, you cannot verify that you connect to the right Bluetooth headset as it has no display or keyboard (still you could read it´s MAC address before you confirm, e.g.). So with some pairing modes I would assume that authentication is on a low trust level (by design).

IMHO as Bluetooth was a replacement for serial/infrared communication in the beginning, it always struggled with security. I would consider it a nice feature for some gadgets, but would not exchange sensitive information (=  it´s not equal to WiFi or LAN).


Client identification using client certificates

I'been digging in the Certificate field recently, and I know it's been a month since you asked, but I hope this helps you some way.

In order to give each of your customers a certificate, You'll basically need a server with its own selfsigned Certificate. This server will "give" your customers their new Certificate.
The flow would be something like this:

1) [FRONTEND] The customer generates a keypair and sends the public key to the server, asking for a new certificate.

2) [BACKEND] The server generates a new certificate based on the customer's public key, and sends it back to the customer with a specific header saying it's a certificate.

3) [FRONTEND] The customer "download" the certificate, the browser knows it's a certificate and prompts the customer to install it on the browser with just a click.

For (1), there are ways to do it with just a click. For most browsers you can use the "keygen" html tag, for IE sadly you have to use ActiveX.
For (2), you'll need some kind of CA Management module, there are some free ones out there, like OpenCA or EJBCA.

It could be a little hard to implement, but it gives an undoubtable authentication for your customers, as they are using certificates signed by you, and it's really pretty easy on the customer side, it doesn't need more than a 2 or 3 field form and two clicks.


Is it possible to crack hash with known salt? If yes how?

Hash functions are designed to go only one way. If you have a password, you can easily turn it into a hash, but if you have the hash, the only way to get the original password back is by brute force, trying all possible passwords to find one that would generate the hash that you have. Assuming the salt is very long, not knowing the salt would make it nearly impossible to crack (due to the additional length that the salt adds to the password), but you still have to brute force even if you do know the salt.

As an example, let's say that the password is "secret" and the salt is "535743". If the salt is simply appended to the end of the password, then the hash you'd be cracking would be a hash of the string "secret535743". Without knowing the hash, you'd have to try all possibilities until you reach "secret535743", which would take quite a while due to its length (keeping in mind that real salts are much longer than this).

But if you know that the salt is 535743 and that it is appended to the end of the password, then instead of trying everything, you'd try "a535743", "b535743", "c535743", etc. This greatly reduces the number of possibilities you have to try until you reach the correct string.

With that being said, it is generally quite rare to have a situation where you know the hash but not the salt since both are usually stored in the same place.


Can nmap undergoing host scan slow my internet speed?

Since nmap will be performing a ping scan in chunks of 4096 host addresses at, at least, 2 ports per host address, (corrected thanks to @Trickycm), it will be generating quite a lot of traffic so yes it will be impacting your other network traffic to some degree but depending on the number of pings and the rate pinged at I would expect the impact to be moderate.

You can add options to reduce the impact:

  --max-retries <tries>: Caps number of port scan probe retransmissions.
  --host-timeout <time>: Give up on target after this long
  --scan-delay/--max-scan-delay <time>: Adjust delay between probes
  --min-rate <number>: Send packets no slower than <number> per second
  --max-rate <number>: Send packets no faster than <number> per second


My bank's homepage is on http. No SSL. Isn't it trivially easy to MITM+change links & get login credentials?

On websites that experience large amounts of traffic (e.g. consumer sites, like banks) administrators have decided to use mixed plaintext HTTP and HTTPS implementations.  Typically, HTTP is used for public information, and the switch to HTTPS occurs when accessing private resources such as a login screen.

This practice largely came from the days when SSL (now TLS) encryption/decryption was costlier (1990s and early 2000s) from a CPU perspective, and could severely slow down page load times.

Now, with faster CPUs more adept at using hash algorithms like SHA256 and encryption ciphers like AES, this problem is less obvious.  However, if you're running a large-scale web server receiving thousands of hits a minute, the administrator will surely notice TLS traffic vs non-TLS traffic in terms of CPU utilized.  The plaintext site will require less CPU and IT maintenance overhead, and in turn cause a savings to the organization in terms of hosting expense.
Additionally as pointed out in a comment by @mgjk, the costs of certificate management between bank IT departments (business versus personal, trading vs other commerce, WAF and DDoS mitigation layers that need to be able to do SSL decryption, etc) is also significant and cumbersome in a large organization, and can lead to a reluctance on the part of management to roll out a TLS-only site.

Thus many banks continue to leverage mixed HTTP and HTTPS web sites.  New best practices are being developed to control for problems and attack vectors present in this setup, notably "SSLStrip" style MiTM attacks.  Control measures include use of HSTS headers, and are making headway to banks -- but have yet to achieve wide-scale commercial implementation from these large, generally risk and change averse entities.

As far as the specific situation you describe with a WiFi Pineapple as an Evil AP, this would be possible if you stage an "SSLStrip" attack, or another man-in-the-middle attack.

However, many banks take measures to protect against session hijack attacks -- notably expiring the session quickly. If the device had visited the site before and it sent HSTS headers, an error (perhaps enough to scare the average user) would surely result.  So, the attack scenario you describe is a bit simplistic and would require a bit more sophistication before being viable against modern bank web site implementations.

However, yes, when banks don't force the use of TLS with HSTS and certificate pinning, a large attack vector is opened up similar to what you describe -- and this practice should be phased out!


Why does Android mix phone state with phone identity?

One specific piece of data you can access with the "Phone State" permission is the IMEI/IMSI of your phone/sim card. This number is used to identify your device for target-ads (so the ad provider could tell whether you've already seen an ad). Since showing ads is a common business model in mobile apps, the "Phone State" permission being requested is as well very common.
I think it's a logical decision (from an economic point of view) of Google to group this ability with other, somehow similar abilities so users won't be scared of permissions that could obviously harm their privacy.
It's definitely possible to give the ability to detect whether the user is on call without a special permission, but that would go against Android's policy of requiring explicit permissions for everything that gets beyond the local concerns of an app.


Kerberos: How could an attacker exploit insider access to invalidate tickets for a service?

A brief answer here, the linked articles go into much more detail.

A local network attacker could MITM a connection using e.g. using Delorean toolkit. This could then cause a server to set their clock into the past.

When calculating expiry dates for issued certificates and tickets, services will then use an algorithm along the lines of expiry = time + timeout, however if time is the attacker's set time, the expiry date will be in the past and the item will have already expired, meaning it cannot then be used for authentication.

An attacker has successfully denied service to users by causing all authentication services to have issued expired tokens. More details here.


OWASP: Insufficient Logging & Monitoring - open source tools

Graylog allows you to define alert triggers/Conditions and Actions/Notifications.

Out of the box it can do an HTTP POST to a nominated URL. I am not sure if parameterisation is available, but this might be enough to do what you need. The graylog marketplace (https://marketplace.graylog.org/) will have some more options which may allow more complex actions - so something may already be available.*

*(Depending on how much hair you have on your chest you can develop your own alert/notification plugin)

I am 99% sure ELK would offer this and even more than Graylog. My ELK experience is limited, but I suspect that Graylog is closest to the Logstash service in the ELK stack. Both use Elasticsearch, but Kibana provides a lot of features not really available in Graylog.

SIEM may also be able to do this, but SIEM's include a lot of pre-defined rule-sets to track anomalies across various sources and correlate and automatically raise security alerts. They generally allow extension of existing rule-sets and/or creating your own. They are almost always goliath systems with a strong learning curve. From what you're saying it seems like overkill.

If you go with SIEM or Centralised Logging - these things need a lot of "juice" (CPU, RAM and IO). If you simply want to deploy application logging, monitoring and alerting, Graylog would likely be the best option. Grab the OVA from the graylog site and have a play, move on to ELK if Graylog falls short and then look at the SIEM options.


Cisco Registered Envelope Service (CRES), big security flaw?

I'm actually the guy that invented the Cisco Registered Envelope.  It was created in a startup called PostX originally. In the beginning we didn't do registration like that we made customer supply passwords for everyone.  The problem is how do you do that if you are sending a message to someone outside your org (or someone you've never talked to before), I mean you could call them on the phone and say I'm making your password : xyz.  Obviously, asymmetric/certificate based solutions solve that man in the middle problem, however, they have there own host of problems and complexities that they bring to the table.  The original PostX product supported S/MIME, PGP, Secure WebMail portal, Envelopes using our SaaS key service, Envelopes using the customers database or LDAP system, Envelopes using a shared secret key that worked offline, and probably a few more embodiments.
Here's what it ended coming down to in the market.  All of these different methods have their plusses and minuses. Sure, setting up S/MIME is super secure, but it's also complicated and requires a ton of pre-arrangement.  The benefit of the Cisco Registered Envelope, is you could literally send an email to a new recipient and the appliance could detect that a possible HIPAA violation might be happening and automatically encrypt the message with a one time key and go ahead and send the encrypted message to the recipient before they have even registered.  You are correct that if someone intercepts that first message, there will be problems, but you already have problems if someone is in your email.  Ultimately, most companies realized that other encrypted email solutions were too complicated or required you to store the messages forever on a website, and the prevailing thinking was if it was too hard (like S/MIME) people would just send it in the clear. We basically used to say, there is a line with security on one end and ease of use on the other end and it just depends on where you want to live on that line. The great thing about CRES technology with the HIPAA lexicon, the sender literally has to do nothing to trigger encryption.  If the words "reserve room 6 for surgery for Michael Johnson" show up in an email, and the customers has the HIPAA scanner turned on that email will get automatically encrypted.  There is one final benefit of this model.  With PostX/Cisco acting as the key warehouse, if you get CRES from multiple different companies, multiple senders - you use the same password with all of them because your password is between you and Cisco. A few more benefits : Each message has a unique key - which also allows you to retract a sent email by disabling that key.  It also supports an anti-phishing pass-phrase that again is the same regardless what org is sending to you (you pick a phrase or word that shows up on the outside of the envelope, you don't see that phrase don't enter your password).  Obviously, as the inventor I am a little biased, we had reasonable success with the product give how little people seem to care about encrypting email, and while it does have it's flaws we found that using something that was virtually painless with a few flaws was better than not using anything at all.


LastPass authentication grid hacked on June 15?

As with any two-factor authentication (2FA) method, then you're back to essentially only having a password protecting your account. But with grids I'd consider the printout a greater security risk than the server getting hacked.

The thing that I find hilarious about grids as a 2FA method is that A) they are too complex to memorize, so you HAVE to have a physical copy, and B) they are super easy to take a photo of.

Some companies print 2FA grids on the back of employee badges, which means that I can turn on my phone camera, walk through the building and capture 50% of employees' grids. Dumb.


What is a good algorithm for memorizing a password in a few minutes?

Maybe the best way is sticking to an algorithm for your password. You might have two or three algorithms to cover complexity restrictions, you might, for example learn the following algorithm:

For any service:

1. Select a reusable secret string
2. Add some common pattern, ie: the name of the service
3. Add some Caesar like algorithm: a=@ e=3 i=g1n d=|) g=Y1 o=()...
4. Add some logic to alternate the strings you have (one char from 1, and one char from 2).
5. Add some random text depending on the length of the service (add a number every length(name of the service)/2.

Build it up, ie:

Secret password: "algorithmpass"
Service: "stackexchange"
Caesar: "@lY1()rg1nthmp@ss" and "st@ck3xch@nY13"
Alternate strings:  "@sltY@1c(k)3rxgc1hn@tnhYm1p3@ss"
Add numbers every len(stackexchange)/2 = 13: "@sltY@1c(k)3r1xgc1hn@tnhYm12p3@ss"

And that is that's you password, it is very hard to remember but "quite easy" to rebuild it.

The disadvantages are clear: once someone crack your algorithm he get access to all the related accounts. The pretty thing here is that you can make really simple algorithms that build great passwords. Also, the passwords generated can be quite complicated to remember, so you should choose your algorithm carefully to meet day to day usability criteria.


What is the correct terminology for a private key corresponding to a public key certificate?

Generally speaking certificates (X.509) contains the public key (of the corresponding private key) that was used to sign the certificate. You can't make any inferences of authenticity of the certificate (and it's attributes) if there is no signature or public key. I suspect your difficulty has to do with how the certificate and keys are distributed.
Certificates are encoded in various formats e.g. DER, PEM and stored in various containers e.g. PKCS12. If you want to store the private key with the certificate you will need to choose a container that supports that like PKCS12 & PFX.
Therefore I don't think the term private key certificate is correct.


What's the right way to provision, share and store (in a db) cryptographic keys?

The first step is to ensure your application is secure, not just to protect the secret in question, but also the application as a whole. If your application is perfectly secure, then there will be no possible exploit, and the secret is safe. Unfortunately, we are not perfect and it is likely that there is some vulnerability lurking in the application that has yet to be discovered.

The following points will help you reduce the impact, should a vulnerability be found and exploited in your application:

Store important secrets outside of the database, -or- you could store the encrypted secret, with its decryption key outside the database.

One of the most common exploits exploits is to gain access to data via SQL Injection. If the secret, or the key that encrypts the secret is stored in a file outside the database you have eliminated that attack vector.
Use the strictest possible Filesystem Permissions possible on the file. It is best if the only user account which can access that file be the application in question.

Other applications can run on separate user accounts so that if those applications are compromised then your secret will still be safe.
Physical or VM separation is even better. The point again is that you do not want exploit of unrelated applications to compromise a secret that is only used by the application in question.

One inexpensive way to achieve physical separation would be with a small computer on the network such as Raspberry Pi or HSM, with a single dedicated purpose. Since your particular secret is itself a cryptographic key, you could outsource the cryptographic operation physically. That device could have only very simple software running on it so you know there is no way to extract the cryptographic key without physically removing the storage media.

In this quote, substitute "deficiencies" for "vulnerabilities" and it still holds true:

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.” ― C.A.R. Hoare.
I'm not familiar with the operation of your service, but if it is accessed via Username and Password, then you could use user-defined passwords to derive keys to decrypt the secret as needed. I've outlined how that would work here: How can we serve sensitive encrypted data without storing the key? Should I use user-defined passwords for keys? However, that solution will not work for an autonomous system, because the user's password and session key would not be available.


What level of access do clients on a secured wireless network have as to the traffic of other clients with wireless isolation enabled?

This has already been asked and answered multiple times. Best answer is here: An attacker knowing the password can intercept with WEP, WPA-PSK and WPA2-PSK, but with Enterprise WPA/WPA2 + 802.1X authentication instead of PSK every client gets its own encrypted "tunnel".

PSK also has the disadvantage of being a "shared secret": changing is hard, as everyone needs to be notified, and is easier to get known to third parties, the more people are using it.

Wireless isolation doesn't solve the problem. It isolates the devices from each other on an IP level, this is true, but the attack outlined in the answer linked above still works. Wireless isolation works on a "higher level" than the attack: it stops ip packages from going from one host to another. Furthermore, when used in combination with PSK, this "wireless isolation" is snakeoil (like MAC whitelisting or SSID hiding). You don't get any real advantage from enabling it. By doing MITM attacks, which are easy when the PSK is known, it can be bypassed.


Is this HSTS HTTP Response Header Misconfigured?

This is an undefined header.
As such, how browsers react to it is browser-dependent. It is possible, but very unlikely, that they will still interpret the header correctly. However, I would not bet on it.
Instead, change the header from Strict-TransportSecurity to Strict-Transport-Security.


TL;DR

SSL/TLS client and server agree to use some weak crypto. Well, turns out that weak crypto is weak.

In Detail

When an SSL/TLS protocol is performed, the client sends a list of supported cipher suites, and the server chooses one. At the end of the initial handshake, some Finished messages are exchanged, and encrypted/protected with the newly negotiated crypto algorithms, and the contents of these messages is a hash of all the preceding messages.

The idea is that an active attacker(a MitM attack) could try to manipulate the list of cipher suites sent by the client to remove all "strong" crypto suites, keeping only the weakest that both client and server support. However, this would break the Finished messages. Thus, these messages are meant(among other roles) to detect such downgrade attacks.

In theory, it's fine; unless the client and server both support a cipher suite that is so weak that the MitM attacker can break it right away, unravel the whole crypto layer, and fix a Finished message in real-time. Which is what happens here.

In Even More Detail

When using the "DHE" cipher suites(as in "Diffie-Hellman Ephemeral"), the server sends the "DH parameters"(modulus and generator) with which client and server will perform a Diffie-Hellman key exchange. Furthermore, the server signs that message with its private key(usually an RSA key, since everybody uses RSA in practice). The client verifies that signature(the public key is the one in the server certificate), then proceeds to use the DH parameter to complete the key exchange.

It so happens that in the previous century, there were some rather strict U.S. export regulations on crypto, and this prompted "export cipher suites", i.e. weak crypto that was compatible with these regulations. Many SSL servers still support these "export cipher suites". In particular, some cipher suites that use DHE and mandate a DH modulus of no more than 512-bits. Moreover, most SSLs in the servers use the same modulus, because using the one provided with the SSL library is easier than generating your own. Reusing the same modulus as everybody else is not a big issue; DH tolerates that just fine. However, it means that if an attacker invests a lot of computations in breaking one DH instance that uses a given modulus p, the same attacker can reuse almost all of the work for breaking other instances that use the same modulus p.

So the attack runs like this:

Attacker is in the MitM position; where he can modify data flows in real-time,
Attacker alters the list of cipher suites sent by the client to specify the use of an export DHE cipher suite,
The server complies and sends a 512-bit modulus p,
The client is still persuaded that it is doing a non-export DHE, but a DH modulus is a DH modulus, so the client accepts the weak/export modulus from the server just fine,
Attacker uses his pre-computations on that value p to break the DH in real-time and fix the Finished messages.

The Logjam article authors call this a "protocol flaw" because the ServerKeyExchange message that contains the export DH parameters is not tagged as "for export", and thus is indistinguishable(save for the modulus length) from a ServerKeyExchange message that contains non-export DH parameters. However, I would say that the real flaw is not there; the real problem is that the client and server accept to use a 512-bit DH modulus even though they both know that it is weak.

What should you do ?

Well, the same thing as always: install patches from your software vendors. As a matter of fact, this should go without saying.

On the client side, Microsoft has already patched Internet Explorer to refuse to use a too small modulus. A fix for Firefox in the form of a plugin by Mozilla is available here now. It is expected that other browser vendors(Opera, Chrome...) will soon follow.

On the server side, you can explicitly disable support for "export" cipher suites, and generate your own DH parameters. See that page for details. Note that IIS is kind of immune to all of this because apparently it never supported DHE cipher suites with anything else than a DSS server certificate, and nobody uses DSS server certificates.

Note that ECDHE cipher suites, in which "EC" meaning "elliptic curve", are not at risk here, because:

There are no "export" ECDHE cipher suites (ECDHE cipher suites were defined after the US export regulations were considerably lifted).
Clients in general support only a few specific curves (usually only two of them, P-256 and P-384) and neither is weak enough to be broken (not now, not in the foreseeable future either).

And what about the NSA ?

The Logjam researchers include some talk about how some "attackers with nation-state resources" could break through 1024-bit DH. This is quite a stretch. In my experience, nation-states indeed have a lot of resources and are good at spending it, but that's not the same thing as succeeding at breaking hard crypto.

Nevertheless, if you fear that 1024-bit DH is "too weak",go for 2048-bit(this is the recommended one anyway), or ECDHE.

Or simply accept that people with overwhelming resources really have overwhelming resources and won't be defeated by a simple modulus size. Those who can spend billions of dollars for cracking machines can also bribe your kids with a few hundreds of dollars to go through your computer files and your wallet.


Is it secure to store my mysql password in a const std::string?

Hardcoding of secrets is never a good idea.

Use a configuration file, to read from. This way you will be able to swiftly change the password if required and prevent the password from leaking through version control or binary analysis.


Assuming you have chosen the right interface (but "en0" looks reasonable) I'd say you seem to be in "monitor mode". Try and disable this at

Edit / Preferences / User Interface / Capture / Interfaces: / Edit / Device: en1 [x] Monitor Mode

Monitor Mode is needed if you want to capture traffic which does not originate from or terminate at the machine you are running your capture on. But from you question I learn that you want to capture the traffic you are creating yourself when connecting to Google.

For background information on this subject, have a look at https://wiki.wireshark.org/CaptureSetup/WLAN.


I Found the issue here.
I was using msfvenom payload @ php/meterpreter_reverse_tcp but my handler was php/meterpreter/reverse_tcp when I changed it to match (php/meterpreter_reverse_tcp) exactly then my session was established.


How was Freedom Hosting 2 hack possible?

No, any user on a *nix system can create a symlink to anywhere else, as long as they have write permissions in the directory where they want to put the symlink.  You don't need to be able to view the target; in fact, the target doesn't even need to exist (this is called a broken symlink).  However, if you can't view the target file, then you generally won't be able to do anything particularly useful with the symlink.

In this case we're talking about /, and / is generally viewable by all users.

There's not a lot of description in that write-up, but it sounds to me that they used symlinks to bypass a chroot attempt and trick the sftp client into allowing them access outside their home directory.


What are the major threats involved in storing the session identifiers in local storage instead of cookies?

I assume you mean a server-side identifier, like PHPSESSID or ASPSESSIONID.

Client accessibility comes to mind. With cookies, they can be marked as HttpOnly, thus making them unreadable from JavaScript. This mitigates an attacker that exploits XSS from stealing your session cookie because a complying browser will refuse to give the cookie to the malicious script.

Local storage on the other hand, has no such protection that I am aware of. Local storage is never sent to the server by the browser (where cookies are), so it would be useless to have local storage that cannot be read client side.


Table or row level security in ASP.NET MVC 5 and Entity Framework 6

I will post an alternate solution to the one that is proposed in MSDN's "Granting Row Level permissions in SQL Server": https://msdn.microsoft.com/en-us/library/bb669076%28v=vs.110%29.aspx.

In my solution, you have a meta table for each table where row level permissions are required. I like to call that meta table as an ACL (Access Control List) table. So as an example, your target table is called Contacts, then you create another table call Contacts_ACL. Now in that table, I put in Contact_Id, User_Id and Permission (or Permission_Id if we have a separate Permissions table).

create table Contact (
    contact_id INT PRIMARY KEY,
    ...
);

create table Contact_ACL (
    contact_id INT REFERENCES Contact(contact_id),
    username varchar(100),
    permission varchar(20)
);

I do this because I feel Stored Procedures is an overkill for something that is very simple (authorization). It also imposes additional code maintenance as everything you change the base table, you have to change the views and the stored procedures.

Here is an example LINQ Query to retrieve stuff:

from contact in Contact
join acl in Contact_ACL on contact.contact_id equals acl.contact_id
where acl.username == <username>
select new {
    contact.contact_id,
    ...,
    acl.permission
}


So what does OpenVAS actually do? It fingerprints your server, does discovery scans, mappings etc. and then compares your system with an exploit database, identifying all vulnerabilities that are most likely affecting your system.

All these steps can be done by a human in a manual way. You can, for example

perform an nmap scan on your server,
grab the server banner and identify the OS/server version,
check for services that run on the server,
search exploit-db for exploits for the services you just discovered,
etc.

Depending on your server setting, this is an immense task and extremely tedious and time consuming - that's why automated scanners were implemented in the first place.

Also depending on your server setting (e.g. you own the server, have full admin access to it and to programs' source code), you can do manual audits, code reviews etc. to verify manually if there are any potential vulnerabilities or policy violations present. It all depends on how much time and pain you are willing to put into it.


Can most mail from *.ru be considered spam?

It might be that 99.99% of your mails are from a .ru domain.

However wether you can block it depends on the 0.01% that are not spam.   What do you want to do with them and most importantly what does it cost you to lose that message.

If this is a local site for an area in another country far away from Russia then it might be a small inconvenience to you and you lose contact with someone. However if you are a site covering a more widespread are and say need to do business in Russia losing these emails might have a measurable cost in reputation if not money. In this case I think you have to ask the business owner how much it would cost to lose that contact and also tell them how much it would save to filter out the .ru domain an let them make a business decision.


Should my company change the internal Root CA hash method from SHA-1 to SHA-2?

Checking the root certificates of my browser I see that almost all
  Root CAs are using SHA-1 or below.

The signing algorithm used for the trusted root certificates is unimportant.  Signatures are used to establish trust.  By definition, a trusted root certificate is one which you implicitly trust based on provenance (e.g., where it came from and how it got into your trusted root store - by the OS/browser installer, by Group Policy, etc).  The signature of the trusted root certificate is never verified against the signer (and they're generally self signed, of course).  Rather, signatures are used to verify untrusted certificates that are handed to the browser on the fly by the not-yet-trusted server.

That being said...... it is probably worth using a SHA-2 signed cert for your internal CA because people look at certificate chains and assume SHA-1 bad, SHA-2 good.  If you go with SHA-2, you won't have to deal with people asking you this very question :)

  1) Should I change from SHA-1 to SHA-2 on my internal Root CA or
  change the web site's certificate is enough?

It is not necessary to change the root certificate to SHA-2, but it may help avoid questions from users and auditors.

I would not go through the trouble of re-issuing existing certs; I would create a new SHA-2 root and use it for all future certificate signings.  That way the SHA-1 version of the root will go away over the next few years as your existing certificates expire.

  2) Today, what is the impact of Root CAs using SHA-2 in browsers? Is
  there any browser yet that doesn't support SHA-1? Some of our customer
  still uses old versions of IE.

I assume you mean "browser [that doesn't yet] support SHA-2?"  Yes, there are still old versions of browsers out there that don't support SHA-2 (nifty compatibility table), but if your users are running those, they should be forced off them for general reasons, not because of your root CA.

  3) Will browsers stop trust Root CAs that use SHA-1?

I would not be surprised if that happens, years down the road, because of the "appearance of security" issue that I mention above.  But not quickly because, again, in technical terms, the browser doesn't use the signature on trusted root certificates.


What is the Constant HashTables Seeds Vulnerability?

Constant HashTable Seeds Vulnerability

HashTables fulfill the dream of constant time insertions and access. A HashTable is a group of linked lists, the linked-lists must be small in order for the performance to be good.

This attack happens when the attacker over saturates one linked-list inside the hashtable, resulting in huge access times, slowing the whole node process. thus the denying of service attack vulnerability.

NodeJS prevents attackers from abusing one linked-list inside the hashtable by randomizing the hash function algorithm as they introduce random seeds for the algorithm at the initialization time.

The bug was that the random seed was always constant (random but never changing across each version of node) as it is initialized during compiling of node code, the reason behind this is that the V8 engine takes a snapshot of the initialized context, and reuses it on the next boots, to make things faster. so the attacker can now know the algorithm and its seed, allowing the attacker to abuse the hashtable and oversaturate one linked list.

I wrote a blog post about the topic explaining the hashTables and the origins of the vulnerability in more details, NodeJS: Constant HashTables Seeds Vulnerability – Medium


Hardware USB Key to Reset Any Windows Password

The kickstarter page actually gives away the method:

  Using the key you can boot the PC into a special admin mode that allows you to view all of the user accounts and reset any password. Quickly regain control of the PC and get back to work.

Basically you reboot the PC with a custom OS located on the USB flash drive itself; from that OS, the relevant files on the disk are modified. The USB device is nothing special: it is just a normal USB flash drive; the "added value" of this device is purely aesthetic. Downloadable boot images which can do the same thing from a "normal" USB flash drive can be obtained from various places, e.g. this one.

This password reset method will fail if any of the following holds:

The boot-on-USB option was deactivated in the BIOS, and a BIOS password was set to prevent reactivation (of course, some BIOS accept "default passwords", and a BIOS password can be cleared by removing the CMOS battery, which is doable with physical access and a screwdriver).
The operating system uses disk encryption and requires a password upon boot -- not just as a verification, but because the encryption key is derived from the password (TrueCrypt can do that).

Also, as @Ben explains, a password reset is not recovery: that which was encrypted with a key derived from the old password remains inaccessible.


How do I create comparable security to PHPmyadmin?

PHPMyAdmin is not a security tool, and using it is risky in itself. You log in directly using the database account, with all the privileges the account has. If your task is to update the database, this means write access. Of course you could create a limited database account that has only access to certain tables, but that's not really practical and most likely the hosting company has given you exactly one account with full privileges. If this database account gets compromised, the whole database gets compromised. It's exposed to several risks when your requirement is to be able to work on any computer with Internet access.

Having a separate tool that is limited to certain use cases is recommendable, as it can have an authentication that is totally independent from the database account, and own account for every user. The tool can also have detailed access control over who can update what, and logs for auditing the changes etc.

The cons are that creating such a tool from scratch and making it secure is not an easy task. The authentication might be bypassed, you might leave vulnerabilities for SQL injections or expose the database password with configuration mistakes. Using anything that has been developed for years, is widely used by others and gets regular security updates is preferable.

To achieve both you would look for a widely used ecommerce platform. If you really must perform administrative tasks from external non-trusted computers, it's recommended to have some multi factor authentication.


To begin with - I won't go into too much detail for this answer. Read more about HTTPS and the certificate system if you're curious ;-)

HTTPS needs certificates to work. These certificates are meant to be a guarantee that you're talking to the right server (and not to the server of an intruder). Encryption only (without this authentication) would be pretty useless, because it would be trivial to intercept and decrypt traffic.

To manage all this certification stuff, we use a  Public key infrastructure. Your phone trusts only certificates signed by a certificate authority.

By installing the app, you mentioned in step 7 that you imported a "packet capture certificate". Now your phone trusts everything it trusted before - plus all certificates signed by the "packet capture certificate".

Now the app can act as a proxy between your device and your web application. It decrypts your traffic so that it can display the packet contents, and then re-encrypts it with its own secure connection to the web application. This is similar to a Man-in-the-middle attack. This only works because you trusted the certificate. (If you wouldn't trust the certificate, your phone would most likely throw a connection error.)

But how does the app get the packets? It probably uses the Android VPN API and presents itself to the Android system as a VPN tunnel. Therefore, Android forwards all packets to the app.

Wireshark can't be used as a proxy because wireshark only listens to traffic and does not alter or insert new requests. If you want another tool which can intercept HTTPS, then try OWASP ZAP, Burp Suite or mitmproxy.


why the website cant understand my request in http smuggling?

what did i miss?

You've missed that you've explicitly constructed a request which is open to multiple interpretations and that the best answer a server could do to this is to reject this request. And that's exactly what the server did, i.e. perfectly normal and sane behavior.

how can i make the second request be a legitimate request?

Ideally, all servers would reject such kind of requests. There are many other ways requests might be open to multiple interpretations - see for example HTTP request smuggling. If you are lucky some of these methods work, but from the perspective of security I hope that none work against the specific target.


How to list missing security updates for Windows servers?

I would recommend Iszi's answers above, but since you do not have access anymore these may not be feasible. I am not aware of any complete list out there listing all patches for a given platform, since the missing patches would also depend upon some other things installed that are not necessarily required (drivers, .NET, etc.). If you do not have access you are not the one who could implement the changes anyway. However, that said... you could install another fresh windows install, apply all patches, export the list, then diff them.

I just found this list of patches released for 2003: http://support.microsoft.com/kb/914962 . It might be a good start for you.


Implications of Trace/Track Methods on Apache

HTTP TRACE method basically replies the request, together with all the headers in response. Cookie header will also be included in response. Session cookies should have httpOnly flag for preventing Session Hijacking attacks. This flag blocks access to the cookie value from Javascript. Basically this ensures that even if attacker will exploit a XSS flaw in a website, he won't know the session cookie value, so he can not hijack it.

But if a web application server has TRACE enabled, attacker can just send e.g. XMLHttprequest (AJAX) to the target server. Browser will attach the cookies to the request, the server will echo them in response - and attacker's JS code will get the response and will be able to hijack the session.

The vulnerability is called Cross Site Tracing and has been described in this white paper.

However, since 2003 when this vulnerability has been discovered, many browsers simply disallowed sending requests with TRACE method. Also the specification for XMLHttpRequest disallows TRACE method now. I don't have any concrete results on which browser allows sending TRACE right now, the closest match I found is this article.

But still, there probably are some old browsers around - and other plugins like Flash, Silverlight, Java that often receive cookies from the browser and may use them for sending TRACE. So disabling it is now the only option to be sure you're not vulnerable to Cross Site Tracing. And it's easy too - just use TraceEnable off in Apache.


Android apps: required permissions reported before installing are misleading

In Android, permissions are categorized into 2 categories:

Normal permissions: Very little risk to user's privacy (like access to internet)
Dangerous permissions: High risk to user's privacy (like reading and modifying contacts)

Normal permissions are allowed at install time, and they won't be asked.

If there are any dangerous permissions, then you will be presented with a pop-up stating the dangerous permissions, and allow you to make a call whether to go ahead with the installation or not.

In your case, access to internet comes under normal permissions, hence there was no confirmation before installation.

For a list of all normal permissions:

https://developer.android.com/guide/topics/security/normal-permissions.html

EDIT: Even if you upgrade to Android Marshmallow(6.0), which follows a different permission model, and allows the users to revoke specific permissions, you won't be allowed to revoke normal permissions. Revocation of dangerous permissions only is allowed.


Can websites track the tabs you open while logged into their website?

Amazon can confidently tell what you you're looking at on another tab if the site you are looking at is affiliated with or is Amazon themselves.

This can be achieved through cookies, browser fingerprinting, and IP address matching, probably along with some other methods.

Amazon can also tell if you leave focus of your tab to view something else - see this stackoverflow answer.

They cannot tell the contents of or what you are searching on another tab if that site is not affiliated with / sending that information to amazon voluntarily.

You can prevent amazon from being able to see what you're searching on an Amazon website or website that is actively sending information to Amazon in tab B by using a separate browser with a different fingerprint, cookies, and IP address (through a proxy or VPN).


Spoofing TCP/IP stack OS Fingerprinting attacks in OSX

This attack works even if I browse a website using Tor browser!

I think you are wrong here.

You are talking about fingerprinting the TCP/IP stack and you claim that the original OS can be even detected this way if you use Tor. But Tor nodes do not simply forward packets like a router does but instead the data are re-packaged in user space and you have each time a new TCP/IP connection. Thus what you should see with fingerprinting at the TCP/IP level is at most the OS of the exit node. This also means that any changes on the TCP settings of your OS should have no effect regarding fingerprinting when you are using Tor.

Since you have probably checked against some site which claimed to detected your OS even through Tor I recommend that you share a link to this site so one can find out how the detection is really done there.


First and foremost: If the token is concatenated into a SQL query (without sufficient escaping), then yes, it can be used for SQL injection. Don't build queries by concatenation!

Tokens, by themselves, have no permissions; they are just identifiers. The app's logic determines what permissions to give the bearer of the token, but it's up to the app to enforce that, and a (successful) SQL injection bypasses such checks. Databases also have permissions (at least, the better ones do), and the app will have certain permissions on the database that determines what a query the app sends to the DB can do (and all that a SQL injection is, from the perspective of the DB, is a query that the app sent over). A very security-conscious app will use the Principle of Least Privilege (which says you should never give anything more permissions than are needed to do its task), such that (for example) a DB query that is supposed to be read-only will be made using a connection with read-only permission on the DB, and in such a case an embedded DELETE subquery would indeed fail. However, in practice very few developers do this, and the app usually makes all queries using a connection with full permissions on the DB.

The permissions of the token-bearing identified entity (presumably a user of a web app or similar) have no bearing whatsoever on the permissions that the app has when talking to its database. In fact, since a SQL injection requires modifying the token, it's no longer actually the correct identifier for that user, so it definitely isn't going to be subject to user-specific access checks.


Why would you decouple your resource and login servers?

This way, if one of your applications gets hacked, you theoretically
  don't lose any login credentials. But is that all there is to it?

No, an additional benefit (or possibly the main benefit) is that a resource owner can give temporary access to a subset of their resources to a client without giving away their credentials. From the document you linked:

  For example, an end-user (resource owner) can grant a printing
  service (client) access to her protected photos stored at a photo-
  sharing service (resource server), without sharing her username and
  password with the printing service.  Instead, she authenticates
  directly with a server trusted by the photo-sharing service
  (authorization server), which issues the printing service delegation-
  specific credentials (access token).

The Beginner’s Guide to OAuth explains this a bit more in-depth.

  What if the authentication server gets hacked?

That would be bad, but it's not any more likely than your resource server being hacked.

In fact, it is probably less likely, as an authentication server is less complex than a resource server and thus less open to the common web vulnerabilities (only very limited database queries, so only few chances for SQL injection; no or close to no user output, so less danger of XSS; no file upload; probably no danger of LFI/RFI; etc). There are of course still problems.

So the second benefit of OAuth is that it separates sensitive data that is relatively easy to handle from less sensitive data that is quite complex to handle, and thus less protected.

  Aren't you putting all your eggs in one basket using this architecture?

You were doing that before as well. Now you at least have two baskets.

And the protocol doesn't seem to suggest that you should only ever have one authentication server for all of your application servers. So if you had multiple, separate application servers before, you can now have an authentication server for each of them (if the costs are worth the gain in security for you).


Tutorial for learning Threat Modeling at enterprise level

Check this Microsoft Threat Modelling Tool 2016 with study guide.

http://aka.ms/tmt2016

  Microsoft Threat Modeling Tool 2016 is a tool that helps in finding
  threats in the design phase of software projects. It's available as a
  free download from the Microsoft Download Center. This latest release
  simplifies working with threats and provides a new editor for defining
  your own threats. Microsoft Threat Modeling Tool 2016 has several
  improvements such as New Threat Grid, Template Editor & Migrating
  Existing Data Flow Diagrams.


Before you embark on the "fist step" of information gathering.  You may want to consider step 0: "What are you attacking,  and what is your goal?".  The point of gathering information is to determine your target's attack surface, and what attacks are applicable.

Is this a web service or web application?  You might want to gather information about
what platform this web service is built on. What language was it
written in,  ect. Dirbuster and spidering help enumerate attack surfaces. BURP and ZAP will build a sitemap of your target(s) and have tools to expand the sitemap.
Is this a mobile app? You might want to sniff traffic to find backend
services.  Or decompile the app to see if they are protecting the
source.
Is this a network assessment?  You might want to use nmap -sV,  or
google hacks,  or use DNS to acquire targets.
Is this a VoIP or Telephony assessment?  You might want to start with
determining the range of your target, and wardialing.
Is this a wireless assessment?  What wireless networks are running?
Are they protected?  How are they protected?
Is this a hardware assessment?  You might want to start by
looking the controller board and its manufactures.  Write down any ID numbers you see on integrated circuits,  and google them. After components have been identified,  try fining developer manuals.

There are many other types of security assessments that follow penetration testing methodologies,  however the ones above are really the most common types I am familiar with.


With which algorithm I can prevent a brute force on a login?

Time is your friend.

Think about what happens when you draw money from "ye average banking machine".

User inserts card (read: email/name/whatever),
Machine says "hi, please enter pincode" (read: password/whatever)
User can now enter correct pincode within 3 attempts. If that fails, the card is withdrawn and the user will have to wait for the next day to personally apply for a new card and pincode, explaining to his bank what happened.

Now, in your situation you most probably don't want people to come knocking at your door because they failed to enter the correct code. To avoid this, you'll simply have to strip the "come and apply for a new card" thing and what's left is "wait until tomorrow".

So, if you give a user 3 attempts to verify himself/herself and he/she fails... make her wait for an hour before he/she can try again.

If someone would still try to go for a brute force attack, it would enable him to try ("3 attempts per hour" maximum x "24 hours in a day" maximum = 3 x 24 =) 72 attempts a day.

Depending on what he/she is trying to brute-force, 72 attempts a day (which are 26280 attempts in a 365-day year) is wa-ay too slow.

This way - and as long as "reverse engineering" to find a backdoor isn't an option - your "software" should be safe from brute-forcing anything.

UPDATE

A little update, based on the comments to this answer...

Now, what about people getting locked out because one or more malicious people abuse the user name of a specific member and simply try to make sure such a user can't log in because they simply entered a wrong password 3 times?

Right, sounds like a "Denial Of Service"-alike attack. But that won't stop you from doing it this way, as such attacks can be circumvented easy. All you have to do is to make sure you don't forget about a second layer of security for such cases.

Remember that there are things like "security questions". Someone might be able to know or guess your username, but it'll take a truckload of time to get around a security question when locked... unless you know the answer. The security question could be limited to simply "unlock" the "locked" login area.

Think about how Google and Co. do it:

login with username/email and password,
fails several times gives a lockout,
answering security question correctly lifts lockout.

Use a captcha at (1) and (3) to slow down any brute-forcing attempts and you're all set.

If you explicitly do not want to use a captcha (which makes me wonder why), you will have to implement a "user-ip", "time-of-access" checking implementation and slow down access to the system for a random 1 to 2 seconds. This shouldn't be a problem as this would be a similar implementation as the lockout-procedure, only that you don't lockout but slow-down things at certain points so a brute-force attack takes time. A 1 second slowdown on 1 page will limit brute-forcing to 60 attempts per minute, while you're locking out the brute-forcer after 3 failed attempts. Same goes for the security question: slow it down. The brute-forcer will have to be smart enough to deal with both points and will have to brute-force both of them at the same time... stealing his valuable resources and time to cause havoc.

However you do it. If you do it like this, there's no need for the admin to even leave the coffee machine while all that's going on, and it solves any problems you think you might have discovered relating to "locking out legit users with a DOS-alike attack".

Let's look at the initial example I provided above in (3):

  If that fails, the card is withdrawn and the user will have to wait for the next day to personally apply for a new card and pincode, explaining to his bank what happened.

Well, the "security question" option to enable legit users from lifting the lockout is just like being forced to personally visit and talk to your bank. Just easier.

Also, this "unlocking" procedure can be useful for the admin/sysop as a simple log file showing the number of "attempts" can help the admin to track down attempts of a definitive attack. Any script kid could try to lock out users by entering the wrong password 3 times... but if someone fails answering the security question severaltimes, there's something bad going.

And last but not least: just like an onion, such security layers can even be wrapped into each other (if it makes sense, like in high-security environments).

The simple trick is to make it hard for people to mess with things, while keeping the regular user happy.

I can only repeat: time is your friend... (the rest is simple logic)


WiFi deauth attack - Difference between Aireplay and MDK3

I was able to sort out the difference in the attack, I think.

I found out that to filter MAC addresses for 802.11 packets I had to use wlan.addr.

After it, I could see that MDK3 would be sending both disassociation and de-authentication packets, where aireplay only sent de-authentication packets.

Since I am using a particular type of wifi, I think this is the reason why aireplay wasn't able to break it. When using a reguler Open Wifi AP, both of them would break the network,

Cheers


Hiding the "Allow" http header that comes with the response after an 405 API call

... our security team said that we need to hide the Allow header

Either they've told you something wrong or you understood it wrong. Allow is actually a mandatory header when doing response code 405. From RFC 7231 section 6.5.5:

  405 Method Not Allowed
     The 405 (Method Not Allowed) status code indicates that the method
     received in the request-line is known by the origin server but not
     supported by the target resource.  The origin server MUST generate an
     Allow header field in a 405 response containing a list of the target
     resource's currently supported methods.

What I find a more likely requirement given the picture you show is that the server should not support the TRACE method in the first place and therefore also should not show TRACE as supported.


How do compilers detect buffer overflow?

Buffer overflows aren't detected at compile time.  There are code analysis tools such as Sparse or Lint (cpplint, pc-lint) that will perform further analysis on both source code files or compiled binaries.  Each analysis tool has their own algorithms for determining a buffer overflow, but it comes down to common known instructions that lead to buffer overflows.

You can also add Bounds Checking at compile which inserts bounds information for each allocated block of memory.  This bounds information is then checked at run-time to ensure buffers are within their limits.  A common implementation is to use "fat" pointers.  Which contain both the address of the real pointer to the data, and additional data describing the region it is located.  I believe Firefox does this for their memory allocations, but I could be mistaken.

Canaries are inserted at compile time to help detect buffer overflows by inserting a word of data between a buffer and the control data on the stack.  At a certain point before the return of the function the canary is verified to be intact.

ASLR has nothing to do with stack protection.  It randomizes the address that your program runs in memory.  This means that you can't rely on functions to be at the same address each time the program is run.  This prevents the hardcoding of library and function addresses.  Making the stack or heap (or any piece of memory that you're trying to execute) executable is necessary regardless, but ASLR will still cause you problems.  If you're just experimenting and trying to understand exploit code I would do the following:

Disable ASLR
Disable stack protections
Attack each problem individually, and re-enable them one at time until your exploit can handle both.

If you have a binary that crashes due to... well anything (not just a buffer overflow) run the program in a debugger.  The debugger will catch the crash at the exact point that the program fails.  You should probably realize that this might not be the exact location of the overflow, but a stack trace should help determine the root cause.  I would suggest reading these posts if you're not familiar with reverse engineering tools, or x86 computer architecture.

Why are buffer overflows executed in the direction they are?
Reverse Engineering Tools


OpenVPN username and password authentication only - unsafe?

The user name and password are encrypted; this is confirmed in the OpenVPN documentation:

  OpenVPN 2.0 and later include a feature that allows the OpenVPN server to securely obtain a username and password from a connecting client, and to use that information as a basis for authenticating the client.


What does "hijack" mean in networking security?

A good translation is being able to control. It doesn't matter whether you control the system via an exploit and installing a backdoor or having an infection vector that connects the device to a bot-net orchestrator or anything similar.

Once you have full control over the system, you have hijacked it.


Is it possible to forge key files and mount a veracrypt container?

From the Veracrypt documentation, it looks like they are using a hash of the keyfile contents and the password to derive the header key.

Due to the nature of hashes, a change to any single bit of the input will cause a large number of changes to the calculated hash value. This is true for all hash functions by design.

However, they only use the first 1 MB of data from each keyfile. While a person is extremely unlikely to duplicate your image accurately enough to generate the header key (this is virtually impossible), any file with the same 1st MB of content would work. This won't be an issue with JPGs, and I wouldn't expect it to happen under normal circumstances.

So, in summary, it is virtually impossible for them to unlock the volume without that original file---or at least the first MB of it. Be careful where you keep the keyfile, and securely delete it when moving it.


First remove access to your account for that device

Now log back in to your Google account. When it asks to not ask for 3FA again for a month, select no.
And now you can go back to your security settings and tell Google that the device is you.


CMS Uses http and so sends password in plain text

You have to use https.  This is not a responsibility of the CMS application, but a responsibility of the person deploying the system, to purchase a signed SSL certificate from a known trusted certificate authority (note you can purchase for free from say http://www.startssl.com or included in the cost of your domain registration at say http://gandi.net ) and force all traffic to be only sent via HTTPS.

Even if the CMS application say hashed your password client-side (using say javascript), sent the hashed password over the network, and then checked the hash server-side, the hashed password (say hash=bcrypt('Correct Horse Battery Staple', salt)= '$2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04.')
 would still be sent over in plaintext for anyone to eavesdrop.  These eavesdroppers would still be able to do a replay attack (e.g., modify the client-side javascript to instead of hash an entered password, to just send back the captured hashed password $2a$14$XUgYF0o3flsoGam2GHiw8OlQv9BBR/ihAwS/k83fZk.YjJ1hA/04.) that they intercepted.  Also, note that this effectively turns the client-side hashed password into the effective password; so ideally you would additionally further hash the received hash server side to compare against what is stored in the database.  Or they could just intercept the session cookies sent over the network and use those to mimic activity of a currently logged in user.

Or they could just do mess with routing to do a man in the middle attack, so you send the password over to their server.

Furthermore, if they required you to use SSL without having purchased a certificate, the users may be scared away due to the browser warnings of an untrusted certificate.

A more complicated scheme may convince you that there is more security than there actually is, even though it would be trivial for an attacker to circumvent.  All that is required is to set it up using HTTPS.


Is it OK to reuse the same SALT key across multiple deployments?

It is NOT okay.

Someone can get your salt, build a rainbow table, and easily decrypt all data from all customers. The whole point of a salt is to negate the effects of rainbow tables.

You shouldn't even use the same salt with one customers. Just generate a new salt with every new key. You can store the encrypted text and salt together, there is no need to protect the salt.


General Purpose Hybrid Encryption File Format

Yes, there are other standards, including the original RSA PKCS#7, its successor CMS (sometimes also referred to as PKCS#7), and the related S/MIME which is used in email.

However OpenPGP is more "general purpose" than any of these and is designed with useful features in mind such as sophisticated key management, configurable ciphers, and compression, among other things. You aren't going to find anything much more general purpose than that.


Is it something to worry about when my browser warns me that my connection to 192.168.1.1 (router admin page) is not secure?

No public Certificate Authority (CA) will issue a certificate for a private IP address, such as the 192.168.x.x blocks.

Because of that, I would expect that I would not see an HTTPS connection to a consumer-grade router in my network, and if I noticed such a connection (this assumes, of course, that I'd actually notice the lock icon when it shouldn't be there; which, if I'm honest, I probably wouldn't), then I would be very suspicious that someone had installed rogue certificates, and has an actively snooping proxy somewhere on my machine or in my network.

It is possible to set up a secure HTTPS connection, depending on your router's capabilities. If you can add a certificate to your router, you can create a self-signed certificate. This will effectively encrypt your HTTPS connection inside of a perfectly valid TLS tunnel, although your browsers will be complaining very loudly that the validity of the certificate can't be verified.

There are ways to get past these complaints by the browser, such as adding yourself as a trusted CA on your computer, or getting a certificate for a domain and using your internal DNS or your hosts files to point the domain to the private IP, as mentioned in the comments.

As far as the specific cases that you're asking about:

1, your own home: There should be nothing to worry about, assuming that all other devices are secure. Rogue devices on your network will be able to do packet sniffing, so don't log in using the same password that you log into your bank with (which is good advice regardless of what you're authenticating with).

2, you're hosting a public access point: Assume the network is being actively probed at all times. In this case, I might take the time to set up TLS properly and even then, if I were truly paranoid (I.e., my access point was set up at DefCon), then each time I access the management web page, I would disable wireless, ensure nothing else is connected via any hubs or switches, then change the password before re-enabling wireless and making my configuration changes.


There are lots of potential reasons for this. It could be a misconfigured DNS, the firewall, a work-installed agent on your machine. Or someone on the local network is maliciously redirecting traffic. A network tech might have configured the firewall to redirect certain sites to their favourite Twitch channel so that their browser history looks work-related, but doesn't realise that the entire network is affected.

There are a lot of potential reasons for internet traffic to go to unexpected places.

We cannot tell you the source of the problem from your description alone or why it is only happening on certain sites. Someone with networking knowledge would have to run a packet capture to start to run down the problem.

You need to be working with your IT team. They are the appropriate people to ask about this.


What is the security problem of Options FollowSymLinks in the Apache configuration?

If you enable following of symbolic links, and an attacker gains access to something allowing him to create arbitrary files on your webserver, he could then create symbolic links to any file on your system (e.g. /etc/passwd, configurations files of databases, ...)


To run an exploit, an attacker needs a vulnerability.
To find a vulnerability, the attacker needs to fingerprint all services which run on the machine (find out which protocol they use, which programs implement them and preferably the versions of those programs).
To fingerprint a service, the attacker needs to know that there is one running on a publicly accessible port.
To find out which publicly accessible ports run services, the attacker needs to run a port scan.

As you see, a port scan is the first reconnaissance step an attacker performs before attacking a system.


What is the best way to manage package signing keys?

You cannot prevent anybody from creating a new key pair. But you can maintain a list of "allowed key pairs" where you insert only one key pair per developer, and whenever you validate a signed rpm, you use that list as your trust base.


I want to buy a used docking station for my laptop. Has there ever been a case of a docking station being a security concern?

As always: do a risk analysis.
What is the likelihood that that a docking station contains a keylogger? According to @multithr3at3d: it is almost zero. There are easier ways of distributing keyloggers than selling docking stations.
You might look at the vendor. Is it a reputable vendor (good shop, good rep on ebay, things like that) or is it a shady man dressed in a raincoat in a dark alley? I exaggerate a bit here, but you'll get the picture.
If you're really paranoid, you can log the traffic that goes to the outside world (the logged keystrokes must be collected, otherwise they are useless). Netflow should be sufficient and you should be able to identify all the sites that you communicate with.
But if you're that paranoid, you shouldn't even look at second hand stuff.