Why send multiple codes and ask the user to input only one?

It does not add anything.

The problem with is SMS as 2FA is that a SMS can be intercepted in transit, or grabbed from the user phone because of malware. Sending one, four, or one hundred codes is the same. If the attacker can get one, can get all of them.

You could give the user a card with hundreds of codes and send a message asking for a specific one, like this:

This way, unless the attacker gets the password card AND intercepts the message, the user is protected.


Why do browsers leak their version info to the webserver?

It also is an open invitation to use the appropriate version of scripts that are supported by the browser.  Unfortunately, to have a usable web, the server needs to know what kind of browser it is dealing with and make adjustments based on this information.  Yes, it does make it easier to target an attack, but someone could also just put a bunch of attacks on the page and hope one of them works.  It's a fairly limited risk with a whole lot of benefit.  The most paranoid browsers disable or fake it, but it comes at a cost of reduced functionality on sites that are visited.


According to Microsoft Bitlocker is FIPS 140-2 approved when used with AES-256 without the elephant diffuser enabled.  The elephant diffuser is designed to prevent CBC bit-flipping attacks: rather than a bit flip affecting one bit in the subsequent block, it would affect more (50% on average, IIRC).  NIST CSRC also lists both CBC and XTS modes as FIPS 140-2 approved, though it's not clear if this applies to all of Bitlocker.


Why would I ever not want CSRF protection?

Actually, there may be a use case, but it is a little contrived and depends on
how the CSRF token is generated.

In many cases, the CSRF token is just a random token which is tied to the
session and is not related to any level of authentication. When the client
requests a page containing a web form, the form has the token embedded in it as
a hidden field. When the client posts the form data, the server verifies the
token is the same as the one it sent and can be fairly confident the response is
from the same client it sent the form to. All good.

However, this work flow is less convenient in the context of a web API where the
initial contact with the server is from a client who is posting some data (often
in the form of some JSON). In this case, the server has not been able to send a
token. Normally, a web api would have some other sort of verification - for
example, you use JWT, the client app will make an initial connection to the
server where it performs some authentication and gets a JWT which it uses in all
future API calls.

Often, this is not an issue as you will have separation of concerns. There will
be a set of URLs used by a web client which follows the normal request a form
then submit the data work flow and a separate API URLs which use something like
JWT. There is no need for a CSRF token.

The problem can be when you have vary similar requirements for both. You really
don't want to have to maintain two separate sets of handlers and would prefer to
just have the one which can be used by a traditional web client and also as an
API client. In both cases, a token is used, but they are different in nature.

I did say this was contrived. In reality, I've only come across this sort of
issue when developing a new service where I wanted a web client interface as
well as the API just for development/debugging purposes. In this case, what I
have done is have some javascript in the browser based version which does an
initial authentication with the server and gets the JWT which it copies into the
web form as just another value. However, I can imagine a situation where you
want to support a general web browser based 'traditional' interface and a
application which uses HTTP/HTTPS for communication via an API.

To some extent, this is really just semantics. The basic concept of providing a
token in web forms to protect against CSRF is not vary different from an API
which is using a token for authn/authz purposes. The only real difference is
that the CSRF token usually doesn't imply anything more than the fact the
response is from the same client the initial form data was sent to while the API
token is making assertions about the actual user. Technically, there is no
reason the latter cannot be used for the former, provided the server can handle
that. The former cannot be used for the latter.


Meterpreter is a multi-stage payload where the first stage is send first which then downloads the second stage DLL. Two things you need to understand here: what transport will be used by the Meterpreter to communicate with the handler and whether the first stage should connect back to the handler or the handler should connect to the listening socket (reverse vs bind).

There are three types of transports available: TCP, HTTP and HTTPS. If you are operating inside a LAN environment, you can use the TCP transport since it is a reliable transport mechanism. However, TCP transport needs an established socket to communicate which means if for some reason the session gets close between the attacker's machine and victim's, it can't get reconnected (unless persistence is already achieved). TCP transport can't traverse proxy servers in order to access Internet and first stage transport is in plain text which can trigger IDS/IPS.

HTTP and HTTPS both use WinInet which means if the victim is behind an HTTP proxy, the first stage meterpreter will be able to use the proxy server and the cached credentials (if required) to traverse the proxy and access the Internet.

HTTPS transport has the added benefit to transfer the second stage DLL on  a complete SSL tunneled transport that can't be sniffed by IDS/IPS unless the session is MITM-ed at the proxy.

In case of bind vs reverse, reverse is almost always the preferred method because a lot of times organizations have script ingress filtering in place but egress filtering is not that much strict (although it is changing).

One final thing you need to understand is that compared to TCP, HTTP(S) transport is bigger in size that is why it won't be fit in every exploit due to the limited payload space they can carry. However, egy7t did some great work to reduce the size of reverse HTTPS transport so that most of the exploits can carry it. You can find more details regarding this at Shellcode Golf: Every Byte is Sacred.


Yes, you could plug the USB drive into a Linux Live CD and format the disk.  Once it's formatted, it's safe to use.

Note that this would not thwart any infection if the malware is in the USB firmware, but that's a remote possibility and I wouldn't be too much paranoid about it.

There is a better reason to be suspicious about good deals on USB thumb drives bought from unreliable sources: they might have a tampered firmware that let them sport a fake capacity, so your 512-Gb drive can in fact hold only 4 Gb only.


How to prevent manipulation of a chain of document? Specifically: medical records

This is hypothetical problem

But if you add one "practicality" it becomes analogous to one already (more-or-less) solved problem.  The practicality to add is:

A doctor should always look at the full medical history of a patient.  What may look at first as an unrelated problem can be an important point in a diagnosis.

In other words, all medical records of a patient shall always be presented to a doctor.  This solves the discussion (in the comments) about whether presenting part of the documentation (e.g. 1/2/4) is meaningful.  So, if we can assume that a patient must always give all documents, the problem becomes analogous to a cryptocurrency.

Bitcoin, or any other cryptocurrency for that purpose, sings all transactions with the private key of the wallet from where the transaction originates.  Then, when the unit of currency is in another wallet, another transaction will be signed with the private key from that wallet.  We have an excellent discussion on that on the bitcoin.SE part of the website.

Therefore a solution where one participant sings a piece of data, the next participant adds more data and signs the result, and so on; does exist and is rather effective.  The stack of signatures can be unwind and each verified.

The difference is that with Bitcoin (or any other cryptocurrency for that purpose) the chain is public, because it can be.  Medical record are far from something public, but, as you said, the patient can keep them and still be unable to falsify a doctor's signature or tamper with the signed document.

Keeping all the medical records on some media that will store the chain of signed data would actually force a patient to always show his complete medical record to a doctor.  Which, in my personal opinion (I'm not a doctor or a lawyer), should be a good thing.

P.S. I'm not considering insurance companies in that last statement.


How to extract the password hash from a password-protected container?

How can you extract the hash of the password from an encrypted
  container, such as a KeePass file, or a LUKS, TrueCrypt or Veracrypt
  volume?

It depends :-). You will need a program that can read the respective file format, and extract information about the password.

Also note that a file/container protected by a password does not usually contain a hash of the password (like for example a UNIX Shadow file would). Instead it contains data protected by an encryption key (which is computed from the password), and possibly information about how the encryption key was computed. Typically some special algorithm (a key derivation function) is used to calculate the key.

This data can be attacked in a similar fashion to brute-forcing a password hash: You can try different passwords, run them through the right key derivation function, and check whether they match the encrypted data.

Then you will need a program that performs this brute-forcing. Hashcat is one popular choice (and Hashcat happens to support the data format used by KeePass - see PR 282 on GitHub).

  I tried to use keepass2john from John the Ripper, but it did not work
  with a KDBX file from KeePass (error message: "file version not
  supported") .

That could be any number of problems, and is probably out of scope here. Try asking a more specific question on http://superuser.com .

  During my research I found some people saying that you cannot extract
  the hash. If so, then what are scripts like keepass2john for?

Well, sometimes some people are wrong :-). keepass2john is indeed for extracting information from a KeePass database that allows you to crack the password with John The Ripper.

  Also, if you cannot extract the hash, how does the encryption software
  validate the key?

They do it like the cracking programs: They try the password, and complain if it does not work.


Wireshark tcp filter: tcp[((tcp[12:1] & 0xf0) >> 2):4]

I presume you pulled this from the "capture HTTP GET requests" filter example.

First, some notation:

var[n] means the nth byte of var.
var[n,c] means c bytes of var starting at offset n, e.g. var[3:4] would return bytes 3,4,5,6 of var.
& is the bitwise AND operation.
>> means bitwise shift right.

So, what do we have?

tcp[((tcp[12:1] & 0xf0) >> 2):4]

Let's deconstruct this into its individual parts:

tcp[12:1] takes 1 byte of the TCP segment (i.e. the packet including header) at offset 12. We can see from the structure that offset 12 (0xC) is the Data Offset field. Its definition is as follows:

  Data offset (4 bits) specifies the size of the TCP header in 32-bit words. The minimum size header is 5 words and the maximum is 15 words thus giving the minimum size of 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in the header. This field gets its name from the fact that it is also the offset from the start of the TCP segment to the actual data.

Ok, cool. This field is only 4 bits, though, and tcp[12:1] takes a whole byte (8 bits). We only want the first four.

