How to defeat doubling up apostrophes to create SQLi attack?

I try to show both sides of the security spectrum. Security is important, so you shouldn't just know how to defeat security, you should know how to implement it as well. Thus, I'm going to list a prevention first. If you don't want to read this, scroll down.

How do I prevent SQL injection?

Doubling up apostrophes is not the answer when it comes to security, and it can lead to insecurity. The answer depends on the programming language you're using.

For SQL Server / Oracle / MySQL

With Java, use CallableStatements and PreparedStatements correctly.
With PHP, you'll need the appropriate Prepared Statements.
With C#/VB.NET, you'll need parameterized queries.

Note that these are all the same concepts in every language. They just have different names.

Even with prepared/callable statements or parameterized queries, the following is incorrect:

// Bad code, don't use
string sqlString = "SELECT * FROM [table] WHERE [col] = '"+ something +"' AND [col2] = @Param";

You must never concatenate your SQL variables.

With SQL server, depending on your chosen language of choice, your query should look something like this:

C#

using (SqlCommand command = new ("SELECT * FROM [tab] WHERE LName = @LName", connection))
{
    // Add new SqlParameter to the command.
    command.Parameters.Add(new SqlParameter("LName", txtBox.Test));

    // Read in the SELECT results.
    SqlDataReader reader = command.ExecuteReader();
    while (reader.Read())
    {
    }
}

Java

Connection con = DriverManager.getConnection("database-connection-string","name","pass");

// Question marks are the bound variables which are parsed in the defined column order.
PreparedStatement findLName = con.prepareStatement("SELECT * FROM [tab] WHERE LName = ?");

// The order in which the question marks appear. You can have more than one in a prepared statement. First one is "1", second is "2", and so on.
findLName.setString(1, Lastname);

findLName.executeQuery();

Statement stmt = con.createStatement();

PHP

Check w3schools for an example, I don't want my answer getting too long.

Note that this still doesn't get rid of potential injection of scripts onto a web page. You could insert exactly as they ask, within acceptable ranges, and then output the results to HTML.

If they insert the following (dumbed-down example):

<script> window.location.href='hxxp://www.mymalwarewebsite.com/'; </script>

...and you output that result to your page, then you're in big trouble. So what if you remove anything from <script> to </script>? What if they insert:

<scri<script>pt> window.location.href='hxxp://www.mymalwarewebsite.com/'; </scri<script>pt>

...? If you remove the script tags with replace, you're still stuck with that exploit.

What you really want is the following in addition to the above:

For C#, you'll want to use HtmlEncode
For Java, you'll want to use Java Html Sanitizer from OWASP
For PHP, you'll want to use HtmlEntities.
For all cases involving unicode parsing, you want to prevent unicode injection.

Shut up, Mark! How do I beat doubling up apostrophes?

You may be able to beat them in different ways; you may be able to force various SQL databases to translate unicode to the local charset. For example, Ā could be converted to A. Even worse: U+02BC, or ʼ would be translated as ', which is U+0027. This is called Unicode-based Smuggling.

Doubling quotes doesn't work in older versions of MySQL.

Although not really an SQL injection attack, you can try to force the website to inject malicious code to display to their users. You can try inserting script tags (read above for an example). Imagine injecting a drive-by download when people view your page, or a user list.
Although not technically an SQL injection attack, you may be able to beat this protection by looking through the console in your browser and checking for integers being sent to the database, and then modify the request. This is called a Direct Object Reference exploit. There are various tools which can do this. Prepared Statements will not protect you against this attack. Please read the OWASP article


Are IDE DMA attacks possible and is it possible to prevent them purely with software means without any IOMMU or other special hardware

The IDE interface itself does not allow DMA, but PCMCIA does.

DMA requires a feature of the PCI bus called the bus master enable bit set by privileged software that recognizes the DMA-capable device and enables it. A hardware driver can enable bus master for any PCI device with DMA capabilities. This is what happens to both the internal IDE hub (in the ICH) and the PCMCIA card. The IDE protocol itself does not support DMA. The main difference is that the ICH is internal and trusted, whereas PCMCIA is external and untrusted. Because of this, connecting a new PCMCIA card is far more risky than hooking up to an untrusted IDE device.

  is it possible to prevent them purely with software means without any IOMMU or other special hardware

It is technically possible to prevent this in software, assuming no ugly bugs in implementations of the PCI specifications. However, it would require modifying the driver software to not grant bus master capabilities to that interface when a device is plugged in which would most likely completely prevent the card from functioning. At the very least, it would limit it to the obscenely slow PIO mode for IDE, rather than the much faster UDMA mode that, as the name implies, requires DMA. PIO is slower because it needs to involve the CPU for every data transfer, which is very inefficient. If PIO is not supported and DMA is disabled... well then the PCMCIA card will not function at all.

  Is it possible to create an universal rooter for TVs and receivers based on a custom PCMCIA card?

This depends on whether or not the TV or receiver is running an architecture that supports DMA and does not have an IOMMU or any other protections against rogue direct memory access. A TV or receiver is an embedded system and might not behave like the familiar IBM-style x86 PC.

  Or can it be that all the TVs are backdoored by backdoored CI modules?

This is not something anyone can know without auditing all the TVs. I would hazard a guess and say no, simply because it would be so easy to detect (and so hard for a single malicious card to support a reliable attack against a large number of presumably heterogeneous TV models).

DMA and PIO are the two ways to do I/O. PIO is significantly slower than DMA.

It might be useful to understand why DMA exists and how it works. When DMA is supported, a dedicated region of memory is set up and the controller (whether the ICH or PCMCIA) directly writes the data read over IDE to that memory region (using the DMA-based UDMA or MDMA protocols). From the CPU's perspective, it issues a command to read data and then can go do its own thing, knowing it will be asynchronously alerted with an interrupt as soon as the process has been finished, with the requested data waiting right there in memory for it. Likewise if it wants to write over IDE, it can simply populate that memory region with the desired data and tell the controller to take it. Just like when reading data, the CPU is free to go off and do its own thing without needing to micromanage the transfers. It will be alerted with an interrupt as soon as the task is completed. This is why transferring data to and from devices (GPUs, NICs, storage devices using IDE or SATA, etc) can be made so fast and require so little CPU to perform.

Taking advantage of DMA to perform such optimizations and get out of the CPU's hair requires DMA actually be supported. After all, how can a device avoid bothering the CPU with every transfer if it's not given raw access to the same memory the CPU has? Normally, the device is simply trusted to only write to that memory region and nowhere else. An IOMMU, if present, can force it to use its dedicated memory region and nothing else (a process called DMA remapping, using DMAR tables hardcoded in the BIOS that specify the memory regions to use for each device). If DMA is not supported, then transfers can only happen over the much slower PIO mode.

There are two forms of PIO (Programmed I/O). They are MMIO (Memory-Mapped I/O) and PMIO (Port-Mapped I/O). They are similar in that they both require active interaction from the CPU. With MMIO, a special address range is set up that looks like memory from the CPU's perspective, but the bits have different functions when they are set, meaning it is not regular memory. With PMIO, data is loaded into a register and an instruction (such as OUT) is called. This instruction writes the data over a certain "port" number that specifies its destination. Some older technologies still use this, such as the PS/2 keyboard. However for large transfers of data, it is very inefficient. It requires the CPU load a small register of only a few tens of bits in size with data to write before issuing an instruction and waiting until the instruction finishes before it is able to do any more work. This has to repeat over and over. It is woefully inefficient, to the point where the maximum speed is only a few MiB/s and maxes out the CPU in the process. It makes the CPU the bottleneck.


Can checking HTTP headers protect against CSRF?

All CSRF protections that only relies on putting a predictable value in a HTTP header has the same basic problems:

