nmap - protocol discovery doesn't work with fragmented packets Using nmap to do a protocol discovery (nmap myhost -sO) identifies the following on my target. Note reason switch is also used.

 PROTOCOL STATE SERVICE REASON
1        open  icmp    echo-reply ttl 255
6        open  tcp     proto-response ttl 255

If I then add the -f to fragment the packets to evade ids / firewall (nmap myhost -sO -f)

the scan no longer reports TCP as a protocol and only reports ICMP

PROTOCOL STATE SERVICE REASON
1        open  icmp    echo-reply ttl 255

Why does fragmenting the packets stop detection of TCP, is the firewall actively dropping these or does it not understand them?

Update:

I tried manually setting mtu in increments of 8 until I discovered TCP again and this occurs at mtu 24 . So nmap myhost -sO -mtu 24

and it's back to

PROTOCOL STATE SERVICE
1        open  icmp
6        open  tcp

Most likely you have a firewall somewhere that is dropping packets for which it cannot make a determination of policy. A MTU of 24 is enough for the full IP header plus the source and destination ports of the TCP header. The next lowest valid MTU is 16, which is not enough to include the destination IP address. The firewall probably does not reassemble packets, so without enough to make a determination it drops the inbound packet. For ICMP, on the other hand, all that is needed may be the protocol number.


Fake popups from popular websites I just visited YouTube.com on Chrome and got a popup message that said "Your computer has a virus. You need to scan it with an antivirus". I think I had "OK" and "Cancel" buttons as options. It wasn't one of those loud ones with sounds and graphics, just the very simple gray Chrome popup in the top middle section that I know Chrome uses from time to time.

First thing I did is look left at the green lock to make sure I was on the right website, which it was, then shut off my machine immediately and unplugged the network cable. On another machine, I then looked up whether there's a live attack/compromise of YouTube, which I did not find. I then rebooted my desktop and checked some things(HW perf, newly installed programs, open TCP connections, running processes, etc) and did not find anything odd. Then I cleared all cache on my browser and went back to YouTube. Everything normal.

What are some possibilities on what happened?

I can only think of malware and XSS. I don't think it's a malware because I would have seen other signs.. Unless it's the sneakiest malware ever, I don't think it's a malware that pops up a fake warning once and never does anything else(altho I could just be not aware of it. But I do have quite tight control over my systems and if I do anything phishy I do it in VMs).

After I cleared cache I realized I could have double checked the browsing history to see if maybe it wasn't actually youtube, but I 100% checked the TLS lock at least before I shut it off.

And I've also seen other people(albeit non-techy) experience something similar, where they go to a popular website and still get those popups. Once I checked the browsing history after something similar happened to someone I know, and the person had gone to the correct website. I shrugged off, assuming the end user probably did something wrong. But this is the first time this ever happened to my machine and I'm more curious about how/what than scared.

