Does a Mailbox Export Request modify the mailbox data?

Mailbox export request is the industry standard way to export data from Exchange for compliance, audit, and compliance purposes.

No data is modified, BUT it is possible to constrain the output to a certain date range, search for specific content, or include/exclude different folders.

If the archive parameter is set, then data will be removed from the mailbox.


Best source(s) for security related news?

For a site I would recommend the SANS Internet Storm Center at https://isc.sans.edu/.

I find the most useful for news for me is a twitter list of security professionals and researchers such as.

@sans_isc
@uscert_gov
@schneierblog
@gcluley
@duckblog
@markrussinovich
@jeremiahg
@briankrebs
@mikko
@hdmoore
@dakami

You can probably find other lists of security related twitter users that would be worthwhile to follow.


In my option you need to think of atleast two factors when implementing the message services. These are authentication and authorization.

Broker authentication

Authentication is the process of making sure the entity's intregrity is intact. Usually this is done by supplying a password. ActiveMQ supports JAAS and also has an API that supports custom built authentication plugins.

The easiest way to implement this is to configure your broker xml file to only allow authenticated users. Example which could be placed under the <plugin> tag in your xml:

<simpleAuthenticationPlugin>
    <users>
        <authenticationUser username="admin" password="password"
        groups="admins,publishers,consumers"/>
    </users>
</simpleAuthenticationPlugin>

The groups provided will be usefull for the authorization of the user. Very usefull when you need to only allow some services to some user groups. Use the createConnection(username, password) method for the authentication procedure.

Broker authorization

Authorization is all about allowing an entity access to a secured resource. Often implemented with the help of ACL's. The following sample XML will provide authorization on a destination:

<authorizationPlugin>
    <map>
        <authorizationMap>
            <authorizationEntries>
                <authorizationEntry topic=">"
                    read="admins" write="admins"admin="admins" />
                <authorizationEntry topic="YourTopic.>"
                    read="consumers" write="publishers"
                    admin="publishers" />
                <authorizationEntry topic="YourTopic.Stats"
                    read="guests" />
            </authorizationEntries>
        </authorizationMap>
    </map>
</authorizationPlugin>

Note that the > wild card provides the authorization scheme recursively to anything under that path.

Message level authorization

Sometimes it can be usefull to add authorization at the message level instead of at the connection level. This is done by creating a java class MessageAuthorizationPolicy thus forcing you to implement the method boolean isAllowedToConsume(ConnectionContextcontext, Message message) . Here you can implement your own criteries of authorization.

To put the authorization policy in good use you need to install and configure it into your ActiveMQ setup. Basicly it is done via these steps:

Compile your class into a JAR file
Put the JAR in ApacheMQ's lib folder
Add a proper messageAuthorizationPolicy element to your configuration
Restart ActiveMQ


If an adversary took over a major Certificate Authority, what bad things could they do?

This has happened.  In 2011, the CA Diginotor was breached by a malicious actor, enabling the malicious actor to issue fraudulent certificates for any site on the internet.  These certificates were trusted by most web browsers, because most web browsers had Diginotor's root CA certificate installed in their trust stores.  This made it possible for anyone with control of a user's network connections to pull-off a man-in-the-middle attack for connections by that user to any site on the internet.

In the case of the Diginotor attack, it is suspected that the Iranian government took advantage of the Diginotor breach to issue false certificates for gmail.com, then used these certificates to conduct MITM attacks by way of its state-run ISP's to spy on its citizens' gmail accounts.  Comodo may have also been hacked.

Nowadays, there are standards in place to protect against these types of such as DNSSEC/DANE.  But, adoption has been slow.

What's scary is that it could happen again.  And, it wouldn't even require a hack. The malicious actors would simply need to write a check, and acquire a CA.  A number of CA’s have been acquired in recent years for under $1B (e.g. Symantec's CA business was acquired for $950M in 2017), which is nothing for a well-funded terrorist group, and pocket-change for a rogue nation.


There are two things you can do.

The first thing you should look into is HTTP Strict Transport Security (HSTS). It's not pinning, per se, but it allows you to tell a browser to only ever visit your site over HTTPS, to prevent SSL stripping attacks.

As far as cross-browser pinning goes, there's no solid solution. However, there's a draft specification for a pinning header, which is explained briefly here. I have no idea what browser support is like for it, but it may be adopted in future.


Burp suite doesn't send accept-encoding header

Under the proxy options there is a setting "Strip Accept-Encoding headers in incoming requests". Disable this if you want gzip encoded responses.


Firefox add-ons are an XPI file. You have to locate them and then just right click and extract them using tools like 7-Zip.

If you can't locate the addon on your computer then just go to the download page where you can download that particular addon --->  Then right click and select save link as or save target as and save the addon file to your local disk.

After that simply open the .XPI file with any zip extraction software like 7-Zip or WinRAR. The extracted contents might contain the code files.

  PS: You can't get source code of every addon by just extracting the addon file. For some add-ons the extracted content may not contain the code files!

If the addon is open source, you should be able to find the source code of addon on respective website.


Besides Plain-Text passwords, is there anything to worry about with sites that don't use SSL?

MITM is the main issue, anything that is capable of monitoring your transmissions can capture/replay data - and of course dynamically change data - with impunity.

This is really bad practice for any site and you should let them know immediately.

Ideally, you should not use the site. If you feel you have to, make absolutely certain you do not give any data that might be used for identity theft, phishing or similar attacks.

I always find it really remarkable that, in this age of cyber attacks, that some site owners and some users still seem to have absolutely know clue that this is an issue.

If, as implied, this is just a forum site, I would still ensure that I didn't use my "normal" email address and certainly I wouldn't reuse a password. Also be aware that it is possible (though I admit not that likely) that someone could easily impersonate you if they wanted to.

There is no excuse for this - even cheap hosting sites will generally offer a cheap shared SSL/TLS option which is enough to stop all but the most determined and resourceful attackers.

For Update 2: Immediately remove any personally identifiable data and ensure you have no financial data registered. If you did register financial details, report the site to your bank/credit-card company immediately - it is likely that the site would loose their ability to sell.

If you reused an email address, try to change it as quickly as possible. Many mail services allow name+something@domain.com or whatever, e.g. you can add a +something after your name though not all registration functions will accept a plus symbol (though they should as it is part of the RFC). If you can't do that, try creating a free mail account (e.g. Gmail, Outlook.com, etc) and use that instead.

If you reused a password, change the reused password on all other sites straight away & turn on two-factor-authentication wherever possible to help prevent identity theft.

If you shared your physical location or other personal details, you should just monitor the situation - after removing the details - it is actually very unlikely that anyone will have been able to do anything so don't panic, just be sensible. Also, even if you only share your City or county take note if you have an unusual name for your locality. Maybe think again about sharing in that case.

Update 3: Having SSL on the login input page, the login transactions and any user profile pages is the absolute minimum for a site that has a login. You must also have it on any secure transactions of course and that includes any session interactions. It is all too easy to make a configuration mistake. Also, it is easy to end up with other pages over time that should be protected. There are also some standards that require all interactions to be over TLS. So you can see that it is by far the best practice to simply make everything TLS secured and have done with it.


I've figured out that it was an in-built Chrome search toolbar that was enabled, that I have mistakenly taken for a virus/malware. Thanks out to those who deserve it.


I found this thread: http://ubuntuforums.org/showthread.php?t=1900623

In summary, port 49152 corresponds to nPNP port in some routers (in that thread is a D-link wbr-1310). Disabling it closed that port.

About port 256, as it is related to VPN, look into the VPN settings in your router.


I figured it out, when you are connected to a wireless AP the gmail applications default to using the better connection so it uses the routers located here with their IP.

When I m connected to the T-Mobile network I send it over to the company in Illinois.

I know it seems self evident but both my work and home connections are remembered on the phone and there's no where else i use it much so it makes sense to see the sporadic dates associated with that IPv6.

Still interesting to know where my data goes when I'm connected to their network.


There are different ways to go about this. First of all I would advice you to upload a shell onto the web server which allows for interactive bash commands. There are tons of them out there, not sure if there is one for java. If you don't find one just create a simple script which performs a reverse TCP shell bind to your IP (you can use netcat, if you aren't familiar with netcat lookup some tutorials).

From here you already have some easier control so you can go looking in files for interesting content. Check the logs for usernames/passwords and go looking for executables with the SUID bit set. Also try to find out what other services are running (these might be exploitable) so make a nice service enumeration. Make sure to check the version of the kernel when you are on there as it might be possible to create a local root exploit (check exploit-db and google).


There's no way to be certain that someone with physical access to your server can't get at your data. But you can take certain precautions:

First of all, if the attacker gets access to your server while it's in its "running" state, so either through the console, through remote desktop, SSH, etc., then there's not a lot you can do. You're relying on your OS protections to save you while the server is operational. Not a lot more you can do there other than what people talk about every day.

But normally an attacker can circumvent your OS by powering down the system and bringing it up in "rescue mode" mounting your drives in another machine. You protect against that attack using encryption.

There are several whole-disk encryption systems out there. TrueCrypt is well known, and LUKS/FreeOFTE is another reliable one. BitLocker and other closed systems may or may not be secure; you don't really know because you don't know what's in them.

Obviously if you use a system like this, then your server boots into an unusable state. That's rather the point. So you must be logged in to bring the server online. If you can get a remote low-level console (e.g. IPMI) then you can type in the password at  boot to unlock your drive.