tcp[12:1] & 0xf0 takes that Data Offset byte and applies a bitwise AND operation, using the constant 0xF0. This is often known as a masking operation, since any bits in the constant set to 0 will also be set to zero in the output. It's easier to think about this in binary. 0xF0 is just 11110000, and since x & 0 for any bit x is always 0, and x & 1 for any bit x is always x, it follows that the zero bits in 0xF0 will "switch off" or mask the given bits, but leave the rest alone. In this case, if we imagine that tcp[12:1] is 10110101, the result would be 10110000 because the last four bits are masked to zero. The idea here is that, since the Data Offset field is only 4 bits long, but we have 8 bits, we mask out the irrelevant bits so we only have the first 4.

The problem here is that, numerically speaking, our 4 bits are in the "top" side of the byte. This means that instead of just having 1101 (our Data Offset bits), we have 11010000. If we just wanted to get the "raw" value of the Data Offset field, we'd right shift by four places. 10110000 >> 4 = 1101, i.e. we throw away the "bottom" 4 bits and shift the top four bits right. However, in this case you'll notice the filter only shifts across by 2 places, not 4.

This is where we want to refer back to the definition of the Data Offset field: it specifies the size of the header in 32-bit words, not bytes. So, if we want to know the length of the header in bytes, we need to multiply it by 4. As it turns out, a bitwise left-shift of 1 is the same as multiplying a number by 2, and a bitwise left-shift of 2 is the same as multiplying a number by 4.

Now, combine this with what we've already seen: >> 4 would make sense in the filter if you wanted to get that raw value of Data Offset, but then we want to multiply it by 4, which is equivilent to left shifting (<< 2), which cancels out part of that right shift, resulting in >> 2.

So, (tcp[12:1] & 0xf0) >> 2 extracts the Data Offset field and multiplies it by 4 to get us the size of the TCP header in bytes.

But wait, there's more!. In the filter you provided, we still need to do one more operation:

tcp[((tcp[12:1] & 0xf0) >> 2):4]

This is easier looked at if we used an intermediate variable:

$offset = ((tcp[12:1] & 0xf0) >> 2)
tcp[$offset:4]

What this does is get the first 4 bytes after the TCP header, i.e. the first 4 data bytes of the payload. In the filter you pulled this from, they were looking for HTTP GET requests using this filter:

port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420

The 0x47455420 constant is actually a numeric encoding of the ASCII bytes for GET (that last character is a space), where the ASCII values of those characters are 0x47, 0x45, 0x54, 0x20.

So, how does this work in full? It extracts the 4-bit Data Offset field from the TCP header, multiplies it by 4 to compute the size of the header in bytes (which is also the offset to the data), then extracts 4 bytes at this offset to get the first 4 bytes of the data, which it then compares to "GET " to check it's a HTTP GET.


Detecting USB-based(Arduino Leonardo) attacks

What you describe is pretty normal. I would suspect that the device has a driver that is installed upon initial connection. When a driver is installed it can disconnect device a few times. After the device driver is installed it will then be properly recognized hence no more installation and disconnections. You can always remove the driver, and debug USB port to see what is happening in the background.


The concern is that each CA included has the organizational power to break your security, and will use that under different and hard to predict circumstance.  The "manual review" step is intended as a reminder that you need to have some process or criteria of which CAs you want to include.

What exactly that should include is subject to ongoing debate by experts.

For example, Google's review process has caused them to kick out a subset of Symantec's certificates.  (https://googleonlinesecurity.blogspot.ro/2015/12/proactive-measures-in-digital.html).  Another example is Tor not trusting CyberRoam  (https://blog.torproject.org/category/tags/ca-certificates)  Microsoft essentially outsources the decision to a group called the CA Browser Forum.

So there is not a specific list of steps you can take in #4 that will satisfy #6.


How widely deployed is TLS with cipher ECDHE?

Last year (May 2013), I ran an experiment by contacting SSL servers randomly: I was connecting to port 443 of random IPv4 addresses and, if I received a response,  my client engaged in a series of aborted handshakes in order to work out what cipher suites were actually supported by the server. I tried a few millions of addresses, and found about 13000 servers speaking SSL/TLS over port 443.

Of these, about 7.5% supported an ECDHE cipher suite.

Mind the details:

This was one year ago. Things may have changed since.
My client did not send any extension claiming support for any specific elliptic curve. It was only claiming "generic" ECDHE support. This may have prevented some servers from trying ECDHE cipher suites. In that sense, my figure may be an underestimate.
A corollary is that "ECDHE support" cannot be stated really generically. Many ECC implementations are limited to some curve types, most of them being able to process only a couple specific curves (the P-256 and P-384 standard NIST curves, so-called "suite B").
There are several ways to make sampling measures. My code was using random IPv4 addresses, thus finding not only Web sites but also many systems like home modems/routers. Existing, published SSL surveys like that one use the "top 1 million Web servers" from Alexa; this favours a notion of "economical significance" which may or may not map to what you want. Concentrating on "top sites" weeds out unmaintained SSL servers and, indeed, home modems and routers, which should increase ECDHE support. Indeed, that survey (from early 2014) finds that a whopping 21.6% of these "top sites" support ECDHE cipher suites.

As a side note, I must say that in most cases, performance increase implied by ECDHE (over DHE) is unlikely to be relevant. It takes an awful lot of connections per second to a basic Web server to actually see the difference (we are talking hundreds per second here). Another salient point is that you get the performance increase by supporting ECDHE cipher suites, and configuring your client or server to prefer such cipher suites when possible; you don't need to stop supporting non-ECC cipher suites to get that purported speed bonus. In that sense, decision to enable ECDHE cipher suites does not need to be backed by figures on who supports them and who does not; you can just activate them and use them opportunistically.


Do TrueCrypt volumes look like random data?

Yes, TrueCrypt volumes look like random data. This is mentioned in the Plausible deniability section of the TrueCrypt FAQ. The FAQ even mentions that having just erased a disk is an excuse for having a volume full of random data. I hate to call it a plausible excuse because as a rule people don't keep such volumes around.

If your disk is seized and found to contain random data, it'll look like you either have an encrypted partition or you've just erased it. Either case will look suspicious. Far better to fill it with halfway-useful stuff like a spare, bare OS installation.

Note that making multiple passes when erasing data is largely a myth; it's neither required nor necessarily sufficient to erase all traces of prior existing data, nor is overwriting with random data a significant improvement over zeroing. See How can I reliably erase all information on a hard drive?, Why is writing zeros (or random data) over a hard drive multiple times better than just doing it once?


Sharing wifi at a business - Bad Policy?

You can't allow customers to be on the same network as your own computers.

A lot of new WiFi access-points take care of this for you, by creating two wifi networks, where the "guest" network does not have access to internal computers. The Cisco/Linksys 4200 is what I have at home for guests, and it's easy to setup, but there are many other systems that have the same feature.


You've been hit by a virus, possibly a ransomware. The way to proceed depends on the kind of virus, but in general you must use an antivirus to check all your machines, and be ready to wipe out the infected ones and restore data from backups.

If you receive a ransom request, it would be wiser to not pay it.

Related question: Getting files back by paying Ransomware

Note: a Google search for doctor@freelinuxmail.org returns a number of shady sites offering to download and install their "anti-virus solutions". Don't install software from unknown sources; rely on legitimate antivirus products (here's some that come to my mind, listed in no particular order: F-Secure, Kaspersky, Norton, AVG, Avast etc.).


Metasploit automate actions when reverse shell connects

You want to look at the sessions command in the msfconsole.

-c (run command) and -s (run script) help you automate what happens on the open sessions from your end.

Man page for sessions here


How can steganography be useful in a social networking and sharing website like Facebook or Reddit?

Steganography is used to hide messages in plain sight. This is useful to do exactly what you say, "so that no one suspects the message to contain secrets and tries to crack the message."

You suggest that private messages could be used, but that violates the use case for Steg: a private message means that it is known that 2 parties communicated and is potentially interesting.

So, then, using your own words, the use case is simple: you can send a communication that is not known to be a message to someone and have that communication channel itself be unknown to 3rd parties.


Can lower level intermediate cert declare SAN that broader than higher level cert?

In a given setup -- it is working configuration. Subject Alternative Names are constrained through different means -- Name Constraints extension in CA certificate. If you do not use Name Constraints, you can use whatever name you want in any certificate.


How to rate a "Ethical Hacking and Penetration Testing" task?

When you hire a security consultant / penetration tester to perform an evaluation of your security posture for a Security Best Practices assessment, you should be receiving a report at the end of the penetration test. This is a large part of the job. As well, there are automated scanners that you can use against your network or web application which will give you a higher-level overview on the overall posture of the network.

When you receive the report from the tester, it is generally going to contain an Executive Summary, which is meant to provide an overall debrief regarding the posture of your security without going too deep into technical details.

Often times, and for numerous vulnerabilities, the tester will be able to confirm the presence of the vulnerability though it may not be a vulnerability that allows for them to gain remote code execution. RCE (or "getting in") is only one part of a large array of vulnerability exploitation.


Is it unsafe to enter administrative Windows credentials when logged in as a regular user?

This is true. To input user administrator credentials on a normal workstation is a security risk.
There are various risks if the workstation is infected on your daily actions, like stealing hashes to later re-use them in pass-the-hash (PTH) attacks, installing keylogger, etc.

There's even a risk if you use a jump host, this is because upon creating a RDP session the hashes are still created on your workstation. Credential Guard is a great way to have a good protection from PTH attacks, but this still doesn't help if the workstation is infected with a keylogger.
https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/credential-guard

Microsoft has introduced PAW Priviledged Access Workstation to have a secure mechanism of managing Administrative tasks. These are basically hardened Windows OS machines on which you perform Administrative tasks.
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/privileged-access-workstations