If you enable CORS with Access-Control-Allow-Headers, you may suddenly be allowing the X-Requested-With header to be set cross origin. Off course, you can solve this by just not setting a bad CORS policy. (The Referer header is "forbidden", and can't be set no matter your CORS policy.)
There have been Flash exploits (and if history is any guide, there will be more) that allows headers to be set in cross origin requests. Sure, Flash is dying, but it's not dead yet.
The Referer header might be blank for loads of legitimate reasons (e.g. stripped away by a proxy). To make this check secure you would have to block requests with a blank header, but that would on the same time block many legitimate requests.

So I'm afraid you still need to rely on setting a header (or some other variable) to a value that an attacker can not predict. In practice, this leaves you with a couple of options, such as a classical token, double submit cookie, or using a bearer token in the auth header.

As always, reading OWASP gives a lot of guidance.


Securely store passwords in a mobile application

It smells like security by obfuscation. If the credentials are stored client side, and if the decryption key is sent to the client, an attacker could install the application on an emulator and through a debugger obtain the decryption key and the credentials. Ok, it is far from being simple but all depends on the value of the database.

A more common (and more secure) usage is to build a multi-tier application: the front app (on the smartphone) does not know the database but only communicate with a server. Here we authenticate the client with user+password, certificate or whatever... And only the server actually communicates with the database. That way the database credentials are never present on client and are never exchanged except on the server-database connection.

TL/DR: you proposal would actually make things harder for a possible attacker that would want to steal the database credential, but does not prevent all possibilities. Use multi-tier design for a really secure solution.


I think there's something to be said for setting a bar, regardless of how low it is.  Can Tripwire be bypassed?  Sure.  Will it catch things that you wouldn't otherwise?  Yes it will.

The main problem I've seen in a Tripwire installation is tuning it to where it isn't false-positive laden to the point of ignoring it.  If it blows up every time someone changes something in their home dir, you'll ignore it.  If it blows up every time your web people change your site, you'll ignore it.  If it blows up every time someone upgrades a package... you get it.  However, if you've got a good workflow around it where it only complains when something abnormal is happening, you'll pay attention to it, and that certainly has value.


Create RSA public, private key pair having numbers generated already

A RSA key pair consist in the following:

The modulus n, a big integer which is equal to the product of two big prime integers, p and q.
The public exponent e.
The private exponent d. d is such that ed = 1 when taken modulo p-1, and also when taken modulo q-1.
The first factor p.
The second factor q.
The value dp = d mod p-1.
The value dq = d mod q-1.
The value q' = q-1 mod p.

The public key contains only n and e.

The private key contains all of the values specified above. Stricto sensu, only n and d are needed for a perfunctory RSA implementation, but the other values allow for faster operation, and also "masking" (protection against side-channel leaks), so the RSA standard defines that a private key contains all the values (see appendix A.1).

From the value you have, assuming that your "m" is really the RSA modulus, the other values can be recomputed, at some effort (less than one second worth of CPU, but more human time than I care to invest in it). From all these values, you could then encode standard-compliant RSA public and private keys; but this requires some knowledge of ASN.1. Finally, a 512-bit RSA key is weak; use at least 1024 bits, preferably more (2048 bits ought to be fine). Some RSA implementations will refuse to work with RSA keys shorter than 1024 bits.

Bottom-line: don't generate the key yourself; use OpenSSL. With the command-line tool:

openssl genrsa -out rsakey.pem 2048

will generate a 2048-bit RSA private key with all the proper encoding; then this:

openssl rsa -in rsakey.pem -pubout

will print out the public key, there again with the encoding done.


Why is there no smartphone OS-style app isolation on PC systems?

Windows 10 does exactly this. Windows 10 Universal Apps run in isolated mode, just as they would on a phone. However, Windows 10 does also allow regular Windows Applications to be installed. Microsoft created a more locked down OS, Windows RT, which only allowed Universal Apps to be installed, but it proved to be not particularly popular.


How is it possible that a  tag was injected, but not executed?

A few possible explanations:

CSP: Check headers and meta tags. I agree that the onerror executing makes it unlikely, but I am not sure it would be impossible.

Browser XSS filter: Only an issue if you are doing reflected XSS. Turn them off, or use a browser without an XSS filter.

Malformed HTML: Are you sure the script tag is actually being interpreted as a tag? Encoding issues, escaping or malformed HTML somewhere else in the document can stop this from happening. To check if this is the case, use the developer tool to see if there actually is a script tag in the DOM.

innerHTML: How does the script tag end up in your DOM? Is it done on the client using JavaScript and the innerHTML, insertAdjacentHTML or similar? If so, the following note on MDN explains the problem:

HTML5 specifies that a <script> tag inserted with innerHTML should not execute.

Note that there may be a framework between you and setting the innerHTML. To execute the script, you have to create the script element via createElement and append it to the DOM explicitly.


Are there any limits to what a HSM will sign?

A HSM does not provide much more than protecting the private key. This is already a strong protection since it means that the private key cannot be simply and unnoticed stolen (and thus misused): If the attacker wants to steal the private key he would not only need to have physical access to the HSM once (which is already a strong protection) but for all transactions since the HSM cannot be cloned.

Additionally HSM are usually protected by a secret (i.e. PIN, passphrase...) which depending on the configuration need to be provided once for all transactions on the initial activation of the HSM (i.e. after plugging it in, after system reboot...) or for each transaction. The latter is more secure but not practical in all cases, i.e. it might be practical if the HSM is used in a certificate authority to sign new certificates but it is probably impractical if the HSM is used to protect the private key of a web server.

  ... Could some application in the OS submit a bitcoin transaction to the HSM to be signed...

The HSM itself has no idea what it is signing. The intelligence if some data  should be signed in the first place (i.e. if some cryptocurrency transaction is valid) need to be provided by the user of the HSM. In most cases the logic to implement such functionality is too complex to be implemented on the fairly small computer the HSM (or smart card) is - if it is clear how such automatic checks should be done in the first place.

If you use for example a HSM to automatically (no PIN required) sign cryptocurreny transactions and you use it on a complex system where it is likely that bugs or misconfiguration allow access to attackers, then you should probably rethink your system architecture. It might be more useful to use the HSM  instead within a separate and minimal system which only implements the necessary checks what should be signed and provides a minimal and secure API to the more complex system.

  Maybe in that case use a TPM? with or without the HSM? but dont TPMs have vulnerabilities?

A TPM is only special kind of HSM with about the same limitations. TPM can have vulnerabilities as much as HSM or smart cards could have. But all these together are very minimal systems which are more easy to audit for vulnerabilities than larger systems. This does not mean though that bugs never happen, it is only much less likely.


Account Lockouts can be a bad idea

Imagine you have the user bob, who has an account at your awesome service. Now Eve wants to be malicious, and lock Bob out of his account.

She sends an invalid login request, then another, then another, and repeats that process until she receives the message that the account bob is locked for a while. Then she repeats this process again and again, until bob is locked for all eternity.

Bob on the other hand would like to log into your awesome service, and gets a confusing error message that his account is locked. He contacts your support at your expense, and they inform him that there has been malicious activity (and helpfully advise him to scan his computer using anti-virus software). After Bob has wasted half an hour of his time, he attempts to log in again, only to find that Eve has still locked his account.

You might ask why on earth Eve would do that. The motive can be manifold:

Blackmail (give me money to get your account back)
for teh lulz
Getting Bob to use Eve's even more awesome service instead
etc...

How to do it instead

What you really want to prevent is online brute-forcing through automated means. Instead of locking the account, consider using a CAPTCHA to verify a human on the other end of the connection. You could also slow-down responses to login attempts to several seconds. This way, Bob would only have to wait a few seconds instead of not being allowed to log in at all.

If you want to go really big and fancy, try to do some behaviour analysis. This will cost you big time, but it does prove to be a useful aid when trying to determine if a login attempt is potentially malicious or not.

What about non-existent accounts?

So far, I explained why account lockouts are a bad idea. But if you really really have to implement them (e.g. because of customer demand), then you should also "lock" non-existent accounts.


Do I need to use DNScrypt, or can I just set up DNS by myself? What's the point?

DNScrypt encrypts the communication between you and the DNS provider. It hides your DNS queries from anyone trying to wiretap your traffic, but it does not hide your queries from DNS provider itself. The primary benefits I see are in situations where you are on an untrusted network (e.g. public hotspot, censored connection, malicious ISP, etc.) and you suspect someone might try to tamper with DNS responses in attempts to redirect you to malicious webpages. This would provide pretty strong protection against that.

If it's privacy and not security you're looking for, then the main question is "Privacy from whom?" If it's privacy from the DNS provider you're looking for, DNScrypt won't help. If it's privacy from your ISP and other potential wiretappers, DNScrypt will protect your queries from being read or modified while traveling between you and the DNS provider.


First off, let's be clear: the client certificates are not self-signed. They are signed by a CA, and that CA's certificate is self-signed. This is important, because a self-signed certificate cannot be revoked at all, by definition: revocation is an information coming from the issuing CA; a self-signed certificate is its own CA.
A second important point is that a CRL is a list of revoked certificates so far. So if you revoke one certificate, then you have a CRL which designates that certificate; if you then revoke another one, then your next CRL must designate both certificates. If the next CRL only talks about the second certificate, then it "unrevokes" the first one. For revocation, Apache has no memory, or rather, the CRL is Apache's memory. Apache will use the latest CRL as the exclusive source of revocation information for all certificates.
This means that you really need to maintain a list of revoked certificates on the CA. The openssl command-line tool can maintain such a list for you: that's the index.txt file, as maintained by the openssl ca command-line option. If you don't use it, then you will have to maintain the information yourself, which is, at best, cumbersome. If you want to handle revocation at all, then the simplest way is to use the index.txt and let OpenSSL manage it.
Now if you have already done it, then it is of course possible to sign a CRL with the CA private key using the library, programmatically; but there is no command-line tool for that. This is said so in the documentation:

BUGS
Ideally it should be possible to create a CRL using appropriate options and files too.

And also there:

RESTRICTIONS
The text database index file is a critical part of the process and if corrupted it can be difficult to fix. It is theoretically possible to rebuild the index file from all the issued certificates and a current CRL: however there is no option to do this.

To produce a CRL with some code, I suggest that you have a look in the OpenSSL source code, in the apps/ca.c file; search for "X509_CRL_new". The functions are not well documented... But, I insist, if you begin to revoke certificates then you must maintain a list of all certificates revoked so far (at least the serial numbers, preferably with the revocation date for each of them), and this basically means making your own equivalent of the index.txt file of openssl ca.


Is it safe to store billing/postal addresses?

On the fundamental front, it is never secure to store or transmit anything somebody wouldn't want people to get. You can make things safer by using various security/encryption methods, but it is still fundamentally unsafe.

On the practical front, addresses are so easy to get as it is. You should avoid correlating them to more personal information which is not a matter of public record, like credit card numbers, social security numbers, passwords, etc.

I believe most users would be as irritated by having to continuously re-enter their address as they would having their addresses lost in a compromise - but one of those makes them think you're making their life harder and one sounds like "a thing that just happens."


Can request from different software on same machine to a server be identified to be from same origin by tracking TLS handshakes?

If two different users visit an website from two different browsers via https, can they be identified by the server to be from same origin(client machine) using information available from TLS handshake?

In some cases, yes.

For example, your question states that the requests come from the same client machine. If this machine has a static IP address then all the IP packets will have the same source IP address in the IP header. IP header information is not protected by TLS. TLS handshake packets are TCP packets, which are then encapsulated in IP packets, which contain the source IP information. Here I am considering this header information to be "part of" the TLS handshake since the remote server will certainly know it.

Edit/Update (to more directly address the question and comment):

  As far as I can understand- since TLS is below application layer, so the Session ID (from Server Hello during TLS handshake) can be same for both requests from different browsers. Thus the server can determine both requests to be from same machine- is that correct?

TLS is below the application layer in a sense, but it is also above the transport layer, since it relies on the underlying TCP.

Since processes communicate via TCP, you would not see two different web browsers (each a different application/process) running over the same TLS connection. Each browser will establish its own TLS connection, each will send its own client_hello, and each will receive its own server_hello. For example, if I use Chrome to connect to www.website.com, and then I use Internet Explorer to connect to www.website.com, I will be able to see (e.g., with Wireshark) two different server_hello packets from www.website.com and those packets have different Session ID values.

So, this would not be a good method of determining that the different browser requests are from the same machine. Whereas, the IP address method mentioned above does have a chance of working.


The Wikipedia article about netcat references this source for Windows:

http://www.securityfocus.com/tools/139

https://en.wikipedia.org/wiki/Netcat#Ports_and_reimplementations


Does OpenSSL leave any traces that a server uses it?

Some servers will advertise their OpenSSL version in the HTTP response headers from an HTTPS request. Example:

Server: Apache 2.2.16 (Debian) mod_ssl/2.2.16 OpenSSL/0.9.8o

These headers can (and often are) be disabled or not include this level of detail, so if OpenSSL isn't mentioned then it doesn't mean the server isn't using it.


OpenSSH is a program depending on OpenSSL the library, specifically OpenSSH uses the libcrypto part of OpenSSL.


What is the difference between artifact and evidence

Artifact: A piece of data that may or may not be relevant to the investigation / response. Examples include registry keys, files, time stamps, and event logs.  You can see many defined in the ForensicArtifacts project on github.

Evidence: A piece of data (artifact) that is relevant to your investigation because it supports or refutes a hypothesis.

With our incident response software, we talk about collecting artifacts from remote hosts and analyzing them to determine if they are evidence.


is pre-master secret computation different while using client certificates

The short answer is no. The way the premaster secret is computed depends on the ciphersuite. With the deprecated RSA-based ciphersuites with no forward secrecy (no key exchange involved), the premaster secret is chosen by the client and is supposed to be random. For ciphersuites based on a Diffie-Hellman key exchange, the premaster secret is the result of the DH key exchange and is thus normally effectively randomly co-generated by the client and the server. The only case where the client certificate is used to set the premaster secret is if the client certificate contains a (non-ephemeral) DH key, and that feature is very rarely used.

Where the client certificate matters (in addition to whatever validation the server performs) is that the Finished message contains data to verify the whole key exchange, including the ClientCertificate message.


How secure is a Python Pyro daemon for storing a password?

I'm not familiar with Pyro specifically, but this pattern is similar to a lot of other common setups.

As you've mentioned, the daemon is storing the password in memory, so any sort of memory dump can retrieve it.

If a user has local access to the machine, they may be able to attack the initial password entry.  Keyloggers are the most obvious tool here; in non-getpass scenarios, you could also leak it through things like reading bash history (if it was in the command-line) or process lists (if it was in the environment).

An attacker may be able to take advantage of flaws in the daemon to write a program that connects to it and gets it to return the password.

Sometimes it doesn't even matter if they have access to the password, as long as they are authenticated.  They may be able to trick your application (either through direct connection to the daemon, or a more remote attack via SQL injection-like attacks) to execute attack code with the daemon's privileges.

  The "storing-password-in-memory-via-daemon" pattern is not something I can deviate from. This approach was decided on by the team as a whole (as opposed to putting the password in a root read-only text file for example). So it's less a matter of, "what alternatives do I have," and more a matter of, "what tools can I use to accomplish this particular task with the simplest and easiest to maintain code without sacrificing too much security?"

This seems like a reasonable implementation of your chosen pattern.


Protect app from Http Proxy like Charles

You can't.

You can explicitly check the certificate used in your app.This will make it harder for anyone to use a MITM proxy. But if the app is running on the device of the attacker, they can change the code and allow their own certificate.


Password manager or two -actor authentication

According to Edward Snowden,

  Shift your thinking from passwords to passphrases

Using Passphrase:

Using passphrase is best practice rather than using passwords. Because password can be guessed or brute-force. But if you like Charles Dickens then your passphrase can be something like this,

  @a@l0v!ng@heart@!s@the@truest@w!sd0m@-by@C.D!ck4fb.c0m
  @a@l0v!ng@heart@!s@the@truest@w!sd0m@-by@C.D!ck4gma!l.c0m

Or you can use a specific command you often use like the following as a passphrase,

  $ awk-F":"'{print$1}'/var/log/random|grep'nothing'

and nobody can possibly guess or (somebody can) brute-force this. You can always develop your own logic for building passphrase.

If are paranoid like me you can add some randomly generated digits in your password which makes it more difficult to crack.
Using Password Manager:

Using password manager is not a bad idea but not a paranoid idea either. Though nowadays password manager like LastPass/onelogin etc are very secure but not totally unhackable. They can be compromised using a vulnerability (Lastpass vulnerability) or anyhow as I believe any method is compromisable. So I do not trust them neither should you.
Two-factor authentication:

These days most of the application supports two-factor authentication which is good. But if you want to use same password for two factor authentication, I don't think that's a very good idea. You just can add some different words like faceb00k#c0m (for facebook.com), ma!l.g00gle#c0m (for gmail.com) etc. of the same passphrase which will make it different.
Changing after 6 months:

Changing passphrase after 6 months is a very good idea. It reduces the attack surface. Suppose an attacker made some reconnaissance about you on last 6 months and came up with your exact password but when you change it after 6 months, you just nip the efforts of the attacker in the bud.


Looking for advice on storing sensitive information - Rails, Postgres, https, pg_crypto, Digital Ocean

Do: use the banking centers data center. Let them take on the burden of physical security. They need to provision something with their IT infrastructure for compliance. Until it's in their environment, just host locally on an encrypted drive with dummy data.

Don't: use any cloud environment. Use a dedicated, managed host. Let the client foot the bill.

Do: double-check on the pg_crypto library's best practices and check out this word for word.
http://www.postgresonline.com/journal/archives/165-encrypting-data-with-pgcrypto.html

Do: read in general about key pairs, salts, and hashes here: https://dba.stackexchange.com/questions/35296/database-encryption-and-key-management-with-pg-crypto

Do: add some authenticators like security questions and allow automated detection of suspicious behavior like logging in from new IP, double-blind customer service verification (customer service cannot see the answers, they only type in the customers security challenges and see if it passed or failed at end)

Do: periodic security audits. Suggest outside firms to assist you and pad your proposal with the added cost. A small e-commerce operation (just talking about signing up for online ed, and paying for it for ex.) costs about $5,000 to audit yearly by a recognized firm.

Do: read up about MITM attacks. Prevent out of date browsers, or self-signed certs from ever using the site. Prefer to use a highly trusted CA and never allow wildcard certs, express certs, or out-of-date certs on server side. All that is your job to do! Congrats on the RFP and good luck.

More to come.


Bitlocker encrypted drive access from other machines

Yes, provided you have the Key Protector (This may be a password, the Recovery Password, certificate, startup key, etc.) then you can access the encrypted drive from any machine which supports Bitlocker.

Usually if it's an internal drive it will be using either the TPM or a Startup Key, but will also generate a recovery password when you turn on Bitlocker. Windows will prompt for the password when you connect the drive to another computer.

External (removable) drives usually use a user-provided password + generated recovery password.

A BitLocker encrypted volume is not tied to the original computer in any way.


No, you cannot hide a open port in any sensible way. The port accepting connections is what nmap tests, and is also the definition of an open port.

It may or may not be a security risk, and it may or may not be desirable. This depends on your needs and applications. If you don't run a webserver, there's no reason to leave it open. If you don't intend for postgresql to be reachable externally, there's no reason to allow it, and so forth.

You should allow only the traffic you need, and block other traffic. Which traffic this is you have to define yourself.


How to conduct a disguised LSA attack against OSPF?

This attack is only need two routers.

Quagga software router, the attacker can launch a simulation.

As shown below:

My problem was solved.


Is it safe to delete a Veracrypt container, empty, never mounted?

It's safe. Just the same as deleting  file.


Can a PHP shell uploaded to a WordPress directory have access to an entire Linux machine?

If you run the WordPress as user www-data, an attacker can do everything the user www-data can do. That's usually quite a lot:

Wide read access. You could test what you can access e.g. using sudo su -s /bin/bash www-data.
Write access to all the other sites run as www-data. You should treat every site as potentially compromised.

To prevent that in the future (not limited to these actions):

Run sites as separate users using PHP-FPM pools.
Chroot jail the web sites.
Disallow potentially dangerous PHP functions.
Do not leave copies of WordPress waiting for installation anywhere.
Keep WordPress and its plugins up-to-date.
Consider adding a web application firewall (WAF).


No it is not pointless. The easiest example: You want nobody to know what's your nickname, in which channels you are and what you're writing in queries (private messages).

To address the concrete question

  Should I be concerned that any router between my IRC client at home and my server hosted in a different country could steal my authenticated, yet insecure connection, and use it to wreak havoc?

In theory you should be concerned, as every router can do so. In practice it depends on who might want to do so and what he can do. I would think the people who both may want it and can do it are inside your LAN.

Your network admin might take over your connection and this won't be too complicated. You do not need to think about messing with TCP-Packets of your stream. He may just have a TCP-Proxy running, which can be as simple as two netcat instances and a firewall rule.


Apparently the system is crashing because he is endlessly trying to read the path, and every other programme running are stuck because they are waiting to access the NTFS drive but they cannot  since the web browser is already trying.


Should we store meeting minutes on an iPad?

I don't believe the solution is to not use your iPad, the benefits are clear. However I do think you need to approach it the right way.

Working on the InfoSec field, I believe you have a responsibility to set a good example. Eat your own dog food.

You need to comply with policy. Is there an exemption process in the policy? This would be the best way to address this, and allows you to formally document the risks you have identified and the mitigations in your exemption request.

As you've identified, be conscious of the sensitivity of information you are recording and storing. Treat the asset as untrusted, or semi-trusted at best. Consider adopting the attitude where you assume anyone can read what you create or store on the iPad. Recording information out of context, and without granular details can help here.

Finally, promote all of the above. When people ask about your use of your iPad within the organisation for work-related purposes, tell them what you've done to mitigate the risks and comply with policy.


Secure crossdomain for rtmp/flash streaming/wowza

A properly locked down policy would look like this in your situation:

<cross-domain-policy>
  <allow-access-from domain="sub.example.com" secure="true"/>
  <site-control permitted-cross-domain-policies="all"/>
</cross-domain-policy>

Allowing * wildcard for all domains means that user sessions on sub2.example.com could be compromised by a malicious Flash app on another domain that the users visits.


TLS is a protocol for establishing the symmetric key that will be used for encrypting data/messages between two endpoints. So if the client communicates with server through the TLS protocol, they will only negotiate (safely), the key that will ultimately be used by each to encrypt/decrypt the data using an algorithm like AES.

To serve your purpose, you will need to encrypt the data one more time with a symmetric key that the two clients (and not the server) are aware of. The suggestion of course assumes a lot about the way you are passing info from clientA->server->clientB.


Sounds like you're doing security assessments for compliance reasons, but I see no mention of compensating controls, acceptable risks, remediation plans in action, etc.

This whole question is really weird to me because from the information you've provided in your question, it seems like neither side of the business relationship -- either you or the client telling you to cover things up -- is qualified to perform compliance assessments. Not trying to be harsh, but there's simply way too many red flags. I'll explain why below.

For some things, the client will not, cannot, and should not be forced to fix in order to get a "Clean Report," but let's [Mass Dispel] some  things first.

Security Assessments

A security assessor's job is to find vulnerabilities, and help explain away vulnerabilities that are not exploitable. Something may be vulnerable, but there could be multiple reasons why it isn't exploitable.

It will then be your job to examine the evidence and determine whether or not the evidence is correct, and then exclude those irrelevant items from the report. In the case of PCI compliance, evidence of this will need to be provided to a third-party Qualified Security Assessor.

If they're hiring you to do the explaining, you'll need to dig deep on each vulnerability you find and attempt to assess whether or not that vulnerability can be exploited. Work with the engineers (sysadmins, developers, network engineers) to get the information you need.

It could be something simple such as nmap/Nessus/etc. returning the wrong version, not realizing that a backported version exists, or something to do with multiple compensating controls for common TLS "misconfigurations."

You can check for the exact version with dpkg -l | grep 'package' for example, then determine if a backported security patch was applied. This problem is really common with many approved scanning vendors.

These are businesses who can't stop what they're doing to fix every little thing that isn't exploitable. It's not a sustainable security model. Should they still be made aware? Absolutely. But they need to prioritize fixes and manage risk.

Clean Reports vs. Fraud

Correct me if I'm wrong, but it sounds like they're looking for a clean report with no remediation. Something's really fishy here. This doesn't make sense.

Any reputable company, especially those involved in required compliance audits, be they quarterly or yearly, will fix all of the vulnerabilities which prevent a passing score for their compliance report. In many cases, they are able to circumvent fixing these vulnerabilities if they can provide documentation for compensating controls, acceptable risks, remediation plan in progress, etc., and you will be required to accept these circumventions if their evidence is correct, but you will need to examine it yourself.

If they attempt to pass off a clean report that is not really clean, then it's fraud - especially if they're pushing these lies to their clients. That's fraud in the highest order, and you do not want to be complicit in this. There will be severe penalties for both you and your client.

Fraudulent Activities

My responses in this section will be made with the assumption that no compensating controls, acceptable risks, remediation plans in action, etc. exist, and they're trying to cover up vulnerabilities.

  They are (rightfully scared) of what I will find. Some even tell me "don't go so deep this time, ok?"

Assuming what you're saying is true and not taken out of context, then I'm pretty sure that's illegal -- unless you're going out of scope. The company should provide you a scope, and you must stay within whatever is determined to be in scope for the audit. If you intentionally go outside of your defined scope, I'd be surprised if they continue to hire your company to perform assessments as that's a betrayal of trust.

  The other solution I tried is restricting scope. If I only test a small part of the stack, the client could get what they are looking for: a "clean report". But it's rare that they agree to that. They usually want everything tested.

I'm having trouble with this. Almost every single client will provide a scope, especially those going through compliance audits. Not everything is going to be in scope for them. If you want to go out of scope because you think you found something dangerous, you need to ask permission and get it in writing.

  I'm also worried that this will backfire because inevitably someone else will re-assess what I did and find massive holes. They they will conclude that I have no idea what I'm doing because I missed such obvious flaws. Reputation is everything in this industry, so this is a big risk.

If you're within scope, then... do you want to be complicit in fraud? You're worried you'll lose clients if people are asking you not to dig too deep, but think about what will happen when a qualified auditor shows up and discovers your company is complicit in fraud.

This is an extreme ethical violation. If you have an (ISC)² certification, then prepare for revocation if anyone finds out. This can also amount to a federal crime if you're in the United States, or anywhere else where fraud is illegal.

Believe me, as someone who has dealt with multiple penetration testing and security assessment firms, if you hold back on glaring flaws like this, many of us will no longer do business with you. If you have a reputation for doing this, it will spread quickly. I've seen consultation firms dropped for not finding very basic things that we already knew about.

Clean report with Remediation

However, it's not uncommon for companies to provide a clean report after they fix your proven vulnerabilities. There should be no need to provide penetration test and security assessment reports that contain vulnerabilities, but only the report after the company remediates them.

If you find more vulnerabilities afterwards (provided they're paying you to do so), that's actually great! Any reputable company will be glad to fix these problems (or have you or themselves explain compensating controls, acceptable risks, remediation plan in progress, etc.) so they can pass their audit.

If they're hiring you too late in their compliance audit process and are worried it won't be completed fast enough, then that's on them and not you -- unless you're too slow at getting your job done within a reasonable time frame.

Where's the remediation coming into play here?

Bringing Balance to the Force

  How to maintain balance between integrity and client satisfaction in vulnerability assessments

There is no balance in the case of fraud or other crimes.

Do your job and do it right. Don't violate anyone's trust and do not commit fraud. Clients who ask you to commit crimes are not the type of clients you're looking for, or they shouldn't be.

TLDR

Get some more experience with assessment and compliance auditing. Manage risk, but don't commit fraud.


TLS certificate - How to assign a CN name for an EC2?

First of all, you should not be using the CN attribute of certificates, but the SubjectAlternativeName attribute (also known as SAN). In fact, the fallback to CN if there's no SAN has been deprecated for some time now in browsers.

Still, your question stands of which hostname to use in the SAN of your certificates. The main question here is which name will you be using to connect to the service, since you should be using the same name in the certificate (and your client should be validating it!).

If you are accessing it as ip-172-xx-xx-xx.ca-central-1.compute.internal, place ip-172-xx-xx-xx.ca-central-1.compute.internal
If you are accessing it as ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com, use  ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com
And if you are accessing it under either of those names, include both in the certificate. The SAN may contain many entries (they are usually capped by the CA, but dozens are easily supported everywhere).

Note that if you are only using the ec2-99-xx-xx-xx.ca-central-1.compute.amazonaws.com name you may use a publicly trusted CA, whereas if there's any .internal entry, you can't do that, and would need to use your own CA and install that one on the clients.


With usual implementations, doubling the RSA key length means that encryption will be four times slower, and decryption will be eight times slower. RSA encryption is much faster than RSA decryption (in the context of RSA signatures, verification is similar to encryption, and generation is similar to decryption). The theory says that for a n-bit key, computational effort for encryption is proportional to n2, while effort for decryption is proportional to n3. In practice, there is a little bit more to RSA than just the modular exponentiation, and the overhead does not scale in the same quadratic/cubic way, hence, for a specific implementation, you will not get exactly an 8x factor.

Also, note that the fast encryption (and its quadratic behaviour) relies on the use of a short public exponent. This is the way RSA is commonly used; it is possible to have a RSA public key with a long public exponent, which will make encryption as slow as decryption. A long public exponent does not seem to improve security, so short public exponents are the rule. Some widespread RSA implementations do not support long public exponents anyway.

OpenSSL comes with a command-line tool which can perform some benchmarks. Try running this:

openssl speed rsa1024 rsa2048

On my PC, this results in the following:

                  sign    verify    sign/s verify/s
rsa 1024 bits 0.000646s 0.000035s   1549.1  28408.6
rsa 2048 bits 0.004097s 0.000120s    244.1   8331.1

so we get factors 6.3x and 3.4x for decryption and encryption, respectively, when doubling key size from 1024 to 2048 bits.


Can Captive Portal links open browser/apps?

In a browser can a captive portal page do everything what another page can. So the only additional danger is that you open it without clicking on it. But that's true for many pages in the modern web, everywhere is stuff loaded in invisible iframes and similar.

There were exploits to do operation system level stuff, e.g. calling costly numbers via tel:// URLs, which was possible from all websites. Modern phones only show you the dialer with the number, but at this time they started dialing automatically. Running other URL intents like whatsapp:// and similar is possible as well, but the apps providing such intents should be secure to do nothing dangerous without more user interaction.

The other less common aspect is, that apps which try to load resources before the portal is detected on the OS level (if there is such a detection) get the portal instead of their resources. Here the security is the same as in an insecure network, where someone can spoof the API endpoints and more.

So the captive portal page is just a hijacked HTTP request with the same consequences as in other hijacking scenarios.


Decrypt AES 128 CTR without IV (Counter)

No, not easily.

If the data is important to you, you could try brute-forcing the range of plausible IV values.  For each guess at the IV, try decrypting and see whether the result looks like it could be your message.  (Incorrect guesses will result in random gibberish.)  If the number of plausible IV values is not too large, this might be successful at recovering your data.

Caveat: I am assuming you are focusing on recovering some data where the IV has been lost -- not on designing a secure cryptosystem.  If you are designing a cryptosystem, you should not rely upon this for security.  In other words, don't rely upon keeping the IV secret to protect your data.  Attackers might be able to guess or figure out the IV; it's not a good basis for security.

Edit 10/2: Do you happen to have any known plaintext?  In other words, do you know part of the message?  If you know part of the message, then you may be able to recover the IV.  For instance, if you know a consecutive 16 bytes of the message that corresponds to a block boundary, then you can xor those 16 bytes of plaintext against the corresponding 16 bytes of ciphertext to recover 16 bytes of keystream.  Now decrypt that keystream block under AES (with the known AES key); the decryption will be the value of the counter for that block.  Then you can run the counter forward/backward from there to learn the counter value for all other blocks, and decrypt the rest of the message.


What methods can be used to verify identity against a database?

Since you have postal addresses send them a letter via mail merge that contains a long random code. They enter the long random code and perhaps some other information they should know such as D.O.B. to validate they have physical possession of the letter and some knowledge of the student.

This tells you they are:

Someone with access to the mailing address
Reasonably the parent or guardian if addressed appropriately
Or a corrupt postie ;) Or inquisitive sibling...

Once they have passed the initial authentication check require they enter an email address and password. Once this has been verified invalidate the code you mailed them. A unique id - either sequential or a guid - should be generated against each user in the DB. This becomes their unique identifier and you can then associate users who should have access with the record.

Since the code you generate is effectively a password good security practice for storing passwords should be used for storing the code - suggest bcrypt ( http://en.wikipedia.org/wiki/Bcrypt ) or PBKDF2 ( http://en.wikipedia.org/wiki/PBKDF2 ) with a suitable salt and work function.

Another potential approach would be Knowledge Based Authentication ( http://en.wikipedia.org/wiki/Knowledge-based_authentication ) - you ask them things only they would know. This requires you to have accurate records of things they should know! (e.g. all the grades from their childs last report card).

Hope that helps.

Regards
Andy


Are there any serious problems with this technique for generating symmetric keys?

Answer to your specific question: There's an easier way to tweak their scheme to achieve what you have in mind.  Go with what's in the book, except make the following modification:

hashed_entropy = SHA2-512(0 || entropy) || SHA2-512(1 || entropy)

so that hashed_entropy now contains 128 bytes.  Now use the first 64 bytes for the Bob->Alice direction (e.g., extracting keys and nonce as in the book), and the next 64 bytes for the Alice->Bob direction (similarly, extracting keys and nonce).

(Here I write || for the concatenation of two byte-sequences.)

Important cautionary note: This scheme does not authenticate Bob.  It is not suitable for use in environments where mutual authentication is expected or required.

High-level comment: I tried to answer the specific question you asked.  However, I would be negligent if I stopped there.  Are you sure you are asking the right question?  Are you sure you need to implement your own way of building a secure (encrypted, authenticated) channel?

While Practical Cryptography is a fantastic book, I'd be pretty reluctant to use a custom design, even one taken from that book, unless I had no other choice.  If it were me, I would first make a serious attempt to reuse some well-vetted, widely-deployed design, e.g., TLS.  Only if that completely failed to meet my requirements would I then consider doing something custom.

My criticism has nothing to do with the quality of Practical Cryptography, but rather with the broad variety of things that can go wrong if you design and implement your own secure channel (including, e.g., subtle implementation flaws that can be introduced).


Why do we ask for a user's existing password when changing their password?

If a user leaves their computer unattended for a few minutes (while logged in), we don't want someone else to be able to walk by and quickly change their password.  For one thing, this would allow the attacker to change the associated email address, too, and now the legitimate owner is never getting his/her account back.

For another thing, just think of the potential for office pranks!

Changing your password is a sensitive enough operation that it makes sense to require the user to re-authenticate.  And, since changing your password is a relatively rare operation, this doesn't introduce much inconvenience for users: it only changes the user experience in the rare cases where you change your password.


While this is true, that is true for many applications. If the attacker already has access to the file system it is far too late to worry about your database server. In unix-type operating systems, the configuration file should be accessible only as root (as it is in /etc/mongodb/mongodb.conf). If the attacker has root privileges to change that file, you're boned anyway. Alternatively, the attacker could simply copy the underlying database-files, run his own mongo database server and create his own user or use it without authentication to get to your data. To prevent this, only the user that the database runs under should have access to those files.

So the issue, in this case, isn't mongo, but the security of the whole system and the stack of controls, of which securing the configuration file is one. Authentication checking is useful only when the access is coming from outside and can't be bypassed.


Sending httpOnly cookie also in HTTP response body

If you're able to send the token in the request body, it must be stored somewhere script-accessible (probably in session or local storage). If it's stored somewhere script-accessible, then there is literally no point having the cookie be HttpOnly.

HttpOnly is only barely a security measure to begin with - for most exploitation scenarios, it might limit the damage or make exploitation harder, but XSS can still easily be catastrophic for the user - and it only makes sense at all if the cookie value is never exposed to script anywhere else. Since that doesn't apply here, the HttpOnly flag is pointless.


In order to be PCI DSS compliant, they are expected to meet the requirements of Protecting Telephone-based Payment Card Data, a PCI Security Standards Council document.  It's complex, but generally requires that they limit recording of card details as much as possible, store them encrypted if they must be stored, and never store Sensitive Authentication Data (your CVV).  The document provides this direct guidance:

  What to Ask Your Call-Center Provider

  How does the call-center system help my company comply with the PCI DSS requirements, and how does it automatically remove sensitive
  credit card information from recorded calls?

  If you take credit card details over the phone, ask your supplier to
  prove that they are “PCI DSS compliant” and to explain how they remove
  sensitive authentication data from their recordings, automatically
  (with no manual intervention by your staff).

In practice, you can usually tell a compliant provider because they will briefly transfer you to enter your CVV to a program using the buttons on your phone, then transfer you back to continue speaking with the representative.  That's how they avoid recording your CVV.

To be clear, they're allowed to record your card number, so long as they protect it (encryption, generally).  No matter how you transmit your card number to a merchant - online, in person, on the phone, or via paper mail - they're allowed to store your card number.  And it is necessary for either them or their processor to store it for a significant period of time as part of the regular card process.


What is the purpose of slowing down the calculation of a password hash?

The calculation is intentionally slowed down to make it harder for an attacker to brute-force the user passwords in case the password database gets stolen for example.

Because a hash function only works "one way", to get the password for a hash you have to hash random passwords until you find one with a matching hash. (Rainbow tables provide a tradeoff though).

Using GPUs it is possible to brute-force billions of e.g. MD5 hashes per second.

That's why hash functions like bcrypt or scrypt were developed to mitigate this problem by running slowly and in case of scrypt requiring lots of memory so it's unfeasible to compute the hash using GPUs.

For your "normal" application this will most likely still be fast enough, because you're computing a single hash only, so the performance impact will be negligible.


Is it worthwhile to restrict SSH on home web server to local network?

The second you open up a SSH port to the public web it will have multiple brute force / default credentials attempts against it. Just automated tools trying to get access - its up to you to weigh the risks, but if you go ahead insure good security hygiene. Turn off passwords based auth - limited retries etc.


Is it possible to block emails (to all email accounts) that contain certain word/phrase patterns?

I don't KNOW this entire concept of targeted marketing which googles uses to brings context based ads on your gmail is worth blogging your mind. They say that they don't do anything with user-mail but they do have abundant filters which are going to pick on anything which matches their dictionary.

I think google does provide you the ability to define just the filter.

SETTINGS>FILTERS>CREATE NEW FILTER


Clarification needed for NIST's whitepaper "Recommendation for Password-Based Key Derivation"

A Key Derivation Function turns some secret data into more secret data, and is used to make keys of appropriate size from other keys which do not have the appropriate size. An example of KDF is the one called "PRF" within SSL/TLS: it is used to convert whatever shared key was built between client and server (using RSA encryption or Diffie-Hellman) into the symmetric keys which will be used thereafter for symmetric encryption and integrity check in the established connection.

A Password-Based KDF (hence the name "PBKDF") is a KDF where the source material is a "password", i.e. a piece of data which is retained in the brain of a human being, and (usually) typed on a keyboard by the brain owner. This is not the case of SSL. A Password-Based KDF is used whenever you want to perform some data encryption "locked" by a password. For instance, when you "encrypt" a file with a password (e.g. the "password protection" in Word, or a password-protected Zip archive, or a PGP keyring or SSH private key stored in a file with "passphrase protection"), you can be sure that a Password-Based KDF was involved.

The job of a Password-Based KDF is to:

accept as input a sequence of characters (of semi-arbitrary length), and output a sequence of bits of appropriate length for the intended cryptographic algorithm (e.g. 128 bits for AES encryption);
"protect" the password against dictionary attacks by being appropriately slow and expensive (an attacker could try to guess the password by trying out potential passwords; we want each trial to be heavy and expensive for him), and by using a salt (so that attacking two encrypted files is twice as expensive as attacking one).

PBKDF2 ensures the second property through a configurable "number of iterations" and a salt (both parameters are typically stored in a public header for the encrypted file).

A devious but common usage of PBKDF2 is to hash passwords. This is about using the PBKDF2 output as a password verification token; a password will be accepted if the derivation through PBKDF2 will yield the same value. PBKDF2 was not initially designed for that, but still does an acceptable job of it, although bcrypt is arguably better (see this answer).


I'm being followed on the web. Explanations for mysterious behavior

I agree with TildalWave and Tracy Reed. This is almost certainly a caching proxy or an indexer of some sort being run either by your VPN provider, their upstream connectivity provider, or the server hosting provider.

It's not NSA/TLA "snooping" for the following reasons:

The NSA would just sniff the packets over the wire
The NSA would force your VPN provider to span them a feed from the outbound side of their gear
The NSA would tap into the packets by compromising your computer
The NSA would not use such an amateurish, easily detectable method of snooping

For all those reasons, I'd say there is no determined adversary spying on you. The other explanations are much more plausible.


In TLS, the handshake messages are encoded into records. Each record has its own header. A given handshake message may be spread over several records, and a record may contain several handshake messages.

The hash computations for CertificateVerify and Finished messages is over the handshake messages only: you input the successive handshake messages into the hash function, in due order; each handshake message begins with a four-byte header (one byte for the message type, three bytes for the handshake message length), and these headers go to the hash function as well. The record headers do not enter the hash function.

In other words, fragmentation into records is ignored in the hash computations. The resulting hash value does not depend on how the handshake messages where conveyed, in particular any kind of fragmentation. EAP/TLS defines that the EAP messages contain TLS records. Neither the Ethernet headers, the EAP packet headers, or even the TLS record headers, enter the hash function. Only the handshake message themselves are hashed.

(This allows for a cleanly layered implementation: the SSL/TLS library produces handshake messages which are sent one after the other on a conceptual endless stream of bytes; the stream is hashed; the library does not have to care about how the stream is split into records encapsulated into EAP messages fragmented into individual Ethernet frames.)


Let's start by thinking of what would it happen if we had 2 different networks with same SSID (say SSID_share), but evidently different BSSIDs (MAC addresses).
What happens if there are 2 different networks with same SSIDs?
Each router sends radio waves which are then decoded by your wifi software manager. It will probably understand that both networks are actually the same, since they have same SSIDs. So it shows you only one SSID to connect to. Now, depending on which AP is closer to your wireless network interface, you are going to connect to one network or another.
For instance, consider your legitimate network A has password MyPass and the fake one B has password MyFakePass. If a client is really close to A's AP (say in the same room) and significantly farther from B's AP (say another level), then B won't affect him.
What happens if a client tries to log into the fake network?
Suppose now a client is closer to the fake AP than to the legitimate one. Without noticing it, he is going to connect to the fake SSID_share. He will not be able to authenticate, though, since passwords are different.
Can an attacker read the password logged from a login attempt?
That acctually depends on the authentication system being used. Fortunately, for WPA2-PSK (pre-shared key) the answer is NO. WPA2 does not send the password to the gateway. In fact, the gateway sends a time-changing challenge created using the plaintext password. When a client wants to authenticate it generates a one-way answer to that challenge 1. So the attacker will never get the password in your logs. The best he could do is try to use brute force techinques.
PS.: Don't know why but I have a strong feeling you did not ask this question for noble purpose :)


There are numerous questions with answers on this site as well as Owasp guidelines that cover the risks of allowing file uploads and how to store files properly.

You may want to check the legislation that applies to your application and take necessary action to store files accordingly (encryption, access rights, data integrity, logging).

As for your idea to store files in the database I think it will cause a lot of stress (as well as storage overhead) to your server(s). It's more convenient to store files outside the web root with tight ACL (access control) and possibly encryption.

The database may be useful for storing metadata and access rights for users of the web application(s).

It's possible to share the files between servers/applications securely using standard protocols like rsync or even https.

You may also want to consider scanning uploaded files for malware and fuzzing attempts.

Find out what your requirements are, check legislation and produce an overview of how your solution should work and what precautions you are taking. Then consult an advisor/expert and revise.


download file/folder anonymously on a ssh session

If you are Windows OS, there is a way to use torify your SSH using Putty client. Here are the configurations you need to set:

If you are using a Linux distribution, it depends on which one you are using.

For example, if you are runnin Ubuntu you can (How to use SSH with Tor?):

  Add the following block to the top of your ~/.ssh/config file.

Host *
CheckHostIP no
Compression yes
Protocol 2
ProxyCommand connect -4 -S localhost:9050 $(tor-resolve %h localhost:9050) %p

Check the original documentation of the quoted answer.

In all cases, I advice you to read the How To Torify section (SSH).


How does Wireshark detect online-messenger traffic?

You're misinterpreting the categorization.

    **[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]**
        [Message: HTTP/1.1 200 OK\r\n]
        [Severity level: Chat]

Other things that might show up there are "note", "warn", and "error". If this were expanded to two words, it would be protocol chat. What this is pointing out is that this packet has some control chatter that relates to the state of the connection. It has nothing to do with the content or nature of your traffic's message at a higher level than HTTP. See http://www.wireshark.org/docs/wsug_html_chunked/ChAdvExpert.html for more info.


Should I reject obviously poor passwords?

Is it worth it to even include a password strength estimator?

A strength meter?  No, because it is too difficult to inform normal users that the "strength" listed is an absolute maximum possible strength, and that their password may be trivially crackable by a skilled opponent no matter what the meter says, while still asking they pay attention to the meter.

A known-weak-password warning?  Absolutely!  If you can detect that a password is weak, then it's weak.  You merely cannot possibly detect whether or not a password is strong, since your software won't have realtime access to the latest in cracking dictionaries, rulesets, and other advances (Markov chains, etc.)

  Is it worth trying to bolster the existing library with stricter rules?

Yes!  Go take a look at Hashcat for the types of rules it supports, and note that when you have the plaintext user password, it's easy to apply many rules.

You can handle all the uppercase/lowercase rules with a simple UPPER() equivalent and an all-uppercase dictionary - if you find it, it's weak.  (JacQueLinE)
Appending/prepending numbers purely to meet length minimums is a simple pattern match - if the last/first N characters are numbers, and the remaining length isn't enough, it's weak. (Riddick123)
Remove N numbers from the beginning/end, uppercase it, and check the dictionary for the remainder (JacQueLine12)
The above, but N-1 numbers and/or symbols (#1JacQueLine)
The above, but date formats. (JacQueLine02121995)
If the last/first N-1 characters are numbers and the last/first is a symbol, and the remaining length isn't enough, it's weak. (!JacQueLine1)
Take out one character at a time, see if it matches the dictionary.  (jacqu$eline)
Combine some of these.
Reverse all of these.

Do a pattern-match for dictionary words as subsets, i.e.

correcthorsebatterystaple

correct: 1813th most common English word, row 16828 on phpbb, row
9871 on Ubuntu american english small.
horse: 1291st most common English word, row 14820 on phpbb (horses is
at row 1723!), row 21607 on Ubuntu american english small.
battery: 3226th most common English word, row 7775 on phpbb, row 3644
on Ubuntu american english small.
staple: 6 characters, all lower case, not in the top 5000 most common
words. row 40524 on phpbb (staples is at row 3852!), row 42634 on
Ubuntu american english small.

Note that all of these are length 7 or less words; there are less than 21,000 length 7 or less words in Ubuntu's american english small dictionary, 21000^4 ~= 1.9E17, which is more or less 2^58 for a very simple "combinator attack: 4 words, no separators, length 1-7, from this one small dictionary".

Certainly correcthorsebattery would be a much, much weaker password against a combinator attack - 3226^3 ~= 3.3E10 ~= 2^35, using the top 3226 most common English words.

Get some better dictionaries; don't try to send them to the client, host them and the more complex rules serverside.  Sure, send the client a tiny one for a first pass, but you need more.  Phpbb is the best common small wordlist I know of, then add in rockyou.  Many crackers start with brute force for tiny passwords, then small wordlists and large rulesets, then large wordlists - the largest I'm aware of is over 30GB, and includes almost every password found to have been cracked by anyone on a given popular forum, plus many, many other large wordlists.

Find yourself a happy medium - fast enough to be performant, large enough and with enough "rules" to cut out the first few fast passes of cracking software - if you really are using enough bcrypt iterations, then only small dictionaries + large rulesets and large dictionaries + small rulesets will be practical attacks for a few years.

  Am I just going frustrate my users when I ban a password they think is a good idea? (I'm worried this will potentially cause them to either give up or copy there password to their monitor, etc).

Yes.  When you say "password", "Password", "P@$$w0rd", "P@$$w0rd1", "P@$$w0rd123", and even "P@$$w0rd123!" are bad passwords, you're going to annoy them.  When you say "Jennifer2007" is a bad password, they're going to be frustrated (and perhaps Jennifer will be upset, too!).  Manage their frustration as best you can, and simply accept some.  Personally, I would recommend actually being explicit - tell them their password is a word in known cracking dictionaries plus two numbers, which is a normal cracking rule!

Your purpose is twofold.  First, you don't want weak passwords in your system.    Second, you want to educate users on what a weak password is, so they have some understanding to mitigate their frustration.

As part of educating, perhaps show them some alternatives you generate that pass your own tests, if you flunk their password.

1) Fully random passwords

2) Fully random passwords translated into bubblebabble or another pronounceable subset

3) correcthorsebatterystaple type passwords, but with longer and uncommon words.  For instance, take the Ubuntu american english insane dictionary, subtract out all the words in the american english small dictionary, and select N words of at least 7 characters in length.  This leaves you without any really short words, and without the most common words.

4) a mix of 1, 2, and/or 3.

Then your users can, if they choose, simply pick something you showed them (over HTTPS with the best cipher suites you can get away with, of course).

Personally, I would also strongly suggest raising your length limit; about 14 is what I would recommend, but for most userbases that's just too long.  Try a minimum of 12 or even 10, enough so a fully random password might have a slight amount of value at the minimum length and character set.


can my corporate firewall read my https packet?

They will be able to see the source and destination IP address and port, as well as the domain you are connecting to (for example, security.stackexchange.com). They will also be able to see the size of each packet. However, as long as they are not actively attacking the connection (e.g. with a root certificate you have trusted which allows them to do interception) and as long as TLS is properly implemented, they will not be able to read the actual contents of the traffic. This includes the path which is being accessed (for example /q/191576/165253).

I recommend you read How does SSL/TLS work? to familiarize yourself with the subject.


When is an intermediate page needed before directing a user off my primary website? What is the best implementation?

What type of information would be risky to disclose via a referrer: header?

Any kind of private or sensitive information shouldn't be exposed to external websites - it all depends on your application. The most common things to consider are:

session IDs (you can sometimes see them in URL params like ?PHPSESSID=....)
user ids / resource ids (they may give a hint to 3rd party on who exactly the user is)
any kind of sensitive tokens like anti CSRF tokens, confirm action tokens, account activation tokens etc.
some sensitive user data e.g. search terms he used on your website.

  Which is a better approach? Click to redirect, or HTTP 301/302 redirection

30x redirect is perfectly fine from the technical point of view as it will lose the Referer header. Consider using a 'click to redirect' if you want to inform your users about the redirection happening.

  If a 301/302, or Javascript redirection to an external URL is used, what additional security precautions must be taken place?

For example, imagine that attacker sets up a phishing site with your site design and a spoofed login form and uses your open redirection to drive users into his website, gathering their logins and passwords. For example, he might send out spam campaign with the URLs pointing to your redirection script. It's a common security vulnerability commonly called open redirection. Click through protection would be better in this regard as the users would be informed about the redirection happening, but it's much much better to have a process of manual/semi-automatic validation of redirect targets so that you can monitor for malicious URLs and block them.

You'll never have a total control over the target URLs as there are many ways for the attackers to hide the malicious content from you, but having a process ready to block unwanted URLs will allow you to develop better filters, blacklist common domains or implement a greylisting feature: for known good URLs a 301 redirect, for known bad - 501, and for all the others - user confirmation. This is what Facebook does more or less.


Is it possible to identify who's behind a nmap -D scan?

In a nmap -D scan, for scanning to return any result, your real IP address must be used amongst the pool of decoys. Without your real IP being used, you will not be able to receive any response from your target server, and nmap scanning would not work.

The -D option creates confusion by introducing decoy IP addresses. So, if the target server is logging incoming connections, it will see an assortment of spoofed IP addresses plus your real IP address.

If you are not careful to ensure that the decoys are up (no response after initial SYN on active port that returns SYN-ACK) or if your ISP filter spoofed IP addresses (only your IP will appear on the server log), it would not be difficult to spot the actual IP address doing the scan.

Here are the relevant parts from the man page of nmap,

  -D decoy1[,decoy2][,ME][,...] (Cloak a scan with decoys) .
  Causes a decoy scan to be performed, which makes it appear to the remote host that the host(s) you specify as decoys are scanning the
  target network too. Thus their IDS might report 5-10 port scans from
  unique IP addresses, but they won't know which IP was scanning them
  and which were innocent decoys. While this can be defeated through
  router path tracing, response-dropping, and other active mechanisms,
  it is generally an effective technique for hiding your IP address....

  Note that the hosts you use as decoys should be up or you might accidentally SYN flood your targets. Also it will be pretty easy to
  determine which host is scanning if only one is actually up on the
  network....

  Decoys are used both in the initial ping scan (using ICMP, SYN, ACK, or whatever) and during the actual port scanning phase. Decoys
  are also used during remote OS detection (-O). Decoys do not work with
  version detection or TCP connect scan....

  ... Also, some ISPs will
  filter out your spoofed packets, but many do not restrict spoofed IP
  packets at all.


Articles covering this research are, IMHO, bit overhyped. There's no "reading of user's activity from mobile screen". There's no storage of sensitive data in shared memory. Attack observes memory (de)allocations and tries to guess what screen (activity) is being shown in the app now. If something sensitive (e.g. logon form) is detected, then phishing techniques are put into play (which aren't exactly new).

As @raz mentions in comments, you need to download and run malicious app on your phone for this to work, so it's more about post-exploitation technique, actually.

Also, this seems to be Android-only at the time. Researches have only demonstrated their findings on this platform, and talking e.g. about iOS and OS X they state:

  But on Mac OS X and iOS, only system-wide aggregated memory statistics
  seem available through host statistics() API, which may still be
  usable for this attack but with a less accuracy.

Inability to get per-process statistics actually hurts the attack pretty badly.

The paper itself is available here.


SSL will usually not help.

If the attacker has complete control over the computer, then he wins. He can inspect and modify the memory of all process in the computer.

If the attacker is only a non-administrative user, then he won't be able to spy on process from other users. However, if the attacker can run code as the same user as either the server or the client of your envisioned localhost-only connection (or both), then he can plunder the RAM of the involved process, and he wins. Also, assuming a non-administrative attacker means that you trust that the said attacker could enter the machine but did not find any privilege-escalation exploitable hole: that's a rather optimistic assumption.

If the attacker can only listen to communications, but not have a look at the memory of the process, then SSL may help, since it will prevent spying. However, this is not a very realistic scenario: spying on localhost connections requires local admin privileges.

Where SSL may help is about authentication: a local attacker, with non-admin rights, may try to connect to the server and impersonate the client, or vice-versa. SSL provides authentication: the client validates the server's certificate, and, if the server asked for a client certificate, the server validates the client's certificate. Note, though, that on localhost, there are more efficient ways for a server to know who is at the other end of the socket (e.g. getpeereid()).


Detecting a rootkit is by nature difficult, this is because rootkits often employ methods to evade detection. A well written rootkit ought to be undetectable.
However, rootkits that are badly coded may leave traces of their activity in the system (failing to delete logs etc).

Unsigned Dynamic Link Libraries Loaded into (all) processes
Random code checksums
General malware detection methods

Also see: https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Rutkowska.pdf


Is it possible to prevent user from dumping hashes?

Hash dumping tools exploit access control weaknesses to gain access to the hashes (if you google SAM file you will find out more about it)

So to prevent used accessing it you need to implement access controls. If your users have admin rights they can access anything in the system so you need to ensure they have ordinary user accounts.

You also need to make sure your system is patched up to date, as a vulnerability may allow a tool to run with admin rights or otherwise gain access.


When you don't want the user to have access to your code, you must not let them run it on their machine. It's that simple. As you already found out yourself, obfuscation doesn't work.

So what option do you have?

Run it on your own servers and offer it to the customer as a service, for example via SOAP. The drawbacks are that you need to administrate servers now, and that there is a latency when your service is used. But on the upside, you can write Cloud(tm) all over your marketing material.


Is it normal for shell scripts to contain binary data?

It's normal-ish; such a file is often called a 'sharball' (shell script + tarball).  It's a way to send files (the tarball) and the method for extracting and manipulating them (the shell script) together in a single easily distributed file.
As to whether it's safe to run, that's a question you should ask with any shell script you're asked to run, not just those with binary content.  It boils down largely to trust in the distributor of the file.


How to extract data using SQL injection on a vulnerable ASP.NET application?

Sometimes (most of the time) you can't. Its so called blind SQL injection. What you usually can do is to delete (you don't usually want to) or create or modify some data (yes, this is what you want to do) or to avoid some expression evaluation (ie password = password).