Alternately, you can put your sensitive data on a separate data drive or parition which you unlock after booting up.

Or, a third option is to run your hardware simply as a VM hypervisor, and run your sensitive software on an encrypted virtual machine.

All three of these suffer from the weakness that if the attacker seizes control of your server but leaves it running where it is, he can modify the environment to capture you typing in your password when you bring the server online. There's no way around this flaw other than to take the server out of your attacker's possession.

But it is arguably better than nothing.


Risks of client-side encryption using Stanford Crypto Library

Javascript is sent from the server to the client; whatever cryptography you do client-side will provide security only insofar as the code which the client runs has not been altered in transit -- which means that SSL is still required, at least to make sure that what the client receives and runs really is the genuine implementation of your protocol.

This implies that if the server is hostile to the client, then the server wins and the client is doomed. Correspondingly, it is a futile endeavour to try to protect the client computations from the server. From this (somewhat simplistic) argument, we may conclude that it makes little sense to encrypt data on the client; just use SSL, send the data to server, and let the server do its job. The server is trusted, which means that if the server wants to betray you, then you are defenceless.

The Stanford Javascript Crypto Library is still good science, but it does not map well to the use of Javascript in a classic Web context. It would make a lot more sense as part of a browser extension or anything similarly scripted which benefits from a specific, independent, secure distribution mechanism for code.

(Note that all of the above applies even if your protocol is rock-solid from a cryptographic point of view -- and not many cryptographers would dare pretend that they can accomplish such a feat by themselves, without extensive peer review.)


password complexity policy for non "English" passwords

Most drive-by password cracking attempts are going to assume that the password is a subset of ASCII characters. However, targeted attacks (under the Advanced Persistent Threat model) are likely to discover that your users aren't using ASCII passwords and change tact.

As such, I suggest the following rules:

Identify which languages are likely to be in use, based on your user base.
Perform dictionary lookups for those languages, and deny passwords based on them.
Ask native speakers to suggest common non-dictionary words and phrases that might be used as passwords.

If you can identify character subsets for each alphabet, you can apply individual entropy scores to them. This allows you to require a minimum security for such a password.

Probably the most important part is user feedback. Ask your users to report problems they find with the password system on your site, and suggest ways to improve the system. Only a native speaker can really identify weak passwords ahead of time.


Should I use the root account on my Digital Ocean server?

It's generally advisable to not use the root user for everyday tasks, so I would recommend creating a different user account.


Is putting every username and password for our organization in a giant Google spreadsheet a spectacularly bad idea?

Without wanting to pick on Google, you should read the article by James Fallows in the November Atlantic Monthly. In brief, Fallows's wife's GMail account was compromised by a scammer. The scammer used her mailing list and old emails to generate a "Help, I've been mugged in foreign city and need money!" scam. On top of that, the miscreant deleted all of her documents and old email before she regained control of the account.

Consider: your shared document is no more secure then the Google account of your most careless team member. While Google's security may be generally better than yours in theory, it's also a more prominent target, and can easily be undermined by carelessness on the part of a user.

You may incorporate the Google cloud into your infrastructure, but you can't just assume that Google is going to take on all the responsibility for your security. Nobody will care about your data as much as you do.


What is the point of encrypting the home directory?

The point is to protect against your disk being accessed outside of the OS.

Encryption is useful against attackers who have physical access to your computer. Without it, it would be trivial to read out the content of your home directory, for example by plugging in a live boot USB stick.


Implementation of Blizzard's Mobile Authenticator

There's a Windows client at http://code.google.com/p/winauth/ which was made by reverse-engineering the protocol. They refer to http://www.wowwiki.com/Battle.net_Mobile_Authenticator_Specification as a description of the protocol, but it's rather sketchy.

You probably have to read the source to an authenticator to get a full understanding. There's one written in python at https://github.com/Adys/python-bna that would probably be the easiest to read.


Have you tried a packet capture? That would allow you to determine if the data is what you expect of SFTP.

Although why your web server is performing outbound connections to a server you don't know on port 115 is alarming to me and worth investigating.


Can web connections from a virtual machine guest using NAT attract attacks from the Web to the host?

The short answer is "yes". If a guest is infected, it could certainly attempt a vulnerability scan of other devices on your network, including the host OS. This is assuming you haven't done something like placing the guest OS's network adaptor into a different VLAN or something similar. I doubt you have. Another way to avoid this would be to leave the host OS with an IP stack that isn't configured, thus mmaking it unable to communicate with the rest of the network. This also assumes it doesn't grab an address via DHCP. This is certainly an option if you don't plan to use the host OS for anything other than running guest VMs. But if you use the host OS for anything network related, then this may not be an option.


In my interpretation of HIPAA/HITECH, NO, it should be encrypted.

From everything that I've read on this over the years the broadest translation of EPHI is ANY information that COULD be used to IDENTIFY a patient.(This would include any account or test numbers) The debate would be "entities that need access to" or "provide access to" however if ruled as negligent in court, it's not an excuse and since you have the title of compliance officer I would require encryption (atleast in writing). If you don't have the ability to approve spending on say encrypted email then provide who does have the authority with Section 164.312(e)(2)(ii) of HIPAA and BCC your external email address to cover yourself that the company is going rogue and not yourself. I always say unencrypted email is like writing information on a piece of paper and putting it on "Joe's" car under the windshield wiper. Enen though it's addressed to "Joe" anyone who is walking by with "curiousity" could read that paper on the windshield of Joe's car and he might never know. If that data is valuable in ANY way, people will try to "acquire it".

Here's a quote from wikipedia's site: PHI is any information held by a covered entity which concerns health status, provision of health care, or payment for health care that can be linked to an individual.[13] This is interpreted rather broadly and includes any part of an individual's medical record or payment history.

taken from: http://en.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act

Unfortunately an ex-employee could social engineer with that information, additional information such as a SS#.

Depending on how much data is sent and how often it will be sent you may want to consider building a SFTP server (usually favored over FTPS by most Hospitals I.T. departments)

Personally I've done this for two of the largest hospitals in my state and that's how they send reports and patient data. I used a turnkey linux distro here: http://www.turnkeylinux.org/fileserver

It's FREE and very easy to setup and will cover the issue of using encryption while the data's "in motion" Also be sure to make a unique login for EACH entity that will connect since all login attempts are logged and be sure to use a long random password and only give that info over the phone or fax since your email does not sound like it's being encrypted.

A word of experience on email encryption, stay away from Trend Micro, it's too difficult for computarded users to count on their fingers and toes the numerical  placeholders of their passwords.

ex.
password: doggypuppy123
enter characters 1, 2, 7, and 9 of your password
answer: d o u p

plus they have security questions on top of that as well.

It is horrible, I was stuck with it for a year from the previous admin and now we have something much more computarded user friendly. Let me know if you have any other questions.

If you just want to send the information VIA email and don't have the capability to run a SFTP server thatn you could use http://www.jumbleme.com/ which offers FREE low volume encrypted emails. The onlything in question is when you look at the HIPAA compliant version of the "FREE" service they say that they charge $49.95/yr per user account.


