First of all that would entirely depend on the encryption used by the access point. There are several types of possible encryption. Mostly on consumer wireless access points these are:

WEP
WPA
WPA2
WPS

WEP

Let's first dive into WEP. WEP was the first algorithm  used to secure wireless access points. Unfortunately it was discovered that WEP had some serious flaws. In 2001, 3 researchers working at Berkeley produced a paper named "(In)Security of the WEP algorithm". They found the following flaws in WEP:

Passive attacks to decrypt traffic based on statistical analysis.
Active attack to inject new traffic from unauthorized mobile   stations, based on known plaintext.
Active attacks to decrypt traffic, based on tricking the access
point.
Dictionary-buildingattack that, after analysis of about a day's worth
of traffic, allows    real-time automated decryption of all traffic.

An excerpt from their paper about the technical problems with WEP:

  WEP uses the RC4 encryption algorithm, which is known as a stream
  cipher. A stream cipher operates by expanding a short key into an
  infinite pseudo-random key stream. The sender XORs the key stream with
  the plaintext to produce ciphertext. The receiver has a copy of the
  same key, and uses it to generate identical key stream. XORing the key
  stream with the ciphertext yields the original plaintext.

  This mode of operation makes stream ciphers vulnerable to several
  attacks. If an attacker flips a bit in the ciphertext, then upon
  decryption, the corresponding bit in the plaintext will be flipped.
  Also, if an eavesdropper intercepts two ciphertexts encrypted with the
  same key stream, it is possible to obtain the XOR of the two
  plaintexts. Knowledge of this XOR can enable statistical attacks to
  recover the plaintexts. The statistical attacks become increasingly
  practical as more ciphertexts that use the same key stream are known.
  Once one of the plaintexts becomes known, it is trivial to recover all
  of the others.

  WEP has defenses against both of these attacks. To ensure that a
  packet has not been modified in transit, it uses an Integrity Check
  (IC) field in the packet. To avoid encrypting two ciphertexts with the
  same key stream, an Initialization Vector (IV) is used to augment the
  shared secret key and produce a different RC4 key for each packet. The
  IV is also included in the packet. However, both of these measures are
  implemented incorrectly, resulting in poor security.

  The integrity check field is implemented as a CRC-32 checksum, which
  is part of the encrypted payload of the packet. However, CRC-32 is
  linear, which means that it is possible to compute the bit difference
  of two CRCs based on the bit difference of the messages over which
  they are taken. In other words, flipping bit n in the message results
  in a deterministic set of bits in the CRC that must be flipped to
  produce a correct checksum on the modified message. Because flipping
  bits carries through after an RC4 decryption, this allows the attacker
  to flip arbitrary bits in an encrypted message and correctly adjust
  the checksum so that the resulting message appears valid.

  The initialization vector in WEP is a 24-bit field, which is sent in
  the cleartext part of a message. Such a small space of initialization
  vectors guarantees the reuse of the same key stream. A busy access
  point, which constantly sends 1500 byte packets at 11Mbps, will
  exhaust the space of IVs after 1500*8/(11*10^6)*2^24 = ~18000 seconds,
  or 5 hours. (The amount of time may be even smaller, since many
  packets are smaller than 1500 bytes.) This allows an attacker to
  collect two ciphertexts that are encrypted with the same key stream
  and perform statistical attacks to recover the plaintext. Worse, when
  the same key is used by all mobile stations, there are even more
  chances of IV collision. For example, a common wireless card from
  Lucent resets the IV to 0 each time a card is initialized, and
  increments the IV by 1 with each packet. This means that two cards
  inserted at roughly the same time will provide an abundance of IV
  collisions for an attacker. (Worse still, the 802.11 standard
  specifies that changing the IV with each packet is optional!)

Some other interesting reading material can be found at aircrack-ng.org.

WPA

The second one is WPA. WPA was originally meant as a wrapper to WEP which tackles the insecurities caused by WEP. It was actually never meant as a security standard but just as a quick fix until WPA2 became available.

There are two modes in which it can operate:

WPA-PSK: Preshared key (password)
WPA-Enterprise: This requires a RADIUS server and can be combined with an Extensible Authentication Protocol (EAP).

WPA generally uses Temporal Key Integrity Protocol (TKIP). TKIP was designed by the IEEE 802.11i task group and the Wi-Fi Alliance as a solution to replace WEP without requiring the replacement of legacy hardware. This was necessary because the breaking of WEP had left WiFi networks without viable link-layer security, and a solution was required for already deployed hardware. TKIP is not an encryption algorithm, but it's used to make sure that every data packet is sent with a unique encryption key.

From the aircrack-ng.org paper

  TKIP implements a more sophisticated key mixing function for mixing a
  session key with an initialization vector for each packet. This
  prevents all currently known related key attacks because every byte of
  the per packet key depends on every byte of the session key and the
  initialization vector. Additionally, a 64 bit Message Integrity Check
  (MIC) named MICHAEL is included in every packet to prevent attacks on
  the weak CRC32 integrity protection mechanism known from WEP. To
  prevent simple replay attacks, a sequence counter (TSC) is used which
  allows packets only to arrive in order at the receiver.

There are two attacks known against TKIP:

Beck-Tews attack
Ohigashi-Morii attack (which is an improvement on the Beck-Tews attack)

However both of these attacks only could decrypt small portions of data, compromising confidentiality. What they can't give you is access to the network. To give you an idea of how much data can be recovered, a single ARP frame would take around 14-17 minutes to get the plain text.

The only attack know, besides flaws in firmware of some routers, is bruteforcing the WPA key. Generally the key is generated as follows:

Key = PBKDF2(HMAC−SHA1,passphrase, ssid, 4096, 256)

Considering this algorithm is meant to prevent hashed passwords from being broken it can take a huge amount of time. The only reasonable attack would be to use a dictionary attack (hence it is important to use long passwords containing characters, numbers and letters).

Also note that you need to change your SSID to something very random. Rainbow tables have been generated for the top 1000 used SSIDs.

WPA also supports AES (which can be used instead of RC4). This would still imply that TKIP-MIC is used.

WPA2

WPA2 supports the same modes as WPA, except that it does not use TKIP but CCMP for cryptograhic encapsulation.

CCMP is an enhanced data cryptographic encapsulation mechanism designed for data confidentiality and based upon the Counter Mode with CBC-MAC (CCM) of the AES standard. This is used to replace TKIP for message confidentiality.

However some access points can still be configured to use both TKIP and CCMP. This was done because otherwise people were required to upgrade their hardware.

Extensions

WPS

Wi-Fi Protected Setup (WPS; originally Wi-Fi Simple Config) is a computing standard that attempts to allow easy establishment of a secure wireless home network. It allowed easy security for home users but still using the more secure WPA rather than WEP. WPS should never be used as there is a great design flaw in it. WPS generates 'by the push of a buton' a PIN code which can be entered by the user. The idea behind this was to increase usability. This poses a problem: the amount of possibilities is reduced to 10.000.000 which any computer can crunch through quite rapidly, even when using PBKDF2.

EAP

EAP is used for WPA(2)-Enterprise and is an authentication framework, not a specific authentication mechanism. It provides some common functions and negotiation of authentication methods called EAP methods. There are currently about 40 different methods defined. Some have their own flaws however considering the vast amount of possibilities I suggest looking them up yourself.


Is it a good idea to use non-ASCII names in the U.S.?

There are even Chinese people in the US. They name their children 李某. Would that be a problem? No. Some systems support these names, some use versions converted to ASCII through romanization (李某 → pinyin Lǐ Mǒu → Li Mou). The only non-ASCII character in X Æ A-12, Æ, is used e.g. in Danish names like Ægidius, converted to ASCII Aegidius.
A good example of such conversion is machine-readable passports: the last two lines on every passport contains only characters A–Z, 0–9 and the filler character <. For passports, every name in the world gets converted to ASCII.
Sometimes using mere ASCII may be more problematic than non-ASCII characters that are easily encoded in UTF-8:

Christopher Null is a real person who has reported some problems with his ASCII name.

My name is Logger, Startkeylogger.

Little Bobby Tables has a name as unique as the little baby Musk. This Robert doesn't have a social security number as he's a fictional character, but for real people the name isn't an obstacle.


Disclaimer: I have never tried using spider oak so I'm only by going what they claim they do, what they told you they do and what the end result looks like.

Given that they claim to be storing your data encrypted and never being able to access it, I would assume the only thing they ever have access to is really the encrypted version of your data. This would mean the application on the client performs all the encryption/decryption operations and only stores the resulting data (and possibly extra encrypted metadata on the server).

This data must be encrypted by something. Now going by their response to you, I would assume they have some hierarchy of keys. My guess would be at least 2 levels, but for simplicity let's just assume one.

This would mean the data is encrypted by some randomly generated key K1 (on your machine). This key is then encrypted by a key K2=PBKDF(32 byte salt,password,16384 rounds). By the preceding ugly description I mean they use the PBKDF2 (Password Based Key Derivation Function v2.) algorithm (using SHA-2) to generate an encryption key from your password. This key K2 would never be stored anywhere (except client memory). It would always be generated on the fly when you want to access your data.

The package that would then be sent to and stored on the Spider Oak servers would be EK1(data),EK2(K1). When you then want to retrieve the data you get the data sent over to you encrypted, and the key sent over to you also encrypted. When you enter your password, PBKDF2 is used to generate K2 which is used to decrypt K1, which is then used to decrypt your data.

So what happens when you change your password? Well the server sends your client all the packages EK2(K1)$ for any K1's it has for your data. Locally these get decrypted by the key generated from the old password, and reencrypted by the key generated from the new password, which gives a new K'2.