If you would like to go a step further, you can setup a tiered architecture on your Active Directory infrastructure.
https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access-reference-material


PHP processing form submission, how can I best protect sensitive information submitted via the form?

Do not use new solution, reuse what others have gone though. A good place to start is OWASP.

For the transport, use SSL and do not manage some kind of encryption on the browser instead.

Once data lands on your server, assess whether to store it encrypted and what risk exactly you want to avoid by encrypting them. This will drive the encryption architecture (physical theft prevention? Admin access prevention? ...).

And then, the absolutely key is to make sure your application is coded correctly. The OWASP link above will point you to generic cases and specific implementation solutions (for PHP for instance)


How to make sure that my operating system is not affected by CVE-2016-5195 (Dirty COW)?

You can do uname -rv to find out your Linux kernel version. You will get an output similar to below:

4.4.0-42-generic #62-Ubuntu SMP Fri Oct 7 23:11:45 UTC 2016

If your version is earlier than the following, you are affected:

4.8.0-26.28 for Ubuntu 16.10
4.4.0-45.66 for Ubuntu 16.04 LTS
3.13.0-100.147 for Ubuntu 14.04 LTS
3.2.0-113.155 for Ubuntu 12.04 LTS
3.16.36-1+deb8u2 for Debian 8
3.2.82-1 for Debian 7
4.7.8-1 for Debian unstable


What's the drawback of enabling auth-nocache in OpenVPN?

The authentication credentials are not cached. So if the connection fails, it is not possible to automatically reconnect.


Understanding the security of a federated public key scheme using WebCrypto

What you are describing is very similar to PoP/RFC7800 (Proof-of-Possession Key Semantics for JSON Web Tokens). (It's also somewhat similar to what AC/DC (Authorization Cross Domain Code) is trying to do.)

With PoP, the proposed steps 1 & 2 are the same: BOB (called Recipient) issues a nonce with the 401 response, Browser (called Presenter) generates a Public/Private key pair to send to the server ALICE (called Issuer).
Step 3 is also very similar - Browser/Presenter sends the request with the public key to ALICE/Issuer.

PoP and your proposed protocol diverge slightly after Step 3 -- whereas you're storing the public key + signed nonce on ALICE's server, in PoP, ALICE/Issuer simply signs the public key and returns it in the response (in a JWT). The Browser/Presenter then forwards the JWT from the Issuer, adding the nonce (which it signs itself with its private key), to the Recipient.

The Recipient can then verify several things: a) that the Browser/Presenter is the one that received the initial nonce (this prevents client token hijacking), and b) that the Browser/Presenter really holds the JWT signed by the Issuer.

  Is there any pitfall I am not seeing?

Both your proposal and PoP accomplish the following:

They protect against client token hijacking by verifying that the Browser/Presenter is the same one that received the nonce in the original 401 Unauthorized response.
They verify that the Browser/Presenter was authenticated correctly to the Issuer -- with your proposal, because the Issuer permitted the POST to /keys/nonce, and with PoP, because the Issuer returned a JWT, signed by itself, that included the browser's public key.

What your proposal does not address is the following important issue:

Given that you're talking about an in-browser application (the Browser/Presenter), how does that application authenticate with ALICE/Issuer? That is, given that the Issuer accepts a POST to /keys/nonce, presumably it has verified the client and has authenticated the user. But how? OAuth2 and OpenID Connect (with which PoP is designed to work) have very specific mechanisms for authenticating public (in-browser) client apps to the Issuer, with redirect protection and so on, because it's not an easy task, and prone to a lot of security holes.
It's likely that you're intending to use some sort of cookie mechanism, but if the browser-side app/Presenter is running from a different origin than the Issuer, how is the issuer going to authenticate it?

This is relevant for in-browser apps, but also especially relevant for native apps, mobile apps, or traditional server-side web applications. How does the proposed scheme attempt to address authentication with those?

  Can any attack happen in point #4 of the diagram?

Not that I can see, although you don't even have to do a POST here, you can do a plain GET and include the Sign(location, nonce, bob) part in the Authorization: header, bearer token style.


Is it possible to access the routers web interface and modify setting if the administrator changed the default password/username of the router?

Hopefully not but some routers have one or even multiple backdoors. Or in case of MikroTik a CSRF attack against the administrator could be used to change the password if the system is not fully patched.

  Why should a network administrator use this method to secure a network since this can be bypassed by mac spoofing and it is vulnerable compared to a WPA/WPA2 security?

There is no such thing as a 100% secure solution and the more security you want the more expensive and/or unusable it usually gets. To make MAC spoofing impossible inside a WLAN you probably need some kind of authentication of the clients which is more robust than the initial username and password. 802.X provides this but then you would need to install authentication credentials (for example certificates) on each device and maybe special software too. You don't want this in public hotspots so you accept instead the risk of MAC spoofing.

  Is it possible to fix this vulnerability of hotspot gateway?

There are solutions but they affect the usability too much if used in a public hotspot. If used inside a company where one has more control over the connecting devices one can detect and block MAC spoofing.


Why is the public key used on server side for an ssh connection?

There's multiple keys and encryption schemes used in SSH:

Server keys, to authenticate the server to the user. The server has the private key, and hands out the public key to anyone asking.
Client keys, to authenticate the client to the server. The client has the private key, the server the public.

Purpose of #1 is to authenticate the server to the user. The user can use the public key to verify that the server has knowledge of the private key. This ensures that there's no man in the middle-attack, as he would be unable to produce the same keys.

Purpose of #2 is to authenticate the user to the server. The server can use the public key to verify that the user has knowledge of the private key.

Authentication may be by the server using the public key of the client to encrypt a random number. If the client has the corresponding private key, it can decrypt the random number, and tell the server the value. This proves that the client has the corresponding private key, and thus authenticates the user - without revealing any information apart from that it has the private key.

The client can do the same with the server key; encrypt a random number, and transmit to the server and ask the server to decrypt it.

For encryption of data in transit, neither is used. A symmetric cipher, with ephemeral keys is used for encryption of data passing over the wire. The key for this is worked out using a key exchange protocol.

This is obviously a very brief overview, and it's simplified. More information can be found in this short and not-to-technical text about ssh authentication.


Is an updated OS, in general, more secure than its predecessor?

Patching addresses known risks while introducing unknown risks, like new unknown vulnerabilities, bugs, performance issues, etc.

That's why places like banks wait a while to quantify the unknowns before patching.

Patching is not something that should be done without a risk assessment. Do you leave known vulnerabilities in place because you fear availability risks? Do you mitigate the known and test the patch before deploying? You have to answer these questions for yourself.

I advocate having processes in place that patch immediately but also have a quick rollback and mitigate plan in place ("patch, test, rollback" instead of "test, patch"). From experience, the downtime from bad patches and rollbacks is less than the downtime from known exploits hitting a server, but those metrics can change at any time.

You are correct to ask this question, but the answer is far from clear or universally applicable (even with WannaCry experience being so recent).


Countermeasures for a family-member attack on a password reset procedure

The two main methods that I have considered for this are:

1. User Defined Questions

Most of the default questions I see on sites seem to be the same or very similar, easily researchable through social media, etc. I would generally think that allowing users to write their own security questions would be better with some guidance. e.g., "Come up with two questions, make them things that no one else would know, not even your mother". User's could still end up coming up with bad questions, but at least some percentage of users will be crafty and it provides an overall improvement across the population of users

2. Private Site Action Verification

While a lot of activity on a social media website may be public, even on such sites there is often some activity a user does which is private or known only to the user. There is no reason for the user to share this information with anyone and it is site specific. For example, on a banking website you could ask them to verify the amount paid on a utility bill. Even giving them the choice of three values and a "none of the above" provides some degree of protection. Of course, in that particular case, the bill may come in the mail or may be a shared expense. A potentially better question may be "Who was the last person you sent a private message to?" since this is by definition not public, but may be guessable by a family member who knows who your best friends are.


Is having multiple correct passwords for a single username a security problem?

Your account is as secure as the weakest password able to access it. If one password is K_ig6W952B[1DGF3&8q.V^-}0ZN?rbDZ and the other password is Despacito2, then the effective security is almost nothing.

Assuming that both passwords are equal, there are still twice as many passwords as usual, meaning that a hacker attempting to crack hashes for your password will only work for half as long.

In practice, this will make no difference. You will lose 1 bit of security, which can be offset by just increasing the length of the password in your password manager.


Why isn't OCSP required by default in browsers?

There are several problems with OCSP. Some of them:

It puts too strain on the OCSP responder (minor issue)
It makes your browser respond slower, as it has to ask the CA before visiting the site.
Privacy reasons: The CA gets the serial number requests for all the certificates you ask, so it can pinpoint which sites you visit. Who says it will not sell that data, do you trust it? Of course you are supposed to trust your CA, but...
There are some man-in-the-middle attacks targeting it (paper)
Also, the current implementation is somewhat weak. If an OCSP validation attempt fails (because the server does not respond for example), the browser has two choices: Continue anyway or fail hard and stop the connection to the site. Both of these choices are bad: If the browser ignores the fail, a possible attacker can mitm the server, if he has access to the potentially invalid certificate. If the browser stops the connection, then an attacker in the network can do a simple but effective Denial of Service attack, just by blocking somehow all OCSP requests.


How to apply custom filters for John The Ripper when cracking RAR3 archive password?

You will need to be running John 1.9.0 to support masks.  The following John mask specification:
john -1='?u?d' --mask='?1?1?1?1?1?1?1?1'