Typical tasks you want to do is to assign admin role to your account or to change admin password, force the application to present modified data to target users (stored XSS and many other things) or just to login without knowledge of username/password. Moreover, on MS SQL (if badly configured) you can also start system commands so in the end there are many possibilities to do including obtaining complete control over the server and further servers in the infrastructure.

Good luck but be ethical!


Finding owner of a Wi-Fi network name that may be a threat

I'd recommend going to your fuseboard and turning off power to different rooms one by one, keep checking to see if the network is still going - if you can have all the power off and the network is still up, then its most likely not on your property. However, if one of the switches turns off the signal, then the access point is on your premises.

i'm not sure by what you meant when you said 'your cameras were hacked', but if you've found hidden cameras in your home then i'd notify the authorities asap.

You could also try connecting to this network and seeing if there is an admin panel that you can access at 127.0.0.1 or 192.168.0.1(most common addresses)


Exploit for a CSRF to a POST server with specific "Accept" header?

According to the documentation[1], the accept header is a "CORS-safelisted request header" and therefore should not trigger a preflight. Thus, checking for that header (unless the server requires an invalid character in it) should not be sufficient to prevent CSRF.

Non-simple requests get pre-flighted, but "simple" (safelisted) ones do not. As long as your server doesn't send back CORS response headers that permit the preflighted CORS request to proceed, and there's no way to make a valid simple request, that works.