Try a few different browsers on that machine to see if they all get the popup. If they don't, you might have a malicious extension or addon installed into chrome. If they do have the same problem, you might be a victim of DNS hijacking on the affected computer considering other machines on your local network don't experience this issue (although if they do it's still possible that your router has been compromised to the same end). If you open up your network adapter settings do you see anything under the IPV4 or IPV6 DNS settings that you didn't set?

There was a really interesting blog post on a similar case of DNS hijacking recently where a security researcher found malicious scripts on popular websites but only when browsed from his computer but I can't find it now. If I can find it I'll link it here.

Edit: Just to address the point about fake warnings, those can actually be a good source of ad revenue if the installation count is high enough. If the DNS hijacker exists, it is probably also inserting other ads into pages as well since that's easier to get reliable money from than attempting to gain and sell personal information. Also, as far as the green lock is concerned, it's possible that the main site resolves the same way but its external dependencies (a jquery cdn, for instance) resolve to something that will occasionally pad a bit extra into the original content.


Help in Suricata rule bitmask syntax problem I have written the following rule in my Suricata rules file:
alert tcp any any <> any any (flow:established; content:"|65|"; offset:0; depth:1; byte_test:1, =, 3, 2, bitmask 0x03; msg:"detected"; classtype:bad-unknown; sid:222; rev:1; priority:1;)

But it shows the following error because of the bitmask:
...
[ERRCODE: SC_ERR_PCRE_PARSE(7)] - parse error, ret -1, string 1, =, 3, 2, bitmask 0x03
...

I have found some examples in the Suricata documentation but none of them mention the way to properly use bitmask with the comparison operator.
My question is, what is the proper way to use the bitmask keyword? and why is it not working in the rule I have shown?

It is unknown what version you are using, but I will assume that you are not using a beta version. bitmask was only recently implemented in 6.0.0-beta1 and is at the time of this writing not available in a stable version. The option was documented much earlier though, i.e. there was a bug in that it was documented but not actually implemented. For details see Ticket 3283 and the ChangeLog where you should search for "#3283" to find out when it was fixed.


GnuPG expiration date differs between public and secret key I exported the secret part of my master key for security reasons. Now I had to extend the expiration date of my key for six months.

When typing gpg --list-keys in my console, the following appears

pub   4096R/D11FEC22 2015-04-11 [expires: 2016-04-05]
uid                  Prename Lastname <prename@lastname.com>
sub   4096R/63FD324E 2015-04-11 [expires: 2016-04-05]
sub   4096R/D0A7E7F3 2015-04-11 [expires: 2016-04-05]

Everything seems to be fine.

When typing gpg -K, I get the following:

sec#  4096R/D11FEC22 2015-04-11 [expires: 2015-10-08]
uid                   Prename Lastname <prename@lastname.com>
ssb   4096R/63FD324E 2015-04-11
ssb   4096R/D0A7E7F3 2015-04-11

Why is there still the old expiration date? I can sign any messages. Apparently this date has no influence, doesn't it?

This must not actually be the problem you encounter, but is a not too unlikely scenario: is it possible you changed the expiration date using GnuPG 2.1? Starting with GnuPG 2.1, private keys are also stored in the public keyring, so GnuPG 1 and 2.0 would read the unmodified private key with the old expiry date from the old private keyring.


Should the sole user of a *nix system have two accounts? Should the sole user of a *nix (particularly Linux and MacOS) have two accounts, one with sudo privileges and one without? Years ago I read that on your personal computer you should do your daily tasks as an unprivileged user and switch to a privileged user for administration tasks. Is this true?

Note: I am not referring to whether or not you should log in as root for daily use. That's obviously a bad idea, but should your daily use account be able to use sudo?

Second note: I am specifically referring to personal devices that are not being used as servers or to host any functionality for remote users.

Updated dramatically after 69 upvotes, see answer history for original answer. Thanks to @JimmyJames for the discussion.

First, let's talk about threat model: what are you trying to stop the potential attacker from doing?
Threat model: identity theft / ransomeware on a single-user system
Generally for end-user systems the de facto threat model is identity theft / ransomware. If the attacker has access to your documents and/or can run shell commands as you, it's game over. From that perspective, root access doesn't gain the attacker anything; they can get what they want without it.
If identity theft / malware is the only thing you're worried about, then it doesn't seem like it matters much whether your user has sudo powers, or ever whether the browser is running as root.
(I should also point out that malware / connecting you to a botnet can happen without root access since login scripts / scheduling a cron job does not require root).
Randall Munroe at XKCD seems to agree with this view:

Lastly, I'll add this disclaimer: Yes, I'm aware that this goes against the general public opinion that "more security is always better". It's just not true. Sometimes more security is worse, like overly complex password policies that end up forcing people to write down their passwords. You always have to look at the risks and decide how much security is actually appropriate. In this case there's no harm to locking down root access, but you are making your life more complicated and it's not clear that you're gaining anything from it.
Threat model: root access or multi-user system
If you have a threat model where the attacker wants something that only root has access to, or there is more than one user account on the machine, then the answer actually depends on which *nix you're talking about. This is quickly getting away from personal computer cases and into server cases, but I'll discuss anyway. For linux, because of a bug (*ahem feature*) in the Xorg windowing system, your everyday account should probably not have sudo powers. For operating systems that don't use X, it's probably ok.
Linux (running X.org window system)
Here's a great article that shows you how to log all keystrokes on a gui linux machine using a simple user-land (non-root) shell command. In summary:
$ xinput list shows you all connected human-input devices
$ xinput test <id> starts echoing all keystrokes on the selected device.
I tested and I get logs of the password that I type into sudo in a different terminal window. If I lock my computer then when I log back in, I see logs of the password I typed into the lock screen. Apparently this is not a bug in X, it's a feature. Right, I'm gonna go hide under my bed now.
So yeah, this supports the idea that any user you log into in the gui with should not have sudo powers because it's trivial to log your password and then become root. I suppose you should have a dedicated account for sudoing and switch to a TTY terminal (ctrl+alt+#) when you want to use sudo. Whether or not this is worth worrying about is up to you: personally, all the data I care about is already there in my user account, but I probably will change my laptop setup because I'm a security nerd.
Note that in my tests I was not able to keylog across users. Doing "Switch Account" in the gui, or startx in a new tty terminal seems to launch an isolated instance of X.
Thanks to @MichaelKjörling for this observation:

That's one of the things that Wayland [windowing system designed to replace X] actually tries to fix (see the bullet point on security). Remember that X11 originated at a time when the threat model was hugely different from what it is today.

For sysadmins: this reinforces the habit of only interacting with your Linux boxes over ssh, never use the GUI.
Mac OSX
I'm not an OSX expert, but I know that it does not use the Xorg server so I would assume that Apple's GUI handles this properly, but I would love for someone more expert than me to weigh in.
Windows
I'm not a Windows expert either, but I believe that the User Account Control (UAC) feature introduced in Windows 7 addressed this by having admin prompts render in a secure desktop whose input busses are isolated from your regular desktop.


Privilege Escalation TTY error while using sudo /usr/bin/vi command I am currently trying to escalate my privileges on an Ubuntu box. When I enumerated the server and run "sudo -l" command, I found out /usr/bin/vi set to (root) NOPASSWD.

(root) NOPASSWD: /usr/bin/vi /var/www/html/*

Then I wanted to use vi for my purpose to escalate my privs to root, so I wanted to create a file with running the command below, so I can run my shell in vi.

sudo /usr/bin/vi somefile.txt

Then I got this error:

sudo: no tty present and no askpass program specified

If someone help me with this issue, it is really appreciated.

I just would like to able to run this command without error:

sudo /usr/bin/vi somefile.txt

I know exactly what you are talking about and you are almost on the right track.

the sudo is letting you run /usr/bin/vi but in the same way you can't just do sudo vi somefile.txt, maybe there is a reason you can't do sudo /usr/bin/vi somefile.txt

For those wondering, I am hesitant to give an exact answer because this is an active CTF and it is discouraged to give the solution until it has been retired.


What does The input is reflected inside a tag parameter between double quotes mean? A recent scan of Acunetix has shown some vulnerability on one of my pages. I tried reproducing it but i can not find any vulnerability. The so called vulnerably is titled The input is reflected inside a tag parameter between double quotes mean.

The scan gives me the following result for my page.

verif.php
Details URL encoded GET input afficher_forgot_password was set to **Oui"sTYLe='acu:Expre/**/SSion(Afih(9717))'bad="**
The input is reflected inside a tag parameter between double quotes.

Request headersGET /verif.php?afficher_forgot_password=Oui"sTYLe='acu:Expre/**/SSion(Afih(9717))'bad="&lang_abbreviation=en&membre= HTTP/1.1
 Connection: keep-aliveCookie: PHPSESSID=feef28e9052ce51f6701e34749ca30ac;lang_abbreviation=enAccept: */*Accept-Encoding: gzip, User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, likeGecko) Chrome/73.0.3683.103 Safari/537.36

Here is a direct link that reproduces the so called vulnerability but I do not see any vulnerability on the page.  what does The input is reflected inside a tag parameter between double quotes mean ?

What happened?

The vulnerability scanner thinks that it found a possible reflective XSS or HTML injection vulnerability in the page.

When it injected Oui"sTYLe='acu:Expre/**/SSion(Afih(9717))'bad=" as a GET request parameter, the page rendered with the following element in it:

...

Part of the content (SSionAfih9717) matched the injected data.

Should you be concerned?

It depends. Tests like this may often be a false positive, as there are many different scenarios where user-input text may be reflected in the page in a non-harmful way.

It looks like the test was trying to inject a HTML attribute named bad into whatever element contained the data, but the word "bad" doesn't appear anywhere in the resultant HTML. I believe a successful attempt may have looked something like this:

...

Note how the attribute bad appears after href. This could be used by an attacker to inject arbitrary JavaScript or manipulate the page in other ways.

In your particular case, you don't seem to be affected by the test, and it can likely be considered a false positive. That said, there may be other scenarios you are vulnerable to, as this is just one test of many possible. That said, if the request could completely replace the href value instead of being added at the end, it could be used to target javascript: URIs or other domains in the attacker's control.

How to fix it?

If you were really vulnerable to this, you would want to follow best practices outlined in the OWASP XSS Prevention Cheat Sheet Rule #5:

  RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL
  Parameter Values

  Rule #5 is for when you want to put untrusted data into HTTP GET
  parameter value.

link

  Except for alphanumeric characters, escape
  all characters with ASCII values less than 256 with the %HH escaping
  format. Including untrusted data in data: URLs should not be allowed
  as there is no good way to disable attacks with escaping to prevent
  switching out of the URL.

  All attributes should be quoted. Unquoted attributes can be broken out
  of with many characters including [space] % * + , - / ; < = > ^ and |.
  Note that entity encoding is useless in this context.

  WARNING: Do not encode complete or relative URL's with URL encoding!
  If untrusted input is meant to be placed into href, src or other
  URL-based attributes, it should be validated to make sure it does not
  point to an unexpected protocol, especially javascript links. URL's
  should then be encoded based on the context of display like any other
  piece of data. For example, user driven URL's in HREF links should be
  attribute encoded.

  For example:

String userURL = request.getParameter( "userURL" )
boolean isValidURL = Validator.IsValidURL(userURL, 255);
if (isValidURL) {
    <a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link
}


Trick client into connecting to unsecure evil twin Wi-Fi access point Let's say I create an unsecured evil twin for a Wi-Fi AP that is secured.

If I successfully deauth the victim and get his device to choose my evil twin to connect to, will he get a message alerting him that this network was previously secured and that now it's not?
Or will the device try to reconnect without providing a password?

If it's a case of "it depends", what does it depend on? The device's OS Wi-Fi implementation? Or the Wi-Fi protocol used?

Thanks!

The user's device can distinguish the Evil Twin from the original AP

In this case the attack can't work if the deauthenticated user doesn't connect manually to your evil twin (And he doesn't notice it's not protected)


Is PGP suitable for encrypting webservices? I would like to know if I can use of PGP to ensure SOAP webservices confidentiality?
I don't want use SSL, it's kind of slow mechanism to make a tunnel for high throughput data transaction.
I though cypher data using a symmetric key, the key will be encrypted to by a asymmetric public key. And push the message in the network, just the intended receiver can read it.
Is it a good fair pattern for web services?

Any help will be greatly appreciated.
Regards

SSL will be faster than SOAP+PGP.  Cryptographically, both SSL and PGP are hybrid systems which use public key cryptography to protect symmetric session keys.  In practice, SSL has been tuned on the client and server side to do what it's doing quickly, PGP hasn't been optimized for this case.  And you'll have to figure out your key distribution and trust mechanism if you roll your own PGP method.

Doing your own encryption will have the advantages of protecting it from the usual cases - MITM proxies, accelerator decryption.

Without knowing more about your app, it's hard to say, but in most cases, it's not worth it to go your own way.  SSL provides pretty darn good security for the average application.


What are the implications of 5 million peoples fingerprints being stolen from the US Government? The recent OPM hack has revealed more fingerprints were stolen than previously believed.

  One of the scariest parts of the massive cybersecurity breaches at the Office of Personnel Management just got worse: The agency now says 5.6 million people's fingerprints were stolen as part of the hacks.

What, exactly was stolen as part of this hack, and what are the potential implications of this data?

With access to this leaked data, can a person whose data has been leaked be identified based on a latent fingerprint?  Can a fingerprint be fully or partially reconstructed from the data?  Can the data lead to replicating someones fingerprints, and then accessing resources protected with fingerprint data?

This is what FiveThirtyEight.com has to say:

What To Do With A Million Stolen Fingerprints Hint: Think bigger than iPhones.

  [Fingerprints] could be used to sniff out individuals operating in a
  foreign country under false identities.

  Imagine that you, an American spy, travel to Hackistan ostensibly to
  work as the ambassador’s dog walker. The Hackistani government grabs
  your fingerprints when you arrive in the country. But now, after their
  successful hack, they can check yours against the prints in the stolen
  OPM database.

  They find that your prints are a partial match with the prints of a
  contractor who worked for the U.S. Department of Defense a decade ago.
  Uh oh.

For national and cybersecurity experts, the thought of fingerprints in particular falling into the wrong hands is especially frightening. As National Journal wrote:

  Much of their concern rests with the permanent nature of
  fingerprints and the uncertainty about just how the hackers
  intend to use them. Unlike a Social Security number, address,
  or password, fingerprints cannot be changed—once they are hacked,
  they’re hacked for good.

Earlier this month, the Defense Department awarded a $133 million contract to an identity-theft-protection-services company to monitor the hacked data. This is an indicator for how much people are concerned.


Intel Management Engine vulnerabilities in CPUs without vPro Intel Management Engine (ME) imposes a security risk (see here for example). As I understand ME is a part of Intel vPro. Does having an Intel CPU without vPro support mean ME is not fully functional and hence less vulnerable? I've seen multiple (non-authoritative, not linking here) claims on the Internet that all the recent Intel CPU have ME enabled. I'm confused what having no vPro support actually means regarding ME and related security issues.

Intel vPro is not a single thing, but is actually a group of several Intel technologies working together to provide a certain set of services. The Intel vPro reference guide lists those technologies (emphasize is mine):

  Intel vPro technology is a collection of platform capabilities that
  support enhanced manageability, security, virtualization, and power
  efficiency.  The key platform capabilities include the following Intel
  technologies:

  Intel Turbo Boost Technology for increased performance and power efficiency
  Intel Virtualization Technology (Intel VT) for Dynamic Virtual Client support and other operating system or application streaming
  techniques using virtualization
  Intel Hyper-Threading Technology (Intel HT) for higher performance
  Intel Active Management Technology (Intel AMT) for greater manageability
  Intel Anti  -Theft Technology (Intel AT) for greater security
  Intel Trusted Execution Technology (Intel TXT) for greater security
  Intel Identity Protection Technology (Intel IPT) for enhanced web security

Among these various technologies is the Intel Active Management Technology, which allows system administrator to remotely manage companies computers independently of their location and their state: even computers turned off or computer where the operating system fails to boot can still be managed using this technology.

What happened is that a security researcher found an vulnerability allowing a remote, unprivileged user to take control of this management feature.

As stated in Intel's Security Advisory (emphasize is mine):

  There is an escalation of privilege vulnerability in Intel® Active Management Technology (AMT), Intel® Standard Manageability (ISM), and Intel® Small Business Technology versions firmware versions 6.x, 7.x, 8.x 9.x, 10.x, 11.0, 11.5, and 11.6 that can allow an unprivileged attacker to gain control of the manageability features provided by these products.  This vulnerability does not exist on Intel-based consumer PCs with consumer firmware, Intel servers utilizing Intel® Server Platform Services (Intel® SPS), or Intel® Xeon® Processor E3 and Intel® Xeon® Processor E5 workstations utilizing Intel® SPS firmware.

AMT is part of the Intel's vPro offering and is not available on non-vPro devices like "consumer PCs with consumer firmware" and "Intel servers utilizing Intel® Server Platform Services (Intel® SPS)".

Intel CPUs without vPro support therefore do not seem vulnerable to this attack as they lack the vulnerable firmware.


Right way to use the TPM for full disk encryption I'm currently setting up a BitLocker equivalent using a TPM and LUKS. I've got the basics right and I'm able to measure the boot process and seal the FDE key using the TPM.

Every time the sensitive parts (firmware, bootloader, kernel) are updated the following command is used to seal the encryption key to the new system state :

tpm_sealdata -p 0 -p 1 ... -p 11 -p 13 -i <keyfile> -o <sealed keyfile>

When the system boots the following is used to unseal the key which is then passed on to LUKS to mount the encrypted volume :

tpm_unsealdata -i <sealed keyfile> -o <temporary keyfile stored in RAM>

This works and has the desired behavior - if the boot process has been tampered with (let's say adding init=/bin/sh to the kernel command line to bypass a root password) the TPM refuses to unseal the key and the system is thus safe.

However, I've got a few questions :

First, the TPM requires the SRK password every time a sealing/unsealing operation is performed. I'd like to avoid that and have it behave just like BitLocker which is transparent and doesn't prompt for anything. I've thought about using a default SRK password but apparently it's insecure, yet the answers fail to tell whether an attacker knowing that password can unseal a key if the PCRs don't match the state they were in when the key was sealed.

Another question is which way should I use to seal the keys - my way involves tpm_sealdata/tpm_unsealdata but another project tpm-luks uses tpm-nvread/tpm-nvwrite instead. I'd like to know the differences and whether one way is more secure than the other.

First of all: NO system is 100% safe, but using TPM is better than no TPM at all. TPM Chip is just some kind of encrypted storage, that resides on the motherboard of computers that support Trusted Platform Environment, and have BIOSes prepared to handle it.

PCR are registers with specific functions that are handled through the TPM_Extend operation. They cannot be "set", only extended(new_hash = [old_hash||new_measurement]).

TPM have Static Root of Trust for Measurements (SRTM) and Dynamic Root of Trust for Measurements (DRTM), and the combination of both creates the Secure Environment. This guy explains very well how this is done. It is a chain of trust between fixed and dynamic items.

Back to PCRs, they are platform independent registers, and the most common ones are:

PCR 0 to 3 for the BIOS, ROMS...
PCR 4 - MBR information and stage1
PCR 8 - bootloader information stage2 part1
PCR 9 - bootloader information stage2 part2
PCR 12 - all commandline arguments from menu.lst and those entered in the shell
PCR 13 - all files checked via the checkfile-routine
PCR 14 - all files which are actually loaded (e.g., Linux kernel, initramfs, modules...)
PCR 15 to 23 are not used

Intel based notebooks commonly use the first 16 registers, but it could be extended to other softwares/uses.

While writing information (sealing) to TPM, you can add a Storage Root Key (SRK) that is somehow a "Management key" and is used to add other keys to this storage. As per manpages, using -z will set TSS_WELL_KNOWN_SECRET (20 zero bytes).

-z, --well-known
    Use TSS_WELL_KNOWN_SECRET (20 zero bytes) as the SRK password.
    You will not be prompted for the SRK password with this option.

So, having this SRK set to the default secret (TSS_WELL_KNOWN_SECRET) will not be enough to attack someone since TPM can only be unsealed if the current PCRs match those used to seal the data. Also, some of the PCR handling happen at boot time(BIOS) and it's very hard to manipulate those and thus create "fake" PCRs. BIOS is the only place where PCRs are seen as zeros before the rest of the process takes place.

The only FEASABLE attack is the one who aims to MITM communications between BIOS and PCR to zeroes PCR without restarting the machine to put the system on "trusted" state. This attack is known as TPM Reset Attack.

  The Attack

  So, given everything we've seen above, it should be very difficult to
  fake a trusted boot process, as long as the BIOS takes the first few
  measurements. The critical assumption here is that the PCRs cannot be
  easily reset without restarting the whole platform that the TPM
  resides on. If an attacker is capable of monitoring the measurements
  sent to the PCRs by the BIOS (with, for instance a logic analyzer, see
  this paper), and capable of zeroing out the PCRs without restarting
  the machine, then she could take a platform in any configuration and
  put it into a 'trusted' state. So, the difficult part is getting the
  TPM to reset without bringing down the whole machine. It is worth
  mentioning that we've also looked at interposing memory and other such
  things to change the running system after its been measured, but due
  to the speed of the busses that memory and hard drives sit on, this is
  a tricky endeavor. Attacking a slower bus is much easier.

  TPMs typically reside on the Low Pin Count (LPC) bus. The LPC bus
  supports a ground driven reset line. This means that when this
  particular line on the bus is driven to ground every device on this
  bus is supposed to reset. Other devices attached to this bus include
  the BIOS, and legacy keyboard and mouse controllers. The video below
  demonstrates that driving this line is indeed possible, and fairly
  easy to do. Please note that in the video, we are accessing the
  computer in question via a remote ssh session. This is because the
  keyboard and mouse controller get reset when we drive the reset pin,
  but the network card does not. More details of this attack (and
  others!) can be seen in my senior honors thesis: A Security Assessment
  of Trusted Platform Modules, Dartmouth College Computer Science
  Technical Report TR2007-597.

Note that this is an oversimplified version of ALL THINGS that involve Trusted Computing. Please take a look at the Architecture Document of TPMv2 to get more information about all operations that happens between bios, hardware and software during the setup of a trusted environment.

tl;dr: Using the default Storage Root Key(20 zero bytes) is not enough to create an insecure system.

Related stuff:

LUKS, TPM and full disk encryption without password.
Full disk encryption with LUKS (including /boot) without TPM.


Is Google API Key a sensitive information that needs to be protected? I'm making use of google API for location (in Android, iOS apps).. Can the key be hardcoded? Or should it be protected? If It's sensitive, why is it sensitive and how can attackers exploit this?

The Google Maps SDK for iOS sends the app's API key to Google in such a way that any end user of the app can find the app's API key by using an HTTPS proxy.  If you happen to be developing on a Mac, you can try this yourself pretty easily using the Charles proxy.

Configure Charles to act as a proxy for clients4.google.com.  On a Mac you'll need to make sure you're using the "alternative version" with full SSL proxying support downloadable from this page.
Download and install the Charles SSL certificate for iOS devices by visiting this link on your iOS device.
Configure your iOS device to use an HTTP proxy (this is available in the advanced options for your WiFi network, accessible via the little "i" button next to your WiFi network's name).  Set the proxy server to the IP address of the Mac running the Charles application, and the port to 8888.
Run your (or any) iOS app that uses the Google Maps SDK for iOS.

In Charles, you'll see POST requests go out to clients4.google.com, where the API key is visible as part of the request body.

So, to answer your questions:

In terms of security it hardly matters if you hard code the key.  Any end user can get your app's maps API key without ever digging into the app itself.  In terms of convenience you might be better off fetching the maps API key from your own server so that if/when you need to update your maps API key you don't need to release a new version of the client app.
The maps API key is not sensitive, in the sense that Google does not treat it as sensitive information.  And in fact, even if Google obfuscated the keys by sending (say) a hash to their API instead of the key itself, a determined end user with a jailbroken device and a debugger could still get your API key by inspecting the parameter you pass to +[GMSServices provideAPIKey:].  So it's questionable that there would be any point in trying to treat the API key as sensitive information.
An attacker can exploit the exposure of your API key by making requests to the Google Maps API that appear to be coming from your app.  A group of malicious users could spam the API to use up your app's "courtesy" bandwidth, or to run up your bandwidth bill if you have billing enabled for the Google Maps API.  If you (or Google) are keeping a close eye on your bandwidth usage, you could partially defend against such an attack by revoking and replacing the maps API key when your app's (apparent) usage of the maps API spikes.


PC showed evidence of a phone being attached for no obvious reason. Theories on why? Connecting via remote desktop to a Windows 7 machine today showed the last couple of seconds of a windows device installing and the "Your device is ready" popup for a Sony Xperia T. Going to printers/devices showed an image of the phone. There's no bluetooth on the PC, and there's no reason for such a device to have been connected. Checking USB attach/detach logs showed expected entries and nothing concerning the phone, though that could have been tampered with. There's also no evidence of any virus, but the machine needs more forensic analysis on that front. Putting aside the most obvious explanation that a phone really had been connected, I'd welcome thoughts on alternative possibilities and things to check for any evidence.

UPDATE: There is a slim possibility that a phone was connected 2 weeks ago, however the machine had been logged into since then, and no device installed message popped up on those occasions. In this case the dialog was seen at the point of logging in again, just as if a device had been plugged in and the drivers had installed themselves, but a phone was definitely not connected at the time.

UPDATE2: Forensics show 4 keys modified including the following with data referencing an xperia at the same time as the remote desktop connect so there is some handle on the event, which seems to be triggered from the remote connect.

HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU\0\3\0

EDIT: 2014 Jan 28

As a postscript to this, a few days ago we replaced the drive in the machine which put it back to how it was at the start of 2013 (we'd copied the original drive to an SSD at that time), and long before there was possibly unauthorised access to the hardware. Looking at the list of printers today, the phantom phone appeared again, and it's guaranteed that one has not been plugged in since the drive was switched. The only software installed since was Skype. Very mystifying.

Remote Desktop does have a way of making local resources available to the remote host. Not sure if a phone would get shared to the remote host (or how it would be shared). If nothing else, it is conceivable that it would be made available as an USB storage device.

Theoretically, you would have known if a phone was plugged into your local computer so this possibility may not apply to your situation.


Is it possible to encrypt an SD card? In the film "Citizen 4", it's said that we cannot encrypt an SD card. Do you know why it would not be possible?

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


Calculating the time required to brute force a random code Say we have amount random entry codes of length characters from an alphabet of size alphabet.
The number of possible codes is then easily calculated as keyspace = alphabet ^ length.

Now take an attacker who is trying to gain entry using brute force random guessing of codes. At guess rate rate, the time in which they can all be checked (and entry is thus guaranteed) is easily calculated as keyspace / rate.

However, what I would really like to know is, how to calculate the time required for the attacker to have a given chance of finding any valid entry code. This is a system where a valid code is all you need, there is no secondary requirement like a username (think coupons). Once again, there are amount in keyspace.

E.g., how long would it take the attacker to have a 1% chance of finding a valid code? And 10%? And 25%? Etc. Or the inverse, given a specific amount of time, what are the chances?

For the expected case (average) the number of attempts has a linear relationship to the probability of success being considered.

expected_time = probability * keyspace / ( rate * 2)

So if the keyspace consisted of 1 billion codes and the attacker could brute force 1 million codes per second to have a 10% chance of success the attacker would need 50 seconds.

expected_time = 10% * 1000000000/(1000000 * 2)

Now in your case you state there are a multiple valid codes (amount).  Can these codes be attacked in parallel?  Generally we try to avoid scenarios where that is possible.  This is one reason why we add salt to passwords.  It prevents an attacker from attacking all possible hashed passwords in parallel.  Another example would be tying a code to a given userid.  Even if userid is known this limits the attacker to searching for a specific code not any valid code.  If no parallel attack are possible then the above formula is true but if the attacker can perform an attack against all possible valid codes with a single attempt then the expected time is reduced by the number of valid codes (amount).

expected_time = probability * keyspace / (rate * amount * 2)

Another way to look at it is the amount of valid codes reduces the size of the keyspace (assuming attacks can be done in parallel and any valid code is acceptable). Note in neither case does the birthday problem apply so there is only a linear reduction in expected time when the attacker can perform a parallel attack. In hashing terms this would be a preimage attack not a collision attack.  Still we generally try to scenarios where parallel attacks are possible because we don't want to increase the efficiency of the attack (even linearly).


Cookie Operations using Modsecurity Rules Here, I'm trying to accomplish calling a Lua script from modsecurity rules.

There are 2 components:-

1.example.com (WAF)

2.test.com (Web Application)

test.com contains pages:-

index.php
protectedpage.php

If user accesses http://example.com/protectedpage.php the rule loads the lua script and writes data to lua_output.txt .

I have been stuck here for past 2 days trying several variations.

  Contents of /etc/apache2/sites-enabled/example.com.conf

<VirtualHost *:80>
    ServerAdmin admin@example.com
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com/public_html
    ErrorLog ${APACHE_LOG_DIR}/error.log
    CustomLog ${APACHE_LOG_DIR}/access.log combined

    ProxyPreserveHost On
    ProxyRequests Off

    LoadModule security3_module /home/testuser/spiderlabs/ModSecurity-apache/src/.libs/mod_security3.so
    <IfModule security3_module>
            modsecurity_rules 'SecRuleEngine On'
            modsecurity_rules 'SecRequestBodyAccess On'
            modsecurity_rules 'SecResponseBodyAccess On'
            modsecurity_rules_file "/etc/apache2/modsecurity.d/include.conf"
            modsecurity_rules 'SecAuditLogFormat JSON'
    </IfModule>

    #Access to /getprotected
    modsecurity_rules 'SecRule REQUEST_FILENAME "^/getprotected.php$" "phase:2, t:none, t:normalisePath, t:lowercase, t:urlDecodeUni, chain, deny, log, id:1301"'
    modsecurity_rules 'SecRuleScript /etc/apache2/lua/checkaccess.lua \
    "id:400,Phase:2"'

    ProxyPass /getprotected.php !
    ProxyPass /getpassword.php !
    ProxyPass / http://test.com:8080/
    ProxyPassReverse / http://test.com:8080/

  Contents of /etc/apache2/lua/checkaccess.lua

   #!/usr/bin/lua

    function main()
        local f = assert(io.open('/etc/apache2/lua/lua_output.txt','a'))
        f:write("--- Hello world ---\n")
    end

The Rule is executed. But the script is not. I'm not sure whether its chaining or not.
please Let me know how to fix this.
Thanks,

References so far:-
1. ModSecurity Documentation

Lua scripting blog 1
blog 2

This is a lua script, why are you doing first a secrule then chain, you better call the script and get the var REQUEST_FILENAME and check it matches your pattern or add a Location/LocationMatch for the path and add the SecRuleScript inside.

The first rule is incomplete as it is a chain start that has no end as the next one is not a rule is a script call.


Podman: What if user is member of docker group? From a security perspective: Is it necessary that a user, that runs OCI containers with Podman, is not at the same time a member of the docker group?

From what I understand the idea behind Podman is to re-map the  user ids, such that the root user within the container is equivalent to the user on the host. The security concept is better because if a user can take over the container and break out, the user is not automatically root user on the host (given that the process within the container was started as the container's root user).

Now if the user on the host is in the docker group it should be equivalent of having root access as stated in the Docker post-installation guide:

  The docker group grants privileges equivalent to the root user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.

  -- Source

So if an attacker breaks out of a container managed by Podman, and at the same time the user who started the container is in the docker group, the security gain should be none compared to managing containers with Docker. Is this correct?

Yes, I'd say that your assertion here is correct. Gaining access to an account which is a member of the Docker group on a host (absent other custom protections) will allow the attacker to escalate their privileges to be root on the host.
Typically podman is used for developer systems rather than running production services, which would usually be done with something like CRI-O, in that kind of environment.
It's possibly worth noting that it is possible to run Docker in a rootless mode similar to podman, which may mitigate this kind of issue.


Is asymmetric encryption is safe on the Internet? Can't a hacker just pose as a valid user? When I read the RSA asymmetric encryption:

In the environment:

Rules are:
blue boy, red girl, and black men.

blue boy and red girl all have their own public key (blue) and private key (red).

In the first step:

  blue boy signs the plaintext(1), sends the plaintext(1), RSA.sign(1) and
  blue public key to red girl; then red girl can use the blue public key sign the plaintext(1), to compare the received RSA.sign(1) and check the data whether is right.

I have two questions:

What's the purpose of the first step?
The black men can truncate the network, then send red girl 3 + RSA.sign(3) + black public key using blue boy's name. Why is this safe?

If you don't have prior knowledge of the keys, and no secure channel or other means for verifying keys, then it of course breaks down in the face of an attacker who can modify messages.

But. We have certificate authorities on the internet that we trust. We trust that they only issue a key for the domain example.org to the entity that can demonstrate control over example.org in some way.

The keys of those certificate authorities is embedded in many pieces of modern software, e.g. Firefox, Windows, Linux distributions, Java and so forth. The certificate used by example.org will be signed by the CA, making it impossible to fake it. As the certificate of the CA is pre-distributed, it can't be intercepted by a trivial MiTM-attack.

In organizations, a private Public Key Infrastructure may be configured, so that the organization can issue key material them self, and configure trust more flexibly than by relying on external trust agencies.

Software such as GPG relies not on central agencies, but rather a web of trust. I may know Bob, so I meet him and sign his key with mine. You may know Alice, who knows me, and also as signed my key. This way you can establish trust to a key you acquired over an insecure channel.

For private citizens, you can verify a key by e.g. phoning the person, and checking that the fingerprint is equal to what it should be. The finger print is not secret, so it does not matter if anyone listens in on this conversation; they will learn naught, but it will allow you to verify the key.


What happens when I send a git request to a Malicious Site? So I mistyped a command. I wanted to do the Angular tutorial, so I did the following:

git clone --depth=14 https://github.om/angular/angular-phonecat.git

There was a typo when I used github.om instead of github.com.

Curious, I visited the site. I'm on Mac OS X // Safari, so it did one of those phony "You have a virus! Have an inescapable dialog box."

So this made me wonder... What happens when you send a git request to a malicious site? What sort of things can they learn about your system, your user information, etc.?

Also, what if I used sudo to complete this command -- let's say that I was on a guest account. What else could they learn from that? Does that change anything?

The worst that can happen, is that you may have a security bug you don't know about in your git client, and the remote you accidentally connected to may host a specially crafted repository to take advantage of it, and you will be pwned.

Unlikely? Yes. But there has been at least one git vulnerability allowing remote code execution during a clone in the past. And git, like any network-enabled software of sufficient complexity, has had its share of security vulnerabilities.

If you're running with sudo, obviously remote code execution could be far worse than normal. So maybe avoid doing that in the future if you can.


Protocols that are highly resistant to code injection attacks ? After reading  about language based security, it seems protocols that are defined using context-free or regular grammars are highly resistant to code injection attacks.

Are there any good security protocols that are context-free or regular ?

This paper deeply analyzes the problem and introduces a technique called Differential Parse Tree Differential Analysis. You should probably start from there.


KSPP is not a competitor. It is a project to get improved security features into the Linux kernel, funded by the Core Infrastructure Initiative. Grsecurity, on the other hand, is a security patch for Linux produced by Open Source Security, Inc. Grsecurity is implemented as a series of modifications to the kernel source code, as well as security-enhancing GCC plugins. There is no KSPP patch to download because all improvements are upstreamed. In many cases, the ideas for improvements come directly from the latest available public grsecurity patch. For example, grsecurity wrote a high-performance reference count overflow mitigation. KSPP tried implementing it themselves, found out the performance was terrible, and instead took grsecurity's version, modified it slightly, and include it in upstream Linux. Now upstream has (basic) refcount protection.
In terms of security, grsecurity is vastly ahead of KSPP. This is in part because grsecurity is willing to take "risks" that Linux kernel devs do not want to take (e.g. using i386 segmentation), but also simply because the grsecurity developers are significantly more security-focused, without the limitations of developers who don't consider security bugs to be any worse than another bug. The main (only?) advantage KSPP has over grsecurity currently is that security improvements brought about by KSPP are made public, as opposed to grsecurity which (currently, at least) is only available to customers.
Due to a complicated series of events, Brad Spengler (developer of grsecurity) has had frequent rows with Linux developers, and the KSPP in particular. He sees them as plagiarizing his work, and they see him as attacking them needlessly. Whether or not this is true is irrelevant to the comparison.
In summary

KSPP provides much less of a security improvement, but is available to the public.
grsecurity provides significant security improvement, but is unavailable to the public.


How do these Windows services affect the security of Windows Firewall? Its common to disable unneeded services in Windows 2008 R2, but sometimes I come across installations that use Windows Firewall and related services. More info: see service dependencies for Windows Firewall.

I've come to realise that Windows services have unexpected side effects when restarted / disabled, etc, so I think it's worthwhile to ask what is purpose and effect of disabling the following services?

This will benefit those who want to use Windows Firewall, yet still disable unneeded services.

Base Filtering Engine
Group Policy Client
IKE and AuthIP IPsec Keying Modules
IP Helper
IPsec
Network Location Awareness
Windows Firewall
Windows Firewall Authorization Driver
Network List Service

Network List Service

Service name: netprofm

Description: Identifies the networks to which the computer has connected, collects and stores properties for these networks, and notifies applications when these properties change.

Critical for Windows Operation?: No, not at all, but it is managing properties such as TTL on various parameters cache'ed in our PC memory. Simply explained, its use is similar to how we cache a domain name's IP in our memory, and need to update this IP at a TTL interval when it is changed on our DNS server. If the service is disabled they it can cause properties set by other computers to not change or not be managed efficiently, but it is not critical for OS operation.

Network Location Awareness

Service name:NlaSvc

Description: The Network Location Awareness (NlaSvc) service looks for and remembers networks that you have connected to in the past and re-connects to them when they are available.

Critical for Windows Operation?: No, but if another program depends on it for auto-reconnect then it will not be able to if disabled. Its behavior can be compared exactly to that of how we reconnect automatically to known Wifi points. Disabled that doesn't cause a problem unless we're disconnected of the network and then we need to manually connect back in since the service is disabled. It is generally recommended to allow windows to manage service optimization here but if you think this is a problem you will not have then you can disable it.

 IP Sec

Reference Link: http://etutorials.org/Server+Administration/securing+windows+server+2003/Chapter+8.+IP+Security/8.2+How+Does+IPSec+Work/

Advice: Leave this one alone. :P

Credits:

I got this from a a bunch of Maximum articles and one NLA from personal experience. Hope I was of some help. :)


Tracing root compromises In regards to the following:

0day Linux/CentOS SSHd Spam Exploit — libkeyutils.so.1.9
SSHD Rootkit

There apparently seems to be a bunch of redhat server being backdoored via a library. Does anyone have advice on how to track and find the initial breach of contact?

In that specific case, as far as I understand, the initial compromise was traced back to a compromised system at cPanel. The breach allowed the indirect attack of some systems which use cPanel, and the attacker was on the habit of installing a rootkit which put a backdoor in SSH.

The general methodology for understanding what happened and whodunnit is the same as in any case of post mortem debug: gather data & think hard. If many machines were compromised, try to work out what they have in common. Inspect all log files. Take a byte-to-byte image of the hard disk of an affected machine and see if there are interesting things in deleted files (most attackers will cover their tracks by deleting temporary files they used, but few will bother to actually fill the corresponding disk areas with zeros). This is called forensics and it is an expertise in its own right.


Decrypt files in safe environment I have a USB drive that has encrypted files on it.  I was wondering what would be the best way for me to decrypt these files on my personal computer without leaving a trace?  Is there a safe environment that once setup would leave no trace of my decrypted files on my personal computer?

I do not want individuals to be able to find and recover the deleted files that were decrypted.

The best way is to boot your computer from a LiveCD, copy the encrypted files from the USB drive to the computer, remove the USB drive, and decrypt the files.  The LiveCD environment is a mix of read-only media (the boot disk) and RAM disk (the user-modifiable parts of the filesystem), so anything you do will be wiped away when you shut your computer down.

If you're feeling especially paranoid, remove your computer's hard drive before booting.


Do password crackers / brute-force attacks put a higher priority on "picture-passwords"? Some time ago I saw a post on reddit about someone with the seemingly very random username "78523965412369874123":

If you trace those numbers on a usual keyboard-numpad, it spells out a swastika with a box around it.

I know from the Android pattern lockscreen, that there exist 389112 lockscreen combinations for a 3x3 matrix.

Edit: You should keep in mind that the pattern lockscreen has some limitations like the pattern needs to be one continuous movement, jumping therefore is not allowed. In the swastika-example the user indeed can jump, start new etc. so the possible combinations should be far higher.

Calculation:

Moves = 4, combinations = 1624
Moves = 5, combinations = 7152
Moves = 6, combinations = 26016
Moves = 7, combinations = 72912
Moves = 8, combinations = 140704
Moves = 9, combinations = 140704

Total possibilities: 1624 + 7152 + 26016 + 72912 + 140704 + 140704 = 389112

It turns out, that users tend to prefer visually appealing passwords,
which are easy to shoulder-surf and also easy to guess based on smudgepoints since they give you a possible start- / endpoint, which drastically reduces the search-space.

Back to the swastika: Since people tend to use visually appealing passwords, would a password-cracker or brute-forcer put a higher priority on those "visual passwords" on a keyboard or a numpad?

Are there lists for that?

Should I advise people in my company to not use visual passwords that represent something? Because most of the passwort guidelines focus on not using dictionary-words or widespread terms.

Edit 2:

My question is not limited to the numpad. Every device that you can type on should be considered.

Visual passwords might be much longer than usual passwords, that you find in a dictionary. Since you "paint" them and only have to remember the visual form, I think that there could be passwords with 20 digits or more.

A brute-forcer usually would not check those long passwords, but if there would be a list of "typable visual forms", suddenly a brute-forcer might be able to check really long words, since there are only so many visual forms that you type on a keyboard.

See example here:

This example spells out "Cool!", which would look like this if typed:

EWAZXTRDCVGYGBNJUIK,.P;/ - 24 symbols.

PS: I am not a native english speaker and I'm not very satisfied with the terms "picture-passwords", "visual passwords", ... but despite researching beforehand I did not find a more fitting name for what I mean. Is there a better one? Should I change the title of my post?

They very well could.

Actually it depends on the content of the dictionary of the cracker. The person that handles the cracking will (as you probably know) start with a dictionary of real words and known passwords, then once the dictionaries have been exhausted, the hacker will start using masks before doing a real brute-force attack.

So now that you put this post here, more hackers will add such "known passwords" in their dictionary. If I was one, I would - right now :)

Now it depends on the person cracking the hashes : they don't have the same dictionaries.


Whats the best custom compression method to use when I have SSL? Suppose I have an application which does encryption using SSL and provided you cannot control what cipher suite is being negotiated, and assuming that I have some custom compression over the data before the encryption takes place. What would be the best mode of compression to be used? If I go ahead and use DEFLATE/GZIP am paranoid I might expose myself to an attack where an attacker can expose encrypted data using chosen plain text attacks. (something similar to the CRIME attack)

Encryption hides data but leaks data size. That's a common property of all encryption systems: encrypted data has (more or less) the same size as the clear data.

Compression alters the data size but it does so by finding "redundancies" (in a loose sense) in the data. So compression success rate depends on the data contents. Thus, compression makes data size dependent on data content.

Take the two together, and this leads you to the unavoidable but grim conclusion: compression leaks information about the data contents, even through encryption. The only general conclusion is then that thou shallt not compress at all.

The CRIME attack simply works with that notion, in a Web-specific setup where the attacker gets to choose part of the data which is compressed, and tries to obtain some other confidential data which is also part of the compressed stream. This is a chosen plaintext attack and it makes the attack really efficient. However, in all generality, a leak is a leak: even in purely passive attack scenarios, compression will make your connection "less secure".

The principle is not specific to Deflate; changing it to a custom algorithm would not save you. Deflate is not "especially weak" or "especially strong" in that respect.

All of the above applies for all lossless compression algorithms. It doesn't for lossy compression algorithms which achieve a fix data bandwidth. For instance, if you compress music into a MP3 at exactly 128 kbits/s (no variable rate) then the resulting data size will not depend on the music contents, only on the original music duration. But, of course, lossy compression algorithms are applicable only to data where loss can be tolerated; e.g. sound, not XML.

(The thing about "lossy" is that you cannot guarantee a fixed compression rate without having some potential data loss, because of the pigeonhole principle, unless your "compression" is actually a lack of compression, with the input data being totally unchanged.)


How to prevent ASCII Encoded / Binary String SQL injection in CodeIgniter I have been using CodeIgniter for two years and I am digging into penetration testing. I think that ActiveRecord does good job at preventing SQL injections, but is there any possibility of bypassing ActiveRecord's filter system by ASCII Encoded / Binary String SQL injection?

If it is possible, then how can I prevent ASCII Encoded / Binary String SQL injection?

There are no known SQL injection vulnerabilities in the latest version of Code Igniter and the guys at EllisLabs try their best to provide fast patches for reported vulnerabilities. If you do discover a security vulnerability in the Active Record code, you should responsibly disclose it to the company developing the product. Otherwise, do not try to fix what is not broken, because you may end up ainserting vulnerabilities, rather than eliminating them.

Important note: Make sure you do not make exceptions with using Code Igniter, by constructing your own SQL syntax (especially when you use user supplied input)

$this->db->query("SELECT id FROM table WHERE column LIKE '%"."$search."'");

Or if you do, properly escape your variables using their predefined functions.


Hashing cookie-values & preventing cookie-stealing I have a problem with understanding how one would securely store a hashed cookie. And how to actually hash a cookie.

This is the situation:
Every visitor (not user, but also unregistered visitor) of the website gets his own 'secret page', there he can enter 'secret' information. The problem is, that the visitor gets this without the need of selecting a password or something related. The secret key is automatically generated and stored as a cookie.
The problem: if the cookie gets compromised the attacker can 'spoof' his own secret key by changing his own key, into that one of the user.

I thought I could fix this problem by:

Generating an unique key for each user
Save the hashed version into database
Save hashed version into cookie
When visitor visits, check if hashed cookie matches database-value

Problem: Attacker could still copy just the hash of the cookie. Because it's just plain-text after all and would still match the database-value.

Or by using this method:

Generated key (A) gets encrypted using e.g AES with key B. The generated string gets stored in a database.
Key B gets stored in cookie; with visitor-ID
When visitor visits, I take his visitor-ID to know in which row
in my database I have to look, and if key B successfully decrypts the "string", the user has access to key A to access secret key.

But this is the exact same problem as above...

I'm struggling with the fact, that besides length a password stays secure as long as the user keeps his mound shut or his PC free from malware.
But because cookie-stealing is so easy, I need another mechanism for cookies.

So, how do I protect visitors from cookie-stealing in this situation?
I'm not asking for flags like HttpOnly or something related, but really for an algorithm/mechanism/...
I only need to make sure, that the user is the same user as in the previous sessions. And someone else didn't changed his cookie in that of the other user. This all without any interaction (mail, username, password) of the visitor.

To simplify your question:

You want to share some secret (i.e. hashed cookie or whatever) with the user.
You don't what to have any user involvement in protecting the secret, i.e. no login or whatever.
You want this to be save even if the computer was hacked.

This is impossible. If the computer is hacked the attacker can do everything which does not require any specific user interaction (like entering password only known to the user). This means that the attacker is able to access this secret and can use it. You might add some information about the computer into the secret (i.e. source IP, browser fingerprint...) so that it is hard to use the secret from another computer, but the attacker can still use the secret directly on the victims system.


What degree of physical destruction is sufficient to ensure an SSD is not readable? My organization has upgraded a few printers and decommissioned the internal SSD hard drives by passing the memory chips through a band saw, cutting each chip into halves, and in some cases tearing whole sections loose from the greenboard.

These printers were used in such a way that they likely have PHI / HIPAA information on them.

I am looking for advice on whether or not this method of destruction was sufficient or not.

I do not believe it is, but would like additional resources.

I have posted what I have found so far as an answer, as it may be the answer to my question, but I am hoping for other input.

No. It is not sufficient physical destruction to ensure that any data is unrecoverable by anyone.
According to
https://www.backblaze.com/blog/how-to-securely-recycle-or-dispose-of-your-ssd/, the memory chips themselves must be cut into 1/2 inch (1.27 cm) or smaller pieces.

It’s important to check the specs of any potential shredder to make sure the shred size is small enough to actually destroy the memory chips on your SSD, however. The shred width should be 1/2 inch or less if you want to make sure the chips get properly mashed up.
No, a woodchipper like the one from the movie Fargo does not have a suitable shred width for secure SSD disposal.
If your SSD looks like a hard disk drive, you should be able to take it apart with the right tools (usually the small screwdrivers included with a computer repair kit are all you need). Inside you’ll find the SATA memory chips where data is actually stored; you can remove them and destroy them however you see fit, whether it’s by a shredder or some other destructive means.


Continuous Integration for Exploit Development I have been thinking about this subject a lot. Exploit Development is nearly the same as normal development, you need to test quite a lot of platforms (eg. Windows XP, Windows Vista, x64, x86, Chinese, English versions). This problem asks for unit tests and continuous integration.

Till now I've been hacking some Python scripts to automatic launch metasploit load my custom exploit launch it. And as payload to set execute my back connector to tell me everything is going well. Now I can have one system on auto-update and get an alarm when then 0day has been fixed (without reporting it) or very quickly test a range of virtual systems.

I am wondering, if their are systems or papers out there on this subject. Things to consider etc etc.

Edit

I've upgraded my method by building the environment as well. I build deploy scripts for my exploits now, the script:

clones a VM
transfers the vulnerable version of the software from my
software library (read NAS)
installs the software with the most-basic (Next, Next, I Agree bot method for windows, apt-get install for Linux)
Checks if the software is running
Gets the port it is running on (netstat / grep hackish (very breakable)
Launch Exploit
Connect back
Write Result

It is cool still hoping to get at least one reply for my Bounty (+100..)

For checking if a vulnerability has been patched or not, why not just have a fixed value for EIP, say like DEADDAED and make sure it matches by getting the output through some debugging module. If it matches the vulnerability is still there.
If it doesn't match but the application crashes, you most likely have the vulnerability there but need to modify the exploit code for it to work properly.

For testing it on new versions, the exploit shouldn't work. For example, I have an IE exploit and the ASLR is bypassed using mshtml. If mshtml is updated in the next IE update, my exploit will not work because of the offset changes that have occurred in the patched mshtml. Unless maybe, you are using some other dll in which no changes have occurred.

As far as I can see it, you need to test it on one version of the software in concern to determine if it is patched or not.

The other parts of cloning a VM, updating the software etc. should be as you stated. The only thing with a MSI installer is you could try doing a silent install, so you avoid the dialog boxes.


How to check if a user's password has appeared in a breach? The latest advice (e.g. from NIST) recommends that user's password are checked against known breaches and compromised passwords are forbidden.

What are some relatively straightforward steps that a regular web dev who is not a security expert can take to implement this? Just knowing what breaches to use and where to download them is a start. It would also be helpful to have an opinion on how far a typical site should go (e.g. it's probably not necessary to continually monitor breaches and update your list).

Edit: Mostly interested in non-SAAS approaches

Perhaps the most popular password breach checking site, HaveIBeenPwned, supports a RESTful API which you can query as part of your password workflow.  It allows you to search a subset of the password hash and returns a set of possible matches for you to compare against the full hash; see this section of the documentation.

Because HaveIBeenPwned is updated with new breaches as they become available, you do not need to worry about monitoring breaches to take advantage of them.


Maintain sensitive key between requests EDIT: Reworked question. Previous version too poorly asked.

On my website users write sensitive messages that must be kept secret.
The entire user area is over SSL, so the communication between user and server should be fairly secure. Now I want to store the messages in a secure way, so that an attacker who gets access to the database can't read messages.

With the help of Security.SE, I'm currently implementing this encryption scheme Implementation review - Independent key, admin side and user side .

As you can see, userkey (uk) is something sensitive and it is generated at login time with PBKDF2 (with password and user salt). I can't require the user to input the password every time he wants to read a message, so I want to mantain the uk between requests. What's the best way to prevent that an attacker obtains uk?

I think I can generate uk at login time (when the user inputs the pass), encrypt it and store it.

I know that php sessions aren't so secure, apc_cache_info() could be very damaging, cookies can be stolen. So, IV in a cookie, key in APC cache, cipher in the session: attackers have to get the cookies, disk access, RAM access to decrypt the uk. Am I wrong?

What if I:

Generate a random key r
Generate a random initialization vector IV
Crypt the data (a PBKDF2 key, 100 rounds) with AES 128 CBC and with r as key and IV as IV
Store the cyphertext in the standard session data
Store the key in APC cache
Store the IV in a cookie
Fetch IV, r, and cipher when I need it, decrypt data and use it

I'd want to know if uk is now stored more securely. Could you suggest better way to do it?

Thanks a lot

The short answer to your stated question is that not knowing the IV makes AES, or really any block cipher in a proper operation mode, that much more impossible to brute-force, by basically making the IV an extension of the key. For AES-256, the 256-bit key plus a 128-bit IV basically requires your attacker to correctly guess a sequence of 384 bits, requiring a worst-case 2^384 attempts. Putting that in perspective, a computer running at the electron level at 100% thermal efficiency, given every photon our Sun will produce in its remaining lifetime, would only be able to try about 2^218 keys before the Sun goes black dwarf.

However, the IV is needed by both sides in order to encrypt/decrypt in any mode that uses one, and so, like other specifics about the encryption scheme except the actual key that would be shared between parties during negotiation (such as algorithm, mode, block size, key size) the IV is considered public information. It's possible to hide it, in the same ways that the key can be securely exchanged (offline, public-key crypto), but it isn't necessary.

With that question answered, I must say that there's a lot of information you haven't provided, that makes it impossible to answer the broader question of "is this scheme secure". For instance, how is the user's password related to the key (are you using a KDF or other "key-stretching" scheme?) What mode of operation are you using for the AES encryption (some modes are more secure than others, and some are effectively broken). EDIT: CBC mode isn't a terrible choice (there are worse) but care must be taken to ensure that your code cannot be used as a "padding oracle"; a "black box" that will tell an attacker whether a particular ciphertext message, when decrypted, is properly padded. That can be used to reverse-engineer the plaintext message from the known ciphertext without knowing the key. Since this is solely a server-side process and so no client code is available to use to decrypt, an attacker would need to penetrate pretty far in to be able to turn your server code into a padding oracle, but never assume; if you have a good implementation available to you, I would choose an authenticated mode, such as GCM or CCM, which will resist padding-oracle attacks.

I will also say that this scheme appears to be server-side only; if the key and IV are stored on the server only, then all encryption and decryption must happen there, which would mean that unless you're using something else such as SSL to send data to the client, the security of this particular piece is pretty moot.


Is this passwordless system secure? A person has a form that asks for a name and password. The password is sent to the server where a hash is created from hashing the name and password. This hash is converted into a number using the ascii value. The number is limited to 10 digits, and is used to seed a random number generator. Three random numbers are generated from 1-77616. These numbers are used to select words from a list of 77616 English words. The three words formed are used as the persons username.

77616^3 is roughly 2^48, so the probability of a collision after a million username generations should be ~0.001774778278169853.

Does this seem like a secure way to manage users, that way a login/register system doesn't have to be implemented? Is there any benefit of using this kind of system over a traditional login/register system?

No, this doesn't seem secure.

Collisions

Mersenne Twister is a deterministic RNG, so it's not suitable for most cryptographic tasks (although it's usage makes sense, because if it weren't deterministic, your approach would of course not work).

In this case, collisions would not happen at the stage you assume and base your calculations on. Instead, they would happen when you limit the ascii value to 10 digits, so the probability of collisions is way higher than you assume.

Comments on Approach

What you have is basically a home-made hashing function. You take some input, you apply some function(s) to it, and receive a fixed-length (3 words) output. The input space is larger than the output space, and it is impossible to reverse the procedure (get the password from the three stored words).

Don't roll your own and Don't be a Dave apply. To properly hash passwords, see How to securely hash passwords?.

You are still implementing a login and registration system (a user needs to enter username and password, you store it in some form, and can then later compare the stored value to newly entered values to authenticate the user).

If you would stop at this step: "The password is sent to the server where a hash is created", you would have an ordinary process. But instead, you add additional steps, which do not increase, but decrease, security.


Decrypting FDE in Disaster Recovery I saw a hot network question on SE, about Workplace Ethics - Do I give my password at work to my old boss after quitting?. My initial response (as are the answers in that question) is always NO. The reasons are highlighted there, and I'm sure all of you agree with me.

My question though is about one of the answers, talking about full disk encryption. For items like TrueCrypt, or maybe even BitLocker. They encrypt the disk, and use a passphrase to unlock it. I also know that Dell (and other companies, I'm sure) can have the hard drives encrypted before booting past the BIOS, again with a password.

With these methods, obviously just resetting a password in Active Directory or your Samba server won't give you access to the system. But what methods could an organization use that would allow Full Disk Encryption, but be able to recover or access the data if the employee leaves (i.e. Hit by a bus, fired, quit)? Or are there other considerations?

I should note though, that one of my previous employers used the Dell Hard Disk Encryption passwords, but it was set to our password, and we were free to change it whenever we wanted. An employee passed on, then all current laptops needed their passwords changed to ONE generic password, which I don't believe should be the case. Correct me if I'm wrong, though.

The usual method for recovery is to have a key escrow. Basically, full-disk encryption uses a symmetric key K. From the user's password p is derived another key Kp, which is used to encrypt K: the disk contains both all the data (encrypted with K) and EKp(K). When the user types his password, Kp is rebuilt, and then used to recover K. (This indirection allows for some interesting things, e.g. you can change your password without having to reencrypt the whole disk.)

A full-disk encryption solution will also store EKa(K), where Ka is the encryption key of an administrator or "recovery agent". This time, asymmetric encryption is often used (Ka is public, but the corresponding decryption key is known only to the recovery agent). If the password becomes unavailable (user forgot his password; user was fired; user died; user has been arrested on the Mexican border with 371 lb of Marijuana and won't be available for a few years;...), then the recovery agent can use his private key to recover K and thus unlock the data.

The key K is often called the "master key". The "recovery agent" can be an external device where a copy of K is stored (TrueCrypt calls that a rescue disk). In some systems the asymmetric encryption with Ka is skipped and a copy of the master key K is directly sent to the recovery agent (details vary depending on software solution and configuration options).

In any case, if your full-disk encryption does not offer at least some duly documented recovery options, then just don't use it.


How is password stolen over non-SSL connection? I am semi-embarrassed to ask this question having worked in the field for 20 years, but can someone describe to me why I should run SSL on any web site that uses authentication? I understand the bigger "why" issues (people use same password on blog and bank) and I am assuming that the passwords are stored encrypted on the site database, but I want to really, simply, explain the technical risk of transmitting non-SSL passwords in a way that is grounded in practical application.

Example: I have a wordpress blog I am hosting on bluehost. I go to the login page and enter my username and password and press submit. That information is sent to the web server in an unencrypted HTTP POST.

Now if someone is on my network or any network where the packets are broadcast, running a sniffer, they can get read the packets and write code to parse for interesting words like "login" or "password." Is that how it works?

How would this work in my example? Assume there is nobody on my home network--that otherwise, I have taken appropriate security measures for devices that are within my control. How does the hacker get in between me and my website? Would he or she just log on to their own bluehost account and be able to monitor all traffic on the subnet? Or could they be ANYWHERE in between; e.g. I'm on Verizon FIOS, so maybe they get onto (install an automated process) a server somewhere within the Verizon network. Or could they literally be anywhere?

My understanding of networking is that my device broadcasts packets with a destination IP that is the bluehost server. Those packets get "noticed" and resent by my router to upstream routers and switches that are part of the Verizon network. As they cross each subnet, the potential exists for any device sitting on that network to observe the packet as it is broadcast locally. Good practices would have those networks set up with security that did not result in people being able to get in the middle...but once the information gets to bluehost, then we are at their mercy in terms of broadcast packets. Once the http server "hears" the POSTed information, it encrypts and compares against the locally-encrypted password.

Is this an accurate way to think about it and explain to others?

When data is exchanged over the Internet, it hops from router to router, starting with the source (your desktop computer) and ending with the destination (the authentication server to which you are sending the password). All the routers, by definition, "see" the data. Moreover, all machines which are directly plugged with the link between any two routers can also see the data.

In practice, for low-level attackers, password sniffing mostly occurs through three mechanisms:

Close to the user (you). E.g. you are using your laptop and connecting through a WiFi access point; other machines connected to the same access point see all your traffic. Note that "taking steps" to prevent such local attackers can be quite difficult (for instance, forget it is WiFi is involved).
Close to the server. Typically, servers are mass-hosted in some shared facilities, and indelicate server owners may spy on their neighbours. Whether this is possible or even easy depends a lot on the competence of the network administrators at the hosting site.
Through active redirection. When you want to connect to a server, you actually type a name, and then the DNS finds the IP address which corresponds to that name. Your machine will send the packets to that IP address. However, the DNS, as a whole, is poorly protected, and can be altered by malicious individual. A bad guy may then transparently redirect your packets to his own machines; he may even inspect the data but still forward it to their true destination, which makes him a Man-in-the-Middle. At that point, the attacker sees all the data, including the password and whatever the password protects, and can hijack the connection at any time.

All three kinds of sniffing can be put into practice, and are actually applied, by students with a few hundreds of dollars of budget and a lack of morality. More advanced criminals can employ other active methods, e.g. trying to disturb dynamic routing mechanisms. Or simply bribe employees at network facilities (in particular Internet Service Providers).

SSL (now known as "TLS") fixes things in several ways:

It encrypts all the data with a key that only the two end points (your machine and the server) know, effectively keeping out passive eavesdroppers.
It uses the server's certificate, so that the client can gain some confidence that it is indeed talking to the intended genuine server, not an attacker-controlled fake. This is the point of the padlock picture and the scary warnings in Web browsers.
SSL ensures continuous integrity, meaning that an active attacker cannot simply put himself in MitM position, forward data bytes back and forth, and then hijack the connection after the authentication has taken place. The protection granted by SSL is both for confidentiality (data is unreadable by outsiders) and integrity (data cannot be altered by outsiders), and this encompasses the complete connection, not just the initial steps.

With SSL active and no certificate validation issue, you can send your password with reasonable guarantee that only the intended server will see it. How the server verifies the password is irrelevant here. Moreover, and again thanks to SSL, the server can assume that the initial authentication is valid for all subsequent traffic over the same connection, because SSL guarantees that it will be talking to the same client all along.


Why do some people think linux machine accounts with passwords are more secure than accounts without passwords? It seems to be a recurring theme that some people are dead set to add passwords to password less system accounts on Linux "because its more secure". I currently have regular discussions with customers about this. They themselves do not understand much about IT, however they have security experts scanning their systems and then have the finding that "that account does not have a password".

To my understanding, the contrary is the case. An account that does not have a password has one option less to authenticate. Or viewed differently, if there is no password, it cannot be brute forced. Do I miss anything? Is there any security benefit in adding a password to an account that technically does not need a password?

It really depends on what you call password less accounts. An account with an empty password in the password database (normally /etc/shadow) is highly unsecure because anybody could use it. On the other hand, an impossible to match password like * in same database prevents anybody to log with this account because no password could ever give such a hash. In the latter case, adding a password is just useless and actually lowers the account security because it could be brute forced.


Insecure to keystroke password via script (when paste doesn't work)? On my Mac, I need to authorize every system-protected action (installing new applications, etc) with an administrator user/password. I have set my main user account to work as a normal user with no admin-privileges.

I use a long password that is 30+ characters and to be honest, it's somewhat of a pain to type it in many times every day since I occasionally type it wrong.

I am therefore considering keeping my system password in a password manager (like 1Password), and then pasting it from the repository whenever I need it. The caveat here is that macOS doesn't allow pasting into system-password forms.

I figure that this ‘problem’ could be circumvented by an Alfred script that takes the clipboard contents (the password) and then executes an Apple script that keystrokes the contents of the clipboard string to the password input.

Before I even consider trying this, I would like to understand if this would undermine security in some significant or insignificant way.

I recon that Apple has disabled the possibility of pasting system passwords for some reason. Does having sensitive information in the clipboard make it more susceptible for hostile interceptions, compared to passwords that are typed directly and never coherently enter the clipboard?

Having your password in the clipboard is not safe at all. An attacker would just have to read the contents of your clipboard to elevate his privileges on your system.

Many of the usb 2 factor authentication devices has a button that can type your password when you press it. It sounds similar to using the clipboard but the idea is that you keep the usb key with you when you step away from the computer. I believe yubikey has a smart card version that works with Mac.


What, if any, URL protocols should I whitelist or blacklist when spawning the user's browser? I'm writing an app using Electron but I'd assume this would be a problem for any software that lets you open links in the user's default browser through the OS.

Let's say I have app that reads something like a twitter feed and displays it. So the app displays 10 entries. Some of those entries have user supplied links. If the user clicks a link I want to launch it in the user's default browser.

In Electron I'm told I should call electron.shell.openExternal(url). Do I need to be filtering URLs? Common URLs are for example http://xxx, https://xxx, mailto:xxx so I could just whitelist those 3 types of URLs. At the same time I don't want to wrongly limit good functionality. In other words I have no idea what other valid schemas there are. Allow ftp://? sftp://? gopher://? So I'd prefer to just pass everything through.

At the same time I'm worried, are there are potentially bad URLs? Hypothetical example: 3rdpartyAppWithScriptingHandler://evil.script

Should I whitelist? Blacklist? Filter? If so what's the filter? Or should I just pass them to OS?

Should I whitelist? Blacklist? Filter? If so what's the filter? Or should I just pass them to OS?

You should whitelist. I would go for a sensible minimum of http:, https:, mailto: and optionally ftp:. Including more protocols is unnecessary if you don't have a special use case in mind. That said some systems are more permissive than others. The Wordpress docs define this list of safe protocols in their wp_allowed_protocols() function:

  Array of allowed protocols. Defaults to an array containing 'http',
  'https', 'ftp', 'ftps', 'mailto', 'news', 'irc', 'gopher', 'nntp',
  'feed', 'telnet', 'mms', 'rtsp', 'svn', 'tel', 'fax', 'xmpp', and
  'webcal'.

None of these are inherently unsafe but you will not have any use case for a fax: or gopher: URL.

  At the same time I'm worried, are there are potentially bad URLs?

There are pseudo-protocols that have side effects. javascript: URLs should definitely not be possible. The file: scheme is dangerous as well because local files are often more privileged than web content. For Firefox you especially don't want to allow chrome: and resource: URIs.

This is a good example for a problem where only whitelisting works since it's not possible to keep track of all the custom URI schemes and their effects for every single browser.


Authenticating requests between APIs I am building an application (“A”) that can interface with a 3rd Party data API (“B”).  A is commissioned by Organization “X”, which has data on B.  Users of A need access to Org X’s data on B.  However, B has no record of A’s users.

A and B live on different servers and communicate through public internet.  User’s of A login with username and password and are issued an expiring access-token that authenticates HTTPs requests to A’s data API.  My question is how to best secure communications from A’s data API to B’s data API.

In other words, what is the best way to ensure request’s to B are really coming from A?  Should A store some kind of non-expiring Bearer-token that B can authenticate?

Note that the developers of B have agreed to make some modifications to B in an effort provide A the data it needs, but modifications should aim to be minor.

Since these are backend calls, there are a few options you can do:

Certificates : SSL/TLS allows mutual authentication whereby you have both end to end encryption and authentication at once.  If you enable client certificates on API A (and check it on B), and vice versa - you have a strong tunnel.  Furthermore, you can use certificate pinning - in which case it may be okay to use self signed certificates.  As long as Api B can verify that A's private key was used to sign the traffic sent, you have this trust.
Shared secret : You can encrypt the traffic with a shared secret between both parties (A and B), this would of course require that you have strong secrets and a healthy key rotation policy.  The shared secret will act as authentication (ie: if you know the secret, you're the right party).  This could be seen as an API key or anything that's known to both parties, but no one else.
Token based : You can get bearer tokens from a general Identity provider (IdP); which Api A will get with a appID / Secret combination.  The (trusted) IdP will create a signed token which APi B can validate and henceforth, trust that the request came from 'A', as verified by a trusted 3rd party, namely the IdP.

Needless to say, Api B should be accessible over an HTTPS connection, and as defense in dept you could ACL network devices in between.


One-Way Data Transfer Cable Is there a cable that physically only supports data flow in one direction (out)? The idea here is to put this on a system that can only export data so that there is very minimal risk of the transmitting system 'getting' attacked (assuming there are no other attack vectors).

It is possible to make one-way Ethernet cables. This site has lots of pointers to various documentations for that. Note that things change depending on whether you are doing 10 MBits/s, 100 MBits/s or 1 Gbits/s (10 MBits/s is easy: simply cut off one pair; 100 MBit/s is tricky; gigabit seems infeasible since the signal uses phase modulation over all eight wirse).

In one situation (which is currently deployed in production !) I used an audio cable, plugged into the "out" port of the audio card of one machine (the green port) and the "line in" port of another machine (the pink port). The advantage of using an audio port is that it is very easy to visually inspect the cable and verify that, indeed, data will be constrained to flow in one direction only. The problem, though, is that data now has to be encoded as audio, which is doable but tends to have an awfully low bandwidth (my implementation got 300 bauds...). In my case, this was for a root certification authority, which has to sign CRL regularly, but must remain offline at all times.

(My initial idea was to use an actual speaker-and-microphone contraption, but an audio cable works better in a noisy server room.)

Audio, Ethernet, and any other medium (people with skills at practical electronics might want to use a laser diode and a photodiode), share the common disadvantage of being, indeed, absolutely one-way. This means that you won't get any acknowledge or flow control; there will be no TCP. The sender has to emit the data and hope for the best. You will organize the transfer with some checksums (to guard against transmission errors) and a lot of repetitions; error-correcting codes may also be an option. In my CA situation, I just had to send a CRL whose length was below 1 Kbyte, and it changed only once per week, so there was no real issue here.


How to access sites whose DNS server is under attack? As many of you noticed, last night's DDoS attack against Dyn.com made many major services unavailable, including Twitter and Spotify. Spending one Friday evening without Twitter was enough and I want to be prepared if this ever occurs again.

The way I understand this attack is that the services themselves (Twitter, Spotify, Reddit...) were not under attack, but the gateway (DNS server, a.k.a Dyn) was, so if I just knew a way to access these sites without relying on the affected DNS server, I should be able to access them? Are there any methods for doing this, or is this simply not possible?

One method I stumbled upon is to use OpenDNS servers, as they cache most of the DNS responses and can therefore provide them even if the actual DNS server is down. (I haven't tested this and I don't know if it should even work)

Before answering your question, i will explain how Internet works.

When we open a website in a browser (or through any other way), our browser first does a DNS request for that domain and then send HTTP request to the web server.

Suppose, we have typed www.stackexchange.com in our browser, then -

DNS request will go to resolver; query will be like - what is an IP address of www.stackexchange.com
If resolver doesn't have the answer (A record in our case) in its cache or if TTL has been expired, then
Resolver does the recursive query for that domain and if able to reach to authoritative servers for said domain, then resolver answer our query.
After getting the IP address of the website, browser send a HTTP request to the web-server and show the result.

Below image shows how recursive query happens in DNS --

Now comes to your question:

  If i just knew a way to access these sites without relying on the affected DNS server, I should be able to access them? Are there any methods for doing this, or is this simply not possible?

Internet in its standard format works in a way as i explained above.
Standards says, you should respect the TTL value. No standard DNS implementation (be it BIND, UNBOUND or any other) supports caching of the domain entries after expiration of TTL value.

If you really want to achieve such thing, then you have to tweak the code accordingly (I will not suggest you to do this at all; Reason is explained below).

Issues involved in not respecting TTL value -
Suppose, you have cached the IP address for a domain and you are relying on your cache, after expiration of TTL;
And domain owner changes the IP address of its domain (for any reason whatsoever);
You will keep on going to the same IP address which is there in your cache;
You will land to the OLD IP address each and every time; And you will not find any data there.

In case domain is signed (i.e., DNSSEC implementation), things will going to be really messy; if you don't respect TTL value.


TLS Cipher Suites for MTA When configuring a mailgateway’s TLS Settings, should one stick to the same rules for Cipher Suites as in running a HTTPS Service (prefer EDCHE/DHE, disable SSLv3, not use stuff like RC4, etc.) or should one focus more on compatibility with other MTAs to prevent email getting sent unencrypted?

It seems to me that it’s a tradeoff. On the one hand, if I use only strong Cipher Suites I’m improving the security of a majority of mails transferred because you can’t downgrade to weak Cipher Suites or SSLv3. But on the other hand, I give up encryption for some mails altogether, because they get sent unencrypted (if the other MTA is extremly old and supports only RC4, for example).

Even with ciphers using 3DES or RC4 an attacker is not able to crack the cipher with moderate costs. And even secret services would probably rather do DNS MX spoofing or simply strip the STARTTLS from the features of the receiving MTA because this is much cheaper than trying to crack such ciphers.

Therefore I recommend that you accept ciphers with RC4 and 3DES in case the peer MTA can have no better ciphers, because bad encryption is definitely better than plain text and in many cases also better than not delivering the mail at all. Of course you should put these weak ciphers only at the end of your list and prefer the strong ones. And you should not use way to weak ciphers like the EXPORT ciphers.

But, if you in an environment with higher security requirements you should configure your MTA to only use strong ciphers and to make TLS mandatory, i.e. no fallback to plain even if the peer does not seem to support TLS. And you should protect yourself against MX spoofing too, i.e. enforce DNSSec. Apart from that you better use end-to-end encryption (PGP, S/MIME) in such an environment anyway.