Will match 8 characters of Upper and Digits.
The MASK documentation file from the distribution is available here and goes into more detail about what you can do with masks.


Can a known MD5 hash limit the search space for SHA1 collisions?

No.

MD5 and SHA1 are largely unrelated. Knowledge about one does not confer any knowledge about the other.


Best practices when forwarding an email or copy / pasting from confidential information sources?

If you can configure your email client to ensure text is the only thing you are copying, you'll be fine, but most commonly used modern mail clients understand macros, formatting, meta-data etc., so cannot be considered safe unless you can fully control that configuration.

To be honest, unless you know exactly how the email client you use handles data (and meta-data) from emails, copy and pasting into a meta-data unaware application (such as notepad) is the safest bet.


How to analyse packets sent by controller in Wireshark?

I want to mimic a replay attack on controller PR402. I connected my
  computer with this controller via TCP/IP <-> Serial Bridge and I would
  like to analyse packets sent between computer and controller.

Because you're dealing with TCP/IP ↔ Serial Bridge, you can assume the data portion of the TCP packet is what's getting carried over onto the Serial line.  So you can ignore everything except the data portion of the TCP packet.

  First of all, I send a command "Disarm the system" from software
  provided by the producer and capture these packets in Wireshark

I assume you're using Roger's PR Master software or the equivalent.  Two things that you'll want to do:

Repeat the "Disarm the system" command several times, separated by time.  This will allow you to see if the command is an exact duplicate each time, or if it includes something that varies like an incrementing counter or a timestamp.
Perform several other commands, several times each.  Again, are they static repeats or do they morph?  Do they have common aspects (e.g., each begins with 0xb03e) or are they all unique?

  I upload 2 captures. These are just some packets from running the same
  command - "Disarm system". I found out that packets from 1st to 8th
  from the first screen and from 2nd to 9th have the same length and I
  think there this "Disarm system" command was transmitted. Let me know
  if this is the right direction of analysis.

Looking at the first capture, I see several small bits of data being exchanged.  (Going back to what I said at the beginning, you only care about data.  You can tell when a packet has data in this example because PSH (TCP "Push" Flag) is being used on all data packets, and the Wireshark view shows "Len=X" to indicate X bytes of data.

1: You -> PR402 3 bytes (0xbe3e01)
2: You -> PR402 9 bytes (???)
3: PR402 -> You 3 bytes (???)
4: PR402 -> You 7 bytes (???)
6: You -> PR402 3 bytes (???)
7: You -> PR402 3 bytes (???)
9: PR402 -> You 1 byte  (???)

Where a 3 byte message commonly initiates a directional series (1, 3, 6), that might be the command, or it might be a meta-command - e.g., packet 1 means "REQUEST", packet 2 means "DISARM", packet 3 means "REPLY", packet means "DONE".

This is where differential analysis, the comparison of capturing different repeats of the same command and different commands, comes in - if you send "ARM", and packet #1 is still 0xb03e01, then that's not ARM/DISARM, it's an attention/request/etc message.

You know you need to:

  Analyse them, dump to a file

With packets this short you're probably just as well off clicking through each packet in Wireshark and typing in the 1-10 data bytes per packet by hand.

So, go through your captures, and summarize what's saying what to whom, write it out just like I did above (but replacing ??? with actual bytes).  Do that for several DISARM and several non-DISARM sequences.  (If you do something like add a user with PIN, then you should see the user id and the PIN in one of the data packets, which will help you understand how these exchanges think of the data as they're exchanging it.)

Once you have those patterns, you'll be able to make a guess at how to implement the DISARM pattern yourself.

  Generate proper packet/frame

You can use something like scapy for this.  If send a TCP packet with data of 0xb03e01, for example:

# scapy
>>> packet=IP(dst="192.168.0.21")/TCP(dport=771)/"\xb0\x3e\x01"
>>> send(packet)
.
Sent 1 packets.

Putting that in the context of a well-formed TCP connection is a little more work.  If you do need to run multiple packets across a single connection, you'll need to dig a little deeper into scapy (for example, reusing sockets), but that's the tool that will quickly and easily do what you want to do.  You could also put a Perl/Python wrapper around nmap, for example, although that gives you a little less per-packet control.

Since you're dealing with a TCP-to-Serial connection, sending individual packets like that - one TCP connection, one packet, and closed - is probably fine.  The Serial bridge probably might care less how many TCP connections are used.

  Transfer it to the controller and achieve disarming system

If you have TCP access to the Serial bridge, then all you need to do is send the packets.  If it works for the PR Master software, and you mimic it correctly it'll work for you.  Remember, this is a physical security device and it likely operates under the assumption that all Serial input is trusted because the Serial line isn't exposed to untrusted physical spaces.  The data size we're seeing in these packet exchanges makes encryption or authentication precautions unlikely.


Yes, swap files can contain sensitive data.

On Windows you can configure the page file (swap file) to be cleared at shutdown this way:

Start regedit32.exe
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management
Set the data value of ClearPageFileAtShutdown to 1
If the value does not exist, create it with the type REG_DWORD and set it to 1
Restart

I don't know for sure if this is a secure deletion of the swap data, but from the fact that it adds minutes to the shutdown process and from the text on Microsoft page about ClearPageFileAtShutdown:

  Some third-party programs can temporarily store unencrypted
  (plain-text) passwords or other sensitive information in memory.
  Although clearing the paging file is not a suitable substitute for
  physical security of a computer, you might want to do this to increase
  the security of data on a computer while Windows is not running. "

I would think the data is securely wiped.

On Linux you can manually wipe the swap partition:

Display swap details: swapon -s
Unmount the swap partition: swapoff -a
Overwrite it with zeros: dd if=/dev/zero of=/dev/sdaX bs=1024
Get the UUID of your old swap partition from /etc/fstab
Create a new swap partition with that UUID: mkswap /dev/sdaX -U <old_uuid> 1024
Mount it for usage: swapon -a

Better wiping tools are provided by the Secure-Delete package which comes with the following commands:

srm (Secure remove) – used for deleting files or directories currently on your hard disk.
smem (Secure memory wiper) – used to wipe traces of data from your computer’s memory (RAM).
sfill (Secure free space wiper) – used to wipe all traces of data from the free space on your disk.
sswap (Secure swap wiper) – used to wipe all traces of data from your swap partition.

Sswap is designed to delete data which may lie still on your swapspace in a secure manner which can not be recovered by thiefs, law enforcement or other threats.The wipe algorithm is based on the paper “Secure Deletion of Data from Magnetic and Solid-State Memory” presented at the 6th Usenix Security Symposium by Peter Gutmann, one of the leading civilian cryptographers.


how to send confidential data through email?

When communicating vulnerabilities to clients, the report is provided through a website under our control. The URL and their username is sent through email, and send the password via SMS. It's not much of a hassle if the steps are simple and largely automated (uploading the file, creating a user, sending the password to a phone number) and the recipient does not need to be tech savvy.

Alternatively, PGP encryption can be used for people who have a public key and the fingerprint has been verified. There are very few people who prefer this, typically only other security teams (and even then, not always).

Note that when encrypting zip files, as you do, the filenames are still readable. This might inadvertently leak information.


DNS cache poisoining prevention by directly using ip instead of url

So If I entered the IP address of a website directly I will not be a victim of DNS cache poisoning ??

This depends on the web server its configuration. Often web server use virtual hosts in order to host multiple domains on the same web server.

Based on the domain name, the content of the web page is routed to the proper content directory for that specific domain.

The generic answer to your question is most likely "no!" because of the above described inner working. The only exception is when one domain is served on a specific IP address. In that case it might be possible.

In order to overcome DNS cache poisoning, one could edit the hosts file where the domain is pointed to a specific IP address. The hosts file lookup is performed before any DNS queries take place.

Please note that when DNS changes are applied to a specific domain, your hosts requires updating as well. Although this will work for some time, it is not the best solution.

The best way to prevent such attacks is to use DNSSEC as it allows you to authenticate DNS messages.


How to ensure that a person whose identity has been verified from an I.D. is the author of their exam answers?

Attack vector:

Examinees may easily swap drives during or after the test, if there is no pre-authentication of which examinee gets assigned which token. Using just the token is not sufficient, as examinees may pre-arrange an SSN swap.

A gives B his SSN.
B startes the exam, generating a token for A's SSN on his usb stick.
After the exam is completed, B gives his USB stick to A.
A turns the USB stick over to the trusted person, who verifies that the token is correct for the supplied SSN.

Mitigation: USB sticks are collected by a trusted person (who also verifies identitiy on the spot and matches it to token on USB stick) prior to anyone being allowed to leave their desk. At no point can anyone leave their desks without supervision. Even in this configuration, it may be possible for students to have swapped sticks prior to ID confirmation.

IMO, a better configuration is not to store anything on physical media.

Instead, the test is served remotely in its entirety. In order to start the test, the examinee must supply not only his personal credentials (SSN, password, whatever your facility/institution uses) in combination with a random, pre-written key that the examinee is given access to only after (1) their identity has been verified, and (2) they can no longer interact with anyone unsupervised.


Finding buffer-overflow code vulnerability

Return addresses are generally overwritten in stack based buffer overflows where the data copied into a buffer exceeds the allocated buffer space and corrupts/overwrites a stack frame, including the return address (future EIP).


Is there an online bitcoin wallet never hacked yet?

I'm sure there is. But even if you pick one of them, you're trusting money to yet underregulated/undercontrolled institutions which might misplace your money, be it through incompetence or by design, disappear tomorrow, or, as you say, get hacked, and you will have basically no recourse. There are very good reasons why the traditional banking industry is heavily regulated.