[1] Thank you for the link, @Steffen Ullrich


Is union based mysql injection able to read files outside database?

SQL Injection can lead to Remote Code Execution in some scenarios. As you can see in this article, it is possible to read files from the Operating System, that are "outside the database".
Tools like sqlmap can help an attacker spawn reverse shells while performing a similar attack. Once an attacker has a shell, depending on the permissions of the user and if privilege escalation is possible, one can potentially take over a server.


What are the disadvantages of single sign-on authentication?

Single point of failure
Single high-value target (attracts more attackers)
Necessary information disclosure between trusting site and SSO authority
Side channel attack against authentication step (theoretically; implementation dependent)
Lack of control over your user list
Yet another interface to maintain (added complexity)
You may never know how secure your system is or if there is a breach
Added cost

These are all off the top of my head. I imagine someone has compiled a canonical list somewhere.


Is it safe to back up passwords to the "cloud"

Doing this makes your data marginally less safe, since "the cloud" is just a fancy name for "someone else's computer".

However, you already have implemented a good control against offline attacks in Truecrypt. And, you've gone with SpiderOak, which is one of the safest cloud providers. So the risk increase is very small.

At the same time, you have also made them considerably more safe, because you are doing off-site backups.

All things being equal, then, you have decreased risk overall.


Is an XSS via Cross-Site File Upload (CSFU) practically exploitable?