When you then come to a different device, fire up your client and try to retrieve your data, the encrypted data come accompanied by the key encrypted using you new password. You enter the password, PBKDF2 does it's magic, and voila you decrypt K1 and then decrypt your data.

edit: GAH how do I get TeX to work here in my posts?

Edit2.: Rereading the information you got from the representative it actually seems like all new K1's are also generated. This seems somewhat fishy in the sense that either they do encryption/decryption on their servers (thus it's not fully zero-knowledge) or they send all the data back to you when you change your password and your client reencrypts it. The first of these seems more likely to be honest, since the overhead for the client otherwise would be quite large. Ofcourse it's also possible the representative doesn't really know what he's saying. I've had that happen multiple times.


They are very highly regarded and for very good reason, however, you're still going to have to continue to learn and evolve as a penetration tester. You'll be exposed to vulnerability detection, penetration testing and exploit writing with Offensive Security exams, however, you are still more likely to see a company looking for CISSP, CEH and/or GIAC certifications in their job descriptions. How much you're exposed to penetration testing afterwards depends on you I guess.
I don't believe they cover wireless or in-depth web app stuff and I'm unsure how much of the targets is Linux-based because I've only ever heard of Windows targets (I suspect there is a good amount of Linux, it's just not talked about).
I believe there's still a lot of stuff related to Windows XP vulnerabilities though I don't know what the percentage. I know there's now Windows 7 and W2K8 stuff, however, it's only natural that there'll be XP testing because it's still very popular and it's got to be a real pain keeping the course content (after all the principles are normally the same regardless of the target).
The real benefit of doing those courses, afaik, is that you not only learn how to compromise a device and hide your tracks, but you also learn how write exploits, look at shellcode and perform reverse-engineering, which means you'll understand better what's going on.
SANS have some excellent courses on penetration testing also (disclaimer: I've done a few of them) but they're somewhat more expensive. There's plenty of other discussions on this forum regarding SANS training so I'll let you search for that yourself.
You should view OCSE/OCSP as only a start.....


This may just be a psychological fallacy in which you only notice the phishing attempts that don't trick you. There are certainly phishing attempts that are near exact copies of the site they are impersonating that trained security experts can (and do) fall for when not alert.

Malwarebytes posted this on their blog, which contains some side-by-side images of phishing login pages next to the site they're impersonating.

As you can see they're similar to the point of being indistinguishable unless you're looking at them side-by-side like this. You're right in that many phishing emails/sites are poorly done - this is generally because it is time intensive to make something a near match, and wouldn't result in as significant an increase in successful phishes as you may think. Overall, for many low-lever phishers the cost outweighs the reward.


Obfuscation is generally not useful as a security feature or enhancement of encryption.

That said, there are reasons to use obfuscation, but it's generally in regards to attribution rather than security.

A classic example would be using steganography to hide your encryption. The purpose is not to enhance security, but to hide the fact that you are communicating at all. Another example would be using obfuscations like "meek", and others, to hide the fact you are using Tor.

Depending upon your intent and environment, using obfuscation with encryption could range from pointless inconvenience to extremely important.


Which HTTPS certificate is the content verified by if the content comes from multiple servers?

If it gets resources from a site like a CDN the certificate will be verified against the URL of this resource, in this case the CDN. The URL of the HTML file embedding these resources does not matter in this case, only the URL of the resource itself.

  ... with a protocoless path

A path like //host/page instead of http://host/page or https://host/page just means that the same protocol should be used as the embedding page uses. But this does affect how the certificate will be validated.


Running as root with raw sockets will let you set whatever IP address you wish on your outgoing packets. Tools like hping3 include this functionality. You could write the binary GET request and feed it as an option to hping3, then specify the source address (or even --rand-source). That won't get you all the way, though.

Since we're talking about completing the full TCP connection, you'll need to take those lessons of raw sockets and write them into your own application (or find one that does this already). To be functional, your source machine's network card will need to be listening in promiscuous mode. You will also need to have your target's (the webserver) network route pumping all traffic directly to the network. The easiest way to to do that would be to make your source machine the default gateway.

Sockstress is one tool that sounds like it might fit the bill, but I'm not familiar with it.


What are some good ways to secure personal computers

There are all sorts of ways that home users can keep their data and / or identities secure while still having a usable computer. Below are a few of the most common ways the average Joe can secure his machine:

Choosing a strong passphrase

Yes, we've all heard it time and time again, but there is probably no easier way to improve your security. If you're a fan of passwords, make sure to choose something that contains enough entropy to be reasonably secure, while still being easy to memorize. A random series of letters and numbers is great, but you probably won't be able to memorize a very long string of them. Anything that includes personal information should also be avoided. Mixing your name with your birthdate is not secure, no matter how long and random it might look.

Personally, I'm a fan of pass phrases. Pick a few random words from a dictionary (I choose somewhere between 5 and 10 depending on the required ammount of entropy), and you've probably generated enough entropy to keep an attacker guessing for much longer than will be practical (see the XKCD on the topic for a laugh).

Other people prefer to use pass-sentences. While these may be longer than your typical passphrase, they may or may not be anymore secure.

For more information on passphrases and passentences see, `Linguistic properties of multi-word passphrases' by Bonneau and Shutova of the University of Cambridge  [PDF], or their blog post on Light Blue Touch Paper.

Encrypting your data

There are plenty of great options for full-disk encryption on both Linux and Windows. Remember, encryption is only as strong as the password you choose (see above).

Windows

TrueCrypt is a fantastic piece of software for full disk encryption on Windows machines. It's transparent, easy to use, and provides a nice little interface for mounting / unmounting your various drives, USB keys, etc. and for creating hidden disk images that can give you plausible deniability when taking encrypted data into / outof countries that don't like encryption. The down side is that you'll need to have it installed on any computer on which you want to mount your drives.

Windows also has built in File System Level encryption, but I've had some issues with it randomly deleting my private key in the past (make sure to have a backup, possibly on a TrueCrypt encrypted volume), so I don't often recommend it.

Linux

Most linux distros come bundled with an encryption subsystem called dm-crypt, often hiding behind a nice key management interface called LUKS. You might also find loop-aes useful, but it sounds more likely that you'd want to use the (often) built in system. For more info you'll have to look at your specific distro's help pages.

Securing your network

You may not have a fancy hardware firewall, but properly configuring the firewall on your router, and the one built into Windows / Linux can go a long way towards keeping your network secure. I know nothing about Windows Firewall, so I'm afraid I can't recommend anything here, but a quick Google Search turned up several articles that appeared to be good guides to configuring it.

Use a supported operating system

If you are running Windows XP or earlier, make sure you update to a later operating system, preferably the most recent stable release.  Windows XP is now end of life and no longer patched.  Windows XP and older systems are becoming increasingly vulnerable because attackers keep finding new vulnerabilities, and nothing is being done to prevent them on these older operating systems.

Don't automatically run programs

Most systems now are configured not to automatically run programs when you stick in a CD or USB key, but some older (unpatched) versions of Windows might not be. If you are running Windows XP, and are not willing to upgrade, at least make sure the last available patches are applied.

Install security related updates

Actually, if you're running anything make sure you've got the latest security updates. Simply turning on Automatic Updating in Windows, or making sure to run updates often in Linux can go a long way towards keeping you safe.

Use SSL / secure wifi

Make sure you're not sending your password over a plaintext connection. Even the least tech-savvy user can check for the little green lock icon ane make sure the site they're logging into says "https" in the nav bar. It may not protect you from much, but at least it will prevent the guy sitting next to you in the coffeeshop from snooping out your password.

On that same note, secure your wifi networks with WPA (and choose a good password... again, see above), and try not to connect via unsecured wireless networks (including those that use WEP).

SSH

If you're using SSH to access your computer remotely, make sure to turn it off for the root account, and always use public key authentication. This is a bit more advanced topic (and probably only applicable to Linux, or not at all for the average home user), but still worth talking about. Other things you can do include disabling protocol 1, allowing only certain users to login remotely, and disabling X-forwarding (depending on your requirements). For more info, see this article on the CentOS wiki.

Conclusion

While most of these techniques are widely known, or may seem laughably simple, you'd be supprised how many people don't follow them and how many attackers can be detered by a little common sense, and basic security policies.


What's to stop someone from just MITMing a checksum?

Your problem is a common problem in security know as authentication.

Checksum solves the problem of integrity, you know that what you just downloaded is correct, but you do not know from who it comes.

If someone is operating a MitM attack, they obviously will try to replace the checksum of whatever download you required with the checksum of the binary they want you to have instead.

If you want to assess the authenticity (prove that the binary has been issue by someone you trust), then you need to use authentication method like digital signature.

The typical process goes this way:

original owner issue a public key he will share for the authentication purpose (see asymmetric cryptosystems)
original owner computes the hash of the document he wants to sign
owner signs the hash with its private key, so that anyone can verify it
client gets the document
client gets the public key of the original owner and validates it through chain of trust protocols (see ad-hoc documentation)
client verifies that the signature of the hash is correct
client verifies that the checksum of the program is the same

If you follow such a process, you cannot be subject to MitM attack. The key point of the protocol here is obviously the verification of the public key. If you fail to assess that the public key belongs to the owner, you can be deceived.


How Regin hides running instances of itself?

I'm not a kernel hacker, but from what I read the technique is analogous to a function hook in user space.

Premise

User space code interacts with the kernel through system calls.
There are system calls that reveal information about the state of the kernel, e. g. f returns list of loaded kernel modules.
The kernel manages a table t of system calls and the location of their implementation in memory.
A kernel module (a. k. a. “driver”) m becomes a part of the kernel, when it's loaded, thus gaining full access to everything the kernel can access.

Steps

m is loaded/injected into the kernel in some way. Now it can do anything it wants to the OS including hooking into some of its infrastructure.
m replaces entry tf holding a reference to function f, which would help to reveal the presence of m. In its stead m places a reference to a similar function f' into tf, which is a part of m and uses f but filters and/or transforms the results as to hide the traces of m.
A user space program is looking for suspicious kernel modules and wants to call f. After receiving the system call the kernel looks up tf, because it expects tf to hold a reference to f. Instead it finds and calls f'. Thus the user space program will receive a result controlled by m.


John the Ripper not identifying a password contained in the username?

Good question

the default rule : will split the "username" on the following characters for guessing purposes.    I put "username" in quotes because it seems to be treating everything before the ":" as possible GECOS fields that could be delimited by any of the characters.

".", "_", "-", "|", " ","#",";","^",","

(and probably others)

so ACC_^.^S#kvV  will be split into the guesses ("ACC","S","kvV") and never try ^.^S#kvV

As proof try APC_Skater.skater778818:skater778818 and the : will solve it.

your rule x[0-9]l is a variation of xNM (extract substring from position N for up to M characters) and in this case go from position x to the end of the string (l).  So this rule does no splitting, but just tries successive substrings.


How do i extract data from response and use it in url for next request in Burp Intruder?

You need to create a Burp Macro followed by a Session Handling Rule within Project Options tab.

  The following URL provides the detailed description of how to achieve this:

  https://support.portswigger.net/customer/portal/articles/2906338-using-burp-s-session-handling-rules-with-anti-csrf-tokens

The Title of the topic on the website says "Using Burp's Session Handling Rules with anti-CSRF Tokens", however it does exactly what you're trying to achieve here.


Is this an insecure implementation of multi-site sessions?

A lot of SSO systems work this way. But there's a bit more to it than just a couple of lines of code, specifically:

use cookies for sessions with the usual httponly and secure flags
when a request for an authenticated service is received but without a valid session, redirect the user to the SSO (this needs some special handling around POST and DELETE/PUT/PATCH if used)
if a session already exists on the SSO or the user passess authentication, redirect the user back to a special landing page in the application with a token in the URL (because that's the only polite way to get data across domains)
at the landing page, establish a link back to the session, set the sesison cookie and redirect to the originally requested page (note that some older browsers ignored cookies set in a 302 response)

  HTTPS [...] helps prevent anyone listening in on traffic from getting this URL, correct?

The key word here is "helps". It doesn't prevent the URL from appearing in the history.

  so how short should the sessions be?

Trying to fix an issue of leaking the session cookie by shortening the session timeout is not the right way to go. A better approach is to have the SSO send back a single use token which the application can then use to resolve the session or authenticate access to the session, e.g. (on the SSO)

if (authenticated()) {
    $secretsid=encrypt(session_id(), SERVERSIDEPASSWORD);
    $_SESSION['otp']=uniqid();
    $return_url=add_get_arg($app_landing_url, array(
      'secretsid'=>$secrestsid,
      'OTP='=>$_SESSION['otp'],
      'original_requested_url'=>$originally_requested_url)
    );
    header("Location: $return_url");
    exit;
}

and at the landing page....

if ($_REQUEST['secreetsid']) {
    $sid=decrypt($_REQUEST['secretsid'], SERVERSIDEPASSWORD);
    if (looks_like_a_valid_session($sid)) {
          session_id($sid);
          session_start();
          if ($_SESSION['otp']==$_REQUEST['otp']) {
             unset($_SESSION['otp']);
             header("Location: $_REQUEST[original_requested_url]");
             exit;
          } else {
             // bad OTP
             log_bad_session_transfer();
             exit;
          }
    } else {
          // might be naughtiness, might be a bug
          log_bad_session_transfer();
          exit;
    }
 } else {
    // must have got here by accident - send them back to SSO
    redirect_to_sso();
    exit;
 }

An alternative way to resolve / validate the token would be to make a direct HTTP call from the landing page back to the SSO (i.e. server to server, not via the browser) and ask it to resolve the SID based on the toekn received from the browser.


What data should I validate when validating  X.509 certificates using Java?

Certificate validation is, huh, a bit more than looking at the dates.

Have a look at RFC 5280. It would be an utter delusion to believe that you could implement certificate validation with any kind of security, and decent interoperability, if you do not read several times and wholly understand that document. A lot of crud has accumulated on the X.509-related standards, which makes implementation of certificate validation a daunting endeavour. The X.509 style guide is a must-read (although now a bit dated, it still gives the right impression about the state of things in the X.509 world).

Really, if your boss told you to implement X.509 validation, then either he mocked you, or he is seriously disconnected from reality.

Your best bet is to use some existing library which already does the job. Fortunately, Java itself comes with some code for that; look it up in the java.security.cert package. Peruse the Java PKI Programmer's Guide and the adjacent note.

Revocation is the PKI equivalent of "Whoops, sorry, disregard my previous message". It is used to declare that a given certificate shall not be used, even though all the paraphernalia of signatures and name constraints and policy trees and key usages says that everything is fine with it. Revocation status checking involves downloading potentially huge lists of revocation (CRL) and/or talking to online servers who assert the status of some certificates (OCSP); either way, it is expensive, bulky, and it will work only insofar as the corresponding Certification Authority publishes revocation information in a proper and standard-compliant way, i.e. not that often.


Prevent Chrome extensions from betraying me

Unfortunately, there isn't a good-enough way out of this situation. This logic extends to every piece of software we use on our computers and phones - not just Chrome extensions.

With browser extensions (Chrome & Firefox), I use as less of them as possible, install only those I think I can trust, and keep reviewing this list as often as I can (once a month or so) - whether I can still trust them. Even this has its pitfalls - but I use "my best guess / judgment" to make this decision - knowing full-well that it might not be enough. In effect I use a combination of your options #1 and #4.

But then I can't afford additional due diligence. So that's where it stops.


Edit: Reading this post: Are WPA2 connections with a shared key secure? I realise that I know too little about the topic.
Original post remains below.

  Does Wifi encryption create a private tunnel between the adapter and the accesspoint?

No. Not even with 802.1X Authentication. -> See https://en.wikipedia.org/wiki/IEEE_802.1X#Shared_media

  When non HTTP/S data is sent over Wifi, can that data be seen by other machines that happen to also be connected to that same access point?

Yes. If you're logged in to the same WiFi (and connected to the same base station on the same channel if there are multiple ones), then you can usually listen to all other participants. It's basically as if you were connected into the same wired-LAN-hub: Everyone hears everything.

Unless you're too far away from some node in which case that node is hidden to you and you won't be able to hear it: https://en.wikipedia.org/wiki/Hidden_node_problem

  Does the privacy of the HTTP data depend on the encryption mode of the network?

No. Not if somebody is properly logged in to the same WiFi.


FIDO: what is the benefit of the challenge parameter?

The challenge-response model is primarily designed to help prevent against replay attacks, in which an attacker sniffs an authentication packet and then replays it within their own session to gain unauthorised access.

As you noted, a server-controlled random token (called a "server nonce" in most protocols) which must be signed in order to authenticate makes it almost infinitely unlikely that an attacker would be able to replay an authentication packet to gain access.

However, one additional benefit is that the scheme forms a kind of zero-knowledge password proof, in which knowledge of a secret can be proven to the server, without ever actually transferring the actual secret over the network. This means that a network eavesdropper must break the challenge-response scheme (e.g. by bruteforce attack) in order to discover the secret.

Thomas Pornin provided an excellent summary of both server nonces and client nonces in another question, which summarises it much more clearly than I could hope to.


There's no single tool or technology that will do all of that for you, much of that will come from defining policies, and from them create procedures and standards for people to follow. You need to understand what information you are trying to protect and from that figure how many documents you need to secure in that way. That will also tell you how much security you need so you can make sensible choices on strategy, policy, and technology. That will tell you whether you really need specialized tools or not.

You also need to understand your budget limitations, tempest proofing a room is not a cheap undertaking and neither are WORM storage units. Security conscious small businesses can probably get by by simply labelling document classifications in the file name and then making sure they put them into the right places. PGP can be used for secure email transfers, but for intra company emails encrypted hard drives and using TLS on mail connections will do the same thing.

You can throw governance, policy, user training, and loads of money at document classification and storage. It's best to make sure you know what you need before talking about technology.


Your assumption is correct. However to avoid a certificate path validation with expired CA certificates at the end, you can have such a link certificate and another certificate from the same CA with the same new public key which is self-signed (uses the new private key corresponding to the new public key). This way you can smoothly switch from the old CA certificate to the new one and your certificate path neither ends with an expired certificate nor it gets longer. In such a case the CA certificates should make use of the AuthorityKeyIdentifier / SubjectKeyIdentifier extensions to simplify things.


How to protect source code locally when traveling with it

You need to start by using a full disk encryption (FDE) mechanism. Something like BitLocker for Microsoft or FileVault for Mac or any others. edit: do not store your recovery key on the same pc.

That is your base line defense but it is certainly not enough for total protection.

To be perfectly honest, you need to change your behaviours in order to be very secure. For instance:

If possible, do not travel with all of the code.
Consider using a secure VPN to access your sensitive info (that leads to other threat vectors though).
Limit your exposure in threat zones, keep your laptop with you.
Do not hibernate your computer (always turn it off and on). edit: hibernation may be ok (personally I do not trust it -but I have an SSD so what's the real difference). Stand-by or sleep mode is the real issue in regards to cold boot attacks.
As an aside to the cold boot attack vector, you may want to look here for info on how to safegaurd against cold boot attacks.
Be alert in general.
Change your passwords frequently.
Never access public wifi
Disable bluetooth and wifi (if possible and when not using it)
You could also look into a remote wipe software/service (but it's not perfect).
Disable Ad Hoc Connections as this is potentially a huge risk.

update: Others have mentioned the bios. You can enable a password there and disable booting from removable media but the bottom line is that if an attacker has your pc in their hands, your only line of protection might very well be FDE. Here is an article about bios protection.


Is it possible to detect OpenPGP mails in TLS encrypted connections?

Being able to recognize OpenPGP messages is especially an issue as the recipient is included in the OpenPGP message's meta data by default (it can be hidden though, using the "hidden recipient" feature; which trades reduced meta data for more effort on the recipient's side, as he has to try all his secret keys instead being able to select the proper one from the beginning).

  As far as I know, its not possible to detect the content of a mail, even just only if it is OpenPGP encrypted when the ways sender - mail server - mail server - receiver are TLS encrypted. Am I wrong?

You're right, as long as there is no flaw in TLS and proper algorithms/parameters are chosen, contents transmitted through an encrypted channel cannot be recognized.

Statistical methods on the message size might be applied to guess the contents might be OpenPGP messages -- but then again, OpenPGP messages are generally hardly distinguishable from "normal" messages with respect to their size.

  Of course it can be detected by the mail servers and if one of the ways is not TLS encrypted.

You are also right about the mail servers being able to analyze whether a message is OpenPGP-encrypted, as they terminate the transport encryption through TLS. If you trust all servers in between (and there are often more than two), also be aware that you cannot make sure all mail servers on your message's route always communicate encrypted -- there is a rather larger portion of mail servers not encrypting connections between SMTP servers at all! This is especially valid for network-internal communication, which is rarely encrypted at all; but also an issue for cross-server-connections through the internet. Finally, even if servers have certificates, lots of them do not have a proper certificate, or do not bother to verify the other side at all.


Can browser bypass hosts configuration file?

If the browser honours the hosts file, i.e. it either uses the system DNS resolver API or reads the hosts file when doing its own DNS lookup, and the browser itself (or a plugin) is not complicit in the malicious act, then no. This is the case for most browsers; very few would not honour the hosts file.

There is no provision within JavaScript to perform DNS lookups outside the normal browser implementation.

The only way around this would be a browser exploit that gained code execution on your system, at which point the DNS issue would be largely moot.


Please recommend best-practices documents for sharing encrypted data with non-technical end-users

Edit: Misread your question. My original solution was how they can provide to you encrypted, you want how you can send them an encrypted file...

I would still say SFTP is an option; once its on their end, it should be their responsibility to secure it. If you server is secured, the ounous is on them once they get the file or they should be specifying what works for them. At the same time, if you made something really convenient that they could use you might be able to get one solution on your side.

You might try the PGP desktop suite which can create secure files and zips. If you really care about security, you won't use basic winzip passwords - you would still need to use key-pairs or exchange a symetics key. I would also recommend trying out truecrypt. You can do that with a password or with keypair. Since TrueCrypt can be run in "traveler" mode with out installation, you can preload it with the private keys they would need to open your files and send them your pre-loaded version (open source so its all good). They would just then need to mount the true crypt archive you sent them and they work with it just like its a disk. You could probably also setup a script on their end so they just drag a truecrypt container onto the batch file and it mounts it for them automatically with the keypair.

There might also be some self extracting encryption/packers out there where they just run the executable. Ultimately though, you can't control policy on a external entities systems and they  will probably copy the files off elsewhere and it should be their responsibility to keep it secured once received (unless you have different contractual requirements).

Leaving original response for other who may pass by one day:

One thing you might try is SFTP. I am not sure if you need encryption at rest, but you can handle that using a script as files come in or have the server store files in a encrypted disk. You provide the end users with WinSCP (I assume anyone working on Linux is technical enough to do what you want), distribute the key, give them a username and password. You could probably write a one page document as well. This is the solution I usually recommend and have recommend to a client in the past who had to obtain lots of data files from their clients.

I find many organization use regular FTP, so SFTP seems similar; winscp or any even Filezilla are similar to a file system and have drag and drop. Each user can have a drop folder, etc; you can force key changes and password changes on an interval. The software on the user end is free.

You could also try to get them to buy or foot the bill for something like PGP desktop tools and have them make containers and email them to you...but they will probably still have the file unencrypted on their end so its not any real protection on the client end. You can manage security how you want once you receive the file.


Our users get a trojan horse alert on our site, but we don't. What do we do?

It depends.

If she's the only one user getting this sort of alert, chances are that her machine is infected. If many users report this issue, it's time to get your website checked.

Also, if she's getting the alert from her legitimate anti-virus product, it could be the case of false-positive. A simple email to the anti-virus vendor would solve your problem.

As AstroDan suggested in comments, it would be better if you check your website using VirusTotal. You should particularly check the URL that the user is reporting.

If you find nothing wrong with your website, ask the user to:
1) Update their OS
2) Update the browsers
3) Use a legitimate anti-virus/anti-malware product, update it, and scan their machine(s).


Understanding a DMZ with multiple servers

The purpose of the DMZ is to do not expose your DB directly to Internet. Instead you expose it to your web application, and your web application to Internet. But you need to take care of the security of both the web app and the DB.

If your web application gets compromised, it doesn't mean that the DB is as well. There are various vectors here, for example, you could have a SQL injection vulnerability in your code, so it would be irrelevant whether the DB is in a DMZ, private subnet or even the same host as the web application, because an attacker could retrieve info anyways.

Another example, somehow your application could lead to access the OS. But if your system is carefully hardened, the attacker could only access the resources the webapp user has access to. The database should not be any of those resources.


You can try to create an encrypted virtual disk. For example truecrypt provides a way to create encrypted files that can be used as storage. (All you need is to mount the file once with the pass and you can use it like any storage place, then unmount and it's secured)

Or else you can also crypt/uncrypt an archive file with GnuPG but that will be more a burden to decrypt everytime you want to access it then recrypt it etc.


where to store the salt for "crypto_pwhash" in a web application with no local storage

The required property of a salt is to be unique, cause it make impossible to use dictionary table for reverse hash of all user with the same table.

The other usefull property is to be impredictable so attacker can't pre calculate dictionary table before obtening the salt.(scenario where this is usefull : the attacker detect a security problem he can use to obtain password hash, he generate a table for the username he want to access then when he obtain the password he can use it before you can react to the attack)

random salt give the two property.

Using site name + username give you the first property.

password give you nothing cause when generating a entry in your dictionary table you know the password (the one you are hashing).

If you store it on the server you can respond to request with invalid username by an random number of the same size of your random hash(this is only obscurity and absolutly no security)


Are security controls themselves considered assets (e.g., cryptographic keys)

Conceptually speaking, no. An "asset" is a thing that has intrinsic value. Controls have no intrinsic value; they have extrinsic value. They have value in that they protect assets.
However, depending on your context and your scope, controls can be considered assets if they are deemed to have intrinsic value. If you are assessing a control environment, then yes, keys are an asset.
Whenever performing a risk assessment, you also need to keep your scope and context clear and not start folding the scope in on itself, else everything is an asset.


It looks like someone is probing your machine to see if you are vulnerable to the shellshock vulnerability.

They are hoping that the command will be executed against the shell and that the response will be returned to them. In this case they are trying to see what system you are running, likely to help choose the next attacks if successful.

You should ensure that you have the patched version of bash or use dash. You may also want to implement firewall rules or proxy rules to filter out requests that include the tell-tale shell shock string as these are likely malicious IPs.


I assume you want to know if there is a way to execute the uploaded PHP file. Short Answer: No

Long Anwser:
As long as the web server is configured correctly only .php files gets executed as PHP. Most web servers will return as content type always the mime type derived from the file extension. The content itself of the HTTP response is typically the content of the file. For example Apache2 will return you the content type 'image/jpg' and the plain text of the PHP file.


Chrome showing SSL warning about SHA-1 when the sites don't use SHA-1

This seems to be a bug in Chrome.

Root CA Certificates are often still SHA-1 certificates, which is not a security problem (and also not considered a problem by Google: http://googleonlinesecurity.blogspot.ca/2014/09/gradually-sunsetting-sha-1.html), yet Chrome spooks users with the warning - even when the only SHA-1 certificate in the chain is the root CA certificate.

It looks like this bug only affects OS X 10.11 El Capitan:
https://code.google.com/p/chromium/issues/detail?id=499506


HTTPS web service switched to HTTP. What can go wrong?

You are right, the regression to HTTP is pointless.

Note that all your points apply to one particular kind of attack, where the adversary is able to access the data transport between client and server. That could be the owner of a WiFi hotspot or your ISP acting as a man-in-the-middle, who sits in between you and the server. This can be hard to accomplish for a remote attacker, but is particularly easy on a public WiFi.

What HTTPS adds to HTTP is secure data transport. The web application itself can be completely fine - if you are communicating over an unencrypted channel, the attacker will be able to read, modify and inject arbitrary data into your requests and the server responses. With a captured session cookie, it will also be possible to impersonate you for as long as the cookie is valid.

What the attacker cannot do is take over your Google account or reauthenticate with Google at a later point. This is because the authentication with Google always happens over SSL and the granted token expires after a given time.

So the situation is somewhat better than capturing your credentials straight away. However, as you said, an attacker would still be able to take over the session and perform any action on your behalf.


Man-in-the-middle attack in SSH when attacker copies the public key

The attack would not succeed, because the Man In The Middle (MITM) needs to have not only the public key of the server, but also the private key as well, in order for the client to be able to complete the handshake with the MITM's server.

This question (and answer) are very similar to:
Could a stolen certificate show as trusted?

Edit 6/4/2020:  Once the ssh tunnel is setup, the client can authenticate with the server.  One method of client authentication is 'public key authentication'.  This is where the client proves that it is in possession of a private key that corresponds with a public key that the server has on file for the client.  See comments below for more info.


Does SSL VPN work with standalone mobile applications?

To summarize the discussion in the comments:

SSL/TLS is an established technology to provide communication well protected against sniffing and modification. It is used most prominently as the security layer in HTTPS, i.e. to securely access web sites. But it is also to secure mail delivery and more.
A VPN is used to securely connect to a different network. SSL-VPN's are using SSL/TLS as the underlying protocol to provide the necessary security, similar to HTTPS using SSL/TLS as the underlying protocol.
In case of connecting a mobile banking app to a server using a SSL/TLS connection (often with HTTP on top, i.e. HTTPS) is the common way to provide the needed protection for data exchange.
While in theory one could also use a SSL-VPN in this case this would not provide any benefits since only the connection between mobile app and the server application need to be secured and not between the mobile app and the whole banking network. In other words: the protection by SSL/TLS is needed but only as a connection between two application and not in form of a VPN. Moreover, using a SSL-VPN instead of a simple SSL/TLS connection would add useless complexity which actually might decrease the security instead of increasing it.


Explaining security vs. performace to a non-tech superior

Password-based encryption, with both encryption of the data and a signature to prove that the data can't have been modified by anyone without having the password, using longer keys, is a good choice.

PBE = password-based encryption. Isn't this what you need?

WITHSHA256 = SHA-256 is a modern hash algorithm, and is used to prove that the data can't have been modified by anyone with having the password at hand. 256-bit hashes are the modern standard, with 512-bit hashes for those of us who want just a little bit more reassurance. The SHA-2 family of hash functions is the most recent NIST standard digests.

AND256BITAES = AES-256 is a modern encryption algorithm. The 256-bit key size is for those of us who want just a little bit more reassurance, even though a 128-bit key size can be sufficient for many uses. The AES family of functions are the most recent NIST standard block ciphers.

CBC = The CBC mode for encryption is the default choice for turning a block cipher into a stream cipher. Stream ciphers are needed when one has a stream of data of arbitrarily length to be enciphered. AES in CBC mode is a more modern choice than RC4.

BC = The choice of crypto provider library. Choose a reliable, performance crypto library. BouncyCastle is implemented in Java, so the JIT may be able to optimize it. OpenSSL is implemented in C and the crypto provider might have bindings to the C functions, but the JIT is unable to optimize the C functions.

If there is a need to encrypt, then there is an equivalent need to encrypt with modern algorithms and techniques. Use them, unless there is a specific, demonstrable, and proven reason against.


Why are CRLs used instead of "valid certificates lists" and inner workings of CRLs

First bear in mind that X.509 was designed at times not every system was online all the time.

Having only serial numbers of revoked certificates on a certificate revocation list (CRL) was mainly done for keeping the size small. Some CAs also remove revoked certs which expired in the mean-time from the CRL for exactly this reason. More sophisticated approaches for addressing CRL size are partitioned CRLs and delta-CRLs.

Today many PKI deployments favor online revocation checks like OSCP. At first this also was just designed to indicate revocation (sometimes read from CRL) but some OCSP responders also query the CA's database. There was even a remote validation mechanism designed called SCVP which is not widely implemented though. OSCP et al strictly require online access.

Like X.509 certs the X.509 CRLs are also signed either by the CA itself or by another delegated revocation authority (indirect CRLs). So it's no problem to distribute them via clear-text and unauthenticated HTTP as long as the relying participant properly validates the signature. (Using HTTPS might cause hen-and-egg problems while checking the TLS server cert against an CRL).


I was redirected to an infected site, what should I do?

The beep comes from the un-completion notification - a thing that pops-up even in g-mail if you do not let it finish various in-progress actions.

The redirect may of been done even by a plugin or an active malicious script on your system. Fortinet is an e-mail security appliance and Spamhaus is an e-mail blocklist centralization system - they are not viruses.

Traditional anti-viruses often miss scripts that are designed to mimic normal functionality so I'd recommend you scanning your system with tools like HitmanPro Malware Removal Tool and Malwarebytes.


I did preview of TPM 1.2 support for VeraCrypt UEFI.

Main idea is to set secret in TPM NVRAM under PCRs protection. It locks boot chain. So modification of BIOS and other components causes authorization deny.


Sniffing packet on wireless connection (airodump-ng)

Yes.

It's possible, it will be shown in the list of detected stations, and if it's connected to an AP, the AP can be shown in the AP list, but with little information it's gathered from the packets sent from the client to the AP.

Give it a try and see it for yourself.

wireshark output.cap

or .pcap, or .ivs file.

EDIT (This is a NO)

I misread the question, as @thomas-weller said, A (The AP) doesn't re-transmit packets of B.
I thought the monitor antenna (B was it?) was in range of the client (c?)


Who should I use for auditing/cerifying server software or specific deployment

You can get several things, if they need Assurance, you will need to get something along the ISAE3402. If you need pure security, you can hire a company that performs Attack and Penetration testing. There are several companies that perform this service, some more reputable than others. Most of the big 4 (Ernst & Young (<== My shop) , KPMG, PriceWaterhouseCoopers or Deloitte) perform these services and are in general, globally accepted. Consult with your client if they have a preferred company.

Just make sure that your client is clear what they want,  because pure A&P reports are often not accepted for Assurance.


How to crawl a web site if content is only visible to registered accounts?

Bad news: Both those attacks are absolutely realistic and practical.

Even more bad news: You can't really protect against this. You can make it harder to crawl your website, but you can't make it impossible. In the end, a motivated attacker will always win.

If you settle on just making crawling harder, here are some tips:

Rate limit, both on account and on IP. But the attacker can just use even more accounts and even more IPs or just let it take more time.
Captchas! But to stop a human from solving it once, and then letting the crawler take over, you'll need to serve them often. Perhaps on every page load. That is not great. And a lot of captchas can be bypassed, by software or paid humans.
Load sensitive content dynamically using JS. This will trick dumb static crawlers who just reads the HTML as a long text string, without e.g. executing JS. There are plenty of crawlers that act like full browsers though, and this will not help against those.
Make sensitive information hard to read by e.g. putting it in images instead as text. This is a usability and accesibility nightmare, and there is nothing stopping a crawler from saving the images or even doing OCR on them. So this isn't a real solution either.

If you want to make your content safe from crawlers, the only solution is to not give access at all to people you do not trust to keep their hands off.


Can a SSL certificate have longer validity period than its parent in X.509 chain?

This is an historically disputed point.

In the validation algorithm from RFC 5280 (that supersedes RFC 2459, by the way), there is no requirement of validity range nesting. However, some historical implementations have insisted on it; see for instance the X.509 style guide of Peter Gutmann:

  Although this isn't specified in any standard, some software requires validity
  period nesting, in which the subject validity period lies inside the issuer
  validity period.  Most software however performs simple pointwise checking in
  which it checks whether a cert chain is valid at a certain point in time
  (typically the current time).  Maintaining the validity nesting requires that a
  certain amount of care be used in designing overlapping validity periods
  between successive generations of certificates in a hierarchy.  Further
  complications arise when an existing CA is re-rooted or re-parented (for
  example a divisional CA is subordinated to a corporate CA).

The Microsoft PKI ("ADCS", aka Active Directory Certificate Services) enforces validity period nesting, in that, when it issues a certificate, it will not allow the end-of-validity date of that certificate to exceed that of the current CA certificate (in effect, truncating the validity period mandated by the template if it would lead to such a situation).

Even though, when renewing a CA certificate, it is possible to keep the same CA name and CA key, in which case both the old and new CA certificates can be
used interchangeably as long as neither is expired, on EE certificates issued both before and after the renewal. That is, if the old CA certificate is CA1, the new one is CA2, certificate EE1 was issued before the renewal and certificate EE2 was issued after, then CA1->EE1, CA1->EE2, CA2->EE1 and CA2->EE2 should all validate; this is very convenient to ensure smooth transitions. While the validity period nesting implies that CA1->EE1 and CA2->EE2 will nest, CA1->EE2 and CA2->EE1 might not nest -- and this is fine.

Summary: you cannot rely on validity period nesting, and you should not try to enforce nesting when validating certificates.


Is it helpful to have a captcha on a login screen?

The way I've seen some large systems do it is to only require a captcha after sequential failed login attempts (ie: reset the count after a valid login).  If you are worried about automated cracking, you could put the captcha at some high number of failures like 20, 50, 100 failed attempts.  Almost no legitimate user will see the captcha, but an automated attack will get hit by it.

Is it worth it to add this complexity?  Security and UX are trade-offs.  You need to find the correct trade-off for your risk profile.


Answering in reverse order, because your later questions are predicated on inaccurate assumptions in your earlier ones:

3: Not if the injection code is sneaky enough. In theory, a process can, of course, scan its own address space and detect stuff that doesn't belong. That procedure that does the scanning needs to be in the process somewhere, though, and in practice you can just edit it out when doing your injections.

2: Incorrect. Any process can be debugged by another process running with the same security token as the debuggee, or with a superset of the token's access (that is, a sandboxed process under user A can be debugged by a non-sandboxed process under the same user), or by any process with elevated privilege (SeDebugPrivilege, which is normally only Administrators but could be other processes). See, for example, WriteProcessMemory. If you want to make the memory executable, you'll probably need to have used/use VirtualAllocEx/VirtualProtectEx. If you then want to start a thread (in the target process) executing on your injected memory, see CreateRemoteThread.

1: You're confusing DLL injection  and something else, probably DLL squatting (which doesn't seem to be a well-known term, but it what I use and have heard used for when you place your own copy of an expected DLL further up the load path - for example, in the program's own directory - than the real version). DLL injection (where the process did not expect to load that DLL) is carried out in a number of ways, commonly using memory injection as above (inject the name of the DLL, use CreateRemoteThread to start a thread that calls LoadLibrary in the target process with the injected DLL name as the parameter). That DLL could then, of course, edit the process to do things like disable or bypass any introspection code that the DLL's author knew about.


Does the separation of the OS partition (C:) and data partition (D:) in Windows increase security?

My opinion is that with correct permissions, in Windows, the
  separation of partitions does not increase security because what is
  most important are the permissions and the separation of the
  partitions do nothing.

You are quite right. Malware is not concerned with partitions, although I recall a few that do. Partitions are just a division of space that makes sense to the user (Docs on D, games on C, etc..).

I must note; this applies to Windows, but in Unix it is well known practice to separate partitions and mount them with special permissions (nodev, nosuid, noexec) and this does increase security.


How to help users manage password portfolios based on risks of compromise?

This is an open research question, actually.

It's a bit hard for users to cope with security advice; just like choosing strong passwords takes time, rationalising over password reuse does so as well. You're probably aware of The Compliance Budget and More is Not the Answer since you cite Herley.

So, it's unlikely that a conscious security awareness program is fruitful in the general case because it'd take up more effort, time, cognitive load for users (if they decide to pay attention to it at all) and this is what is already spare. It'd be very difficult to experimentally validate that a password strategy awareness scheme pays off. You'd need to show that the time and effort investment is made voluntarily by users in their real-world settings (something extremely few people in our field acknowledge because it'd make them publish slower :) ), and that the cost associated to it is significantly lesser than the benefit it provides in simplifying password handling for end-users. You'd need to do that for various systems and participant demographics to have a viable end-user strategy.

You could do training on specific populations for which the training time can be acknowledged as part of their primary occupation. For instance, system administrators and executives are high-risk populations and their employers would be wise to explicitly allocate security training and security management time for them.

For the general end-user population, it's probably better to outline the value of assets to be protected when choosing a password rather than insisting on using strong and unique passwords. For instance, email, online payment and bank accounts must retain unique passwords. Other sites should allow more flexible options such as federated ID, one-time passwords (based on email/phone) and weak passwords. Since you're citing current research from some of the topic's world experts, you probably know there's nothing better out there already.


My email address is being used to enroll for online services. Should I be concerned?

Should I be concerned about this?

Yes.

This should be of concern to you because an attacker was able to obtain the valid password for your Gmail account. From the details of warning you have provided, it looks like it is from fraud detection rather than an OTP failure. If it was an OTP failure, you would have received an OTP when that login attempt was made (unless your OTP delivery mechanism is not email or SMS based).

You should explore the possibility that your password may have leaked. Do a search on HaveIBeenPwned to see if any of the websites where you have used that email were compromised.  It is likely that you may have used the same password for signing up to a trivial service and forgot all about it.

The the intention of attacker was not to use your email to enroll these services, rather it looks like an attempt to verify if you are a user of any of those services.  Most sign up options would ask you to login instead of sign up if you have an existing account with them. From the looks of it, the attacker wanted to identify the services you are already enrolled to with that email and wanted to try the same password on them.

To sum it up again, yes you should be concerned. You should explore why you are being targeted in the first place and how that initial password compromise may have happened.


Standard for Generating Multiple WEP Keys From a Passphrase

Shamelessly stolen from the client-side JavaScript code of http://www.wepkey.com:

function wepkey64(val)
{
    var pseed  = new Array(4);
        pseed[0] = 0; pseed[1] = 0; pseed[2] = 0; pseed[3] = 0;
    var randNumber;
    var k64 = new Array(4);
        k64[0] = ""; k64[1] = ""; k64[2] = ""; k64[3] = "";
    var i, j, tmp;
    for (i = 0; i < val.length; i++)
    {
        pseed[i%4] ^= val.charCodeAt(i);
    };
    randNumber = pseed[0] | (pseed[1] << 8) | (pseed[2] << 16) | (pseed[3] << 24);
    for (i = 0; i < 4; i++)
    {
        for (j = 0; j < 5; j++)
        {
            randNumber = (randNumber * 0x343fd + 0x269ec3) & 0xffffffff;
            tmp = (randNumber >> 16) & 0xff;
            k64[i] += bin2hex(tmp);
        };
    };
    return k64;
};

// converts one byte to a 2 chars hex string
function bin2hex(val)
{
    var hex = "0123456789ABCDEF";
    var result = "";
    var index;
    index = (val >> 4) & 0x0f;
    result = result + hex.substring(index, index+1);
    index = val & 0x0f;
    result = result + hex.substring(index, index+1);
    return result;
}

Call wepkey64("your key") to calculate the four 64-bit keys. They will be returned as an array.


Can the Host Header be used to hide the existence of a service?

The only way to determine the other name based virtual host on the same IP address is to perform forward lookups to all domains and see the A records with the same IP addess. Only after that it's possible to see whether the server is responding to all these hostnames through the Host header or not, and is the reponse same for every hostname or are there different services.

Knowing that, it's indeed possible to hide a service like this, but it would still be security through obscurity. While someone might be using this, it has some disadvantages:

The secret hostname may leak by accident, which makes "the Host: header" a rather bad place for a password. This may be caused by:

A request through a 3rd party DNS service. It doesn't make this less bad at all that DNS is typically unencrypted and that it may be cached on multiple recursive servers.
If the hostname is on a public authoritative DNS server, it may be vulnerable to insufficient zone transfer restrictions or DNSSEC zone walking (possible with older NSEC records, fixed by NSEC3, RFC 5155 & RFC 6781, 5).
Server Name Indication (SNI, RFC 6066, 3) reveals the hostname, as it's part of unencrypted ClientHello on all TLS versions prior 1.3 (how encrypted SNI works).

Depending on how the hostname leaked you might still need to know which IP address to connect to, but that's merely a slow down.

The IP address would be hidden if the A record was only available on a DNS server on a private network, but that would make it hard to use the service outside the network: in that case it would be better to have the service on the private network, too.
If the IP address was on the local hosts file, it's still available on the IP packet header for anyone who could see your traffic on the network layer (L3). That would include anyone who already got the hostname by monitoring your DNS requests or SNI.

Difficulties with TLS implementation.

You won't get a certificate for an arbitrary fake address.
If it was a subdomain of your real domain...

A certificate issued for the subdomain would reveal the hostname through Certificate Transparency (e.g. https://crt.sh/?q=example.com)
e.g. Let's Encrypt requires it to be publicly available for the ACME challenge.

Suitable ways to circumvent this would be

an own internal certificate authority
a wildcard certificate *.example.com covering the "secret" subdomain.

Because it creates more problems than it solves, I wouldn't recommend it. Password protection with multifactor authentication and possible client certificates are better options, and hiding the location of the service doesn't really add much security over that.


Does escaping quotes in a HTML attribute context prevent XSS?

Yes, XSS is possible.
Escaping is not a proper defense against XSS in a HTML attribute value context because the HMTL parser doesn't care about escaping (it only cares about encoding).
When you have
, browsers will interpret foo as an attribute and bar as a value.
So why isn't your payload firing? Because onload is not a valid attribute for div. What will work is a payload such as test\'onmouseover=alert(1) :

test

In some browsers, you can also gain XSS without user interaction in a div, see eg here.


Social Engineering and Reverse social engineering are mainly used in computer security however they can be applied outside this field as well.

Both social and reverse social engineering exploit the non-technical human weakness in security therefor the actual exploitation occurs outside the computer.

One example of social engineering is creating distrust, which in fact can be used in reverse social engineering as well. After creating distrust between two target parties (possibly by falsifying or altering information) he can then introduce himself as a "mediator" for fixing the conflict. The mediator is then able to acquire security information from both parties.

Another example is causing a maintenance problem in a building (power black-out) and then arriving dressed-up as the maintenance repair-man to fix the problem and in doing so, gain access to the building and maybe the sensitive systems inside.

The main reasons that make social engineering attacks successful are:

Poor Security Awareness: An extremely large
percentage of users do not understand the importance of a password for authentication and
access to a computer system. They do not realize that their account can be accessed from
anywhere in the world, given the proper access point.
Users also do not understand the lengths that people will go to obtain the information
that the users have access to on a daily basis. They also do not realize that throwing
something in the garbage does not mean that the information is destroyed. What is garbage
to a user might be extremely valuable to a hacker.
Human Weaknesses: People give out information for many reasons. In most cases, they just want to be
helpful, because that is their job and/or nature. People can also be intimidated to release
information, either by being made to believe that a superior wants the information or by just
trying to make an annoying person go away.
Untested Plans and Procedures: Organizational procedures that require an authenticating mechanism must carry with
them additional procedures that protect the mechanism. This is where a large number of
security plans fail. Many organizations test a specific part of a security plan or procedure,
but these plans and procedures must be tested as a whole.

Based on the above, most social and reverse social engineering scenarios are based on technology because the general public is not aware of the security significance of certain information. But social engineering was used long before computers were born (the words "con" and "scam" refer to a more general non-technological form of social engineering). However with the evolution of technology there has been new and intuitive ways to accomplish this procedure.


Workarounds for :visited CSS History reconnaissance

It is still possible.  However, it is much harder to do unobtrusively now.  See the following research paper for details of how to do it:

I Still Know What You Visited Last Summer: Leaking browsing history via user interaction and side channel attacks, Zack Weinberg, Eric Chen, Pavithra Ramesh Jayaraman, and Collin Jackson, IEEE Security and Privacy Symposium 2011.

Please do not use this to spy on visitors to your web site without their consent.  That has the potential to be a bad business move.

We've been through this before.  The last time some web sites tried using CSS history sniffing, they eventually got caught.  The fact that they were using history sniffing got into the news, and caught the attention of the FTC and many others.  Lawsuits were filed, and investigations were opened.  So I think we have solid evidence that if you history-sniff your visitors, you are asking for trouble.  For more information on this, see the following sources:

NAI To Probe Epic Marketplace's 'History-Sniffing' Techniques.
Suit to Snuff Out 'History Sniffing' Takes Aim at Tracking Web Users.  Note the quote from the FTC official.  It's not good when the FTC is willing to make a public statement expressing concerns over your business practices.
The FTC Promises an End to History Sniffing (Microsoft, Take Note).
Browser History Sniffing in the News.  Excerpt: "Clearly, companies know it’s a bad practice to sniff browser history. In fact, it’s probably illegal too."
History Sniffing
The research paper that kicked off all of this: An Empirical Study of Privacy-Violating Information Flows in JavaScript Web Applications, Dongseok Jang, Ranjit Jhala, Sorin Lerner, and Hovav Shacham, ACM CCS 2010.


A VPN encrypts your traffic between you and the VPN provider. The traffic appears as if it is originating at the VPN provider.

With that said, there's many other ways to identify someone other than their IP.

Cookies set in the browser
User agent
Various other fingerprinting (canvas, resize, visited links, flash, Java, webrtc, location API, etc.)

If you're attempting to post anonymously on a forum you're banned from it may evade a IP ban, but you could be identified from other logged information (most likely would be a full user agent match since those are saved on most server logs by default)


Bouncy Castle - document signed by sender and only readable by receiver?

The BouncyCastle OpenPGP or S/MIME packages should allow you to do what you want. OpenPGP will be more appropriate when using OpenPGP certificates (often only referred to as "PGP public keys"), whereas S/MIME will be more appropriate when using X.509 certificates.

There's no "double-signing" involved: you'll sign with the sender's private key and encrypt with the recipient's public key.

GnuPG (or other implementations of OpenPGP) should allow you to test the results if you use BouncyCastle's OpenPGP implementation.

Note that you should sign first and encrypt afterwards, not the other way around, on the basis that the signer should be able to look at what it signs, and the recipient to be able to decipher and read, but keep the signature attached if necessary.

There doesn't seem to be many BouncyCastle OpenPGP examples around, but this blog entry looks rather complete (although I'd still sign first and encrypt afterwards). Compression is also taken into account.


Is there a way to download the Firefox Phishing and Malware Protection list?

The phishing and malware protection in Firefox is provided with Google Safe Browsing service. This is not a list you can download.

It is instead a database with an SDK on top of it which provides an offline way to determine if a specific URL might be dangerous and which requires in the positive case an additional online verification to eliminate false positives. This additional check is necessary since the blacklisted URL's are not stored in plain but are hashed which might lead to collisions. This hashing is done so that the information can be stored in a memory efficient way and also so that the blacklist cannot be reversed. For more information see the API documentation.

  I'm building an app that needs to check bad websites  ...

Depending on your use case you can use the provided API for free or you have to use the commercial Web Risk API.


What additional methods for user tracking are there?

I suspect this list could be made much longer, but just from the top of my head:

E-tags and other cache mechanisms
HSTS (and perhaps HPKP?)
Local storage
Flash, may it rest in peace (perhaps included in "super cookies")

Basically, you can use anything that creates some sort of state in your browser, that affects the browsers behaviour towards servers. That includes a lot.


Certificates are signed. The signature covers all the certificate contents, including the Key Usage extension. You cannot change anything in the certificate contents, not the smallest bit, without invalidating the signature. So no, you cannot "change" a certificate. Certificates are immutable by construction.

Your certificate vendor might accept to give you, or sell you with a discount, a new certificate which fits your requirements.


How to detect if a site is using a JavaScript exploit?

Code is neutral. There is no intrinsic difference between code which fulfils some functionality, and an active exploit, except that in the latter case you would prefer it not to happen. The difference is in your head, not in the code; computers cannot detect it automatically.

This is a fundamental property of IT security: there is no reliable test to know whether a given piece of code is benign or malicious. At best, we can:

Enforce benignity with heavy constraints, e.g. with NoScript: if the code cannot run, then it cannot harm.
Try to prune out malicious code by inspecting its source: allowing code to run only if it comes from a trustworthy source, and we have some reasonable assurance that what we got is indeed what that source sent (i.e., in a Web context: Javascript from a specific HTTPS Web site that we decided to trust).

I agree that this is unsatisfying. Unfortunately, the World has a tendency to be such.


Does enabling EnableLinkedConnections pose a security risk?

I found an answer from Jon Schwartz, UAC Architect, which provided the following details:

  Mapped drives get interesting in combination with the "split-token" account, because of a weird dichotomy in the system (in large part historical) -- the drive letters are per-user, but the underlying drive mappings are per-LUID (i.e., distinct for each individual logon, even for the same user).  This is why the mappings disappear when you elevate, and the setting you found tells the OS that you want the mappings you make non-elevated to be mirrored into your elevated context as well -- under the covers, the NTLanman network provider maps the drive and then asks the LSA to find the associated elevated token and use it to mirror the mapping.

As for any vulnerabilities, Jon had this to say:

  Technically, it opens a small loophole since non-elevated malware can now "pre-seed" a drive letter + mapping into the elevated context -- that should be low-risk unless you end up with something that's specifically tailored to your environment.

This is from 2007 and mostly applies to Windows Vista, though. I don't think much has changed since then. Since we are still using Windows 7, I should be fine, I guess.


I understand it is a bit late for your assignment ;) but for other students who may be groping in the dark with similar problem, here goes...

Python is written in C, and the C executable is throwing the segmentation fault error. To understand segmentation fault you need to run Python itself in gdb (GNU Debugger assuming you are on Linux/Unix) and then pass in your script as the parameter and then step through the C code written for Python.

It is quite possible that you have have caused a buffer-overflow within the python interpreter to have caused a segmentation fault (so that's good!). Though I cannot say for sure in the case you are executing here.

I have studied one of the vulnerabilities of Python in detail and blogged about it. It affects older versions of Python 2 and 3. I downloaded the Python source and built the source with debugging on.

Next I figured out how Python works and executed Python scripts on the built interpreter and stepped through them in GDB.

I have uploaded my work on my Blog (http://yazadk.wordpress.com/2014/12/10/remotely-exploitable-buffer-overflow-in-python/) - though mind it we were specifically looking for C programs that had buffer overflow available in the wild and I happened to choose Python which is written in C.

I hope this gives you some basic insight in what you or anyone else is trying to achieve.


Why wouldn't you institute Strict-Transport-Security headers?

I read recently that HSTS can cause problems with site access.

Yes, HSTS can lock visitors out.

Note that a misconfiguration of HSTS is less likely and serious than for HTTP Pulic Key Pinning (HPKP), which it's often confused with. HPKP can be tricky to implement because it requires you to work with public keys, whereas setting up HSTS is quite straightforward.

To recap, what the HSTS header does is to instruct clients (browsers) that they may only access your site over HTTPS in the future (for a specified time) and not attempt any plain HTTP connection.

In these situations you should be careful with HSTS:

You don't know how long you will support HTTPS in the future. If you send a HSTS header with a high max-age and switch back to HTTP during that time, you risk locking out previous visitors. That's because if their browser has seen the header earlier, it will block all attempts of a plain HTTP connection until expiry.
You need to maintain some plain HTTP access, particularly on subdomains. Here you should make sure you don't set the header's includeSubDomains flag. Otherwise, you deny HTTP access for all subdomains as well.


Logging error details in a (desktop) client application

Let's try looking at this using threat modeling techniques.
What are we trying to protect?
Client logs for later analysis by support.
What is our risk?
If a client-side handler breaks and is stored on the client side, what could this lead to? Are we looking at having a local command execution, log injection, etc.? It is essential to understand what the application provides, and what could be compromised.
Yes client-side is always dangerous, that doesn't mean it can't be protected or understood.
What's our attacker like?

Basic user: Scrapes the history of the application, tries to search for the files on the system, mainly conducts basic lookup and recon.

Risks: tries to understand and haves fun with what breaks the UI controls and how they can change the output. If the logs contain secrets disclosed, they'll be able to grab them and abuse the system (or blackmail the org).
Mitigations: employing symmetrical encryption protects the logs as the user don't have enough knowledge to reverse engineer the application and grab the key. If the logs sanitize the input and don't output secrets, the risks are almost non-existent.

Advanced user: on top of the Basic User, this user is capable to have a stronger understanding of what is breaking, and tries to fuzz the service in order to force an unhandled behavior (which could break it). This user is capable to reverse engineer and extract strings from the application if stored.

Risks: by identifying how the application behaves, this user is capable to study the client application, identifying its weaknesses, and possibly find issues in it (DoS, local execution, etc.). This user will in most cases report the vulnerabilities or issues to the company behind the application.
Mitigations: Create a mapping of the errors with codes which are only known by support. The user will be able to know the exception triggered, but not the details of how it broke exactly and what's happening. Becomes a blind attack (harder to achieve). As u mentioned, asymmetrical encryption can be used. What you can do to speed things up is the use of a nonce with the key in order to create ephemeral sessions, which requires from the user to instantly break the logs and look them up, otherwise only support can get it.

Malicious user: similar to the advanced user, with clear intent to cause damage.

Risks: the user builds exploits to try and own other users' systems, destroy the company reputation, etc.
Mitigations: in this case, if the application is actually exploitable, the user will already have identified what's happening, and encryption is almost meaningless at this stage. The logs would only confirm the analysis of the attacker. Since this is specifically related to logs, asymmetrical encryption should be used, with possible triggers that call back home if a certain activity is launched or done (system takes too long to conduct a task, a system command is executed, network exfiltration, etc.). This allows for proactive controls which is the best mechanism to protect your user-base.

In all cases, the network attacks are not catered for. The nonce is a public entity, thus always retrievable. Otherwise, no specific secrets were communicated through the channels. I mainly focused on application behavior. There are no major network attacks related to the above approaches.


How can I validate the authenticity of SSL certificates when Blue Coat is used?

Bluecoat and other firewalls do SSL interception to analyze HTTPS traffic for malware too. To do this they create a HTTPS connection between the firewall and the server and a new HTTPS connection between the client and the firewall. Of course this new connection can not have the original certificate of the server, since the firewall does not have access to the private key of the server. This means that the firewall will create a new certificate signed by a CA at the firewall.

To validate this new certificate the client has to trust the proxy CA of the firewall. Usually this is done by adding this CA as trusted to all computers inside the company. But, different applications use different trust stores and this certificate is usually only added to the OS specific trust store, which means that in Windows only IE and Chrome will automatically trust the proxy CA. For any other applications you need to explicitly add the CA as trusted. How this is done depends on the application but for pip you might find help at this question.


What are good resources to do hands-on practice on network penetration testing?

Check out the following:

Metasploitable - The Metasploitable virtual machine is an intentionally vulnerable version of Ubuntu Linux designed for testing security tools and demonstrating common vulnerabilities.
Metasploitable 2 - The Metasploitable virtual machine version 2.
Damn Vulnerable Linux - Damn Vulnerable Linux (DVL) is a Slackware and Slax-based live DVD. The distribution, purposefully stuffed with broken, ill-configured, outdated and exploitable software.

Edit: Fixed url to Metasploitable


Timing attack - Is safe to check if strings have the same length?

You are correct this implementation of constant-time string comparison will  leak information about the length of some string that is being compared against an attacker controlled string.

However, if this is checking strings for authentication purposes, you never should be comparing raw strings.  You would first hash (preferably with a salted key-stretched hashing function like bcrypt or PBKDF2) the entered password with the salt taken from the database and compare against the hashed password from the database.

In such a scenario where a password login could potentially work, the lengths of the compared hashes will always be identical (regardless of what string the attacker enters).  Now, there may be scenarios where the lengths aren't identical; e.g., maybe you used to use sha256crypt but decided to migrate user hashes to bcrypt.  So you explicitly check whether the user-entered password works against either hash which have different lengths, and there's no vulnerability if different lengthed hashes fail quickly.  (Obviously it makes more sense to use an identifier to track the hashing algorithm you used).  Or you use client side code to hash first and then transmit the hash and the attacker tweaks the sent hash length.  If they send an incorrect length, there's no problem to fail quickly (it's not like the correct hash length is a secret).

You do have to be careful about writing code like the following python code:

def bad_constant_time_str_compare(str1, str2):
   ret_val = 0
   for c1, c2 in zip(str1, str2):
       ret_val |= ord(c1) ^ ord(c2)
   return ret_val == 0

which seems like it should work, until you recognize that bad_constant_time_str_compare('hello', 'h') returns True because of how zip works (stopping at the length of the shortest string).

You could fix this with say:

def better_constant_time_str_compare(str1, str2):
   ret_val = 0
   for c1, c2 in zip(str1, str2):
       ret_val |= ord(c1) ^ ord(c2)
   return ret_val == 0 and len(str1) == len(str2)

but if you think about it, it is still vulnerable to timing attacks leaking the length of the string.

Finally, you should recognize that constant time string comparison in principle leaks information about the length of the two strings being compared -- the running time will be proportional to the number of comparisons run.  You could try to mask that (e.g., add random wait time), but in principle any secure system will not be weakened in any practical way by knowing the length of the strings being compared.


I think the answer to that is 'it depends' - I was looking at something similar recently, for example the IPs issued to the AT&T phones we tested all resolved to an Atlanta, GA address - even though none of the devices were within a few hundred miles of Atlanta.

Different carriers are likely to yield different results though - some may yield more accurate results than others.

Trying to tie an IP to a physical location is often unreliable, it depends on the service provider to provide more detailed information about smaller IP blocks than they typically do. It's that much more management overhead.

I never assume that the location mapped to an IP address is correct.


Is it possible to locate web document root using SQL query/SQL Injection?

If you have permissions to write files, you probably have permission to read them, too.
I'd start from reading web server configuration files, e.g.
SELECT * LOAD_FILE('/etc/apache2/apache2.conf');
SELECT * LOAD_FILE('/etc/nginx/nginx.conf');

However, it's not guaranteed that the MySQL has permissions to write to the document root.


How much money does it take to equip a fully funded black hat team? How much money to defend against such a team?

$2500 is all it takes to get a black-hat operation started

In 2009, it was reported that US banks lost more than $140M from Internet heists, as quickly as $10M in one 24-hour period.

I believe it is possible to start a criminal operation with as little as 2500 US dollars.

Cloud servers: 300 US dollars for 3 months
LAMP stack: 0 US dollars
Malware that can steal money from banks: 700 US dollars (ZeuS, although sub Meterpreter)
Web exploit delivery/management system: 800 US dollars (Fragus, although sub Drivesploit)
An affiliate system using advertising to drive traffic/eyeballs: 700 US dollars (or a nice SQLi or RFI botnet)

Total: 2500 US dollars

My proof

Brian Krebs runs articles on Security Fix focused on fraud. There are countless examples, but let me pick on this one regarding the county of Kentucky, who lost 415000 US dollars in 2009 to the exact situation I created above. This particular one involved 45 or so wire transfers in amounts just under 10000 US dollars. Considering mules were paid about 500 dollars each, and the whole operation involved 2-4 UKR scammers, you are still looking at a 391k score split 2-4 ways, with almost no investment other than the time to babysit the money mules and grease over the affiliates (oh and that initial 2500, lest I forget that!).

The skills of these scammers can also be very, very low. This isn't even college level system administration. Anyone with a summer interest in Linux could get this operation going. Yes, there is also the money mule piece, which perhaps takes a good scammer with some experience and way above average charisma -- but we assume that at least one of out every 3 criminals already has these skills.

Go back to any of those articles and reverse engineer what you think it took the criminals/scammers to get their job done.

The Cost of Defense: 6-7 percent of IT budget

You've seen the cost of PCI DSS compliance numbers no doubt; ignore those for a second. Gartner says that the security budget should be in between 6 and 7 percent of the total IT budget. UMD professors Lawrence Gordon and Martin Loeb say not to spend more than 37 percent of the asset you are trying to protect.

Staff your org with incident handlers to the number of incidents

I say that we need to hire to the incidents. If you have 1-400 incidents a year, you are going to need somewhere in between 1-400 security incident handlers. Calculate the time involved in handling the incidents and hire accordingly. I am perfectly fine with staffing taking up the entire information security budget and so should your IT finance decision-makers. People play the most important role in an information security management program.

If you haven't had any incidents, perhaps now is a good time to hire an incident response and forensics / malware research company to come in and determine if you have actually had an incident or not (let's say this is a 20k one-time assessment). While that's going on, stay on the safe side and hire at least one FTE incident response manager (100k/year) -- especially assuming you have at least 250k worth of stuff to steal, or brand damage to be done.

Monitor your apps, systems, and networks

Hand your new incident response manager an OSSIM CDROM to install in an AMI instance or whatever. Email can be sent to his or her GMail/GApps account for all I care. The point is that most companies overspend on firewalls, VPNs, and "security server hardware". I think most companies would be better served with an open firewall and access-list policy, but using the bogon filters and FATF Blacklist as null routes on every router or system with a public IP (or NAT/PAT'd to one). Give the manager at least enough budget to cover the cost of TruArx for the year if there is no other risk management portal in place already.

Give risky job roles safe tools and awareness training

Finally, equip any worker that is handling financial, banking, or payment card information (or anything else with a severe data classification) with a freaking iMac or Mac Pro and training to go with it. Make sure they have to complete some sort of SaaS-based security policy and awareness training with providers such as Cornerstone OnDemand. This may in fact be the cheapest answer to the problem, but this is the TRUST not the VERIFY. The incident manager/team provides the verification. There have been reports of targeted malware inside large-installation Mac-centric companies, although they are not hit quite as bad on the drive-by-download frontal assault. If Win7 is required, then implement a rollback-before-every-transaction VM-guest strategy.

The Cost of Application Security Defense

The real expense comes if your company or organization doesn't buy COTS, but instead rolls their own code (or outsources app development). In this situation, things can get really expensive in the long-term if the org doesn't start a very thorough appsec program before the design and coding starts. Even then, most co-ordination with application security consulting companies costs at least 1-4 million dollars over 2-3 years. If you have 10M US dollars worth of applications to protect, this should be a no-brainer -- it's going to also increase the quality of the apps and your business intelligence. It is also where the Gartner IT spending strategy tends to fall down for information security management programs, especially considering that firewalls still take up over 50 percent (and some as high as 90 percent) of Fortune/Global 2000 security budgets.


File shares from a DMZ into an internal network

What's wrong with SFTP? You can mount it as a drive if WinSCP isn't enough and they really must have it look like a Windows folder.