So I'd suggest to not put your trust in any one such wallet, but split your bitcoins among several, so you won't be left out hanging to dry in the rain when one goes down. I'd also suggest a preference for those online wallets under the regulatory domain of a countries that have the legal framework to deal with them (which might be difficult just yet).

Or keep most of your bitcoins in a wallet at home, make regular backups, keep one of them in a secure off site location and only transfer as much bitcoin into an online wallet as you need. Basically, it's the exact opposite of what I'd counsel someone who asked me where he should put is cash to keep it safe.


This depends on what should be achieved with the timeout. You might timeout a session if the user did not interact with the site for some time. Or you might timeout the session if the user has not visited the site for some time, but don't timeout if the site is still open inside the browser. The first way is more secure but the second is more comfortable for the user (longer timeouts are more comfortable too). How to weight security vs. usability depends on your specific use case.

If the session timeout should be triggered based on actual user activity then it should be reset only if such activity is found, i.e. at the start of a HTTP request which was caused by activity of the user.

If the session timeout should instead be based on browser activity (i.e is the web site is still open in the browser) then it can be reset whenever data is successfully exchanged with the browser. Such successful exchange means that the web site is still open inside the browser and the the browser has network connection but it does not mean that the user is actually doing something with the site (i.e. might be away from keyboard).


OpenPGP encrypting backup files and sending them to Usenet servers

In principle, encrypting with AES 256 bit should be fine, as long as you don't mess up (and upload unencrypted information by accident), the math stays secure (new findings could harm the used algorithm's security in future) and finally the data really does not deleted exactly at the time you require to restore from your backup.

Using --symmetric encryption will disable public/private key cryptography, as already indicated in GnuPG's warning message:

$ gpg --recipient a4ff2279 --symmetric
gpg: WARNING: recipients (-r) given without using public key encryption

If you want to do public/private key cryptography, do not use the --symmetric option, otherwise don't use the -r/--recipient flag to denote a public key to encrypt for. OpenPGP is a hybrid cryptography protocol, and will use symmetric encryption anyway -- but will use a random session key encrypted using your public key instead of a (weaker) passphrase.

Anyway: although your provider accepted you (mis)using their servers for this purpose, I'd not go for that route:

You distribute the data publicly to everybody. If your private key is weak, lost or gets public for any other reason, "the whole world" might be able to read your backup. The same applies if you upload unencrypted information by accident!
You are allowed to (mis)use the servers, but have no guarantees they don't change their mind and delete the files at any time.

15GB of data are not a lot. There are lots of services providing you with a personal cloud storage in that size, even for free. Not only are you using the storage in the way it is purposed to be used, but also there is some additional safety net in case something goes wrong, and not everybody can read your data (although you also should remember: "there is no cloud, just other people's computers" and you still have to put some trust in them (so encryption on your client computer/file server is a very good thing go do).


Before reinventing the wheel and building your own session manager,  read the OWASP Session management Cheatsheet,  which will help you avoid common mistakes.

The problem is that the proposed authentication token sha512(password) used to maintain the authenticated state, it is in fact a very understandable session token for a number of reasons:

The worst problem is that this proposed session id has a very small
key space.  It is lot easier for an attacker to guess
sha512(password)  than to guess 16 bytes of /dev/urandom.
Encryption != Authentication. Multiple keys can act upon cipher text
    to yield some result,  only the correct key will actually yield the
    real plain-text.   You still have to verify that you have received
    the exact key and AES-CBC won't do that.  The correctness of this key could be verified with a
    hash function,  a CMAC or HMAC. AES in an authenticated mode of operation would work.
CWE-613 states that session ids or "tokens"  must expire.  By
using the password hash, in effect a new password has been created that is sha512(password) that
doesn't expire and can be used to authenticate without knowing the plain-text password. Once this value is compromised an attacker can
access the account.
SHA512 is bad Key Derivation Function (KDF) and a bad way to store
passwords in general (CWE-916).   bcrypt,  pbkdf2, scrypt are all good options.
If you are being RESTful,  then use the proper VERB!  Using
POST for everything is confusing.  Enforcing POST doesn't make the system more secure,  these requests are just as vulnerable as GET to attacks like CSRF or other attacks.


Doesn't hashing passwords server side mean a compromised website could leave passwords vulnerable?

The weakness you allude to is real. An important point is that once the server is compromised, the attacker has little incentive to grab passwords that grant access to that server -- he is already in the place. However, human users have the habit of reusing passwords, and that is a big problem, because a reused password means that compromises on one server tend to "propagate", exactly in the way you explain: the attacker grabs password P for user U, and guesses (alas correctly, most of the time) that the same user U will have used the same password on some other servers.

Hashing client-side is a nice idea, but there are details:

Whatever the client sends to the server, be it the password itself or the hashed password, grants access. It is password-equivalent. If the server stores these hashes "as is" in its database, then it is in the same situation as a server storing plaintext passwords, and that's bad. Thus, the server MUST also do some hashing.
Client-side hashing occurs only if there is code on the client side that does the hashing. In a Web context, this means JavaScript. Unfortunately, JavaScript is poor at cryptographic implementations; in particular, it is quite slow, so the client-side hashing will not be able to use the many iterations that are usually needed for good password hashing (see this for details). Also, this would not work for clients without JavaScript.
Still in a Web context, the client-side hashing, if it occurs, is done by JavaScript code sent by the server. If the server has gone under hostile control, then it may send malicious JavaScript that pretends to do the hashing, but does not. The user will be none the wiser. Thus, the root problem is not solved.

Client-side hashing is usually envisioned under the name of "server relief", not to increase security against evil servers, but to allow the server to handle many concurrent users without spending all its CPU on a lot of hashing. JavaScript being what it is, this is not commonly done nowadays.


How is Google Chrome managing authentication to sites?

With a cookie!

Chrome, like any other browser, is storing a cookie in your file system. Those cookies are what enable you to reconnect automatically to some site. Since it's in your file system, even if you reboot they will still be there. Multiple processes or not is irrelevant here.

Then you might wonder, if the cookies are in my file system, does it mean that any page can access them?

No. Only the page for which the cookie was created can access it. The one that enforces this policy is your browser. If your browser is doing its job correctly then you are ok since it will only send the cookie to the right site (server).

You can also access the cookies directly by looking at the file system, but for that you need to have access to the operating system. Webpages don't have access to that hence the browser is doing that job for them and only gives them the cookies they should be able to read.

Fun thing

You need to protect your cookies. Stealing your cookies is nearly the same as stealing your password/username. If someone or something, like a virus, steals the cookies residing on your computer, it can impersonate you on that website if you are currently logged in.

You can check, edit and add cookie with tool like firebug. So, if you want to mount a fake attack you can :

log in on a website using chrome
read the cookie in chrome using the developer tool
open firefox with firebug and add the authentication cookie that you found in chrome

You will then be logged into that website in firefox as well as in chrome. This is a simplistic version of the hack session hijacking. You could transfer the cookie onto another computer if you want to.


Is there any reasonable argument against immediately validating a new customer's email address?

Sure, they probably don't want to bother people with unnecessary steps. Why would you bother asking them to validate their email address after a lengthy sign-up process with lots of fields already? You want customers to have a good experience and finish signing up for the service without hurdles, who cares if their email address is valid. Worst case you send them a letter, which will have to arrive because the service (in this case) is delivered to a home address. If it's not a valid home address, then it would also be fine to cut the service as there can be no service. The most important detail to the ISP will be the payment details, not whether they're accidentally sending the order confirmation to another email address.
I am sorry you had to deal with this, but I'm not sure there is a definitive answer to this question. Many reasons can be thought of, the most obvious one being usability.


Is there an effective social engineering employee awareness program?

Note that I am writing a book on this very topic.

Social Engineering is all about getting people to do something. To combat that, you need to train your users to do something else. A 20 minute video once a year is not an effective means to affect someone's behaviour.

Ongoing, recurring training, embedded in the user's normal work routines, is the most effective method to change behaviours. Add to that, simulated scenarios (mock phishing, etc.) so that users have a chance to practice their skills in a safe way, can cement the new behaviours in the long term. There is a lot of research and study on the effectiveness of this approach.

Security Awareness is not a "fire and forget" exercise. It requires a "slow drip" of knowledge, training, and practice that is supported by an approachable, and even empathetic, security team.

In my book, I liken the problem to trying to get your entire workforce to loose 5 pounds. Once you start to think like that, you start to see that the problem is not "what's the best video to show?" but rather, "how to help each person every day?"


This hash function indication is there to support streamed processing. A signature on some data always begins by processing the message to be signed (or verified) with a hash function, e.g. SHA-256. Then, the hash function output is that which is used in the rest of the cryptographic operations.

The "signature" itself, i.e. the binary thing that GnuPG adds at the end of the email, contains the complete specification of which hash function to use, so the Hash: header at the beginning is conceptually redundant. However, the point here is that the GnuPG-produced binary structure is at the end of the email. The recipient's emailing software must then, upon reception of the email, first read it entirely, to reach the GnuPGP object at the end, and then read the full email again in order to hash it. On the other hand, if an explicit hash indication appears right at the beginning of the email, then the hashing can occur while the email is read the first time: this is streamed processing.

This makes sense if you consider that PGP was designed a good twenty years ago. At that time, software could not necessarily afford to keep a 2 MB data file in RAM; streamed processing was important. Well, stream processing is still important, but no longer for data sizes as are commonly encountered in emails. Over the years, average email size has not grown as fast as average RAM size. Nowadays, we do streamed processing for big video files, not for emails. So this "Hash:" header can be considered as a remnant of older times.

It still is part of the ASCII-armor format for cleartext-signed messages, though; theoretically, you may remove it only if the hash function is MD5. Since the information is redundant, it is possible that GnuPG would accept to process an incoming message lacking this "Hash:" header. Or not. I encourage you to try; but be aware that you may encounter interoperability issues if you deviate from the standard.

PGP/MIME does not use "ASCII armor" but MIME, the signature object then being an attached file, as if it was a picture. MIME cares less about streamed processing than the original PGP.


Best ways to store private keys on a client?

Essentially, the problem you are trying to solve is the same as DRM. It is practically impossible to securely store secrets client side (at least without specialized hardware), since the user has unlimited access to the client and can modify and inspect it at will.

Include the private key with the jar file

As you say, the user can easily reverse engineer and recover the private key. Obfuscating the key may make it harder to retrieve the key, but any decent determined reverse-engineer will eventually be able to recover it.

Send the private key over HTTPS after the client runs and cache it in memory
I am worried about the user intercepting HTTP packets.

To solve this specific problem, you could use certificate pinning to prevent the user from simply using some sort of TLS inspection proxy to intercept and inspect the packets. However, a reverse engineer could remove the restriction from your application. Or they could just dump the memory and retrieve the key from there.
If you are trying to prevent casual users from being able to extract the key, hardcoding the key along with some obfuscation should be sufficient. However, if you want to prevent an experienced reverse engineer from extracting the key, you are out of luck.


What information could be gained from an Amazon shipping label?

A standard Amazon Shipping label (ANSI/UCC-128) has 6 zones.

Zone A: Ship From
Zone B: Ship To
Zone C: Carrier Routing Barcode(Ship to Postal Code)
Zone D: Carrier Segment (Carrier Specific info. Usually Bill of
Lading # & Tracking #)
Zone E: Customer Segment (Usually contains Purchase Order#/ contents
info - UPC, Qty, etc...)
Zone I: SSCC barcode( A unique identifier for the package. Like a
license plate.)

Aside from the human readable data on the label. None of these barcodes relate to any personally identifying information; A 9 digit postal code, and a license plate number identifying the package.

  Could they get the credit card number or choice of Payment, etc?

To answer directly, no.


Use TLS you don't need to do anything else. Don't try to build your own protocol unless you have someone very good at cryptography, even then it is not worth the risk. The server, not the client sends the entire certificate chain including the root. All of your machines will have this root installed and thus accept it. Otherwise abort the connection. At most you may have to rewrite client so that it only accepts your company root as a trusted root.
EDIT:
Digital certificates by themselves do not authenticate anyone. They are never meant to be secret in the first place. It's purpose is to certify that the public key of some server or anything indeed belongs to it. Your certificate contains your public key which is used to verify your signatures. The public key is used to verify that the signature used authenticate the server (and client if it is two-way) is indeed valid. The signature is also used to ensure that key exchange has not been tampered with. After key exchange, the data communicated is secured by encrypting (which also includes message authentication with it) it. If you just send your public key bare instead of the certificate, an attacker can easily inject her own public key instead making it insecure. The signature in question can only be produced using a private key which is paired with that public key. I won't go into much detail you can look into mathematics of cryptography if you are interested but deriving private key from the public key is infeasible, at least we know of no easy way to calculate private key from public key.


Securely storing username and password in conjunction with a mobile app

To my mind, the weak point here is that you are storing and decrypting user passwords to the second API on your platform.  If the endpoints of the first API are compromised, an attacker would gain access to both to the encrypted usernames/passwords, and any passphrase submitted by a user.

You've swapped the potential compromise of a single username/password on a device for the potential mass compromise of usernames and passwords on your platform.


Is there a way to prevent changing the MAC address on a Windows machine?

(There may be network cards which use a fixed MAC address, but I've not yet heard of them.)

As the comments suggest, an Administrator account in Windows can adjust the MAC address, as well as the IP address. A non-administrator account cannot. So, if you do not trust the user, or want to reduce the risk of viruses, you should certainly run a non-administrator account.

However, with physical access to the machine, there are many possible ways to bypass the user account controls, and gain administrator access anyway. Properly securing a machine when someone has physical access is quite complex and depends on the specific requirements.

And besides that, could someone just unplug the network cable and plug it into a a separate device for which they have root access?

The best thing to do would be to have a middle-man device which controls the traffic. For example, with a Managed Switch, each PC can be plugged into a separate port. The physical port number can be tied to a specific IP address and MAC address requirement.

Besides a proper Managed Switch, many Routers, or small computers with multiple ethernet ports have the ability to enforce such restrictions.

(Finally, were you to use a Proxy or NAT, then the MAC address would be reset in that way, but this is probably not what you are looking for.)


Does site need SSL to resend info to a site that does use SSL?

Yes, the page that renders the form needs to use SSL as well as the target. If the form page does not use SSL, an attacker will be able to manipulate it during transmission.

He can change the target.
Or more stealthy: He can add some JavaScript somewhere in that page to send a copy of the data to his server

You should not teach people to enter sensitive information on non SSL pages


I actually switched from pass to keepassx2, because it clears the clipboard after 5 seconds. Before that I just had a shell script, that I used to call pass that cleared, that clipboard 10 seconds after pass was closed.


It would cause a performance hit.  Additionally, it depends on what you are concerned about having stolen.  It's possible that even if you do this, an attacker might still be able to acquire your customer list, and potentially payment information if you are storing it.

Even if the data isn't useful in your application without a relation key, an attacker would probably be quite happy with the unrelated data if that data is coherent in any way.


Vertical information portal security with a customized web browser

It sounds to me like you want your Web based SaaS application to be accessed only by browser/client/hosts that have some system integrity properties that are usually lacking in a typical web client host -- e.g. absence of malware, resistance to malware. If that is so, then you should consider developing a client that is a hardened dedicated browser appliance:
a) delivered to users as a liveCD image to be booted on typical PC HW from RO media;
b) built using SE Linux and bootstrap to restrict the executable application software to consist of a web browser;
c) local packet filter configured to permit communication only with the host(s) of the server side of the application;
d) browser configured to trust only the server certificate of the server side of your application;
e) several other supporting characteristics, but that's the gist.

