If the Web browsers states that the certificate is not to be trusted, then, basically, you cannot trust it. If there was a simple method to validate whether a certificate is good or not, besides certificate validation, then browsers would apply it.

The above is not entirely true: there is one method to validate a certificate, that browsers cannot do. You can phone the organization which owns the expected HTTPS server; here, apparently, the Bureau of Consular Affairs, from the US Department of State. Ask to talk to a sysadmin, and have him spell out, over the phone, the SHA-1 fingerprint of his certificate (40 hexadecimal characters). Compare with what your browser shows you (it is at the end of the "certificate details"). If the values match (exactly), then the certificate is genuine and you may proceed. This validation method, of course, assumes that a phone call is trustworthy and won't be intercepted (in particular, how you obtain the correct phone number might be subject to malicious alterations), and also that a US administrative bureau will have someone to answer the phone and will accept to forward your call to a sysadmin who has time to answer, and a clue about what SSL and certificates can be (that's his job, but being assigned to a task has never guaranteed competence).

Even if you can make sure that the certificate is real, then this begs the question of why the certificate was declared incorrect by the browser. This can be the consequence of a number of possible mishaps, including a failure to renew a certificate on time, or even a bug in the browser code.


Alternatives to HTML's deprecated  for client certs?

In this post in the chromium forum there are alternatives mentioned

Within the browser space, alternatives exist such as:

Use the device's native management capabilities if an enterprise use case. On Windows, this is Group Policy. On iOS/Android, this is the
mobile device management suites. On OS X, this is Enterprise settings.
On ChromeOS, there is chrome.enterprise.platformKeys [11] for
enterprise-managed extensions.
Use WebCrypto to implement certificate enrollment, then deliver the certificate and (exported) private key in an appropriate format for
the platform (such as PKCS#7) and allow the native OS UI to guide
users through installation of certificates and keys.

WebCrypto is supported by many browsers: [link]
And you can use openpgp.js and other solutions. [openpgp.js]
Here are some examples.
You can also generate a CSR: https://www.w3.org/community/webcryptoapi/draft/#generatecertrequest-method
Some library for generating CSRs: https://pkijs.org/
Here is an example with PKIjs for generating selfsigned X509 certs + the keypairs:
https://github.com/infotechinc/create-x509-certificate
The generateKey() function creates keypairs.
https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#SubtleCrypto-method-generateKey


How to get hold of intermediate certs programatically?

You can use openssl s_client to capture the certificate chain from a given web site, and (with the -showcerts option) it will helpfully identify the (s)ubject and (i)ssuer for each certificate.  If the root is not included, then you should be able to find it in your local certificate store.

Here is some example output from openssl s_client, with the meat of the actual certificates trimmed (...) for brevity:

$ echo "" | openssl s_client -showcerts -connect www.google.com:443
CONNECTED(00000003)
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
-----BEGIN CERTIFICATE-----
MIIEgDCCA2igAwIBAgIIRLhIyqBaCIMwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
...
segXWw==
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
MIID8DCCAtigAwIBAgIDAjqSMA0GCSqGSIb3DQEBCwUAMEIxCzAJBgNVBAYTAlVT
...
wSHGFg==
-----END CERTIFICATE-----
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
-----BEGIN CERTIFICATE-----
MIIDfTCCAuagAwIBAgIDErvmMA0GCSqGSIb3DQEBBQUAME4xCzAJBgNVBAYTAlVT
...
b8ravHNjkOR/ez4iyz0H7V84dJzjA1BOoa+Y7mHyhD8S
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---

The first certificate in the chain (0) shows you it's subject and issuer.  As you can see, the subject for the second certificate (1) is the same as the issuer for (0), and the issuer for (1) is the subject for (2).  The issuer for (2) is the root certificate, which is not included.  (It is accepted, but not required, to include the root in the chain; as the purpose of the root is to be a locally stored "trusted" copy, software should never "trust" the root handed to it by a web server.  That said, I have seen (non-browser) software which broke if the root was not included in the chain, so it does happen).

On a Linux system, you can track down the root certificate in the /etc/ssl/certs directory, either as an individual file or as part of a large file such as ca-certificates.crt (Ubuntu) or ca-bundle.crt (Red Hat).  You can use openssl x509 -noout -subject -in filename where filename is a single certificate file to get the Subject of each certificate; comparing those to what you extracted from the certificate chain above will allow you to track down the server certificate.

(extracting the subjects from all those files, or exploding the bundle into a number of files and extracting subjects from them, is a medium-complexity Unix scripting challenge left to the reader).

You may find web servers which do not provide the necessary chain.  In such cases, it's usually because the intermediate certs are also commonly distributed by browser vendors, so they can get away with it.

Finally, if you can't track down an issuer cert by any of these methods, try Google-ing the Subject.  If it's a public certificate authority, chances are it's listed somewhere.

Reply to comment:

No, the subject is not guaranteed to be unique - remember, the whole point of x509 certificates is that you have to have a trust chain up to an implicitly trusted root; you know the Subject is good because it was signed by someone you trust.  But by themselves, a subject could be forged if you're not verifying the cert.

So key fingerprints are the best way to uniquely ID a certificate, and you can use openssl x509 to print them given the certificate:

$ openssl x509 -sha256 -noout -in my_cert.crt -fingerprint
SHA256 Fingerprint=DC:5F:B5:98:53:E0:FC:B2:33:7B:8A:CE:64:09:75:76:65:84:A0:8C:2F:B1:D4:01:6D:1F:70:04:C6:0E:23:69
$


OIDC/OAuth2 id_token and it's usage in the client application

Access token is used to grant access to resources for which your external provider is in role of Authorization Server. In this case the UserInfo endpoint is the resource which access is secured by your external provider.
No. You will never do the request with identity token as a Bearer token. But there are requests defined in OpenIDConnect protocole where you can use an id_token as a "hint". The example is authentication request where you sent id_token_hint to point which authenticated (or past authenticated) session was already issued (valid or invalid).
The id_token is issued only for client which requested it (it is called Relying Party). You should not send this token to any other parties (clients or resources). From my experience I have short lived identity tokens (5 minutes). I validate this and confirm the user is correct (extract "sub" and validate the token). If I want to get the user credentials I can also extract those from id_token (only if the identity provider have included those in it) but more often I use UserInfo endpoint to request those with access token. After that I create the application session with all user information. Important is that I store the id_token in some storage (i.e. application session) for usage like I explained earlier.
No. You do not have respect "Exp" of the id_token. Look at my answer on 3. My id token is valid for 5 minutes but session is much longer. I would said that this is "just" a recommendation.

Hope it will help you.


https://www.apriorit.com/dev-blog/160-apihooks
Here's a good tutorial and explination on this. Many antiviruses are taking the same step and using malware like functionality in order to combat malware. Pretty neat how everything is transforming.

  Mhook library
  Several API hooking libraries exist. Typically, they do the following:

  Replace the initial part of a defined function code with our own code (also known as trampoline). Upon execution, the function jumps to a hook handler.
      Store the original version of the replaced code of the defined function. This is required for the defined function to operate properly.
      Restore the replaced part of the defined function.

  About API hooking

  Windows API hooking is a process allowing to intercept API function calls. This gives you the control over the way operating system or a piece of software behaves. Some of the software solutions that utilize hooks include: antimalware software, application security solutions, security monitoring tools, system utilities, tools for programming, and many others.
  API hook types

  API hooks can be divided into the following types:

Local hooks: These influence only specific applications.
Global hooks: These affect all system processes.

  The type of hook technique for Windows that we cover here belongs to the global type. It affects all processes across all sessions (as opposed to the SetWindowsHooks method, which is limited only to a selected desktop).


Website asks for my identification card - Is it safe?

With the updated information, that PaySafeCard are requesting this I would be more confident it's not a scam / social engineering attempt, they are a legitimate and registered UK company.  Although - any one can be vulnerable to a breach, so the question is do you trust them to securely store a significant piece of your identity? Do they store it permanently, if so , how and where? Do they destroy it after initial verification?  These are perfectly valid questions and their customer services team should be able to answer you and comfort any doubts, if they can't then don't trust them with your data.


Cache timing attacks don't tell you anything about the value stored in the cached page. They only tell you which page was cached. The trick of Meltdown (and Spectre) is loading one of many pages into the cache depending on a value that the program is not allowed to know, and that the CPU "forgets" very quickly.

Meltdown exploits the fact that the CPU will briefly act as though an illegal memory read succeeded, and use this illicitly-read value (multiplied by the page size) as an index into an array to cause a page of memory (one segment of the probe array, which can be legitimately accessed) to be cached. The exploit then recovers from the exception (segfault / access violation) of the illegal read, and checks how long it takes to access each page of the probe array to figure out which page of the probe array was accessed, which in turn reveals what the "unreadable" value was.

Line 4 accesses some kernel memory and attempts to read a byte from it; this access triggers an interrupt. (The page that contains this kernel memory will end up in the cache, but this fact is irrelevant to us; we already know what address in the kernel we are accessing.) At this point, we start a race to execute the next few lines before the interrupt diverts this entire thread to its interrupt service routine.

Line 5 is simply multiplying the retrieved value by 4096, which is typically the size of a page in memory. This operation is performed entirely on a register and an immediate value, and is very fast, so it will probably happen before the interrupt catches us.

I don't know why line 6 (or line 3) is needed; perhaps the scenario this code is pulled from cares a lot about whether the retrieved value is zero or not.

Line 7 uses the illicitly-obtained value from line 4 (multiplied by 4096 in line 5) as an index into the probe array, causing one of the 256 pages the array spans to be loaded into cache. This instruction will take a while, and therefore probably not complete before the interrupt catches us, but it will start quickly (just add two registers and hand the resulting address off to the memory manager). When the memory manager returns the value at that address, the CPU will throw it away instead of storing it into the register RBX (because the interrupt causes everything done after it was triggered to get thrown away), but that one page of the probe array will stay in the cache anyhow; the CPU isn't "smart" enough to un-cache pages which were only cached based on the illicit read.

Similarly, when the interrupt catches up, it will revert the illicitly-read value from EAX/AL to its pre-line-4 value (which is zero, as set by line 2). In the theoretical model of the CPU, that register never even received the value; the next few lines simply execute as though it had. In practice, the CPU pipeline has many copies of each register, and the copies downstream of the illegal read store the illicit value (which is then used by the downstream instructions), but that illicit value never gets written to the "real" register. Therefore, the attacker cannot do anything much with the illicit value - it only gets a few clock ticks before the interrupt throws out all the downstream instructions, which isn't nearly enough to do something like "write this value to disk" - but initiating a memory read is fast enough and it doesn't have to complete in time.

At this point, the program receives the "OS trap" triggered by the interrupt, and handles it using a handler that it had already set up (signal handler for SEGV on *nix, or SEH exception handler for access violation on Windows, see https://stackoverflow.com/questions/457577/catching-access-violation-exceptions). The program ignores the trap and continues execution (normally this is dangerous, as it implies something unsafe has happened with your pointers, be in this case we are the unsafe thing). The program then times how long it takes to access each page of the probe array, finds the one that can be accessed super-fast (because it was already cached), and divides that index by the page size (4096 again) to get back the byte which was illicitly read.


OAuth 2 client credentials grant is designed for communications between services. Authentication for client credentials grant typically involves passing a shared secret, instead of a login/password. The shared secret is used to meet the RFC requirement of a "confidential client" for client credentials grant.

If you don't already have an authentication server in mind, I suggest taking a look at Keycloak, at least for a proof of concept - it's an open source offering from RedHat. It utilizes Open ID Connect (OIDC), which is an extension of OAuth 2 (adds an ID layer). Keycloak's server admin documentation on service accounts  for details.


"All versions of OpenSSL are vulnerable to CVE-2014-0195, but this vulnerability only affects DTLS clients or servers (look for SSL VPNs... not so much HTTPS)." is already right in the posting you linked to.  If it is using DTLS, then it could be impacted potentially, but HTTPS generally doesn't.


What is the easiest way to sandbox an application in a *NIX environment?

There is no secure, easy-to-use command line sandbox utility. Popular utilities such as Firejail can often be a cure worse than the disease, and many sandbox bypasses and privilege escalation vulnerabilities have been found (and continue to be found) in it. Sandboxing an application usually requires using mandatory access controls, such as the popular AppArmor or SELinux framework. This will generally involve customized security policies, tailored to the specific application.
I wrote a lot about Linux sandboxing in another answer.


Encryption of headers in IPsec tunnel mode

It is not that the header has to be encrypted in tunnel mode; rather, if the header is not encrypted, it is not really a tunnel.

Tunnel mode is about having two routers linked together with an encrypted tunnel. They exchange packets for other hosts. Schematically, router A is the exit router for network netA, and router B is the exit router for network netB. A and B run an IPSec tunnel. Whenever a machine in network netA wants to send a packet to a machine in network netB, then that machine sends the packet to its exit router, i.e. router A. Router A sends the packet to router B within the tunnel. Router B receives the encrypted packet, but decrypts it upon reception, and discovers for which machine in netB the packet should be sent. Router B proceeds to send the packet to the final destination machine.

With the tunnel:

The source and destination machines which talk to each other don't need to be aware of IPSec; only the two routers at both ends of the tunnel.
Eavesdroppers on the link between routers A and B (i.e. the "bad people on the Internet") only see encrypted data and cannot even know which machine is talking to each machine, since the whole packet is encrypted, including header.


Can I use Metasploit to demo penetration testong on Zigbee or Smart meter?

The Short answer is Yes, however, like most IoT Devices, you would not be exploiting hardware-specific vulnerabilities, you would likely need to focus on services running on those devices.

For example if a IoT device connects to a remote server to store captured data into a Database, your could easily research current vulnerabilities that apply to that Database Software.

In order to find out what Services are running on a device connected to an IP-Based Network, you would need to simply run a IP/Port/Service scan while connected to the same network. After a scan is successful, then you may use MetaSploit to execute a payload against the Network or Device.


Authentication scheme security: unique link and birth date

I would say its secure.
The unique link, ensures that nobody that know your birthdate, can just logon and gain access to your information.

And the birthdate login, ensures that somebody that catches the email in transit (for example, on a public wifi), and the email happens not to be encrypted, cannot abuse your link since they don't know your birthdate.

I would say its sufficently secure for sending, not extremely sensitive information, but I would say your SSN, department, doctor's name and appointment time, for a single patient, is not extremely sensitive.

As you know, the rules for security changes in how many patient details you send. For example, sending a stack with 100 journals from one hostpital to a another, is not permitted via snail mail at all, you need to send it with guarded transport.
But sending a single journal to a patient, is permitted to be sent in a simple letter, you don't even need to send it traceable or registred.

And its generally similiar when it comes to email. You may send simple information, but not more than that. Sending a link to the journal would not be permitted, but sending the information you got, is OK.
However, sending a link to the journal via a GUID link + for example a SMS code to your phone, would be permissible.

So I would say, for the threats that are applicable, I would say its sufficently secure.

I think that they have made so the link expires when your appointment are over. It would ofcourse be dumb to make the link expire earlier, since you might read the appointment on mobile, think "yeah, its 1 week left, I can write the time into the calendar when I come home", and then when you come home, the link is expired/used.


Is it safe to put my own router in my neighbour's DMZ?

Yes that would be fine. However what ever ports you expose on your router your neighbor will be able to access as well. To minimize risks you could block access to that port from your neighbors ip range and also your external ip. This would minimize risks of them discovering your services however would not stop them from connecting from another ip or preforming a port scan from a remote host. To clarify things setting up a dmz will expose your router to the Internet the computers behind your router will be fine unless you have ports forwarded. For further questions I would go to Super User forum as your question only just makes it on the on-topic list for this forum


Is it worth it to install the same web application on different kind of web servers in a vulnerability assessment?

This could be of benefit if customers buy your web application and then install it on a platform of their own and you need to make it secure despite the underlying OS and back-end architecture.

If the application has been properly put together and treats user input correctly in all places, then there should be no difference. If however, parts of the application will allow an MS SQL exploit to work whereas a MySQL one will fail, or a Windows exploit will work, however when hosted on Linux this is not possible, then there is benefit. Of course, you will not know this unless you assess vulnerabilities on these platforms either dynamically (using a scanner like you propose, plus manual testing) or statically (analysing source code both automatically and manually).

Having said that, most applications would tend to exhibit similar vulnerabilities no matter what platform they have been installed on, and would have to be coded in a unique way for it to be exploitable on one platform and not the other.


windows/shell_reverse_tcp exploit is not working if listener is not running already

If i run exploit.exe first and listener second then it doesn't work

Of course it won't, and that's what reverse_tcp means. The payload is reverse_tcp shell, it will start a connection from the victim to the attacker machine, so the listener must be up and running for accepting the connection.


XMLHttpRequest with preflighted CORS missing authorization token

However, when I attempt the following exploit, I can't seem to get any browsers to forward the token.

Given that nothing in your code actually sets the Authorization header it looks like that you are assuming that the header gets automatically set by the browser based on cached credentials, i.e. similar to cookies.

But, such caching is only done for authentication credentials entered by the user in case of basic or digest authentication. If some script in the site instead explicitly sets the Authorization header for a specific XHR no caching of the credentials will be done and therefore also no automatic setting of the Authorization header from cached credentials.


How come MIM is getting through outlook SSl security

accept the fake certificate

This is the problem. SSL won't protect data against end users who read security alerts about unrecognised certificates and then accept them anyway.

  Is there different types of certificates stronger? or better?

Yes, but that won't help with a MITM gives the user a different certificate and the user accepts it.


Is BASIC-Auth secure if done over HTTPS?

There are a few issues with HTTP Basic Auth:

The password is sent over the wire in base64 encoding (which can be easily converted to plaintext).
The password is sent repeatedly, for each request. (Larger attack window)
The password is cached by the webbrowser, at a minimum for the length of the window / process. (Can be silently reused by any other request to the server, e.g. CSRF).
The password may be stored permanently in the browser, if the user requests. (Same as previous point, in addition might be stolen by another user on a shared machine).

Of those, using SSL only solves the first. And even with that, SSL only protects until the webserver - any internal routing, server logging, etc, will see the plaintext password.

So, as with anything it's important to look at the whole picture.

Does HTTPS protect the password in transit? Yes.

Is that enough? Usually, no. (I want to say, always no - but it really depends on what your site is and how secure it needs to be.)


Does Wanna Cry encrypt files on network drives?

Yes, WannaCry will target network drives and removable media, according to Talos Intelligence:

  The file tasksche.exe [a WannaCry component] checks for disk drives, including network shares and removable storage devices mapped to a letter, such as 'C:/', 'D:/' etc. The malware then checks for files with a file extension as listed in the appendix and encrypts these using 2048-bit RSA encryption.

This is specifically worrisome because according to the technical analysis by Endgame Inc the malware also grants full permissions to Everyone on files which it is capable to do so which could have severe ramifications in the case of Active Directory shares.


How can I securely edit an Office file that I downloaded from the Internet?

While in read-only protected mode, select all text, and copy/paste into a new document.

The text of the document is not the threat but any macros and programming behind the document are threats. So, if you only need the text, copy that.

But, it is often not that simple. Some documents (like Excel) require macros and some programming to make them useful. At that point, you need to either:

open the document in the most up-to-date document reader available
open the document in a reader that is not the most common and targetted reader (something other than MS Office, like LibreOffice)
open and edit the document in on online reader (like Office 365)
open the document in a sandbox (like a Virtual Machine) that can limit the impact if the document is going to do something malicious

These options do not check that there is no threat, but it severely limits what impact the threat may have.


XSS prevention when inserting HTML without user controlled data into the DOM?

No user controlled data is returned, but could the returning data be modified somehow?

No, you're safe. You're fetching a document from a fixed URL (/includes/blocks.php) on the same origin which reflects no user-controlled data. For it to be vulnerable to XSS, you'd need an entry point where the attacker can inject code, but at no point does the your code even handle user input.


encodeURIComponent in a unquoted HTML attribute

From MDN:

encodeURIComponent escapes all characters except the following: alphabetic, decimal digits,
- _ . ! ~ * ' ( )

You would normally require a space character to add another attribute (such as onclick), unfortunately this will be encoded as part of the URI.
However, from OWASP XSS (Cross Site Scripting) Prevention Cheat Sheet:

Unquoted attributes can be broken out of with many characters, including
[space] % * + , - / ; < = > ^ and |

So you might want to try the - or * characters to attempt to create a new attribute.
e.g. set somevar to http://www.example.com-onclick=alert('xss')
or http://www.example.com*onclick=alert('xss')
Your mileage may vary between browsers and unfortunately the = will still be URL encoded so you will also have that hurdle to overcome. So even though the value is not quoted nor encoded properly, it may not be possible to turn this encoding flaw into an XSS exploit.
Your second example is more secure, although the value should really be HTML encoded:
$("Download Here	");

where htmlEscape is:-
function htmlEscape(str) {
    return String(str)
            .replace(/&/g, '&amp;')
            .replace(/"/g, '&quot;')
            .replace(/'/g, '&#39;')
            .replace(/</g, '&lt;')
            .replace(/>/g, '&gt;');
}


Auto login works by storing the credentials in the registry in plain text. Once the winlogon.exe process has finished loading it checks for those particular registry values. If they exist, Windows logs on with those credentials. It's as if a user typed the same credentials in themselves.

It's usually designed to be used in a kiosk style mode, with user accounts that have limited access to the network or local machine.

Is it secure? No. Your user password is stored in plain text in the registry. This was designed for kiosk-style systems for accounts with limited access.


Why wasn't the flame malware flagged by firewalls?

That's a very good question.  Will's answer is accurate as far as firewalls go.  Another part of the equation is why didn't any intrusion prevention systems (IDS/IPS) catch it?

My first-hand knowledge is limited to Cisco's IPS solution, but I'm sure most of them work similarly.  They can be configured to scan outgoing as well as incoming traffic, but they rely on signatures to profile and match traffic that are updated regularly, much like anti-virus definitions.  As long as Flame was an unknown threat, there were no signatures added to match against its traffic.  Now that it is known, I'm sure there are updates that will detect it.

There are some IPS/IDS products that claim to work "heuristically" and can catch "zero-day" or brand new exploits. Given the level of sophistication used by the Flame malware, I'm surmising that its creators simply bought samples of heuristic IPS systems and tuned the malware to avoid detection by testing it against real world gear.  It is pretty clear at this point that a national government with serious resources was involved so that sort of expense is not unlikely.


Custom Python Server - how to secure it?

How can I implement secure connection between client and my python server? I guess I could use SSH or SSL, but which one will be better suited for the job? And If I choose SSH then wouldn't it interfere with SSH login service I use to manage my (whole) server?

If it is only you that will be connecting to the server, I would secure the whole process using a VPN.

  Is opening multiple ports very insecure? What kind of attacks could it bring on me? How can I prevent them?

The ports are only as secure as the services listening on them. Opening multiple unneeded ports serve to increase the attack surface of your server, as there are many more points of failure possible. Disable all unused services on your server.

  Do you have any other tips regarding own server implementation?

Keep your server up to date. This involves running a command like sudo apt-get update && sudo apt-get dist-upgrade on Ubuntu-like distros or yum update on RHEL-based distros.

Have proper iptable rules configured. See this link for a good baseline. Configure as necessary.

Configure ssh to use key-based authentication instead of passwords. This helps to increase the difficulty of bruteforce attacks against the ssh service. Disable root login using ssh.


ASLR and how a program can actually call its functions

You do not call functions inside the kernel. The kernel resides in another privilege level; its memory pages are not accessible from normal code. To jump into kernel code, application code performs a system call which entails using a specific doorway which handles the temporary privilege escalation. On a 32-bit x86 system running Linux, this is done with int 0x80: a software-triggered interrupt. The system call parameters are provided by the caller in some specific CPU registers; in particular, the %eax register contains the symbolic identifier for the system call which the application wants to perform. The interruption handler (within the kernel) looks at the CPU registers to know what the application wants the kernel to do (whether the system call is granted is yet another issue).

There is no ASLR for system calls; this is not a relevant concept here. ASLR is for DLL. A DLL is a piece of application code which is loaded into the application address space and is accessible to the application under its normal privileges; in particular, the application code can "jump" into the DLL code with a normal "jump" opcode (a function call is nothing else than a glorified jump).

Since the actual address at which the DLL will be loaded is known only when the DLL is actually loaded, application code follows special conventions so that its jump opcodes can be dynamically adjusted to point to wherever the DLL happens to be loaded. This dynamic adjustment is performed by the dynamic linker. This linker uses relocation tables to perform its job: an entry in such a table describes an opcode which needs to be adjusted, and the name of the function which the opcode tries to reach. When the DLL is loaded (by the dynamic linker), the emplacement in memory of that function is known, and the jump opcodes described in the relocation tables are adjusted.

As you see, the whole concept of DLL allows for the DLL to be loaded at an arbitrary emplacement in RAM; that emplacement may differ upon successive executions of the application. The actual emplacement depends upon where there is a sufficiently large "hole" of free memory to do the loading, so it can change depending on what the application does, how much memory it allocates previously, and so on. DLL loading "naturally" implies non-fixed loading addresses. ASLR is just voluntary moving around of DLL: the dynamic linker chooses a random (free) loading address on purpose. This is (almost) completely transparent for the applications.


Why would someone upload many iptables files during a security breach and are they a cause for concern?

They obviously changed the rules to stop the hackers

Chain DENYIN  sole purpose is a blacklist of ip addresses.
Obviously, this list was derived from the log files as the sources of the attack.

Chain DENYOUT
Clearly is meant to log and drop outbound connections to the attacking list of IP addresses.  Just in case they are still in the system.

Chain INVALID
Is for packets that shouldn't occur on your network.

The rules look good, but as you said this is only part of your rules.  A hacker would not put rules in place to block themselves as that is self defeating.

Whoever wrote these rules knows something about security.  However, they should be using ipset in combination with IP tables for efficiency as excessive iptables rules use extra CPU cycles.  However, they were smart enough to divide the traffic into chains to at least make a bit easier on themselves.

Yet with an INPUT policy of drop, and making the last rule in INPUT drop just incase many of the other drops are un-necessary.  Except the last 3 log lines ALL of LOGDROPIN is redundant(538-555).

The fact that there are no subnets like (/30) or whatever would make it easy for a hacker to +1 their IP address and possible break in again.  Some IP you may not be able to subnet mask, but many of them you can.  If it turns out they used an amazon,google,microsoft cloud server, you can't block all of amazon,google,microsoft it doesn't make sense.

I am not auditing ALL your rules because I am not getting paid, however I have given you some good general info.  Don't post all of your rules, for me anyway, I am not doing a free audit of your whole system.


I think you're mistakenly recalling the movie.  In Citizenfour, Snowden warns the journalist on the risks of leaving a SD card unencrypted on his laptop with sensitive documents on it.  He never says that SD cards cannot be encrypted.  In fact, as the other answers point out, you can encrypt a SD card just like any other mass storage device.


No Client Hello w/ SNI when accessing website's subdomain via link

I see there are no Client Hello messages with the mail.yahoo.com name in the SNI extension field.

Every ClientHello in both pcaps you've provided has a server_name extension with the name of the target server. There is no connection with a ClientHello for mail.yahoo.com in the second pcap though which matches your description.

There are several other TLS connections though which are captured somewhere in the middle, i.e. without the TLS handshake and thus the ClientHello captured. For example the second TCP stream in the packet capture matches the IP address of mail.yahoo.com from your first packet capture. This indicates that it is using an already established TCP connection (with TLS on top).

Note that your first packet capture indicates that a connection to mail.yahoo.com is actually successful, i.e. it is not blocked as you claim (TCP connection number 6). The connection you see in the second packet capture might actually be the previously unblocked connection to mail.yahoo.com which you cannot block now since no new TCP+TLS connection was established and thus no new ClientHello was send. But it might also be a connection which had a different server_name in the ClientHello.

  Is the browser somehow using the same TLS session since the *.yahoo.com certificate is valid for both www.yahoo.com and mail.yahoo.com?

If the inner protocol is HTTP/2 the client is allowed to use an existing TCP connection to the same IP address provided that the certificate matches the authority part of the URL (i.e. the domain) too. See RFC 7540 section 9.1.1. This would explain that no new connection (with a new ClientHello) would be created and thus that your filter failed to detect and block the access. Thanks for HelpingHand to pointing to this standard.


What key does Linux use when storing user passwords?

The passwords aren't encrypted, they're hashed. It is mathematically impossible to derive the original password from the hash. Verification is done by hashing the password that the user enters and comparing it to the one in the vault. If they match, the user is authenticated and they can log in.


How is site-to-site VPN better than SSL + IP whitelisting?

While your assumption #1 is true, whitelisting your corporate IP means that anybody in your company can have access to that application, even though they might be blocked by the SSO.
Using a StS VPN helps here because you can use subnets and only allow people in specific subnets to have access to the application.

Also, if you have a corporate WiFi and a guest wifi, whitelisting your corporate IP would allow ... guests, to have access to that application.


Will Google block HMAC-SHA1 along with SHA1 signed certificates?

Due to the mathematics of how HMACs work, a weakness in the hash algorithm doesn't automatically mean that a HMAC based on it is also weak. This might seem counter-intuitive, but comes down to the fact that the known weakness in SHA1 relates to collisions, and can't be applied to a HMAC due to the construction method. In fact, even HMAC-MD5 is still fairly secure, even though MD5 is considered completely broken.

All this means that Google haven't made any indications of wanting to retire HMAC-SHA1 at the moment. They may want to in the future, especially if different forms of attack against SHA1 are found, but currently the only known way to break a HMAC-SHA1 is to brute force the key, which should, given a sensible key selection process, be really hard.


How does reuse attack protection (RAP) work?

RAP is very similar to a stack canary, except designed to prevent against ROP.

EDIT: After speaking to spender from grsecurity, it turns out that what I'm describing here is a subset of the RAP functionality, specifically the return pointer protection. RAP is actually callled "Reuse Attack Protector", which is designed to protect against all forms of indirect calls. The paper you linked describes some of the functionality within RAP, of which both the return pointer protection and ICFG features are a part of.

We can see the following assembly from the paper:

push %rbx
mov 8(%rsp),%rbx
xor %r12,%rbx
...
xor %r12,%rbx
cmp %rbx,8(%rsp)
jnz .error
pop %rbx
retn
.error:
ud2

The first block there sets up the RAP cookie:

; store the old value of rbx
push %rbx
; read the top value on the stack (the return pointer) and put it in rbx
mov 8(%rsp),%rbx
; xor rbx with a random value stored in r12
; rbx now contains the RAP canary
xor %r12,%rbx

Then, at the end of the function, before the ret:

; xor the RAP canary in rbx with the random value in r12
; this "decrypts" the stack pointer from the RAP canary
xor %r12,%rbx
; compare the top value on the stack (the return pointer)
; with the value decrypted from the RAP canary
cmp %rbx,8(%rsp)
; if the comparison fails, jump to error
jnz .error
; restore the original value of rbx
pop %rbx
; return
retn
.error:
; an error occured, quit the process
ud2

The idea behind ROP is that you would find instructions you want (gadgets) followed by a return instruction. This protection feature re-writes the functions so that the final instruction before each return is always a pop %rbx, and previous instructions are used to validate the RAP canary. This makes it really difficult to find ROP gadgets outside of non-aligned instructions (i.e. gadgets that just happen to exist due to the binary interpretation of instructions outside normal alignment).

The protection can be applied to both usermode and kernel. The cookie value (the value in %r12) is regenerated per task, per syscall, and per iteration in some infinite loops (e.g. event handlers and dispatch loops). The reason for the last one is that infinite loops often use a ret to break out of the loop. (this isn't quite correct).

EDIT: After discussing this more with spender, I'm going to suggest waiting for the explanation to come out. There's a lot of subtlety to how the feature works and I'm not sure I can accurately cover it from the paper and my brief discusson on IRC. Once it's out I'll re-update this answer to give you a better idea of what it does.


Most malware depends on both knowledge of the operating system and the (hardware) instruction set.  That is, most malware is written for a particular class of hardware running a particular operating system.  The instruction set of a typical mainframe, e.g. IBM zSeries, is quite different from the Intel x86 instruction set.  Although mainframes can and do run Linux, it is much more likely that they run the z/OS operating system or an older OS.  Mainframe programming skills at the OS level are relatively rare.  The small number of mainframes, compared to machines running Windows, MacOS, or Linux, means they're mostly let alone.  (The majority of malware comes from criminals, not "hackers" and the former are interested in maximizing profit.)

So, it's a combination of security by obscurity (instruction set and OS) and a smaller target space.  That means there is very little to adopt for more common server class machines.

Many of the things mainframes have "always" had, like privileged instructions and memory protection, were introduced to single-chip processors with the Intel 386; there isn't much more that such processors can borrow from mainframe hardware architecture.


What do algorithms `128000` and `256000` do in `sha3sum`?

... man page does not say.

It is not in the man page of sha3sum but in the documentation of the module:

Allowed values for $alg are 224, 256, 384, and 512 for the SHA3 algorithms; or 128000 and 256000 for SHAKE128 and SHAKE256, respectively.


How do a VPNs route SSL traffic and do they compromise security?

The VPN forwards data packets indiscriminately. When you do SSL with Gmail's server, then the SSL connection actually consists of data "records" (described in the SSL/TLS standard) which are sent over a TCP connection between your machine and Gmail's server. That TCP connection, in turn, is embodied as a lot of individual IP packets.

With a VPN, all the IP packets that you emit go to the VPN server; and all IP packets which are sent back by Gmail's server go to the VPN server. The VPN server forwards these IP packets by encoding them into the tunnel that it maintains with your machine. So the IP packets (that encode a TCP connection that contains the SSL connection with Gmail's server) are encoded into the tunnel and thus encrypted again. There are two nested layers of encryption, the SSL connection between your machine and Gmail's server, and above that the connection (which may be some SSL, too) between your machine and the VPN server. The VPN server removes and adds the external layer, but the internal layer remains opaque to that server.

The VPN server is, generally speaking, in an ideal position to run a MitM attack on you, since it controls all the data which enters and exits your machine; but the SSL layer (the one between your machine and Gmail's server) protects you against all attackers on the path between your machine and Gmail's server, and that includes the VPN server.


Vulnerabilities and Threats to Non Web Based Windows Applications

As Sachin Kumar pointed out, you should probably start doing some Threat Modelling. The leading resource in this respect is the Microsoft Security Development Lifecycle book/resource. This does not mean this only applies to Microsoft environments or software. In fact, it is a very generic methodology which works pretty well for any kind of application. The Threat Modelling Tool itself isn't really necessary. It just helps putting the data together. I find it easier to just use pen and paper though, unless it's an extremely complex setup.

The idea (extremely briefly) behind this methodology, is to first of all map out the Data Flows, using a DFD (Data Flow Diagram), and then apply the STRIDE classification of threats for each component of the DFD. Once you did that, and really thought about each potential threat carefully, it should already give you a pretty good idea what the main problems are and could help you focus on what to look for. You can also use DREAD to rate those issues in terms of priority/risk. Although if you have some experience you would know the rating almost instinctively. DREAD is a bit too detailed for most cases anyway.

Actually testing for real vulnerabilities or issues can be the next step, but it depends on the environment and the skill-set involved in actually performing it. Another approach that can give you a lot of added value is doing some security code review (if you have access to the code). Or if you have some security static code analysis tools, those can help a lot too.


Sending encrypted file and password by email

Ignoring the fact that most data is stolen at the nodes rather than in transit, your thinking isn't really quite right about how networks work, and how attackers think about traffic interception.  Networks aren't just random points on a grid where a different path is chosen all the time.  They're organized in a fashion where there's often going to be common points where interception is possible.  This is where an attacker wants to insert him/her/itself.

Consider how the NSA behaves.  The NSA tries to insert itself into these key points.  You can clearly see this on one of the Snowden leaked slides:  The point being, you don't have to "get lucky" and choose the right path, on the right day when you've inserted yourself into a choke point on the cloud.

Also, consider that attackers make "active attacks" and try to redirect traffic rather than sitting passively and hoping traffic will come their way.  Simple examples of this are ARP poisoning and DNS poisoning.  More sophisticated examples are the NSAs "Quantum Insert" project.


What are some possible ways of sending anonymous request to re-crawl to Google?

Simplest is to use any VPN or SOCKS proxy.

When you submit your recrawl request (or pretty much any request) via a VPN/proxy:

The end service (Google) only sees the VPN/proxy's IP address, not your real IP
The proxy/mediator can't see the data (URL) you submitted, because your connection to the end service (Google) is encrypted using public key cryptography (TLS)
Your only concern is to ensure your browser doesn't send cookies (or similar tracking identifiers) when connecting to the end service (Google). This can be done by using a new browser profile.

The only "weakness" here is that since this is a low latency, real time request, it's possible for a sufficiently advanced attacker that can monitor all of the VPN/proxy server's internet link but have not compromised the VPN/proxy server itself to do traffic analysis to see that there is an outgoing request to the end service shortly after your packets arrives to the intermediary server.

To protect against traffic analysis, you'll need a high latency/store-and-forward system. The stereotypical store-and-forward protocol is email. It is possible for the intermediary server to run an email server, you send an email to the intermediary, which stores the email for a random amount of time, and then forwards the mail/request to the end service at that timeout, possibly batching the requests. To ensure privacy of the URL against the intermediary's email server, you can GPG encrypt the email to a GPG key held by the end service.


Is Certificate pinning different from CA pinning?

The generic processing of a certificate goes thus:

The client builds a certificate chain going from a trust anchor (a given certificate which is known a priori by the client) down to the server's certificate.
The client verifies that all signatures and other information are correct along the chain (each certificate has a subject and an issuer names: its issuer name must be equal to the subject name of the previous certificates; each certificate is signed and the signature must match the public key from the previous certificate; and so on).
The client checks that the expected server name (the one from the https:// URL) appears where it should in the server's certificate.

Certificate pinning is equivalent to turning the server's certificate into a trust anchor with limited scope: the client stores the server's certificate, and will used it as the trust anchor when validating the server's certificate again. In the description above, this means that when coming back to the server, the client will build a chain of length 1, containing only the server's certificate itself, which the client "trusts" in that context because it remembers it exactly.

Certificate pinning can be inclusive or exclusive; the former means that the client will accept the remembered server's certificate as a trust anchor in addition to its other, "normal" trust anchors (its "root certificates"), while the latter means that the client will use only the pinned certificate as trust anchor. The overall effect of exclusive certificate pinning is that the client will accept the server's certificate only if it is bit-to-bit equal to the one it remembers; no other certificate would be deemed acceptable.

Usually, when people talk about pinning, they mean exclusive pinning.

CA pinning is the same process higher in the chain. The client remembers a CA certificate (which may be an "intermediate" CA) as a trust anchor. There again, this can be inclusive or exclusive. Exclusive CA pinning means that the browser will validate the server's certificate against that CA as unique trust anchor; the certificate will be accepted only if a chain can be built coming from that specific CA, and none other.

The important points above are the following:

The client remembers a certificate from the server's certificate chain.
The client complains loudly if the actual server's certificate (upon an ulterior connection) does not match what was remembered (subject possibly to some heuristics to smooth out normal renewals).
This process is site-specific: this is the main departure of pinning from the usual "root CA store" model. What the client remembers and requires is for a specific target site. The remembered certificate (CA or not) is not general for all sites, but only for one.


Monitoring access logs of Web application

Use OSSEC (http://www.ossec.net/) for log analysis & real-time alerting,
use logwatch (http://sourceforge.net/projects/logwatch/) for log analysis & report creation OR combine those two approaches: http://www.chrisbrenton.org/2010/02/combining-logwatch-and-ossec/


Is it possible to redirect https to http in modern browsers?

What happens if the browser requests https://example.com, but example.com has never had a valid SSL certificate? Will the browser automatically redirect to the http:// version?

No. Modern browsers don't downgrade to plain HTTP autonomously. If a certificate is invalid, the user will simply see a certificate warning (and eventually an option to add an exception).

  If so then an evil proxy operator should be able to simulate that response, right?

If browsers did redirect to plain HTTP when seeing an invalid certificate, a MITM could silently downgrade any new secure connection by modifying the transmitted certificate details. That would be a major security problem. That's why, as long as you use HTTPS right from the beginning, a MITM can't redirect you anywhere.

Rather, what an attacker can do is try to intercept a plain HTTP response before the connection is upgraded to HTTPS. E.g., if you type in mybank.com, your browser doesn't know if the site provides HTTPS yet and tries http://mybank.com first. Even if this HTTP site immediately responds with a redirect to https://mybank.com, a MITM could already intercept the response and remove the redirect to keep you on plain HTTP. (The HTTP Strict Transport Security (HSTS) feature prevents this exact attack by instructing your browser to always visit the site over HTTPS and reject all attempts to use plain HTTP.)


By looking at A= "Tg==" and B= "Tw==" and base 64 decode these values you'll get A= "N" and B= "O" which triggered me as it looks like some sort of substitution.

In your case they used double encoding because as it turned out, it is ROT13, which actually stands for ROTate 13 times:

Now in order to decode your message, you'll first have to base 64 decode the encoded string and then decode the result from ROT13.

ROT13 Decoder: http://rot13-encoder-decoder.waraxe.us/


Javascript client side image decryption, does this add any safety or is it flawed

it DOES potentially add security in that the private key is not on the web facing server. Since that server is Internet-facing 24x7 it has a VERY large attack potential.

It does assume however that the administrator PC is well secured & this may not be the reality. The use of a removable secure store such as a smart card is potentially better as indicated by you - assuming the store is kept secure ;)

The copy on the web server will be as secure as the method used to encrypt the data. Assuming best practice, that should be pretty good though if an attacker got the whole database and if that contained many thousands of entries all encrypted with the same key, the security would be weakened. Salting and multi-pass encryption would probably help with that.

However, there is an even stronger and potentially simpler way of security the data. It depends on how you are using the image though. You could simply not store the image on the web server! In a typical enterprise setup, you would keep a secure data server inside your network (whereas the web server would be in the DMZ). The secure data server would periodically take the data from the web server and delete the image on the web server. Combined with a sensible encryption process similar to the one outlined but where the private key was kept on the internal network, possibly in a security accelerator card for ultimate security, this would get rid of the need for administrator intervention and would keep the sensitive data out of view.


Securing server to server http communication

Use IPSec to create a secure VLAN. Better performance than HTTPS and more secure(no payload is in plaintext anymore). You can use your own PKI infrastructure and with some custom code you can integrate strongswan easily in your systems; it provides hooks for nearly every stage of the connection. Plus you also get client authentication (machine certificates).


Can a system administrator see if someone is using a VPN?

Yes, VPN traffic is easily distinguishable on the network, and yes, it can also be easily blocked if the admins care for some reason. So, "a friend of yours" shouldn't really do it to circumvent IT policies. :)


I have an open source App that installs firewall rules, but should your firewall rules remain secret?

If knowing your firewall rules helps a hacker, then not publishing them is only security through obscurity.

Just like the rest of your code, if your firewalls are configured securely, knowing the exact configuration is irrelevant. On the other hand, if it is not configured correctly, then there is no real security to prevent exploitation.

On the plus side to open-sourcing your rules, others can inspect them and verify they are correctly if it concerns them.


I believe this question is best addressed in chapter 4 of The Art of Software Security Assessment, a book by Mark Dowd, Justin Schuh, and John McDonald.

Without it as a reference, I can safely tell you that the best method is using runtime data along with source-code while determining "hits" (or traces, aka coverage) using black-box testing -- but only after a threat-model and general architecture of the system is well-known.

The authors also appear to like secure static code analysis when combined with candidate-point strategies, although it's my opinion that these can vary wildly in value assuming the following are not true:

The language, and its base class libraries, must be supported by the secure static analysis tool
The entire system must usually be available. I.e. it must include buildable source code including all third-party/contrib components and external libraries -- possibly even to include the system compiler, VM, or other artifacts of the original system
All external components/libraries that are not a part of the base class libraries must have sources and sinks defined in the secure static analysis tool's source-sink-passthru database. The intricacies of some passthrus (i.e. filters) can vary by implementation or implementer, and thus almost always require custom configuration
Additional use of certain patterns or architectural code elements could cause other variations, which could require customization that isn't possible with most modern secure static analysis tools

For the reasons above, as well as the reasons put forth in the NIST SATE studies (done by NIST SAMATE), I find it difficult to recommend many secure static analysis tools for use in white box analysis. It is almost always simply better to use code comprehension strategies that most likely involve reading the source code from top to bottom, which is really very important if you are looking for managed code rootkits and the like.

Instead of testing and auditing/assessing applications, I would take a different approach that is largely very technology-agnostic. My suggestion would be to implement an application security risk management portal that includes an app inventory along with each app's currently implemented application security controls. After an initial baseline, the application security controls should be evaluated against industry standards such as MITRE CWE, SAFEcode, and OWASP ASVS. A gap analysis (note that this is a standard risk management term and works best when implemented in an information security management program based on ISO 27001 or similar) can then be used to determine the optimal application security controls, as well as a path to get from the currently implemented controls to the required ones.

You should implement this risk management portal before performing risk assessment activity such as white-box or black-box testing in order to get better results, and to measure the success of your program.


Preventing millions of requests to Amazon s3 bucket

About deleting the bucket - you're right, if someone else creates the bucket with the same name it will get all your traffic.
As you don't want to delete the bucket to prevent abuse - I think it is best to open the ticket with them and see their stance on that. If they care, great - they will find a solution, if they don't - why should you pay for their ignorance ?
In my dealings with their support regarding (other) security/abuse related topics they actually were quite responsive and helping.


Does it really matter if I use the same password for all my most important sites, including banking?

If, as you say, your password storage is decipherable only by you, I'd say it is good-enough encryption for you - in the sense that it serves the purpose.

However, using unique, complex and long passwords is not only for the purpose of someone stealing them from you. Your strategy works only if you reconcile to risks like these:

One of the websites you use is hacked - and they crack your password due to a weakness in their password storage scheme (or a weakness in your password).
The hackers then attempt reusing this password on other sites and succeed.

I don't know the why you're reluctant to use Password Managers. As Troy Hunt says "Password Managers don't have to be perfect, they just have to be better than not having one".

As an Infosec pro, I'm paranoid and skeptic (don't easily trust even reputed vendors). I use an open source password manager KeePassX. I try to stay aware of the residual risks, compensate with "constant vigilance" (thank you, Alastor Moody) where possible and accept the risks where it's not.

Of course, your needs might be different.


I'll supplement @schoeder's answer with some technical details.

My understanding of your situation is that you have servers applications like this:

intranet.xyz.abc.com
documents.xyz.abc.com
applications.xyz.abc.com
...

and your partner also has some applications running on the same server:

partner1.xyz.abc.com
partner2.xyz.abc.com

All of the above are internal-facing (not accessible from the internet). Now, the partner was too lazy to make individual certs for each of their IIS applications, so they made and installed a global a cert for:

*.xyz.abc.com

Cool. That covers all of their applications. But it also covers all of yours. Assuming they have access to the private key that belongs to this wildcard cert, then they can Man-in-the-Middle your intranet or documents servers and read all the traffic.

Also, if your company has (or a malicious admin with your partner decides to stand up) any public-facing websites that match the wildcard, for example:

www.xyz.abc.com

then, since it's a private internal CA, the general public would not be fooled by their spoof, but any of your employees connecting from internally (with that CA installed into their OS) would trust the spoofed version of www.xyz.abc.com.

As @schroeder points out, the potential for insider-threat here is huge.


How does a Registrar/Domain Lock increase security?

Domain locking is meant reduce domain hijacking. That said, it is not clear that all implementations provide protection. Especially being that many domain hijacking attacks occur via social engineering targeted to the support personnel of registrars.


Are there problems with reusing strong passwords for private gpg keys

Generally, in terms of security, reusing passwords is not a good idea.

Mind that the revocation is not the only problem if you get compromised. An attacker with access to your previously encrypted messages, by having the key and password, is gonna be able to decrypt them. So, having different passwords makes the attacker's job harder.

Also, making this setup (keeping the keys in the same machines) is not necessarily a good idea. If you can avoid having one of your keys in a machine, do it. Make your attack surface as smaller as possible.


Making it harder to scan on-screen QR-code from a distance

A decent camera like that one, with some adequate zooming length, will get from 20 meters away a snapshot of your screen with a lot more detail and precision than your own smartphone's camera. By "obscuring" the QR code, you will make the scanning harder and then impossible sooner for your smartphone than for the attacker. Thus, this "obscuring" thing won't work against a decent attacker (it will work only against cheap attackers who also have only smartphones).

Longer range eavesdropping can be done with bigger but still off-the-shelf hardware, such as this one. Its aperture should allow for picture precision down to 1 mm (i.e. sufficiently low to scan the QR code, even "noised out") from 500 meters away.

Also, remember that QR codes are optimized for easy reconstruction in a fraction of a second by a smartphone. The encoding is ripe with error-correcting codes so that scanning works even in noisy environments. This helps both your phone and the attacker. But the attacker can spend more time cleaning up the picture with Photoshop, allowing him to obtain the data from a picture which would be too blurred for a generic smartphone to handle.

A better way would be to block the view of the screen from the attacker. The "blanket" method would work. If you want to improve things, I suggest that you modify the QR-displaying system so that it shows a blank square most of the time, displaying the actual QR code only when you strike a specific key on your laptop keyboard, and for only three seconds. That way, you can keep the critical phase (during which the QR code is actually visible) short.

Not performing sensitive operations in locations where there are roaming shoulder surfers might be a good idea after all.


What secure RFID standards are there; for high value item inventory?

I've done work with class 1 gen 2 UHF tags in the past that regulated read/writes to memory with a password. Not sure how well (if) they protect against e.g. brute force but the understanding around our shop was that they're reasonably secure against tampering/cloning (although I'm not sure TIDs are as difficult to spoof as some would like to believe).

Like most everything though it depends greatly on your particular threat model.


Do I need to revoke both my OpenPGP primary key and subkey?

Revoking the primary key is sufficient. OpenPGP clients will refuse to use subkeys of revoked primary keys. Revoking primary and subkeys is different: primary key revocations are special self-certifications (self-signatures) containing revocation information, while subkey revocations are issued by the primary key they belong to.

Using GnuPG, it is not possible to generate a revocation certificate for subkeys anyway. From man gpg:

--gen-revoke name

   Generate a revocation certificate for the complete key. To revoke a
   subkey or a signature, use the --edit command.


How can DH provide a known secret to two parties over an unencrypted connection without it being intercepted via MITM?

Here's Diffie-Hellman for a student - a five year old does not understand logarithms ;-)

DH uses two ideas:

exponentation is fast (2 to the power 3 equals 8) but the reverse process (an exact logarithm) is very time-consuming to do. In reality we take large numbers, but for the sake of explanation small numbers here.
exponentation is commutative, i.e. 2 to the power 3 to the power 4 is the same as 2 to the power 4 to the power 3

Say that we want to communicate. We agree upon the base number A that we're going to raise to a certain power. And that doesn't have to be private. We just send A to each other.

Now I choose a big random number for my B. You choose, separately, your own big random number, which we'll call your B. And we both raise this agreed-upon number to that big power. Now, we send that intermediate result to each other. And now I take your intermediate result and raise that to my big power. You take my intermediate result and raise that to your big power. We both end up with the same answer.

A MITM sees A and both of our intermediate results going by, but he can't do the reverse process in reasonable time.

He can't figure out what our powers were that we made up. So we end up being able to choose random numbers, use those to raise a common value to that power, exchange those results, do it again, and we both end up with exactly the same value, which we can then use as a key.

In reality, there are some other requirements to A other than being big (e.g. it has to be prime).

Credit: Answer based on the transcipt of Security Now Episode 34


Is deleting LUKS keys during operation a good way to protect my data?

Would your solution be more secure than choosing a really long password?

That depends on the size of the passphrase.

The luks header contains a certain-sized key and iv.II don't know the sizes in bits of those two without looking them up, but lets assume that together they are 512 bits long.

If you overwrite the luks header, in order to decrypt the partition, you need to correctly guess these 512 bits. This is currently impossible to do in a useful amount of time (think anytime before the sun explodes...)

If you assume luks doesn't do any key stretching (which it does), you need a random passphrase of 64 characters to match this. You can easily produce such a key:

$ dd if=/dev/random of=my-key bs=64 count=1

You can even pass in such a key directly while creating a luks partition. This is how encrypted swap works on linux. The swap partition gets reinitialized with a new random key every time the system boots, so the old swap contents are securely destroyed.

For your system, you could make it easier to handle by storing the luks key in memory (or /dev/shm). When the system unexpectedly shuts down, the partition is lost. when you want to reboot, you store the key to disk (or export it over the network) and open the luks container using the stored key after reboot. Then you replace the key with a new key, which you again only keep in memory.

This way, you won't lose the data on scheduled shutdowns.


How do shared hosts protect different sites?

With the setup you've proposed there, yes.  The only solution here is something like suPHP.  If his website runs as the same user as your website, there is nothing that you can do to protect yourself.  You need to set his website up as a different user, and ensure permissions on all the files are tight (0700 ideally).


Why do some websites force users to come up with difficult passwords?

When a site implements something, it is always to serve their interests; however, this sometimes coincides with serving the user's interests as well, e.g. as in "protecting the users against themselves", which is the case here.

The point of the restrictions is to (try to) make the password harder to guess by an attacker. Truly, preventing some users from using some specific password values mathematically reduces the number of possible passwords; but, practically, this is more about forbidding the easy passwords that users would almost always choose if they had the choice. The total number of possible passwords is ludicrously large. If we consider that a password may include letters (lowercase and uppercase), digits, and, say, some punctuation signs which are accessible from a common keyboard; and if we allow passwords to go up to 30 characters in length, then the number of possible passwords is equal to 157935773974908502215194845377591539584935386309545795005451 (including the "empty password" of length 0; otherwise, subtract 1 to that count). Possible passwords are not a scarce resource, and there is little problem in removing a few billions from that count.

The scare resource is user imagination and patience. Given the possibility, most users will use short passwords with only lowercase letters, because that's what most easy to remember and type. And they will pick "meaningful" words, e.g. "castle" and not "bsigrz". The attacker knows that: easy passwords are the first that he will try, and there are not many of them, so the attacker will succeed.

The "password rules" are an attempt to force users away from the easy passwords. If you force them to include a digit and an uppercase letter, they will do so, but with a digit that the attacker cannot predict, and with the uppercaseness applied to a random letter. (At least theoretically; in practice, users will put the uppercase on the first letter, and the digit will be added at the end, and will be a '1'). The fervent hope is that this will increase the number of possible passwords that user will effectively choose, and thus make things harder for the attacker.

Password rules may backfire, sometimes spectacularly; users will forget their password and nag the helpdesk; users will write the password on a stick-up note cunningly concealed under the keyboard. (As far as backfiring goes, writing a complex password on a piece of paper stored in the user's wallet is not that bad: at least, users care about the whereabouts of their wallet.) One very common instance of backfiring is, exactly, having a "usual" password which the user uses with many sites. This means that a security breach on one site immediately extends to all other sites on which the user also has an account. That's Bad.


Are these both cross frame scripting attacks?

Though this being an old question, I'm adding an answer for future viewers.

"Cross-Frame Scripting" is basically data leakage that can happen when an attacker embeds a victim's website into a frame within their own website and monitor/spy on the activities does on the framed website. An attacker can register a JavaScript listener which listens to all key events on the page. The spying is possible because, the (buggy) browser notifies the listener of key events even from the framed victim's webpage. Thus, the attacker can embed the victim's login page in their website (in an iframe) and thus obtain the login credentials of an innocent victim.

"Cross-Site Scripting", on the other hand is actually more of a forced JavaScript execution where an attacker injects/reflects malicious JavaScript which is then executed on the client's browser.

XFS prevention revolves around frame-busting or adding x-frame-options in HTTP headers, equal to either DENY (informing the browser to never frame the website) or sameorigin (frame only if in the same context).
XSS prevention, however, is more concerned with input sanitization.

That being said, in the scenario you described, the first case is an example of an XFS attack, while the latter can be considered as an example of an XSS attack involving frames.


Essentially ret2libc is somewhat a ROP exploit, since you create a new stackframe to call the system function by returning to the libc library and circumventing a non-executable stack.

A ROP in general works similar, you jump to fragments of code (called gadgets) that return at some point and "build" yourself the code you want to execute by combining those fragments. You literally program the code you want to execute, creating new routines that were not in the code before. ret2libc utilizes the system function to get a shell.


Docker: when to use apparmor vs seccomp vs --cap-drop

You can use all of them.
Each of these security features have different purposes, and there is actually little overlap. They all function to reduce the damage that a process can cause once it has been compromised. They are all very low-overhead and can be used to significantly improve the security of software.
Seccomp is a Linux feature that allows a userspace program to set up syscall filters. These filters specify which system calls are permitted, and what arguments they are permitted to have. It is a very low-level filter that reduces the attack surface area of the kernel. For example, a bug in keyctl() that allows simple calls to that syscall to elevate privileges would not necessarily be usable for privesc in a program which has restricted access to that call.
AppArmor is a Mandatory Access Control framework that functions as an LSM (Linux Security Module). It is used to whitelist or blacklist a subject's (program's) access to an object (file, path, etc.). AppArmor may be used to allow a program to have read access to /etc/passwd, but not /etc/shadow. The policies can also be used to restrict capabilities, or even limit network access.
Capabilities and capability dropping is a general technique whereby a privileged process revokes a subset of the privileges it is endowed with. A root process can drop, for example, the capabilities required to create raw connections to the network, or the capabilities required to bypass standard UNIX file permissions (DAC), even though it remains root. This technique is not very fine-grained as there are only a limited number of capabilities that can be dropped, but it reduces the damage a program can do if it has been compromised nonetheless.
In general, you should know that:

Seccomp reduces the chance that a kernel vulnerability will be successfully exploited.

AppArmor prevents an application from accessing files it should not access.

Capability dropping reduces the damage a compromised privileged process can do.

See also How is Sandboxing implemented?


Is there *ANY* conceptual downside to enabling preloaded HSTS on greenfield

The reason to be careful with preload is the case for when you think all your sites have converted to HTTPS, but then it turns out marketing uses some CRM from 2005 that still runs over HTTP. When you turn on HSTS with includeSubdomains, their tool will no longer work.

If you have a new domain you still have total control over it, and it is unlikely that you break some HTTP site by preloading HSTS. So in your case, I think it is acceptable to preload HSTS from the start.


Is it reasonable to block Cookies company-wide?

You can use black lists of tracker or advertisement websites (from ad-block software) to filter cookies that you can safely remove. You should leave legitimate cookies because you should not hinder your users in their work without a really good reason.

However, you can change default settings in the browsers to keep cookies until the browsers are closed. This will allow users to change the setting on the website that matters. You should document this change of policy and communicate it to your users before applying it.


In the old days, if you were a big company with multiple private local networks in multiple locations, you connected them together by installing private data lines between the various locations to make a Wide-Area Network. Then the Internet came along, and you also had to connect each site to the Internet.

It turns out that Internet feeds are much, much cheaper than private lines are, so inevitably people began asking "why can't I just connect these sites together with the Internet, and save money?"

The answer, of course, is that the Internet is a public network, so you don't want to send confidential company data over it. You could modify all your systems encrypt their data when they talk to each other but that is likely to be complicated and expensive.

One solution was a technology called VPN. You tell each computer in the New York office that if it has anything for a computer in the London office that it should send it via a VPN gateway. The gateway is a machine connected to both the New York private local network, and to the public Internet. When it receive data for London it encrypts it and sends it over the Internet to another VPN gateway. The second gateway is connected to the public Internet and to the London private network, and when it receives the data from New York it decrypts it and drops it into the London network. The same thing happens to data going from London to New York, and if you open a Tokyo office you just install a third gateway and tell them about each other.

In this way, the machines in New York and London can talk to each other, but while the data is travelling over the public network it is encrypted and safe. You don't have to change anything about the machines that are talking, you just have configure your network routing tables, so everything works as if you had the expensive private WAN link.

This is Site-to-Site VPN. This idea was developed into Remote Access VPN.

An employee at home or travelling can connect their computer to the Internet and run a piece of software called a VPN client. When their computer has data to send to the New York office, the VPN client intercepts it, encrypts it, and sends it to the New York VPN gateway, which decrypts and drops the data into the New York network. In this way, the employee is able to safely access machines on the private New York network from anywhere they can get an Internet connection.

A further development has arisen more recently, called VPN as a Service.

Sometimes a person has data that they are OK to send over the Internet in general, but their local connection to the Internet is one that they specifically don't trust. Maybe they are in a sleazy Internet cafe and don't trust the owner, or they suspect the government has ordered their ISP to spy on them.

They can work around this problem by signing up with a VPN service provider. This works in the same way as the Remote Access VPN, with a local client installed on their machine encrypting data and sending it to a VPN gateway at the service provider. However, instead of accessing a private network, the service provider decrypts your packets and sends them out to the Internet over their connection, which you trust.

(This is why VPN service providers make a big deal of not logging traffic; if you suspect the Government has a warrant for your ISP, then they might also get a warrant for your VPN provider, so you want them to keep as little information about you as possible.)


Digital Certificate Repository Integrity

Short of asking the Certificate Authorities yourself (preferably with a secondary list of valid CRL and or OCSP download URL's lists) one by one I know none.
You could script that, or you could recreate the Repository and create a hash of it. Also checking if the checksums are valid can give you a clue (although it does not show a replaced certificate / added certificate)

TL;DR none that are fast & easy. only hand checking is available.


What is the security/copy protection model for streaming media services?

If you can see or hear it, then you can record it. Even without messing with the obfuscation/encryption, it is trivial to copy the content, just start a screen recording program and enjoy.

I doubt cryptography is ever involved, it's mostly a matter of obfuscation; if the attacker can break the obfuscation and reverse engineer their player applet, then they will do the same to get the key if crypto is involved, so why bother ?

Content providers used to use some garbage called Flash to create an applet capable of talking to their server over RTMP and get the video stream from there. Note that the video is only streamed, never downloaded to disk, so the only place the decrypted/deobfuscated frames ever exist is in the computer's memory for a short period of time; that limits the "exposure" to a level they deem acceptable (or rather, a level Hollywood is forced to accept because it's either that or not selling their movies on the Internet at all).

Now content providers are aware of the decline of Flash's popularity and are starting to use HTML5 Encrypted Media Extensions, a plugin interface allowing a browser to communicate with the site's proprietary and obfuscated software that will be decrypting/deobfuscating the video frames before sending them back to the browser's media player which would play them; essentially the same thing as Flash except the proprietary applet now only does decryption instead of being the actual video player.

In the end, there is no way to prevent saving the content, so providers are trying to limit the damage :

first off, it's quite hard and time consuming (but never impossible) to reverse engineer the Flash or EME applet and most people won't bother, they will either accept the restrictions or go somewhere else (unfortunately what they don't understand is that "somewhere else" also means "some pirate site" and they're loosing even more money by not letting honest users save the content they bought)
the content isn't downloaded in advance but streamed in real time, this allows some control over how much content can potentially be saved, as their server won't accept to stream more than one file (or a few if they're lenient) simultaneously per account, which means the pirates wouldn't be too efficient at ripping content from the site and will look for other sources, ie. physical DVDs or Blu-Ray discs which are rippable more efficiently and as a bonus offer more quality than streaming, so web-rips (as they call them) are often done only for content not yet available on physical media, as a way for pirate teams to be more popular by leaking the content before it's physically released


A security administrator shouldn't need to have any access to any system within a production environment and certainly not any administrative access. Their function needs to be logically separate and independent to the roles of those users who perform administrative functions.

A security administrator should be able to run vulnerability scans, have access to review patching levels, anti-virus configuration, standard configuration information, review security logs etc. Each of these should be available through the production of reports from management systems or through application interfaces which can be presented to that user.


Without more details about your suggested options only more general advice can be provided.

With regards to encrypting files (assuming it is the data of the received email communication), certain malware might be prevented from reading and maliciously modify the data, much less from deleting the data altogether (something that also LSerni comment hinted on).
Consider that efficient malware would strive to gain (or already have) access to the memory of your application , including the key used for encrypting the data. With encryption you might only protect against malware running as unprivileged (non-root/non-admin/non-ring0) code.

With regards to the virtualization sandbox, which sadly is not a very explicit thing to discuss much about, I would state that again this could prevent some sort of malware interaction, only under the condition that the malware again is not running in a privileged code. Frankly it is mostly the way that virtualization is a technology with merits as to contain (restrict/limit) malware, as is the concept of a sandbox. To my knowledge sandboxes are not the method of choice to prevent a program from attacks (by malware), but sandboxes are rather the tool to prevent potential malware to attack legitimate programs/data/systems.

Anyway it seems that a reason to employ either method (encryption/sandbox) would be to protect your email-client-users from receiving malware from the emails, in which case your software (email client) is the vector, in which case it seems that a sandbox might -imho- be much more effective (when well designed) to protect the host system, then the encryption of emails.

TL;DR

both options, encryption and virtualization, cannot reasonably protect you against bad malware (rootkit, ring 0).
a sandbox (well designed) might be a more effective tool to secure the host system from your email-client (and the emails), then encryption.


Best practice to secure hard-drive in case of theft or loss or unauthorized access?

The best solution for protection of the contents of a fixed storage medium is to use a password-based full-disk encryption system with a strong password. Windows 10 Pro and Enterprise come with BitLocker, which can be configured in such a mode. Third-party products are also available to accomplish the same task.

Many of these products provide an automatic unlock feature. While this is more convenient, it can also be a vulnerability. Essentially, this feature sets up a chip on the motherboard so that the hard drive can be unlocked without typing a password as long as it is in the same computer.

Since you're concerned about the whole computer being stolen, automatic unlock might defeat the protection that the encryption provides in that case. However, the thief would still probably have to get past the Windows password, because they wouldn't be able to get at the drive without booting into Windows.


What are the risks and benefits of engaging with hackers?

Hacking your server and profiting from it is the cybercriminal's job. Their "job" is unregulated, risky, unstable, without any guarantees, highly competitive, in an environment where they need to be faster than their opponents (not only other criminals, but also sysadmins, antivirus vendors, etc.) and they need to exploit every opportunity they have before it's too late. You are a stranger to them, and you are an opportunity. Why should they help you? They need to make money from you, not lose time and money because of you. That's why you can't expect anything from cybercriminals, and engaging with them will be very dangerous. The only thing you can expect from cybercriminals is other exploit attempts, so engaging with them is only useful for investigation or research purposes (and only professionals and investigators should take these risks).

The only hackers you can expect to help you are ethical hackers. The problem is though: how do you distinguish an ethical hacker from a cybercriminal, or even from a gray-hat hacker? Sometimes it's hard to know what is running through a hacker's mind. Unless you have enough experience and you know what you are doing, if you need help with cybersecurity the safest option is to contact a cybersecurity professional.


How to start with an Information Security Program?

I'll give it a shot.

In a nutshell, the language is CYA in case you get breached or hacked and have access to their data, they can tell their customers "Acme said they had a security program and was protected so this is their fault".

In that case if you end up being the cause of them losing data, they can blame you.

That being said, its pretty standard contract language when companies are partnering or sharing data.  Mostly its a "Due Diligence" type artifact.

Regarding your questions:

  Can someone please translate the above quote into common English?

Basically you need to have documented security policies/procedures.  Within those documents you should state what you do to maintain systems and ensure that adequate security is provided.  You should also try and address actual procedures that touch on security related subjects (access control, auditing, monitoring, incident response, etc.).  You may already cover some of this in your normal Standard Operating Procedures (SOP) and you can reference those documents.   When you create a new user or change groups/roles, are there written procedures for how to to it?  Is there someone who approves that change?  Those are the kinds of things that should be addressed.  When they aren't written down, people don't have references for how to do them and they take liberties which may introduce security vulnerabilities.

  I read something about annual certification, would it be ok to say that our company should make use of a third party security auditor and let them tell us what we should do?

This is the route a lot of organizations take, but security is definitely not something that should be reviewed "annually". It is an ongoing, forever process that should be integrated into your daily operations. That being said, a third party group can perform an "audit" that serves as your annual certification.  The result of that will be a report that you can used to fix deficiencies and enhance your security posture.  Highly recommend this, no matter how mature your security program is.  The first few times you go through it, use different vendors so that you can compare the results.  The quality of these types of assessments varies GREATLY.

  Who within our organisation would typically be responsible for implementing an Information Security Program?

They go by many names, but the ultimate responsibility of security will lie with the system owner.  That could be your CEO, the program manager, or in larger organizations an ISSO or Information System Security Officer.  In smaller organizations, it usually falls to a Product or IT Manager.  Hiring a consultant to help start this process may be a good idea at this stage.  You're only going to see these requirements more often as you start working/partnering with large enterprises.

  I am thinking about recommending to buy ISO27001, but who should read it? (related to the previous question)

What exactly are you considering buying?  ISO27001 is a security compliance framework that provides a direction for securing your assets/enterprise and as far as I know you shouldn't have to pay for anything upfront unless its a service or product.  Choosing a compliance framework to base your program off of is a great first step in establishing a security program.  I would personally recommend ISO or NIST as they are large international/national standards and have a lot of overlap with other compliance frameworks (PCI, HIPAA, etc.).  That being said, I have no idea what your goals are so you'll have to do some research and choose what's best for your organization.

I've written a lot of documentation and done a lot of security control testing so I may be opinionated at this point, but if you have additional questions, feel free to PM me.  Good luck!


Email security between Outlook and Exchange 365

You cannot guarantee that emails sent outside of the control of your email provider are sent encrypted. That's up to the receiving email server.

So, no, there is zero trust that anything you send will be encrypted end-to-end (that's why we have all these end-to-end encrypted IM platforms).

Transfering files to a server over TLS offers far more control and security functions with fewer complications (and fewer parties involved). This should be considered the more secure option than emailing files.


Yes, you could do this.  This should be fine.  It is a reasonable defense against CSRF.

Do make sure that side-effecting actions can only happen via POSTs (never via  GET), and that all POSTs check for the presence of the token.  Also, make sure you generate the token as a cryptographically-strong pseudorandom number (e.g., using CryptGenRandom(), /dev/urandom, SecureRandom, or similar) and store it in session state.

I don't know if this has any benefit over, say, cookie double-submission -- but you could do it, and it should protect against CSRF successfully.


Short answer: no

Long(er) answer:

Up until some time ago you could see(in both yahoo and gmail) the network address of the sender by looking at the full headers of the e-mail message. Currently, this option is no longer available in gmail.

An attacker can use a service like this to send an e-mail with custom headers(meaning that the source address can be anything(i.e. b.obama@whitehouse.gov)) in conjunction with an anonymizing service such as a VPN, TOR, or both, in order to conceal his actual network address.

The MAC serves as an identifier within a subnet and is stripped and replaced once the packets leave that subnet(by the station that acts as the gateway). So, there is no way to tell the MAC address at it's not specified in the headers of the e-mail.


What is the best way to secure your web resources when you provide API as web service?

Normally an API will be protected by an API Key or an API Secret which is commonly sent in the headers. However, with the wide acceptance of OAuth, developers seems to use this method, which they can set the time for refreshing an OAuth token which is a much better way.

If you still need more protection for your API, (Which I Guess some bank or payment related ones), normally the client send an encrypted string to the server, the server decodes it, then send the response back again in an encrypted string.

So the person with the key can only decrypt the string.

So, in fact, you can mix API secret method with API string encryption for a stronger method.


PHP code execution attempts on an ASP website

The attacker might:

not know that the website is running asp, or
be a robot.

In most cases, I would say it is the latter: many, many crawlers try all sorts of attacks on every website, hoping to find a website where they get lucky. Figuring out, by hand, which technology is used by a website, costs much more time than just doing a few GET requests and matching the expected output.

  what will happen when a php code is tried to execute on an asp running web server. whether this will create an impact on the server and any chances of getting compromised

No, there will be no impact at all. If there is no PHP anywhere on the server, then PHP code will never do anything.

Well, it could theoretically be that valid PHP code is also valid ASP code. I don't know ASP that well, but a function_call() is probably similar in both languages... so any PHP attack will not work, but any attack that is valid for both languages might work, if your website is vulnerable... but the odds of this are negligible. Attacks almost never work in multiple languages, especially not if someone is blindly trying requests against your web server.

This is very common and generally nothing to worry about. It generally impacts common setups like Wordpress, PhpMyAdmin, Typo3, Joomla, etc.


Can I safely use an encrypted URL parameter for the session id?

If your session ID is truly random, there is no additional security in AES-encrypting it. If, however, it is not random, I would strongly recommend against doing so, for reasons similar to why no-one sane uses predictable session ID tokens.

Also, if you're not using SSL, your traffic can be sniffed. This means that, no matter how much you encrypt the token... it is still plainly visible. (Well, your traffic can be sniffed with SSL on, but it's a bit more complicated)