The cross-domain file upload attack is prevented by the Same Origin Policy (SOP).
The only way to automate the file upload, with arbitrary contents set by an attacker, is using the FormData API. This involves constructing a file upload HTTP request and sending it via XMLHttpRequest (ajax request) or the Fetch API. You cannot perform cross-domain requests with these methods unless the target domain explicitly allows it via CORS.
If the target domain set a header such as Access-Control-Allow-Origin: *, thus effectively disabling SOP, then you could exploit this by constructing a form data object that contains your XSS payload:
var payload = new FormData();
payload.append("file", "<script>alert(1);</script>", "evil.txt");
fetch("http://target.domain/upload.php", {
    method: "post",
    body: payload,
    credentials: "include"
});

This sends a file upload via JavaScript, with an arbitrary name and contents. But, as I said earlier, this only works if the victim domain bypasses the same origin policy with a dangerous CORS header.
One thing I noticed in your demo code is that the filename being displayed is also vulnerable to XSS, since it is printed without being escaped. You might consider an attack page like the following:
<script>
function rename_file_to_something_evil()
{
    var form = document.getElementById('exploit');
    form.files[0].rename('<script>alert(1);</script>'); /* this is not real JS */
}
</script>
<form id="exploit" method="POST" target="http://target.domain/upload.php" enctype="multipart/form-data">
    <input type="file" name="file" value="Choose a file..." />
    <input type="submit" onclick="rename_file_to_something_evil()" value="Upload" />