An worked example of hardened dedicated browser appliance is available at:
    https://github.com/trustthevote/BrowserAppliance
In addition, you will probably want to build into the client image a key pair and PK certificate that the server requires as a pre-req for service. As you point out, it is certainly possible for the cert and key pair to be extracted and used by a different client host; but it is a strong measure to prevent casual or accidental use of "normal" client hosts such that the server would interact with these risky clients. If your application uses strong user authentication, then you de-scope your risk further by limiting the pool of people who would benefit from something as weird as cracking keys out of a perfectly usable hardened dedicated browser appliance, in order to rig up their existing PC as a client, without having to boot from RO media as a pre-req for using your application.

Hope this helps!
John Sebes
http://osdv.org


What is the difference between Exploit and Payload?

The exploit is what delivers the payload.
Take a missile as an analogy. You have the rocket and fuel and everything else in the rocket, and then you have the warhead that does the actual damage. Without the warhead, the missile doesn't do very much when it hits. Additionally, a warhead isn't much use if it goes off in your bunker without a rocket delivering it.

The delivery system(missile) is the exploit and the payload (warhead) is the code that actually does something.

Exploits give you the ability to 'pop a shell/run your payload code'.

Example payloads are things like Trojans/RATs, keyloggers, reverse shells etc.

Payloads are only referred to when code execution is possible and not when using things like denial of service exploits.


SSL decryption without installing a certificate on each client

This should be possible with certain configurations of proxy servers. Usually SSL proxies are put in place to proxy all outbound traffic, not just traffic to a server that you own, which is why you typically need to install the SSL proxy cert on all devices. If you want to only proxy traffic to one domain for which you have a cert signed by a root authority, then you should be able to install that wildcard cert on the proxy and not need anything from the clients.


Would it be possible for a malicious user to change the LAN IP address of an uncompromised device?

If you don't trust devices on your local network the second method wouldn't work, since someone could host a rogue DHCP server (unless you have some nifty switches which can do layer 2 ACLs to prevent this). If that DHCP server would respond faster than your own DHCP server, the attacker would be able to tell your camera to start using another IP address.

If you're worried about the IP address of a device getting changed, setting a static IP (method 1) would be the best way to do so.

I think there's another issue with the second action you're mentioning though: I assume you want to block traffic to the camera's IP on a router/firewall. However, devices in your local network will not use that device to reach the camera. So unless you can configure that ACL on the camera itself, this won't help you against attackers coming from your local network.

The bottomline here is that you probably should isolate the camera to another network not shared with untrusted devices where you can implement stricter security measures, but you mentioned that that was not possible.


Measuring SNR to detect jammers in Wi-Fi networks

If you just like to detect those jammers - SNR can be measured with tools like kismet, netstumbler, vistumbler.

But keep in mind:

Other WiFi channels will be in your SNR analysis.
A jammer is not the only way to take down a wifi network ;-)


When using HMAC-SHA256 do I must save the secret in the databse to verify the sender?

HMAC-SHA256 is a message authentication code that uses a shared secret between the two communicating parties.  It is absolutely necessary that both ends possess the same key (and anyone with that key can both generate and validate messages).  So yes, your conclusion that the service provider still has the key is a correct intuition.  (They could either store the key or use some mechanism for deterministic regeneration.)