The Wikipedia description (https://en.m.wikipedia.org/wiki/WebSocket) of the protocol seems to sum it up best.

To quote:

  In addition to Upgrade headers, the client sends a Sec-WebSocket-Key header containing base64-encoded random bytes, and the server replies with a hash of the key in the Sec-WebSocket-Accept header. This is intended to prevent a caching proxy from re-sending a previous WebSocket conversation,[25] and does not provide any authentication, privacy or integrity. The hashing function appends the fixed string 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 (a GUID) to the value from Sec-WebSocket-Key header (which is not decoded from base64), applies the SHA-1 hashing function, and encodes the result using base64.

Edit: removed statement regarding replay protections thanks to Steffen


Understanding TS 133 501 (5G) Step 2 of EAP-AKA'

EAP-AKA' as specified for 5G by ETSI and other organizations under the 3GPP umbrella, is a slightly revised version of EAP-AKA' as specified by IETF in RFC 5448.
It is adapted for use in mobile wireless cellular networks. The version in TS 133 501 is designed for usage in 5G networks. Hence, it involves network functions like UDM, ARPF, etc., that are specific to 5G networks, but that are involved in the EAP-AKA' signalling in 5G networks.
RFC 5448 was published in 2009, and since then, privacy requirements, for example, have become more important, with the GPDR and other such frameworks emerging sometime after 2009. Identifiers like the SUCI are there in 5G for privacy purposes but were not originally in EAP-AKA' as specified in RFC 5448.
You asked about text like the following in TS 133 501

when the UDM/ARPF got the SUCI it shall continue as shown in RFC 5448 (a description of a EAP-AKA'), otherwise, it shall follow the EAP-AKA' shown in the specification (TS 133 501)

This is because EAP-AKA' for 5G is a slight revision of RFC 5448, so in some circumstances, part of the flow would follow exactly as described in RFC 5448, whereas in other places where there are changes or adaptations in EAP-AKA' for 5G, then that needs to be specified in TS 133 501.


How does one know when a message is successfully decrypted?

I'm sure the real -not so useful- answer is "it depends", but I think you're on the right track here:

A good way to start is to detect ASCII characters (assuming, it's a text message in ASCII), or a file header (if the file type is known), or a "known" sample, being a sequence of characters (think TCP/IP headers, XML tags, ...).

In weak cyphers (such as XOR or any Caesar-alike thing), you can detect patterns, which if you substitute with another value, you can try to derive the key, or parts thereof.

This is of course a simplified version, Cryptanalysis is a very broad field and by no stretch am I an expert in it.


Could one fit a root application in sim card

Some SIM cards have a capacity for 128KB (or more) of storage, easily large enough for a small exploit, perhaps a rootkit plus remote execution vulnerability. Conceptually, phones have a sandbox that protect them from the SIM's data, but there are known vulnerabilities that can be exploited. Technically, these cards aren't supposed to contain executable code (they should contain only data), but there's nothing prohibiting this rule. After all, they are basically small processors with permanent storage (Software-on-a-Chip, or SoC).

One such article that I found suggests that the sandbox can be defeated, and also that no carriers have bothered to patch this exploit, simply because "nobody's using it." Admittedly, this article is already two years old, but for most vendors, that's almost as good as yesterday in terms of carriers, who rarely spend time patching even critical exploits, much less exploits that supposedly aren't used in the wild.

A well-versed hacker, such as Mr. Robot is supposed to be, could easily write code that could exploit a phone, even if it hadn't been previously rooted. Of course, if the phone were already jailbroken, perhaps to enable a custom OS or unlock features such as tethering or changing carriers, the exploit might be even easier. Mind you, I'm not aware of an explicit exploit that exists in the wild, only example/proof-of-concepts, but it appears that the author of Mr. Robot has bothered to do their homework within the realm of possible. Please keep in mind that Mr. Robot, like almost all television shows, are science fiction, usually based on fact, but not historical evidence.

It's also well-known that a hacker that has physical access to almost any system basically has full control of the system. For example, a hacker can easily crack all Windows passwords using Linux-on-a-disc, and a hacker with sufficient knowledge and resources could hack any phone, even one with full encryption enabled (but this is a very specialized, and very costly technique).


Why do I need a strong password for my home computer? What kind of attack is it trying to thwart?

The primary reason to have a strong password is to defend against people who have physical access to your machine, but are not tech-savvy. If you do not encrypt your drive, anyone could mount - and read, delete, or change - your data easily if they have access, and thus also gain control of your system.

But how many people who have physical access to your computer can actually do that? There is also a psychological barrier. "Just checking out" if you use your birthday as password may not feel as big a violation - and is easier done than - other attacks.

If you use a weak or no password for a more privileged account, malware could also possibly do more damage.

  Can malware launch the kind of attack used against stolen database password files?

You do not generally allow remote access to your personal computer via system users, so online bruteforcing is out of the question. If someone has physical access and the drive is not encrypted, there are easier ways than bruteforcing.

  How securely is my computer password stored?

That depends on the system. In many linux systems, it is stored in the /etc/shadow file, which is only readable by root users.

  Would the malware need to know my password anyway, as presumably it would have my logon authority?

The malware will most likely first run under the permissions it was installed with, which is likely your primary account. It doesn't need your password to do this. It may then try to gain more privileges via exploits against the system. Theoretically, it may also try to brute-force passwords for more privileged accounts, or use a keylogger to read the passwords when you enter them.

  So what function does the password then serve? What is there left to protect?

As mentioned above, having a reasonably strong passwords prevents people with pysical access to easily access your system without the need to perform any actual attack.


How to prevent an infected PC from infecting other machines on the same network?

If your router supports VLAN, you can create a VLAN for your father, another for everyone else, and forbid intra-VLAN communication. This will isolate your father from the network.


Does Intel or Arm support private key memory?

Intel can do register-to-register encryption with the AES instructions and many ARM chips have crypto accelerators with similar functions.

There's two kinds of attack here: having an external DRAM bus physically snooped, and having a software exploit that sees the memory from the processor's point of view. The former is actually easiest to deal with by using on-chip RAM only.

Dealing with exploits is a problem, because the key has to be available to software at some point. The ARM solution is TrustZone, which is a sophisticated anti-compromise virtualisation-like mechanism that lets you have a secure microkernel on top of a much larger insecure OS. On the iPhone, the "secure world" is running the sel4 microkernel.

Write-only 'fuses' are used to seal the system once the chip is programmed to prevent JTAG access and unsigned updates. This is partly why the FBI attack on Apple is so serious: it involves forcing them to make an insecure version of the software that's signed with their keys.


As a workaround you could implement something like a SVG proxy on your server which rejects SVG files which trigger the dos and link all SVG files through the proxy e.g. /svgproxy?f=https://evilsite.com/badsvg.svg. But of course there would be a performance disadvantage even if that could be limited by doing the check only for chrome users.

A not too costly way to detect a bad SVG is to try to render the SVG with a process which has a memory limit. If the rendering fails its a bad SVG. You could try ImageMagick which at least sometimes also rejects bad SVGs by itself.


You are combining a few components.  TLS/SSL is rather complex because there are so many individual pieces which fit together.

The public key is part of the cert and the key exchange and server authentication are two independent steps which (can) use different algorithms.

The server first needs to be authenticated because DH and variants are vulnerable to MITM attacks.  You can't securely exchange keys until you know you are talking to the right entity otherwise all you did is "securely" exchange keys with an attacker.

So the server authenticates itself by signing a message using the server's private key.  The message, signature, and cert are sent together to the client.  The client verifies the signature to authenticate the server is who it says it is.  If I am going to https://example.com the browser will expect a cert with a hostname of example.com but a cert is public information.  Only the server with the private key can generate a valid signature

The RSA in your example means the algorithm in the digital signature verification is RSA.  The algorithm used will be determined by what type of public key the cert contains.  If you have a ECC (ECDSA) keypair the authentication is going to be using ECDSA.  If it is an RSA keypair the authentication will be using RSA.  DSA is also a valid option but I am unsure if CA are still issuing DSA certs.

At the same time the browser will verify the site cert was signed by a cert it trusts.  It works backwards as far as it needs until it either reaches a root cert it already trusts (because it is built into the OS) or it runs out of chain and reports the "cert is not trusted".

Once that is all that is complete the client knows it can't be MITM spoofed and is actually talking to the server in question so it can use a key exchange protocol such as RSA, DH, DHE, ECDH, or ECDHE to securely exchange keys with the server. Yes RSA can be used for exchanging keys as well as in digital signatures.

DH_DSS = Key exchange using DH. Authentication using DSA.
DH_RSA = Key exchange using DH. Authentication using RSA.
ECDHE_RSA = Key Exchange using ECDHE Authentication using RSA
ECDHE_ECDSA = Key Exchange using ECDHE Authentication using ECDSA
RSA = Key Exchange and Authentication are both done using RSA


Under what circumstance might your email not make to your intended recipient?

Email is sent over SMTP.  Normally speaking your email client sends the message to a configured SMTP server.  That server then uses DNS to resolve the MX (mail exchanger) record for the destination domain (the part after the @ sign).  It then sends the message on to that server.

If your SMTP server or the DNS it uses were compromised it could send to a malicious MX that allows an interloper to not only read the message, but prevent its delivery to your intended recipient.

The attacker forging a reply is trivial if the sender's domain (your colleague's domain) does not have SPF (Sender Protection Framework) implemented.  In that case an attacker can send email as your colleague and it will likely get through.

You should be able to determine a lot by looking at the raw email source if your email client allows this.  The headers provide a certain amount of information about where your mail server received the attacker's messages from.  Comparing the headers on your sent mail to those on the received messages may provide insight as well.

These headers won't track a somewhat clever attacker because they will mask, forge or omit the Received headers on their side.  The only information you can trust is the very last Received header and that is only true if your email server is configured properly and not compromised by the attacker.  Unfortunately open SMTP relays exist making it very easy for an attacker to bounce email through and drop all meaningful tracking.

Assuming you have usable Received headers you may be able to reconstruct a real path to your attacker and unmask them.  It will certainly identify opportunities for implementing proper SPF on both domains and spam filtering that drops emails that fail SPF verification.


Is reflected XSS impossible, when HTML meta-characters, e.g., , are encoded, and the result output in HTML context?

This depends on the context. I am assuming you're using htmlentities() function, which would be generally safe. It does more or less the exact same thing as htmlspecialchars() does.

Both of which secure against general XSS, and prevent event-based XSS when the sanitized parameter is injected into a HTML tag.

They both do not prevent javascript: attacks, which can happen if injecting the parameter value into a link, iframe, or other similar tag. If injecting a src or href from any of them tags, I would recommend first removing any whitespace from the parameter, and then checking for both javascript: and data:.

javascript:alert(0) will give you an alert when injected into a link or iframe.
data:text/javascript:alert(0) will do the same.
data:text/html:<script>alert(0);</script> does the same thing too, and bypasses strip_tags.

The reason for first removing whitespace, is to prevent an attacker dropping a line break/CRLF character in the middle of their payload, so PHP reads it as not being javascript: or data: when blocking the payload, but it will still execute as javascript will ignore it.

I hope that explains what type of attacks are possible, it's very easy to claim that htmlentities() and htmlspecialchars() are a one-fits-all solution to the problem, but depending on the situation, that can be extremely dangerous advice.


DNS hijacking and Subject Alternative Names

In the simplest case your domain at Firebase Hosting is sharing the same IP address with the other hosts mentioned in the same certificate anyway, which means there is nothing to actually DNS spoof.

If the IP address is not the safe and the DNS response can be spoofed to point to a different IP address serving the same certificate then both the server name inside the TLS handshake and the Host header inside the HTTP request will still have your domain in it. How the web server reacts to having a domain inside these headers which is not configured at the web server depends on the server configuration which also means the behavior might change over time. Typical behaviors are either sane responses like an error at the TLS level (unknown server_name), error at the HTTP level or an insane response of returning data from another domain at the server. I would expect that the server is configured in the sane way but have no way to test it. But if you know that the same certificate is actually employed on different IP addresses you can try it yourself:

$ openssl s_client -connect IP:port -servername example.com
GET / HTTP/1.0
Host: example.com


I'm going to call your PCI compliant network #1, and the other #2. If no credit card information is going to traverse the VPN to #2 then it does not have to be PCI compliant. However, if any system located in #2 will need to access credit card information, or systems that store credit card information, then it would have to be PCI compliant.

Honestly though, the PCI rules for network are good practice for all parts of your network, not just the parts of it that deal with credit card information. Strong authentication, logging, etc should be considered standard.


UPDATE

Your device (W8901G) is in all likelihood VULNERABLE, to the very exploit described below, and more, and even more. I think that the steps suggested below may ameliorate your situation,  but unless a firmware fix is available from TP-Link, you should consider replacing your router.

The TP-Link search form did not supply any link (W8901G is end-of-life, but even activating EOL listing I only got the W8901N model), or perhaps I wasn't able to have it working properly, but since their pages have the product code as name, I tried entering it directly and found this:

http://www.tp-link.com/lk/download/TD-W8901G.html

This seems the most recent page, and as you can see, the firmware release is earlier than some of the exploits above. It is therefore likely that this firmware upgrade, while fixing some vulnerabilities, may not fix all of them. Also, it is only for V6 hardware; if you have an earlier revision, applying the patch might well brick your router.

Unfortunately, your router also seems not to support DD-WRT, which is a way (not for the faint of heart, in my opinion) of breathing new life into an older router, or squeezing more performances that the original manufacturer allowed - or even believed possible.

So I'm afraid that the easiest way out is purchasing a new router (after checking it out in the vulnerabilities database... just in case).

OLD ANSWER

Some modem-routers have vulnerabilities that allows for unauthenticated access from either the inside or the outside of the network.

So you can be tricked by an Internet page which is able to successfully mount a script attack and have you access, say,

http://192.168.1.1/cgi-bin/adm.cgi?cmd=DNSUpdate&ip1=5.104.175.151...

Your modem "sees" the connection coming from your computer, which is not exactly infected even if it's reading a hostile webpage, accepts it and - bang.

Also, your modem might expose a remote control page, or vulnerability, which allows anyone from the outside to update its values.

What I would do is,

UPDATE the modem firmware to the latest compatible version,
VERIFY that there are no up-standing known vulnerabilities (a Google search for "MYMODEL MYBRAND vulnerability" is often enough)
TEST accessing your own IP from the outside using a different network (a smartphone, for example, not connected to your home wireless) and see what happens (hopefully, nothing). Even a "Not Found" page is BAD NEWS because it means that the modem is listening. It's not obeying your malformed command, yes, but there's no guarantee it can't obey a properly formatted exploit as long as it is able to listen. A deaf modem would be way more secure.
DISABLE any remote control capability on the modem. On some models you can not do so explicitly, but you can instruct the modem to redirect all incoming requests to a DMZ host of, say, 192.168.1.254 -- of course you must be sure there are no IPs allocated there; better if it's outside the DHCP address pool altogether. This way, any incoming administrative connections will be rerouted to nowhere-land.
CHANGE the IP address range of your modem from the default (often 192.168.1.1 or 192.168.0.1 or 192.168.2.1) to something like 192.168.219.137, and your network to 192.168.219.0/24. This will ensure that any "simple" reflection attack will fail; at the very least the attacker will need to send some 60,000 attempts for a blind attack to succeed.
Also: you can instruct your PCs to not ask DNS information to the router, and instead rely on a fixed address you'll enter manually (e.g. the classic Google DNS 8.8.8.8). It is not a complete defense against everything that could be done through a compromised modem-router, but it does protect against simple DNS+DHCP hijack.

What's the worst it could happen?

TL;DR It would be bad" (i.e.: fly, you fools!).

In the general case, with a compromised router of sufficient power you can basically no longer trust anything coming from the network. This includes, for example, any apparently legitimate software update package. Not all software companies employ strong cryptographic verification of their packages.

In a recent news, a company calling themselves the Hacking Team resorted to installing rootkits on targeted computers by temporarily recruiting the ISP's assistance and, among other things, let people download "Flash security upgrades" that were anything but (although - given the abysmal Flash security record - it could be argued that a bona fide malware was indeed coming up in the world).

At that point they achieved what whoever hacked a sufficiently powerful router could also achieve: total communication control and the possibility of gaining the complete control of the machine beyond, given that at some point either the machine itself would willingly start, or its user could be enticed into, downloading and executing code coming from the network -- i.e., from the attackers.

Another very real possibility is to install keylogger and navigation hijacking/monitoring software. Consider one of the possible scenarios:

I am now your DNS's daddy.
Every site you want to connect to, you first willingly tell its name to me.
Your PC's firewall will more than certainly trust any DNS query.

So now I (aka your friendly if a bit dishonest new DNS) get asked for

Q. DNS-QUERY IP_ADDRESS_OF customers.vulnerable-banking.org

I now send you a fake IP address. I could try to set up a Man-In-The-Middle attack (and if I have gained access to your browser's key storage, it would probably succeed, because I am now also your Root Certificate Authority). But I don't need to.

The new IP address is a machine that simply redirects you to the real address via HTTP redirect, but now I have been able to legitimately send "you" some information that I could not via DNS. One of the cookie requests is actually a command to the keylogger to start operating.

And in the next few minutes some other DNS queries come along, and they are not intercepted, sent by the keylogger:

Q. DNS-QUERY IP_ADDRESS_OF KeyUp.keylogger.pwn
A. KeyUp.keylogger.pwn has address 127.0.0.1
Q. DNS-QUERY IP_ADDRESS_OF field.user.content.wuijang.keylogger.pwn
A. field.user.content.wuijang.keylogger.pwn has address 127.0.0.1
Q. DNS-QUERY IP_ADDRESS_OF field.pass.content.thisismypassword.keylogger.pwn
A. field.pass.content.thisismypassword.keylogger.pwn has address 127.0.0.2

...and now what was "only" a DNS server also happens to know that when connecting to customers.vulnerable-banking.org, a certain username/password pair is sent.

Not too long afterwards, your banking account is mysteriously transferred to Elbonia.

In your specific case the router is not so powerful, which means that the above disastrous scenario is still possible but requires a bit more subtlety, and most attackers wouldn't bother developing a sophisticated enough attack. Which means that you would notice anomalies and would cotton to the fact your router was compromised (as, indeed, happened). You would probably notice errors in software packages upgrades, or fishy and sloppy pieces of crap trying to pass for software patches.

Unless you were roaring drunk, you would never fall for it.

I don't feel this is enough to feel safe. Having the equivalent of a spyhole embedded in my router, allowing who-knows-who to reroute my traffic as soon as it catches his fancy, would creep me out of my mind. Also, I might someday want to get roaring drunk, and once is all that would be needed.

What if I never do anything 'meaningful' from my home network?

Your network may not contain any sensitive information (frankly, it would be a first), and never be used for anything meaningful for the "real life" "out there". No Amazon purchases, no eBay, Paypal, maybe Craigslist, no home banking and no email checking. No Facebook or Twitter (would you believe there's a market for FB/TW stolen credentials?)

Even so, the network could be, and sooner or later will be, used as a relaunch point - imagine being able to say, "Send one million copies of this spam" and one thousand compromised networks launch one massively parallel spam run, one thousand copies each. Lots of spammers would gladly pay good money to be able to do that, and so lots of crackers are actively looking for ways to sell them this capability - which translates into being able to acquire it illicitly. They need victims. Don't be one.

Also, from a legal point of view, whatever illicit operation your router does (not spamming, no, but maybe bruteforcing a bank account of someone else?) could bring the Law's attention to your door. Even if you were able to readily explain what happened (it depends on their technical savvyness), and they were disposed to listening (I saw it happen. Every now and then), that's your precious and irreplaceable time going down the drain.

Router suggestion

I don't like this kind of suggestions because I don't know where you live or who you're getting connection from (sometimes it's best to get your ISP's recommended brand as it's the one that will work best). Also I wouldn't want the responsibility :-)

However, a nice router I've been recommended is the Buffalo AirStation WBMR-HP-G300H; not new (it first came up on Amazon in 2011) but sturdy, easy to configure, enthusiastically hacked (and patched), and if the worst comes to the worst, it does support DD-WRT. I myself own a patched D-Link that I ensured is not reachable from the outside (I am on copper Ethernet though, no WiFi).


Can my company track my laptop if I've reinstalled the operating system?

There are two questions here.
First of all, just because you reinstalled everything (that is, format the disk and reinstall the OS) doesn't guarantee that the computer will be free of any persistent rootkit (think Computrace).
Besides, the computer may be connected to a corporate domain, meaning that when you're logging in to that domain, policies may kick in and install stuff in the background as part of the normal corporate software update/provisioning scheme.

Most of the times my laptop is connected to the Company's Wifi. I
wanted to know if they can see my Whatsapp texts or not?

As long as you are visiting HTTPs sites the traffic is encrypted so they can't see the messages in clear. But they still can see lots of things, plus many types of traffic like DNS are typically unencrypted so anybody who is sniffing on the wire can figure out the patterns of your online activity, like what sites you visit.
If you are curious you can install Wireshark on your computer and sniff your own traffic to better understand the data that is flowing out of your network interface.


A few questions come to mind with the brute force attack:

What is the length of the PIN
What is the timeout length

Now for actually trying to break into the phone I would first look for wear on the screen protector, smudges, or wear on the keypad (specifically numerals).  If you are allowed to match it to an employees desk I would look for written down passwords and/or calendars marked with what appear to be important dates (birthdays and anniversaries).  Also, looking at the wear on the keypad of their computer keyboard could be a large indication as to what their PIN is, namely because humans don't like to have multiple passwords for multiple systems.


What does banking etc. server room protection look like? What happens if it fails?

Well, what they are really supposed to do is look to the most effective physical security measures used in the customary practices of high-security data centers in data processing industries in general, plus implement specific measures & practices that their lawyers tell them are required by the collective body of federal regulations that speak to the information security of U.S. financial institutions.

Guidance on best practices and recommendations for the secure design and operation of data centers in general certainly isn't hard to find.  You seem interested in the specific details of what access control mechanisms should be in place, how perimeter security should be monitored, etc., (which I'll admit I've always found interesting as well.)  This piece from CSO Online is one of the more comprehensive and readable run-downs, listing 19 specific physical security elements that a well-protected data center should implement well. ("Mantraps, access control systems, bollards and surveillance." among them.)  Probably not surprisingly, there are compliance certification standards for data center physical security that companies in "highly regulated industries"--financial institutions first and foremost-- are very often required (by practical forces if not directly by legal regulations) to comply with.

Now, talking about info sec regulations that apply to banks and other financial institutions is always a massively complicated endeavor. Such regulations come from, just talking at the federal level, the "Board of Governors of the Federal Reserve System (FRB), the Federal Deposit Insurance Corporation (FDIC), the National Credit Union Administration (NCUA), the Office of the Comptroller of the Currency (OCC), and the Consumer Financial Protection Bureau (CFPB)".  So says the IT Handbook resource for the Federal Financial Examination Institution Counsel, which is probably one of the best official government sources you're going to find that covers federal information security regulatory requirements for banks comprehensively, coming from that broad, broad swath of agencies.  FFEIC's specific page on data center physical security is here. It is a fairly short document, and addresses intruder detection, the training of security guards, and other topics. Look at topics surrounding that specific page in the virtual IT Handbook for information on physical security concerns that will often pertain to data centers as well as other facilities. You might also take a direct look at the Federal Reserve's guidelines regarding information security standards; some of those high-level conceptual standards most definitely do eventually affect how banks do the specifics of providing physical security at their data centers.

So there's some fun night-table reading for you.

tl; dr:  They should being doing what responsible companies in other security-intensive data processing industries are doing, plus meeting what the requirements in regulations from any number of different agencies and jurisdictions that oversee financial institutions mandate.


I think you need to separate you concerns. Protecting the JWT on the client side is the job of the application using the JWT, not the API. If this line is blurred than you may need to re-engineer you application as it's probably more monolithic, rather than service driven.

JTI, EXP and IAT are designed more to give you the tools to mitigate an attack if it's been compromised. TLS is used to prevent snooping of the JWT while in transit. Shortening the window for the EXP will limit the exposure of the single token, but ultimately if they got the token via the application, the EXP is mute, they'll just grab the next token.


How to connect to Windows RDP and delegate authentication to a (reverse) proxy?

You need to use a RDP reverse proxy, not just a TCP proxy. There are plenty of software providing that functionality (in different forms), free and paid.


Is there a problem with issuing a HSTS header in PHP?

HSTS is enabled by returning the strict-transport-security header from a HTTPS response - the browser does not care whether this is set in PHP, by the server, or by a load balancer - as long as it receives a valid header over HTTPS then HSTS will be enabled.

You should be OK only returning this header from a single page for testing too. RFC 6797 states

  If a UA receives HTTP responses from a Known HSTS Host over a secure
     channel but the responses are missing the STS header field, the UA
     MUST continue to treat the host as a Known HSTS Host until the
     max-age value for the knowledge of that Known HSTS Host is reached.

so your other responses without the header will not cancel HSTS for your site.

Setting max-age=0 is also the correct way to cancel HSTS for your site (per receiving user agent). The only thing I've spotted which is non-standard the way you are doing is that you are sending the header over HTTP also - although this would be ignored by a compliant user agent it is invalid so I would make sure to only transmit this when the connection is secure (best to stick to standards as close as possible I find).

You can check whether to emit the header with the following code that will check that the page has been accessed via HTTPS:

<?php
function isSSL(){

    if($_SERVER['https'] == 1) /* Apache */ {
        return TRUE;
    } elseif ($_SERVER['https'] == 'on') /* IIS */ {
        return TRUE;
    } elseif ($_SERVER['SERVER_PORT'] == 443) /* others */ {
        return TRUE;
    } else {
        return FALSE; /* just using http */
    }

}
?>


What's the distinction between a missed hardening opportunity and security flaw?

It is always risk that defines that criteria.

What's the likelihood of the problem being exploited, what are the mitigations in place to prevent or limit the impact, and what are the impacts of a successful exploitation?

Once those are defined, you can classify what's wrong with a system and rank them in order or priority, regardless of the type of problem (hardening, 0-day, patches, flaws, etc.).


Should I block outbound TCP RST (on closed ports)?

Whether you want to take the trouble to do this largely depends on your own threat model and the effort required to make the change.

The effect of filtering access to closed ports is that it makes it harder for someone foot-printing a network to establish potential attack targets.

Theoretically any information provided to an attacker is useful to them, so reducing the amount of information you provides improves your security.

There is also the potential risk that at some point your host might have an exploitable bug in its TCP/IP stack that could be exploited by a scanning host.

Whether any of that matters enough to you, as I say depends on your particular risk model.  In general, I'd say that if it's easy to do, and has no other negative consequences, sure filter the traffic.


Defense of a server against malicious uploaded resources

The server should do validation on the user submitted file. E.g. If you allow the user to upload an image file for their profile picture, you should make sure that the file is a JPEG or PNG file and not an EXE file.

More info : http://www.waytocode.com/2012/file-uploading-validation-in-php/

If you are running a file sharing service and allow all types of files to be uploaded.
Even if a malicious file to be uploaded, it will not infect your system as long as you do not execute it. For added security, set the executable flag to be off so that it cannot be executed through any means.


SSL Newbie : Does HTTPS client also need a certificate?

Depends what you are doing, and what you want to verify. If you are accessing data, and want to be sure that the server which knows the corresponding private key is the one sending you data (e.g. you're accessing a web page), you don't need your own certificate.

If the server wants to be able to verify that the client is a pre-defined one, which knows a private key corresponding to a public key recognised as a valid source, your client will need a certificate. This tends to be used when a pair of servers are communicating - they each sign the data with their own private key, and can verify that the data is coming from a known source by checking against public keys. It can also be used with some APIs, where only specific clients are intended to access.

At a guess, therefore, you don't need your own certificate for your client - it's generally fairly well documented by the server if you do.


Another domain pointed to my server, what are the risks?

There are a number of risks, for both you and (assuming it was a mistake) the domain owner.

For you, it means at least exposure. In some cases, that can mean more DDOS attacks. If the domain owner had some issues with hackers, that may come to your website too.

If the domain that erroneous points to you is blacklisted somewhere, that blacklist could in some circumstances extend to your IP address (depending on who does the blacklisting).

It is possible that some DNS registrar contacts you with an invoice. You should not need to pay that, but it is again an annoyance.

That is more or less the list of risks I can think of.

For the domain owner, it effectively means that you are now in a position to do a MITM attack on him. For him, that is a serious risk. The domain owner should at least be grateful for your 404-serving approach.


Carpet bombing is a military term - meant to indicate laying a carpet of explosives or incendiaries in order to kill/destroy anything within the target area.

Wikipedia says:

  Carpet bombing is a large aerial bombing done in a progressive manner
  to inflict damage in every part of a selected area of land.
  The phrase evokes the image of explosions completely covering an area,
  in the same way that a carpet covers a floor.

This ZDNet article shows what your Windows desktop looks like after the Safari "carpet bombing"
vulnerability has run.  The image from the article is shown below.

I suspect that someone called this "carpet bombing" because your desktop looks like a carpet has been applied to your desktop as each of the malware files on your desktop appear like a carpet pattern.  Each file could also be thought of as a "bomb" because when executed the malware will infect your machine.

Also, the vulnerability is "dropping" many copies of the malware indiscriminately onto the desktop in the hope that one will cause the malware to get executed.  This is much like the carpet bombing performed during war as described in the Wikipedia article.


intel wireless 5100 AGN adapter to support injection

Try using Backtrack or Blackbuntu.  Those two distribution have better driver support for packet injection.  Some wireless cards need specially modified drivers.  Once you figure out which one you need you can install it in Ubuntu.  Backtrack and Blackbuntu are worth using for that purpose though.

Also it is worth noting that you MAY have better luck using a 32-bit OS,  Backtrack for one is only 32-bit because most drivers and tools work better.  I can't vouch for there being any issues with using a 64-bit OS though.

Good luck in your Penetration Testing. (I hope that's what your purpose is)


Can an intermediate CA be trusted like a self-signed root CA?

A root CA is actually an illusion. In X.509, there are trust anchors. A trust anchor is, mostly, a name and a public key, which you know a priori and that you trust. Representation of that name and that public key as a "certificate file" (traditionally self-signed) is just a convenient way to keep the trust anchor as a bunch of bytes.

As per X.509, a CA is "intermediate" only if you do not trust it a priori; it is not an intrinsic property of the CA. What you need to do is convince your software to consider the CA as a trust anchor. One possible trick is to reencode the relevant data (the CA name and public key) as a (purportedly) self-signed certificate. Note that the self-signature is just a Tradition; it is there mostly because the file format for a certificate has a mandatory field for a signature. For a "root" CA, this signature has no significance (it makes little sense to verify it, since it would buy you nothing security-wise). Therefore, applications which use root CA certificates rarely verify that the signature is "self".

Therefore, you could build a custom "self-signed" certificate with the name of your "intermediate CA" as both SubjectDN and IssuerDN. For the signature, just put random junk bytes of approximately the right size (256 bytes for a 2048-bit signature). Then, try to set this pseudo-self-signed certificate as a root: chances are that it will work with your VPN. Alternatively, create your own root CA, and emit an extra certificate for the intermediate CA (you do not need the cooperation of the intermediate CA for that, you just need its name and public key, and you have these, in the intermediate CA certificate).


What are the pros and cons of enabling 2 factor authentication on internal user workstations of an organization?

Pros:
You could gain security by having that the physical access card, that is used to open doors in organization, must be placed on a Reading pad or inserted in a smart card reader, and kept there to keep the computer logged in.
As soon as the card is removed, computer is forcefully logged out. (shutdown /l /f /t 0)

I would advise against locking the computers instead of logging out them, both for security, but also so shared computers do not get "locked up" by careless users. Better to log the computer out, if the user want to continue working, he has to save his work prior to removing the card.

If this card is used to access basically all doors in the organization, even for the exit direction, even toilets and lets say vending Machines, coffe Machines, copy machine, printer, etc

then it will become a habit of the workers to actually Always bring the card with them when going anywhere.

This means that you dont need to logout the session after inactivity.

This means you can actually use it with a one-factor login (only card) instead to make the login extremely convient for the user. To protect against lost cards, you could have that the card needs to be presented and a PIN code needs to be entered, at the front door or lobby area, to enable the card for 12 hours.

Thus on the beginning on work day, the user has to use card+PIN to activate the card. After this, the card will work for 12 hours, in all doors and on all computers where the user is allowed to be.

Cons:The cost. It can be prohibilively expensive to buy RFID readers for computer login, or replace all RFID cards with combo Chip+RFID cards and then invest in Smart card readers.


Best security practices for software development and release?

Developers should never have direct access to the production environment. From an audit perspective this is a big no-no as this poses fraud  risks. Also if one developer makes a mistake he can take down your critical systems which could have a high impact on your business.

The best practice is to have 4 separate environments, Development, Testing, Acceptance and Production. Developers can have access to testing and in some cases to acceptance, but NEVER to production. This is called the DTAP principle:

  The program or component is developed on a Development system. This
  development environment might have no testing capabilities.
  Once the developer thinks it is ready, the product is copied to a
  Test environment, to verify it works as expected. This test
  environment is supposedly standardized and in close alignment with
  the target environment.
  If the test is successful, the product is copied to an Acceptance
  test environment. During the Acceptance test, the customer will test
  the product in this environment to verify whether it meets their
  expectations.
  If the customer accepts the product, it is deployed to a Production
  environment, making it available to all users of the system.

As said, if an auditor sees or even gets the slightest hint that a developer can get access to a production environment you will almost certainly get failed. If you want to perform audits, it's best done by an independent person/organisation. If you want to setup more processes and regulations have a look at the COBIT framework.

Make sure you define KPIs and SLAs  to have a form of power to enforce your regulations.


What browsing history exactly would police have under proposed UK law change? Plain english

Currently, the measure is just an idea. It is not even an idea by a politician. It is an idea by the UK police. The exact wording for such a law is not made yet, so we can just guess how it could look.

However, this article by The Guardian gives the impression that the idea is to have the internet service providers do the snooping:

  Senior officers want to revive the measures similar to those contained in the“snooper’s charter”, which would force telecommunications companies to retain for 12 months data that would disclose websites visited by customers

So the rest of this answer focuses on the question what information can your internet service provider collect about your internet activity?

  Web browsing in general

A web browser has two ways to request websites. The unsecure http:// protocol and the secure https:// protocol. Not all websites support both modes of operation. Stackexchange is one which does. Which mode is used can be seen in the address bar.

When you read this text via http, your internet service provider will know that you just visited http://security.stackexchange.com/questions/104284/what-browsing-history-exactly-would-police-have-under-proposed-uk-law-change-pl. They would also be able to log the complete content of the text your read right now.

When you browse this website with https, the data trail is a lot smaller, because the communication with the webserver was encrypted. All your ISP just learned about you is that you requested something from https://security.stackexchange.com, how many bytes you sent and how many bytes you received. But they can not infer from this information that you read this exact question.

  Thunderbird?

Email can be accessed encrypted or unencrypted. Check the server settings in your account settings to see what security mode Thunderbird is using (should be "SSL/TLS" or "STARTTLS"). When encryption is enabled, all your ISP can learn is which email provider you use, how often you check your email and how much email (in byte) you send and receive.

However, even if you access your email encrypted, the exchange of the emails between mailservers might have been unencrypted. Generally, email should not be considered a secure medium. Encryption addons for email (like PGP) can protect the content, but not the meta-information (sender and receiver address).

  Startpage searches?

startpage.com always uses https, so they will learn when you used it, but not what you were searching for and what results you received.

Many search engines always use https, by the way (Google, DuckDuckGo and Yahoo do, Bing does it only on request).

Keep in mind that when you actually visit one of the search results, that request might or might not use https (see "Web browsing in general" above).

  Bit-torrent downloads?

Bit Torrent is always unencrypted. An eavesdropper can learn what files you share and who you are sharing them with. In order to do that, they don't even need to be an ISP, by the way. Joining the same torrent swarm as a client is enough. Information obtained that way is frequently used by companies to press legal actions against filesharers who violate their copyrights.

  Proxy browsing?

Proxy servers can be encrypted or unencrypted. Unencrypted proxy browsing doesn't affect the eavesdropping capabilities of the ISP at all.  When the connection to the proxy is encrypted, they know that you used the proxy, but not what information you accessed through it. However, if an attacker can also monitor the outgoing traffic of the proxy server, they might be able to  correlate it with your requests based on timing.

  VPN?

Internal traffic inside a virtual private network is always encrypted. When you use a VPN as a proxy to access websites, then the situation is identical to an encrypted proxy server.

  noscript?

Sometimes Javascript applications on otherwise encrypted websites can cause the web browser to make unencrypted requests. Under some circumstances this might provide an eavesdropper with additional information.

  Epic browser (in Windows)? xombrero?

I am not familiar enough with these products to provide a good answer, but I don't think they can do anything which is not already covered by the points mentioned above.


What is hacking hackable virtual machines useful for?

Think of hacking virtual machines to be the equivalent of being in a shooting range but for pentesting/offsec. It is all about practice.

  In the real world, how are these practices of hacking virtual machines useful?

Learning & Testing of exploits/tools
Understanding, Finding risks and vulnerabilities
Also, the legality of these practices, you won't have to worry much about legal problems as these boxes are set up in a way primarily for hands-on experiences & education purposes.

  What do these virtual machines represent: a webserver, someone's PC, phone, any kind of server, or something else?

If I didn't understand wrongly, these VMs can be made in a way where they serve a purpose, like a database, webserver, and or someone's phone. Different functionalities, different ways of cracking.


Virusscanners (in general) hook in on the filesystem. This means whenever a file is transferred it passes the virusscanner, which tries a table of common know patterns (aka definitions) against the file. This works well for binary files as patterns are easier to detect in static content. Patterns are not the only assessment, for example Windows Defender traces routines to see where they lead to. A combination of system calls can also trigger an alert. Windows host scripts (eg, js, vba, vs) are well known to cause problems, and are scanned in various ways to insure they cannot cause harm (or unintended actions). Malware scanners have various ways of detecting threats, these a re only two of them.

If you were to download a random, malicious, python script that has been slightly altered to cover its purpose, changes are it will go unnoticed.

Executables are also checked before they are loaded into executable memory. Ofcourse options and techniques vary per product.


Is piping a `ssh-agent` signed message as a password secure?

It's no less secure than entering a password over SSH to decrypt the container.

Whatever decrypting a container on a remote system is secure at all is completely different problem.


How are public key certificates updated securely?

The operating system comes with a set of "default trusted root CA". This is how a Web browser can connect to existing HTTPS Web sites and be content with their certificates without requiring the user to do anything special with his trusted CA. Similarly, the "OS update" mechanism will use the same principle: it will accept an update only if it comes from a trusted server, with a notion of trust which is relative to a public key which is already known to the machine. One may note that OS updates may include updates to the store of default trusted root CA.

Of course, this raises the question of how the OS got there in the first place. All these trusted root CA only move the problem around; trust still has to start somewhere. Usually, a physical medium (say, a DVD) is involved; even more usually, this is done in the computer factory, and the user gets a computer with a pre-installed OS.

If the root CA you are talking about is not part of the "default trusted CA" (i.e. that specific CA did not make a deal with Microsoft to be included by default), then the trust system is bootstrapped by a manual procedure: when the root CA is installed, the machine asks for confirmation to the user; a thumbprint of the new certificate is displayed. The thumprint is a hash value computed over the complete encoded root CA certificate. The user is then supposed to check that the displayed hash value matches a value which was communicated to him through some out-of-band mechanism (e.g. with the on-paper documentation).

Trust must start somewhere, but, thanks to cryptographic hash function, that "somewhere" can be a value small enough to be handled in the physical, non-computer world (a human user can verify that a 40-character hash value matches that which was printed on some paper).


It's going to depend on which characters are being filtered, the specifics of the filter, as well as the specifics of the SQL injection vulnerability.

Filters can be bypassed with encodings that are interpreted differently by the filter versus the browser, the injection may be possible without the character (if the string is not quoted), a different character can be used sometimes, or two injections can be used in conjunction to escape quotes in a useful way .

OWASP has an XSS Filter Evasion Cheat Sheet (originally started by RSnake) which collect a lot of these techniques.


There are a number of ways of phrasing the same things, personally, I prefer "True/False Positive" (referring to times when the system accepted the attempt, and whether it should have) and "True/False Negative" (referring to when the system rejected the authorisation attempt, and whether it should have).

The fact of the matter is that the True attempts are of little concern. They basically signify "the system is doing what it should be". The False Positives are very bad, because they mean that someone has been able to gain access when they shouldn't have. Any significant level of False Positives basically mean that a system is broken.

False Negatives are bad, but for different reasons. It means that the system hasn't allowed someone in when it should have. While this means that the data may still be secure, the user inconvenience should not be discounted. Remember "Security that comes at the cost of convenience, comes at the cost of security". A system that people don't use is as bad as a system that is broken.


Need example and working Security Token Service (STS)?

Some posts I've written (.NET based, but basic enough):

http://blogs.objectsharp.com/cs/blogs/steve/archive/2010/10/30/the-basics-of-building-a-security-token-service.aspx
http://blogs.objectsharp.com/cs/blogs/steve/archive/2011/07/04/part-4-secure-architecture.aspx (section on authentication)
http://blogs.objectsharp.com/cs/blogs/steve/archive/2011/02/22/multiple-identity-providers-in-a-multi-tenant-system-using-access-control-services.aspx
http://blogs.objectsharp.com/cs/blogs/steve/archive/2011/01/31/the-problem-with-claims-based-authentication.aspx
http://blogs.objectsharp.com/cs/blogs/steve/archive/2010/10/18/what-makes-claims-based-authentication-secure.aspx


What is the best way to respond to phishing emails sent from a government domain?

It is likely that the from header has been forged. I get emails from fake .govs quite often, mostly they end up in my spam filter. The hyperlink within is either unique, allowing tracking, or just delivers malware. Most of the time I just ignore these.

If you believe that the header is not forged then you can typically contact the agency by Googling their name and Webmaster or Contact Us or other such things. Do not use the phishing email, it is almost certainly fake.


How I can get MAC address of devices using passive wifi?

How do I understand the command airdump-ng is looking only for access points?

By default airodump-ng wlan0 will listen for any 802.11 devices beacons (master and managed mode) at 2.4 GHz. So, you know it is not only capturing AP beacons, your only alternative is to filter clients later using something like Wireshark if this is an issue. It is important to realise you are entering your Wi-Fi card into monitor mode (not managed mode) for this type of surveillance.

I do understand this can be an issue, so I would suggest specifying the BSSID of the AP before you start capturing and writing to a file in Airodump-ng, as the legality of intercepting traffic outside of your network is in question.

  It is necessary to determine student attendance.

I do not understand exactly what you are asking here. But, you can look through all BSSIDs associated with your station (AP) MAC address in airodump-ng or Wireshark.

  Is it possible to get the MAC address of these devices, given that they are not access points?

Passively via monitor mode, presuming you are within the distance of capturing beacons of the clients, then yes! You will see this in the image above.

To present this data in a more readable or appropriate format look at the Aircrack-ng documentation and Wireshark. Although, for anything regarding capture dumps, I would recommend Wireshark for processing and filtering.


What is the best strategy to store and share pem files between team?

The right and only answer is do not share secret keys!

Things like private keys in PEMs are often not changed regularly and you have no way of auditing who is using the key. The keys can also be easily copied by an employee leaving the company or be leaked/hacked.

The best solution is to have keys issued to individual employees and ensure passwords are used to pretect them. You should also have some software/scripts on the servers to properly maintain the trusted public keys.


How does the user agent know who is logged in? (Using auth codes)

What you're refering to is session management, which is not part of the OAuth 2 specification.

In practice, for session management many solutions make use of the HTTP session. After successful authentication the server stores whatever user related information in the HTTP session on the server side. If you close your user agent/browser, it will kill the HTTP session, in which case you'd have to login again. Except for the HTTP session, the user agent doesn't actually need to know any of the tokens involved.

If you want a user's session to persist even after closing a browser, one way would be to use cookies.


What is a good analogy to explain to a layman why passwords should be hashed?

The Short Answer

The short answer is: "So you don't get hit with a $5 million class-action lawsuit." That should be reason enough for most CEOs. Hashing passwords is a lot cheaper.

But more importantly: simply hashing the passwords as you suggested in your question isn't sufficient. You'll still get the lawsuit. You need to do more.

Why you need to do more takes a bit longer to explain. So let's take the long route for a moment so that you understand what you're explaining, and then we'll circle around for your 5-minute synopsis.

Hashing is just the beginning

But let's start with that. Say you store your users' passwords like this:

# id:user:password
1:alice:pizza
2:bob:passw0rd
3:carol:baseball

Now, let's say an attacker manages to get more access to your system than you'd like. He's only there for 35 seconds before you detect the issue and close the hole. But in those 35 seconds he managed to snag your password database. Yes, you made a security mistake, but you've fixed it now. You patched the hole, fixed the code, updated your firewall, whatever it may be. So everything is good, now, right?

Well, no, he has your password database.

That means that he can now impersonate every user on your system. Your system's security is destroyed. The only way to recover is to start over with NEW password database, forcing everyone to change their password without using their existing password as a valid form of identification. You have to contact them out-of-band through some other method (phone, email, or something) to verify their identity to re-create their passwords, and in the mean time, your whole operation is dead in the water.

And what if you didn't see him steal the password database? In retrospect, it's quite unlikely that you would actually see it happen. The way you probably find out is by noticing unusual activity on multiple users' accounts. Perhaps for months it's as if your system has no security at all and you can't figure out why. This could ruin your business.

So we hash

Instead of storing the password, we store a hash of the password. Your database now looks like this:

# id:user:sha1
1:alice:1f6ccd2be75f1cc94a22a773eea8f8aeb5c68217
2:bob:7c6a61c68ef8b9b6b061b28c348bc1ed7921cb53
3:carol:a2c901c8c6dea98958c219f6f2d038c44dc5d362

Now the only thing you store is an opaque token that can be used to verify whether a password is correct, but can't be used to retrieve the correct password.

Well, almost. Google those hashes, I dare you.

So now we've progressed to 1970's technology. Congratulations. We can do better.

So we salt

I spent a long time answering the question as to why to salt hashes, including examples and demonstrations of how this works in the real world. I won't re-hash the hashing discussion here, so go ahead and read the original:

Why are salted hashes more secure?

Pretty fun, eh? OK, so now we know that we have to salt our hashes or we might as well have never hashed the passwords to begin with. Now we're up to 1990's technology. We can still do better.

So we iterate

You noticed that bit at the bottom of the answer I linked above, right? The bit about bcrypt and PBKDF2? Yeah, it turns out that's really important. With the speed at which hardware can do hashing calculations today (thank you, bitcoin!), an attacker with off-the-shelf hardware can blow through your whole salted, hashed password file in a matter of hours, calculating billions or even trillions of hashes per second. You've got to slow them down.

The easiest way to slow them down is to just make them do more work. Instead of calculating one hash to check a password, you have to calculate 1000. Or 100,000. Or whatever number suits your fancy. You can also use scrypt ("ess-crypt"), which not only requires a lot of CPU power, but also a lot of RAM to do the calculation, making the dedicated hardware I linked above largely useless.

This is the current state-of-the-art. Congratulations and welcome to today's technology.

Are we done?

So now what happens when the attacker grabs your password file. Well, now he can pound away at it offline instead of making online guess attempts against your service. Sadly, a fair chunk of your users (4% to 12%) will have used the password "123456" or "password" unless you actively prevent them from doing so, and the attacker will try guessing these first.

If you want to keep users safe, don't let them use "password" as their password. Or any of the other top 500, for that matter. There's software out there to make accurate password strength calculation easy (and free).

But also, multi-factor authentication is never a bad call. It's easy for you to add to any project. So you might as well.

Now, Your 5 Minutes of Glory

You're in front of your boss, he asks you why you need to use PBKDF2 or similar to hash your passwords. You mention the LinkedIn class-action suit and say, "This is the minimum level of security legally expected in the industry. Anything less is literally negligence." This should take much less than 5 minutes, and if your boss isn't convinced, then he wasn't listening.

But you could go on: "The cost of implementing hashing technology is negligible, while the cost of not implementing it could be in the millions or higher." and "In the event of a breach, a properly-hashed database allows you to position yourself as a well-run security-aware organization, while a database improperly hashed is a very public embarrassment that, as history has shown many times over, will not be ignored or overlooked in the slightest by the media."

If you want to get technical, you can re-hash the above. But if you're talking to your boss, then you should know better than that. And analogies are much less effective than just showing the real-life effects that are perfectly visible with no sugar-coating necessary.

You don't get people to wear safety gloves by recounting a good analogy. Instead you put some lunch meat in the beaker and when it explodes in green and blue flames you say, "that's what will happen to your finger."

Use the same principle here.


Web app and database on same server, what is benefit of encrypting database data?

The pro's:

Encrypting the database will ensure that should the database files be leaked they will be inaccessible by the attacker or any other party they are shared with (given the attacker did not also obtain the key/password/user privileges). This means if the server is stolen or old backups are lost or the database files are obtained otherwise the data should remain confidential.

The con's:

There is a performance overhead associated with encryption/decryption of the data in the database. This depends greatly on the database system you are using and the type of encryption. It can be ascribed to the fact that every data set that is queried from the database would have to the decrypted to be usable by the web application and similarly all data written to the database would have to be encrypted. These operations can take a long time, especially on large data sets. This performance overhead can be negligible or significant depending on your use and expectations of the database.

The caveat's:

Encrypting the database does not protect the data in it if the attack vector is your web app (like the SQLi you mentioned). Your web application accesses the database as a privileged user that can decrypt the data in the database, thus any attack that is executed through your web application will be able to access the encrypted data. This means that a determined attacker would still be able to extract all the data from your database via a SQLi vulnerability.


How do SSL authenticated users prove authenticity through UDP packets?

The safe method is to use DTLS: that's SSL/TLS applied to UDP.

The less safe method is to invent your own protocol. In this case, since you worry about authentication only, things would go that way:

Client and server make some normal SSL and run an authentication protocol within that SSL.
Client and server exchange a symmetric key K within that tunnel (e.g. client generates K randomly and sends it to server).
Each UDP packet sent by the client is authenticated with a MAC (e.g. HMAC) using key K. The server uses K to verify that the packet really comes from the client and has not been altered in transit.
Each packet must include a sequence number, and the server must maintain some knowledge of the last received packets (with a window for out-of-order packets), so that the server may notice when packets are dropped, duplicated, reordered, or replayed.

Proper packet management to avoid replay attacks is a matter of subtlety; leaving that job to an already implemented DTLS library is the smart thing to do.


very secure router and advice to prevent intrusion

Many routers can be flashed with custom firmware, e.g. DD-WRT, OpenWRT, or Tomato. These alternative systems have additional security features, for example:

Enforcing SSL-only administration.
Allowing HTTP(S) logins only internally, or only on wired connections.
SSH login with client certificates.
Stateful firewalls with more features than your average home router.
Advanced logging (e.g. log servers, SNMP traps, etc.)
Native IPsec support.
More advanced settings for wireless security (e.g. RADIUS)

On some of these systems you can also disable firmware uploads on the web panel entirely, to make it a little more difficult for attackers to do drive-by attacks.


Is Redux a secure place to store JWT tokens?

Redux stores the state in JavaScript object. This makes it vulnerable to an XSS attack just like localStorage or sessionStorage. If you need your JWT be readable on the client side you can freely use Redux, just be sure you take care of XSS properly. If the JWT is not required on the client side, better leave it in httpOnly cookie and handle CSRF instead.


Do browsers know domains that are supposed to be encrypted?

The short answer: they know a very limited number.
HTTP Strict Transport Security was introduced to provide better guarantees that a website is being served over HTTPS when specified by the operator.
This works well for websites you have visited recently as your browser will remember their HSTS policy and refuse a plaintext connection.
For example, if you visit your (previous visited from home) bank's website from an untrusted network that happens to have a man in the middle attempting to downgrade the connection to plain HTTP, your browser will refuse to connect because it remembers the website's security policy.
If you have not visited the site previously, the man in the middle needs to not only downgrade the connection security, but also remove the HSTS header (Strict-Transport-Security) from the response. This isn't difficult.
The problem you have identified is the major limitation: what happens if you are the victim of a downgrade attack during the first visit.
One solution browsers have implemented is to package a "pre-loaded HSTS list" of popular websites known to require HTTPS. Obviously this cannot be comprehensive and even with the list, attackers can still setup security downgrade proxies at slightly related DNS names.
You can submit a domain for inclusion in the HSTS Preload List at hstspreload.org.


SQLi with comment filter: dumping the database

I figured out that the following injection dumped the database(not through outfile though):

' union select null,group_concat(username),group_concat(password) from users group by '


You will surely have to handle a whole truckload of messy things if you really want to do that. And if you are doing this alone, it's way more than you can probably handle.

Assume that every user will try his best to abuse your server, attack other servers, mine cryptocurrencies, send spam, host porn and warez, steal each other passwords. And you will have a small army of misbehaving users doing that all the time.

First, you will have to harden the server as paranoid as you can, it will have to be barely usable to be harder to be abusable. List all SUID programs you have, and determine if they all need SUID. Remove the SUID bit from any program you can live without.

Subscribe to all security lists you friend Google can give you. And follow them. You must be sure to patch any bug on the programs you have as soon as you know there's a bug, because your users will know before you and will exploit. Have a policy that allows you to reboot the server any time you want, with no forward notice, for any reason. Patch and reboot.

Properly configure SELinux or AppArmor on the server. They will help you keep your clients away from each other, and will log misbehaving programs or users. Use the logs to ban users later.

You will have to setup a beefy firewall, with both ingress and egress filtering to limit the traffic to known bad places. Dropping all Tor traffic will be good. And define traffic shaping, and bandwidth allocation and allowances by user. And ban UDP. And torrent, and DHT, and anything  loosely related to P2P.

Put a good IPS/IDS in place on the server, and on the gateway. If anyone gets root on your server, he can put a rootkit on the server and mask his activities. Having a IPS/IDS on another server will help you detect discrepancies. And secure that gateway the better you can. It will probably be the prime target for hacking.

You would like to remove compilers and a lot of interpreters from the server, so your users will have less room to misbehave. And limit the disk quota. And mount /tmp with the noexec flag. And mount /home with noexec too. And hunt down every world writable file/directory, and change the permissions. World writable directories are easy to abuse.

And log everything. Twice. On the local server, and on a remote server, a hardened and hard to access server. When someone from your server abuses another party, you may be liable to some extent. Having documented all access will help you steer the blame away to the user.

And use a log manager (like Splunk). You will not be able to read all the logs you will be generating and parsing them by hand. A log manager will help you detect faster when someone abused the server, and kick them as soon as possible.

Have a draconian TOS, EULA, Service Agreement. The most draconian your draconian lawyer is able to write. And have one lawyer write it, so it will be valid when you have to sue one user who used your server to commit fraud. And be the BSfH (Bastard Sysadmin from Hell) when dealing with them. Don't let your users break any rule twice, kick them out of the door on the first offence.

And don't even think about providing this for free. You must have some way to punish the bad users, and having them paying first and using later, and losing access if they abuse your service can turn down some bad users. Charging someone 500 USD for Abuse fee (with all supporting documentation) will help you.

And securing you server is not an activity, it's a day to day routine. Every day you will have to harden something.

And I wish you luck.


How to implement magic link sign in with oAuth2

Yes you could use OAuth2 for this szenario, however I think  that OAuth2 is a little too much overhead for this particular use case.

What you basically want is a JWT (Json Web Token). After authenticating against the portal, it creates a JWT-token. This token contains some information about the user, maybe his username / mail and his permissions. Also, this token gets signed with the private part of an asymmetric keypair - only the portal knows this private key. When accessing the client-application, you pass the token as an http-header (probably the authorization-header) with the request. Your client-app knows the public part of the asymmetric keypair so it can verify the token. When the token is verified and not expired, the user is authenticated in your client-app. Here you could also check some permissions which are included in the token.

You can read about JWT here: https://jwt.io


How to retrieve Kerberos Service tickets?

Sometimes it might happen that the tickets are not cached in the memory, and so they will not be retrived by mimikatz. So to retrive ticket of the SPN the second step will help in retriving the tickets for the specified SPN if not already cached.


How secure are the password files used by Password Safe and Password Gorilla?

By fast, they mean once you've set up a decryption key (e.g., entered your passphrase), you can decrypt a large or small file very quickly.  The time necessary to check a single passphrase of twofish and DES are both similar (see time/cycles to set up key and IV - initialization vector):

http://www.cryptopp.com/benchmarks.html

(these are benchmarks for encryption; but should be similar).

Wikipedia lists some progress on attacks of twofish, but concludes by quotes the first author of the a decades old published partial attack:

  "But even from a theoretical perspective, Twofish isn't even remotely
  broken. There have been no extensions to these results since they were
  published in 2000".

However, you mention you have a complex password.  You probably should be using a passphrase.  Eight random characters (upper/lowercase + numbers) ~ 247 ~ 1014?  The quoted benchmark may take ~10 microseconds (10-5 s) to try one password; so you could try 10^14 passwords in a 109 s ~ 100 years of CPU time; which is in the realm of feasibility for say gov't to eventually break.  If you had say a 6 word diceware passphrase (77 bits of entropy) it would take 100 billion years of today's CPU time to break.