</form>

Here, the idea would be that we could get the user to upload any file through some social engineering pretext, e.g. "upload a picture of yourself and we'll show you what you look like in 20 years", then use JavaScript to rename the file to an XSS payload and send it to the target domain, since cross-domain form submissions are allowed even if cross-domain ajax/fetch requests aren't. If we could get the user to manually initiate that request, but somehow modify the contents, perhaps we could exploit it that way. However, the standards developers considered this attack vector already, so they made it impossible to rename a file with JavaScript before upload. You can't apply a FormData object to a form in the DOM either.


What information needs to be sent (with the URL) to the frontend, so
  that the frontend knows what user identifier needs to be sent back?

Don't send any information to the front end if possible. Some sites fetch the user name to show greetings but I would avoid that too.

So the complete workflow will be,

  Request reset for an email (frontend)
  Whether the given email is present or not send response OK (backend)
  Generate a random reset-hash (if one is not present & not expired, to avoid spam) (backend)
  Send the reset link @ user's email (backend)

In the landing page from the email link, obtain the hash from the URL and check if the hash is valid
Redirect to an error page in case of expiry, invalid link, etc... (Kindly don't fake an OK response here as you did while obtaining email. Here errors can occur as usually email provider re-route the links through their server and some may remove parameters)
Else, redirect to reset-form, obtain the password from the user and send it along with hash to the backend.
Use the hash to match the user and update the new password.
Show a success screen to the user, send an email and redirect them to the login page.


Tools or techniques to perform live memory capture of Solaris

Standard Linux kernel programs won’t work with Solaris.

You will need to follow the procedure that Sun specifies for dumping a live system, and use their tool (mdb) for analysing.  Note that dumping a live system requires configuring the dedicated service to support it.

https://docs.oracle.com/cd/E23824_01/html/821-1451/tscrashdumps-4.html#tscrashdumps-32


How to find vulnerabilities in a program by looking at it's source code

and welcome to Security.SE.  This question doesn't really fit the StackExchange format, and will likely be closed. Questions like this typically end up just being a list of books, which could potentially get out of date very rapidly.
To answer your question, I would recommend a couple of things:

Pick an area that you would like to study (i.e. web vulnerabilites
vs.  C source code).
Find applications which fit your choice which are open source and have had security vulnerabilities which have been discovered in the past.  There are also plenty of purpose made vulnerable applications such as Owasp's WebGoat you could look at.
Download an old version of the source code which still contains the vulnerability, and read through the code to see if you can
understand how the vulnerability presents itself.

As far as books go, there are plenty available, but as @multithr3at3d mentioned, it's kind of a broad topic.
You can also try running some static analysis tools against some open source projects, and review the results to find other potential vulnerabilities.


What vulnerabilities other than directory traversal come under IDOR?

It's important to understand why OWASP classifies directory traversal as IDOR: The parameter that is accepted by the application is a direct reference to a file (instead of an indirect reference which for example points to a database entry, which in turn points to a file). By passing a different direct reference, an attacker can read arbitrary files.

CWE - which is more fine-grained than the OWASP Top 10 - for example uses a different classification:

  The "Insecure Direct Object Reference" term, as described in the OWASP Top Ten, is broader than this CWE because it also covers path traversal (CWE-22). Within the context of vulnerability theory, there is a similarity between the OWASP concept and CWE-706: Use of Incorrectly-Resolved Name or Reference.

Some would classify open redirects as IDOR (although OWASP doesn't as it's covered under Unvalidated Redirects and Forwards)

IODR is basically an authorization problem.

The most common other example is a direct reference to database indices. For example, you have a functionality which shows private message:

id = [userinput];
message = getMessage(id);
showMessage(message);

function getMessage(id) {
    return query("SELECT message FROM messages WHERE id = ?", id);
}

The idea is that each user can only read their own messages. But because the ids are direct references to the message, and because there is no authorization check, an attacker can read messages of all users. Note that proper authorization alone would fix the problem, but so would using indirect references (ie each user has messages with id 1 to x, so there is no possibility of accessing other messages).


How to reduce false positive in hydra http-post-form module due to more than 1 error?

Hi Hydra Is not the best tool to bruteforce http post forma i suggest to use wfuzz

Here there Is the documentation of Wfuzz
https://tools.kali.org/web-applications/wfuzz