An asymmetric keypair (OpenPGP being one example) would avoid this, but does have a far more complex implementation, more room for error, and higher compute times on both ends for the communications.

In the case where they regenerate the HMAC key, it could be done in a fashion that would make it difficult for an attacker to steal the key.  Perhaps they compute an HMAC(username, secret) using a secret that is stored in an HSM.  This would allow them to deterministically generate the API key without needing to store it in the clear.  Using an HSM makes it very difficult for an attacker to steal the secret needed to generate per-user keys.

The decision as to which is appropriate would depend on several factors, including the necessary integrity requirements for the service in question.  Perhaps the service provider considers that the damage that would be done by a leaked database is not made worse due to API keys being included -- if the information is much more valuable or the site only serves to allow retrieving information from that database, then the access to API keys adds little to the attacker's bounty.


When you introduce secret information in to a device you do not own, it's simply not your information anymore. Whoever owns the device owns the information. If you unlock the password vault with your password, there is always a chance it's recorded somewhere. In the end it all boils down to trusting the device provider.


Is restricting access to file content a way of securing sensible but day to day needed information from 3rd party software?

If I understand this question correctly, you are proposing a system where applications never gets to read a file, but only send commands to an interface that reads and modifies data. That way, the application will know nothing about the data it operats upon. That is not going to work as a way to protect your data. Let me explain why.

So let's say I have some photos I want to crop, but I don't want my photo editing application to see them. The photo editing application would then just send the crop command to the JPG interface, and the interface then does the cropping.

And if I want to see the image on the screen while I crop it, I guess the interface will have to take care of that as well. And if the photo app window should resize to fit the image, the interface would have to do that as well because the app wouldn't know the size of the image. But know the photo app doesn't know the size of it's own window... so how can it control what buttons are shown in the toolbar? I guess the interface will have to take care of that too.

Do you see what is happening here? The interface is taking over all the complexity that the app handles. There simply is no clean interface between reading and writing, so the interface will just swallow more and more of the app until the app is just an empty shell around the interface.

And if the interface is as complex as the app used to be, one has to ask the question: Where does the interfaces come from? People will just be downloading trojan filled interfaces instead of trojan filled apps.


Firefox pretending to update itself, but actually not doing it, and thus being a risk for security - what am I missing?

As far as I know Firefox updates when you close and restart the browser.
What happens normally for me is that I download the FF update when it proposes this in the browser. When done with my browsing session I close FF and restart it. Then you should see a window with a loading bar displaying FF being updated. When that is done, it launches the browser with the message of the new version.


How effective is the Mac Open Firmware password protection?

"Would does the firware password prevent others from doing?"

It stops people who have access to the machine from booting into other partitions, target mode or single user mode. For me this is huge. If you're not encrypting your primary partition, a user could simply sit down at the machine, target boot it and grab anything from your machine. Along with that, a user could boot into single user mode and create new admin accounts allowing persistant access to the machine without the user being any wiser.

"Is it worth the hassle of having to deal with it?"

Depends on your environment. For me, I think it fits for either A) highly accessible machines or B) highly valuable (data-wise) machines.

"How easy is it to get around the firmware password protection?"

If you replace the memory on the machine the firmware password gets removed. So to get by it a person would have to have prolonged access to the machine and the know how to do a hardware swap.

"Is having a firmware password a best practice?"

Again, it depends. I think the highest end security you can provide is encrypted drives with open firmware passwords. That way if the user does have prolonged access to the machine, they can remove the open firmware password but still not read any data. But that's the high end. You have to weigh the difficulties of implementation of this against the damaged that would be done by have a users data lost. Again, think of how likely it will be for users to have prolonged access to the machine and how important the data on there is.


Checking if an RSA private key is passphrase protected

Just open it, if it's encrypted it will begin with

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,0F5C7993DCFA4C0962CE249CFD854B91

if it is not it will begin directly by the (base64 encoded) key :

-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQDNhe+F6Ww2Q9XLLDFJ2s+yp/K/rQn2QMCqT3y0sqS6j+a2T


Check for insecure CORS settings with cURL

You should only specify the origin header in your request. The application will respond with the Access-Control-* headers. Try only specifying the origin header and see what the result looks like.

As far as if the headers are not returned at all, the web server doesn't have to respond with a CORS policy. If it doesn't then the browser will not allow cross origin requests as per usual. CORS allows the server to enable cross origin requests given certain criteria.

The main issue that I find when doing testing for CORS issues is that the Access-Control-Allow-Origin header is populated by what is sent in via the Origin header in the request. This defeats the entire purpose of CORS. An attacker shouldn't be able to define allowed origins.

There are several different Burp extensions that will report on CORS related misconfigurations and security issues. There is also this post on the Portswigger blog detailing some common misconfigurations.

http://blog.portswigger.net/2016/10/exploiting-cors-misconfigurations-for.html


How do I maintain/check a user session in the backend without having to use tokens?

Security goal
Let's take a step back here and ask what security goal we are trying to achieve here. I think with any "login session" system the goal is the same, and comes in two parts:

Initial login: the user proves that they are who they say they are; this is usually done with passwords, MFA, email confirmations, whatever.
Maintaining the session: each subsequent request from the client to the server contains some proof that they are the same person that did the initial login, and not an attacker trying to hijack their session and pretend to be them.

The common way of achieving this is that upon successful login (step 1), the server gives the client some sort of long random-looking string (aka "an auth token"), and the client includes it in each subsequent request as the proof for step 2.
I say "common", but I'm not actually aware of any alternatives unless you want to get into TLS client certificates, or pre-shared API keys but those are a lot more effort and are not really "sessions" anymore.
Implementation
There is a lot of variety for what counts as an "auth token", for example:

JSESSIONID (commonly seen with Tomcat servers)
custom session cookie
JWT tokens
Bearer tokens
some custom value in the Authorization: header

Each of these has their own pros and cons. For example if you do JWTs, then you need to worry about securely storing a signing key in the server. Or if you use a session cookie then you also need an XSRF token. But in a broad sense these all follow the pattern of the server issuing a random-looking token upon successful login that the client echos back with each request.
Session management
(Response to comments)
You getting into the complexity of session management. This is getting way outside the scope of a security question, but I'll answer it anyway.
Yes, in order to process a request, the server will need to know "stuff" about the user and their session. For example:

Username / email
What group / permissions / access controls they have
What time they logged in / when their session expires
Whether they logged in with just password, or with password + MFA (for example if you require "step-up" to access sensitive parts of the app).
What IP their session is from (maybe you want to enforce geoIP restrictions, or make sure they don't change to an IP halfway around the world part way through their session)
A lockout-count (for example if you're doing a per-session lockout)
etc, etc

As this is mostly security stuff, the server needs to be keeping track of this, rather than trusting the client to give the correct information. Debates about where and how the server should store these "session objects" are basically as old as the internet itself. The most common designs are:

Server-side in memory: could be as simple as global vars in your application, or as complex as an in-memory database that synchronizes across servers. Pros: high performance as no db calls are needed. Cons: can run out of server memory, hard to scale horizontally (adding more copies of your server behind a load balancer), you need to worry about clearing out data when sessions expire.
Server-side in database: make a db table for tracking sessions. Pros: scales nicely. Cons: slightly worse performance, you need to worry about clearing out data when sessions expire.
Client-side (aka "stateless): put all the session data into an encrypted JWT (aka "JWE") and get the user to hand it back to you with each request. Pros: high performance, does not consume any memory on the server, scales nicely. Cons: more complex to implement properly, extra bandwidth usage.

As I said, this is an age-old debate, so google something like "server side session management" and you'll get loads of people debating the best way to store session data.


Shellcode doesn't execute despite correct address on EIP

The stack is probably non-executable. Compile the vulnerable program like this to disable the protection:

gcc -z execstack -o program program.c


Assuming all relevant SysRq features are disabled when the lock screen is active (SAK, sending SIGTERM or SIGKILL to all processes, triggering the OOM killer as you mentioned, etc), and assuming advanced attack vectors like DMA attacks, cold boot attacks, and network exploitation are out-of-scope, then there is no way to bypass the lockscreen short of exploiting a bug in the code that is currently unknown (they are not too uncommon, though). In short:

Bypass may be possible by using other SysRq features you have not mentioned.
Bypass may be possible by exploiting an unknown bug in the lock software.
Infoleaks may be possible by plugging in a large monitor, triggering a resize.*
A local process could (intentionally or unintentionally) interfere with locking.

There are other, more secure lock programs out there. An example is vlock which works by opening a new TTY that it controls and disabling TTY switching. It also disables SysRq while it is active. It should be noted though that, if it is run from a terminal, it will exit if the terminal crashes for any reason (this is a bug which is easy to fix). The reason vlock is particularly secure is because it does not rely on the security of your X server, which itself has fundamentally no concept of lock screens. Instead, it is designed to utilize TTY isolation which is something that was designed with security in mind. Another alternative might be xsecurelock, a simple graphical lock screen created by Google which emphasizes security against crashes. However, like most screen lock software, it does not disable any SysRq features by itself, so you must do that yourself if it is enabled.

* If a large monitor is plugged into the locked computer, the root window may automatically resize itself. If the lock screen does not detect this and maximize itself again, it may be possible to see beyond the lock. This is not an issue with virtual terminal-based lock software like vlock, since the X server is in another TTY.


Can USB host ports be dangerous in uncontrolled environments? Virus etc?

Consider this:
It is not possible for a USB-hosting device do determine what kind of USB-device the plugged in USB-device really is.

You plug in a USB-stick, the USB-stick tells the hosting-device: "Hey! Im a Keyboard!" and the hosting-device has no possibility to proof whether it really is a Keyboard.

So if you have the basic USB-features enabled (automatical mounting e.g. -> "PlugAndPlay"), there are a lot of possible attack-vectors.

e.g. your fake-keyboard or mouse or whatever can change all the 'settings' bye calling a scripted fake-user input.


There might be a man in the middle attack against my server

When a change in the fingerprint of the key is detected, it can mean a few things:

the key on the server genuinely changed - this is normal after an OS reinstallation and can happen after the sshd reinstallation
someone is posing as your server, trying a MitM attack. This is possible only with password-based authentication.

Your comment about a password-based authentication suddenly appearing out of the blue would hint about the second case.

As a side note, there is no added value for someone who already hacked into your server to change the ssh key as it will raise an alert.


What are the consequences of turning on Apache AllowEncodedSlashes?

Your web server should not be responsible for correct encoding of user supplied input. If this would cause you to be vulnerable to injection, it means that your application does not sanitize user input correctly.

It has always been considered a security issue because the application running on the web server weren't always escaping the input correctly, resulting in path traversals. But the responsibility for the issue ultimately lies with the web application, not the web server. So if your application correctly escapes these values, you should be alright.


Possibility of Man in the Middle attack in SSL Protocol during initial Handshake

This would not be possible at step 3 (emphasis added by me).

Now, he can further generate his own version of the symmetric key, encrypt with server's public key, send to the server and pretend like an actual user

The public key cannot be used to encrypt, only to decrypt. The encryption is performed on the server using a corresponding private key that is kept secret and never leaves the server.


How to check connectivity between raspberry pi and server

Use nmap with the -p option to have it "ping" the specific port you'd like to test. You can cron this, or script it in any number of ways.

The nice thing about this is you can test the TCP connectivity without creating logs on the server or take it a step further and get the version information from the server which will confirm that the server itself is responding to requests.

You can do this with lots of other tools like curl or wget and each have different advantages and disadvantages. Alternatively there are lots of small-footprint network monitoring tools which would also do the job.

If you are also looking to log this data setting up something like MRTG or RRD may also be useful to spot patterns in downtime.

https://nmap.org/

https://curl.haxx.se/

https://www.gnu.org/software/wget/

http://oss.oetiker.ch/rrdtool/gallery/index.en.html

http://oss.oetiker.ch/mrtg/


How do I make SQL injection harder but not impossible?

Blind SQL injection is probably one of the harder techniques, in that it requires more work. You could make a page that doesn't display any output based on the query, but shows error messages when a query is malformed. The attacker would then be forced to use blind SQLi techniques to attack it.

Of course, an automated tool would break this immediately, since it could automate the entire injection. One interesting way around that would be to have some kind of super-simple image CAPTCHA (no distortion, just a plain image) that the attacker must solve in order to send a query. This would either force them to do it manually, or make them look into OCR techniques.


How can I validate imported keys with GPG?

This is what I could guess, since I have been checking two aspects:

GPG's source code (version 2.1.18, file g10/sig-check.c)

The function that validates signatures will check the following:

Look up the public key that created the signature.
the signature was not created prior to the key.
public key was created in the past.
no unsupported features.
hash against digest.

Since I imported three keys into an empty keyring, nothing looks wrong (date, hash, etc.) except the fact that there is no other key to check the signature against it. Thus, the signature looks like self-signed (no other key IDs are found) with the sig!3 result (trusting marginally) and the importing process warned me with "no ultimately trusted keys found"

A fresh Debian installation in a virtual machine.

I exported one of the public keys with this command:

gpg --armor --export EF0F382A1A7B6500 | gpg --list-packets --verbose --debug 0x02

Not only will it dump the key part, but also signature packets. I could compare my GPG key contained in the GPG keyring, against the same KEYID in another computer, contained in the APT keyring. The whole byte sequences were identical.

Something similar is described in Debian Manual/Securing Debian (section 7.5.3.8, Verifying key integrity)


Security concerns allowing internet connected server to write on network server

When a hacker takes over the public server, you have to assume the worst case that they can do everything the public server is allowed to do. That means in case of a compromise, any security precautions implemented on the public server are inefficient. You can only rely on those precautions you have on the private server.

Make sure that the public server only has permission on the private server to store files in that one folder. You certainly don't want it to put some files into system folders.
Set file permissions on the private server so that no user is allowed to execute the uploaded files (but keep in mind that simply opening a malicious document might exploit a vulnerability in the reader software which might allow code execution).
Storing the files from the frontend should be the only purpose of that folder. There should be no other data in there which might get overwritten.
Setting a quota for the maximum size of that folder can also be a reasonable protection against an intentional or unintentional denial-of-service attack through filling the whole storage space of the server with garbage.
Having a virus scanner on the private server to scan the incomming files can't hurt. But don't trust it too much. Remember that a malware scanner can only find what it knows.
A sensible precaution can be to only allow files with specific extensions to be uploaded. But keep in mind that the file extension is not a reliable method to check for a type of file. Finding out that hello.jpg is actually a renamed executable is non-trivial. However, it prevents accidental execution due to double-clicking in most cases.

Another possible way of doing this is to use a pull-method. Don't have the public server push its files to the private one. Have the private server check for new files on the public server at regular intervals and pull them. This gives you greater control over what files to pull. You can, for example, only pull files with filenames matching a specific pattern.


How secure is the Windows 8 included Anti Virus known as Windows Defender?

Let us analyze each one of the techniques you want the AV to protect against:
UAC Bypass: Any process in the Windows environment running with the trusted root certificate can turn off the UAC bit of its own process, as well as any process spawned by it. This means that if your malicious code can inject itself into a process running with the trusted cert, it will have all the privileges of the injected process. Then, if you create another process, you can easily turn its UAC bit off, because this is a built-in feature of Microsoft Windows. This is the technique employed by the Metasploit framework for UAC Bypass.
Process Injection: Microsoft provides an API called LoadLibrary through which you can load any arbitrary DLL from the disk into a running process. The only thing that malicious code does is load the arbitrary DLL from within memory, and not from the disk. This is achieved through a technique called Reflective DLL Injection, which Meterpreter makes use of as well.
Root Kit Detection: Rootkits operate at ring zero (kernel level), while antivirus products run in userspace. Most of the time, the AV only hooks certain APIs in kernel land. Any process running below the user space cannot be analyzed by the AV. Before Vista, AV products used to load drivers in the kernel for monitoring. However, after the introduction of PatchGuard, that technique can no longer be used by antivirus software.
Running the Process Directly Within Memory: This is an area where AVs have made some progress. Nowadays, even if you are directly interacting with a running process, the AV examines the traffic received by the process from the network, and checks it for malicious signatures. However, there are two shortcomings to this approach: first, it is signature based checking, so it is inherently weak. Secondly, it is done only for common Windows processes such as SMB.

As you can see, the things you most want to protect against, are the kinds of things against which no AV product can effectively defend. Most of the items you have mentioned are not malicious by nature. Rather, these are considered "features." In Windows 8, Windows Defender is the combination of Microsoft Security Essentials and Microsoft Defender software. On the plus side, it is free, and has low performance impact. However, if you really want to protect against the techniques you have mentioned, Windows Defender, or any other AV product, won't be able to provide an effective solution. For these kind of attacks, Microsoft has another product called the Enhanced Mitigation Experience Toolkit (EMET).


No, I don't think that the certification itself will make you legitimate and/or job-ready. However, you can learn a lot while preparing yourself for those exams. You haven't stated what you try to achieve, but by simply attaching a certification or two to your application, will not make you a great and experienced infosec guy, and every big/serious IT company knows this.

Don't get me wrong: It is definitely helpful in getting across your experience, but in the end there will be job interviews and you'll have to prove that you can stick up to the claims made in your CV. So, while it might be a good door-opener and a good foundation to start the discussion, you still will be asked about previous work experience, etc. Nobody will take it you for real, simply based on some certification attached to your application.

Unfortunately getting a decent system administrator is nothing you can learn and be done with it. It is a process of learning from mistakes you (and others) did. If you want to switch into this area (system administration, security) you should start small-ish, with some test setups / environments, read about it and shouldn't be too picky about any job.

I would argue, that Working in the infosec area is even more challenging. If you are seriously interested in it, just start to look into it, work through some material (there is a ton of it available) and try to apply it to some software you like. While doing this, you might get some attention from the company you want to work with, and applying for a job with them, might be become easier in the future.


Is there any way to validate the firmware in a USB flash drive?

Yes, there is, but is complex and time-consuming:

Open the case

Use hardware probes to the pins of the NAND chip storing the firmware

Take a dump of the firmware

Use a disassembler or debugger to check the firmware

In the end, it depends entirely on your reverse-engineering skills. Even a good reverse-engineer can be fooled if the firmware have specific functions made to confuse or misled debugging, so your results may vary.
Instead of using the firmware to store malware, an attacker will most likely use the storage itself.


Bluetooth attack against Android phone - could be successful?

I don't know what makes you think that a file that couldn't get into your phone would attack you. If you got a "file transfer unsuccessful" or similar message, it clearly means that the file isn't received. So, no worries.
SQLite is a database that is used in android.
Even if you had received the file, it should be executed by a program, your or a third party who can physically access your phone. Which didn't happen. Also, you would need root permissions to allow other apps to make something to execute.
So, basically, don't worry on it and don't keep the Bluetooth to discoverable mode to avoid such surprises.