"If encryption has not been implemented, a comparable alternative has been implemented" What constitutes as a comparable alternative to encryption? I know that password keepers and other services are not comparable and are not considered encryption.

If the context is authorized access only, does unmounting offline drives in a locked up location classify as a comparable alternative for example.

This is in context with HIPAA/URAC. Data storage, user information, and sensitive type information. Nothing in terms of networks or traffic communications.

Disclaimer; I haven't done HIPAA work for over a decade, and reality may vary from history.  I welcome comments and alternative answers from someone currently working in the space.

The encryption specifications of HIPAA are "addressable", which is to say, they're not "required".  You can choose to do something else as long as you document in writing that you believe your alternative is a "reasonable and appropriate security measure":

  In meeting standards that contain addressable implementation
  specifications, a covered entity will do one of the following for each
  addressable specification:

  (a) implement the addressable implementation specifications;

  (b) implement one or more alternative security measures to accomplish the same purpose;

  (c) not implement either an addressable implementation specification or an alternative.

  The covered entity’s choice must be documented. The covered entity
  must decide whether a given addressable implementation specification
  is a reasonable and appropriate security measure to apply within its
  particular security framework.

So, you can choose to implement encryption, or to lock the drives in a drawer, or to do nothing at all - as long as you document that your decision that it is a "reasonable and appropriate security measure."

Now, in reality, you'll want to implement solutions that your auditors agree are reasonable and appropriate, or it goes on the report as a gap.  Your management will want there not to be gaps on any audits, or their susceptibility to fines goes up.  And when something bad happens, those documents that accept the risk of doing it otherwise become even more important.

So the best answer I can give you is to get a reputable auditor to review and approve any alternatives you consider.  HIPAA is known for being hard to implement for this reason.


Is it possible to execute Server Side Scripts despite Content-Type header? Say, there's an upload function where users are supposed to upload images only. However, it's possible to upload arbitrary files bypassing the restriction.

Say, I uploaded a shell (aspx) and requested the corresponding resource. As I've read, it's possible to execute such shell code in some scenarios. The server, however, is setting a Content-Type response header as image/png.

I also Googled, and found that it's possible to execute php code by embedding php code directly into the JPEG image. So, my question here is;
- Does the server executes server side code despite Content-Type header?
- If not, in what cases it's possible to execute codes directly instead of by embedding it inside the image?
- Is there any similar way for aspx codes?

The first question, as it appears to me, isn't it the server which sets the Content-Type header? So, I believed the code should have executed before the page is rendered.

Please, help me clear things.

In a perfect (and bugless!) world, it would not be possible. An image file should always be recognized as an image file by the web server and handled as such, this means:

Setting the mime-type accordingly for a proper display on user's browser,
Raw file data sent to the user's browser: no script executed.

However, things turn wrong when there are possibilities to trick the web server into thinking that this .jpg file is actually an ASP (or whatever) script to be executed. The web server will then open this file as a script, execute its content, a be screwed...


Impact of Root certificate Renewal I have generated a good number of leaf certificates with my root CA but now it(Root) has expired. Even though leaf certificates have a longer expiry date than root CA, they also expired due to expiration of Root CA. Do leaf certificates will still valid if I renew the Root CA with the same keys or Do I need to generate new leaf certificates again with renewed CA?

If you renew (same key, same name) the Root CA certificate then the leaf certificates will still validate.  A certificate's identity is defined by its key and name, and if neither change then it's effectively the same certificate.  All a renewal does is change the validity period of the original certificate.
Contrast the above with a re-key (new key, same name) where the identity has now changed and you'll need to resign the leaf certificates (or preferably just the online CA you have in place for these sort of situations).


Visa Secure / TAN App showing wrong amount charged So, the other day I was charging my prepaid VoIP account from sipgate.de via credit card payment. I chose 10 Eur which is the default and entered my card details.
As usual, I was redirected to a different payment processor which itself redirects me to a page hosted by my bank asking me to confirm the payment (Visa Secure). The confirmation dialog showed an amount of 1 Eur instead of 10 Eur. To confirm the payment, my banking app on my mobile got notified. The app also showed 1 Eur.
I confirmed, because I thought the worst that could happen is the payment failing or me getting 10 Eur balance for 1 Eur. It succeeded and I got 10 Eur added to my VoIP balance.
But when I looked at my banking account later, it showed that indeed I was charged 10 Eur, not 1 Eur.
Somehow the Website of my Bank and the App (different devices) were showing the wrong amount charged.
I contacted my bank, but I haven't heard back so far.
So... Are there any legit (but obviously not obvious) explanations for that? Or is the payment system of my Bank broken?
Disclaimer: This MAY be specific to payment used in Germany... Not Sure how this is handled in other countries.

Got a reply from my bank yesterday.
They confirmed that I authorized a 1 Eur payment to sipgate and that sipgate charged me 10 Eur instead.
This is possible because sipgate cancelled the 1 Eur transaction I authorized and then sent a 10 Eur transaction afterwards. The cancelled transaction doesn't show up anywhere in my account and I did not have to confirm or was notified of the 10 Eur transaction.
The bank confirmed this as valid process.
For me this shows how broken the payment system is. The authorization I have to do is just to guarantee the merchant that I gave him valid credit card data he can charge me from. But I have no control at all. The merchant can charge whatever amount, whenever he wants, as often he wants.
The fact that I just authorized a 1 Eur payment is worth nothing.


How can a company ensure cybercriminals destroy hacked data after payment? Cloud computing provider Blackbaud reported on https://www.blackbaud.com/securityincident "...the cybercriminal removed a copy of a subset of data from our self-hosted environment. ... we paid the cybercriminal’s demand with confirmation that the copy they removed had been destroyed."
How can the company be certain that the data is destroyed, and what reparation can it get if it is found later that the data is passed on after payment?
I couldn't find any technical solution on Google. I guess the only assurance is the criminals' "reputation": if these particular criminals are well-known, and word gets out that they leaked the data despite being paid, future are victims less willing to pay them(?).

How can the company be certain that the data is destroyed,

It cannot be certain. The only hope that it is part of the criminals business model to maintain a good reputation in that one gets what is claimed.
But business models might change. For example if the existing ransomware business does not provide enough profit anymore it might be worth checking if one can get more profits from previously collected (and not actually deleted) data.

... what reparation can it get if it is found later that the data is passed on after payment?

None. They are dealing with criminals in the first place.


Google thinks I am a robot when using proxy, but only in Safari Google greeted me with this message while being behind a private proxy:

  Our systems have detected unusual traffic from your computer network.
  This page checks to see if it's really you sending the requests, and
  not a robot.

I did my research and is seems that this is caused by automated searching, which I am not doing. I guessed that someone was doing automated search with the proxy I have (private proxy ehhh?). Now comes the part I don't understand and it differs from other questions: This only happens while using Safari and does not when using Chrome. Why is that? Did the automated searcher used Safari's User-Agent? I thought that google bans everyone using the same IP as the bot, which is unpleasant when using mobile bandwidth.

Google's new reCAPTCHA uses cookies:

  To put it simply: user’s past behavior and previous CAPTCHA solves are recorded in their cookies, which are then detected by future reCAPTCHA challenges.

So seeing different behavior in different browsers isn't surprising. You may find that using an incognito/private browser window changes the behavior.


Obtaining e-mail address at registration In a registration form the user is asked for his e-mail address. The e-mail address will be validated for the correct format (e.g. at the least contains @) and I'm considering checking if it's already registered. Would this pose a security risk as it would allow attackers to verify e-mail addresses of users with accounts? If yes how can the threat be mitigated?

To avoid this kind of leak, you could also begin the registration process by asking for the e-mail. After entering it, you would send an e-mail with a link so that the user could continue with the registration process. If the e-mail was already registered, you would send an e-mail saying that.

That way, only the owner of the e-mail could register.

Drawbacks:

probably the real, common users will get bored by having so much steps to register.
in very few cases simple revealing that an e-mail is already registered in a site is a problem, specially because it's easy to register at any site providing any e-mail that you want. You'll just won't receive the e-mail to activate your account, but in general the site will link the account / username to that e-mail.


Browser security - Firefox + NoScript is better than Google Chrome? I saw that NoScript + Firefox combination blocks all "dynamic content" (especially those spammy ads). I really like that. It reduces the chances of being exploited.

But, chrome only asks me to allow flash and some other plugins for some sites. It looks like FF + NS is much better than chrome.

Is that really the case ?

For starters, Chrome has better security features and a larger security effort than Firefox.

It's true that JavaScript can be involved in exploitation and exploit kits use JS to hide exploits and profile the browser for exploitation. But disabling JS should not be considered a silver bullet for browser security.

More than just blocking JS, NoScript brings to Firefox security features which Chrome already has, like XSS protection. And features that Chrome lacks, like Clickjacking protection and protection against plugin based attacks. Take into consideration that NoScript will also increase the attack surface.

There isn't a clear winner here considering that the security of Firefox + NoScript depends on the user configuring NoScript and the usability trade-off.

For more about browser security read the Browser Security Handbook by Michal Zalewski. His book, The Tangled Web: A Guide to Securing Modern Web Applications extends this handbook.


What service could penetrate my Firewall via UDP on Port 17275? Has anyone monitored various requests from all over the world on Port 17275 via UDP?
My firewall logs show huge amounts of such requests from lots of different IP Adresses.

I can't find any documented service which shall use this port.
Anyone knows what piece of software may cause these requests?

Port 17275 is not registered to any specific service so it can be any application that's configured to listen on that port.

Remember that:

Well Known Ports are: 0 through 1023.
Registered Ports are: 1024 through 49151.
Dynamic/Private are: 49152 through 65535.

Some googling shows that several pieces of malware seem to use this specific port for communications.


Calling string functions safely I wish to implement some user callable functions in my code. I use something like this:

function funcTest(){

    echo "This is test function";

}

if (isset($_GET['cmd']))
{
    $func = "func".$_GET['cmd'];
    $func();

}
else echo "ERROR";

Is the code safe? Can someone execute arbitrary functions? I didn't find a way but I want to be sure as it's an important project.

You do not sanitize your user input, that by itself is considered bad practise. Although I don't think it can be exploited, perhaps the following code is considered more secure.

    <?php

      function x()
      {
         // what ever this function should do
      }

      function y()
      {
         // what ever this function should do
      }

      function z()
      {
         // what ever this function should do
      }

      $func = yourInputFilerFunction($_GET['cmd']);

      switch ($func) {
        case "x":
            x();
            break;
        case "y":
            y();
            break;
        case "z":
            z();
            break;
      }
    ?>

When the parameter 'cmd' is tampered with, the script will not do anything. In your case, the script will try to load a function based on the cmd variable.

If the function does not exist, PHP will throw an error and possibly discloses information about the system such as the internal path.


Using Selenium tool for xss scripts Ok, so i need to know can Selenium webdriver tool be used for testing xss vulnerabilities and exploits. If its possible, then pleasee provide me with some example or tutorial. Apologizes, if am wrong to ask this question.

If you boil an XSS exploit down to the basics, it's just inserting text in a field. In this regard, yes Selenium WebDriver could be used to carry out an XSS attack by inserting the appropriate code into text fields.

That said, there is a lot more to effecting an XSS attack than just inserting a script into text fields. You could just scan pages for text fields and blindly insert your payload, hoping for the best, but I wouldn't imagine it being a very effective delivery system. Then you come to the hurdle of verifying whether or not a payload was successful or not. You could reload the page and scan the DOM for your script, obviously countering any nasty surprises you inserted, and verify it that way but it doesn't sound very efficient. There is a research/discovery period in any successful attack unless you just hope to strike it lucky.

From a test automation / QA point of view I could see it being useful in terms of pen testing or regression testing. You can attempt to carry out XSS attacks on fields within your web application. Inserting script tags and ensuring the input is either rejected or handled properly depending on the expected outcome could be useful.

It really depends what your goal is. Are you looking to test and secure your own app or find vulnerabilities in others?


Is it secure to show admin pages only on certain host? I have public website with no database (with static content). I have one admin page, which allows to edit static content. I want to use that page only when website is on my local computer but not when it's uploaded to hosting server.

Is it safe to add check in admin page for $_SERVER['HTTP_HOST'] or $_SERVER['SERVER_NAME'] to be equal to localhost?

$_SERVER["HTTP_HOST"] is unsafe, as it relies on the HTTP request - meaning it can be manipulated by the client.

You should implement a basic login system for this (or use Apache's folder protection)


Verifying that no malicious certificate has been issued while a DNS record was pointing to an uncontrolled IP Given the scenario that:

Victim rents VM1 from a cloud provider, and points his/her DNS record to that VM1's IP address
Victim deletes VM1 and switches to a different cloud provider, and creates VM2 there, but forgets to modify the DNS record (before deleting the old VM, but after creating the new VM)
The Victim's DNS record is now pointing to an uncontrolled IP, which could be claimed by Attacker
A few days later, Victim realizes that the DNS record was not modified, and points the record  VM2, thus fixing the issue
Victim issues a new certificate for the domain on VM2, using e.g. Let's Encrypt

In the few days between Step 3 and Step 4, Attacker could have taken control over the IP the DNS record was pointed to.
Attacker could have issued a new certificate with e.g. Let's Encrypt, using which, Attacker could have obtained a private key & certificate for the domain, valid for at least 3 months. Attacker could use this obtained (and still valid) certificate in the future to perform MITM attacks between Victim and VM2 since the certificate would be valid, even after Victim modifies the DNS record.
Is it possible for Victim to verify that no malicious certificates were issued in the few days between Step 3 and Step 4?

Is searching for new entries in Certificate Transparency logs sufficient? What if an authority doesn't log the new certificate publicly?
If it is not possible to verify that no certificate was issued, should Victim stop using that domain (and its subdomains) completely? How long should Victim wait before using the domain name again (to make sure any malicious certificates previously issued expire)?

TL;DR: Yes, checking for that domain in any public CT Log viewer and finding only certs that you bought will give you pretty high confidence that no malicious certs were issued to that domain.

Yup, I totally agree with you that an attacker could have gotten a VM at that IP and that would have been sufficient to get through the automated domain validation checks and gotten a cert. You talk about the attacker getting a cert from Let's Encrypt, but unless the victim had set up a DNS CAA record for their domain:

CAA records allow domain owners to declare which certificate authorities are allowed to issue a certificate for a domain.

then the attacker could get a cert from any CA, and some CAs offer certs with lifetimes up to a year.

Solution: *Superhero music blares* Certificate Transparency to the rescue!
The catch with CT is that some browsers enforce it and others don't, there is no global requirement from the CA/Browser Forum that CAs log to CT.

Chrome (and I think also Chromium) strongly require CT logging on every web site cert since 30 April 2018 or the browser will throw errors (source).
Safari looks like they are starting to require it, though that's news to me and that page is dated Mar 2021 (source).
Firefox does not require or check CT logs (source).

That said, I can't imagine that there are any major CAs who do business by only being in the Firefox root store and not Chrome's or Safari's, so it's a pretty safe bet that all majar CAs CT log every cert they produce to Google's standard.

Summary: Yes, checking for that domain in any public CT Log viewer and finding only certs that you bought will give you pretty high confidence that no malicious certs were issued to that domain.


Wouldn't forging the balance of a prepaid telephone card allow to make a lot of calls? Suppose I have a prepaid public telephone card containing £5 in it. Now I connect this card to my laptop and figure out where in the card £5 is stored. I then change this to £5000, and leave the rest of the card untouched.

Wouldn't this modification allow me to make many calls for the total cost of £4900, even if originally I could have only used £5?

Back in the 90s these prepay cards were easily hacked in a number of ways. First, as you said, people could reprogram them with much larger amounts for free calls. A more low-tech method was that they'd simply scratch off or cover the conductive surface on the pin which decreased the amount on the card, allowing for infinite free calls on a one-time topup. These systems are now almost universally obsolete.

Modern prepay cards usually use one of two methods.

In some cases they'll contain just a numeric identifier (ID) and your balance will be maintained on a remote server, which is the case with many MAN systems. These are usually the most secure, but they have a downside: you need continuous connectivity between the phone system and the remote server.

However, in some scenarios (particularly remote areas with poor infrastructure) the validation can't be done against a remote server. Instead, the prepay card is a smart card (similar to a SIM) with certain functions exposed. Each function requires a different access key. One function is "charge an amount to the card", and the key for this is present in a payphone box. However, this key can't be used to access the "add funds to the card" function, which is only accessible by top-up devices in stores. The keys in top-up devices are kept in tamper-sensitive systems, similar to how chip & pin machines work. The actual amount value on the SIM is kept in an encrypted form within a tamper-proof EEPROM (or similar), with an authenticity record maintained using a key pair deployed in the phones and top-up machines. Attacking these is very difficult, but potentially possible if you compromise a top-up machine.


Amazon EC2 Abuse Report My company recently received an email from Amazon which notified us of malicious activities occurring on our running EC2 Instance.

The email states:
We observed machines under your control participating in a DDoS attack
targeting Google IPs.

The attack was a UDP amplification attack. In this attack, a UDP-based
service is abused to attack others, wasting your bandwidth and computing
resources.

I am fairly new to all of this stuff in addition to AWS and have no idea as to where to start. What should be the first steps for me to take to mitigate this?

After running the commands from @ximaera

Davids-MacBook-Pro:~ davidpham$ ntpdc -nc monlist *ip*
*ip*: timed out, nothing received
***Request timed out
Davids-MacBook-Pro:~ davidpham$ dig @ip +edns=0 +ignore com ANY

<<>> DiG 9.10.6 <<>> @ip +edns=0 +ignore com ANY
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
Davids-MacBook-Pro:~ davidpham$

This was the output I received. Am i missing something?

Generally, there's a long list of servers and protocols vulnerable for UDP amplification. A few command line calls to determine the presence of some of the most prominent amplification vectors might be found here. All the commands should better be invoked remotely. E.g. if your server is 192.0.2.1, then, to check for an NTP amplifier, you do

ntpdc -nc monlist 192.0.2.1

from your laptop or an adjacent datacenter machine.

I'd recommend to check NTP and DNS first, and if there's no match, then to dive into details.

tcpdump -ni any udp on the server itself will definitely help you to dive. If you're able to spot any traffic you don't expect to see in the dump, you can then track down the vulnerable application listening on the port seen in the dump by looking (or greping) at the output of ss -lpn.

EDIT. So now, as you've provided the IP address of your server, I've been able to check it myself, and it turns out you have a PORTMAP amplifier active:

$ rpcinfo -T udp $ip | wc -l
      17
$

So you basically needed to go through the rest of the checks past DNS and NTP ones.

The fix is obviously to disable port mapper (here's how you do it on Debian/Ubuntu) or at least block the access to the port 111/UDP via firewall.


Running SSH on a different port vs adding the port number to a password So, a pretty typical piece of advice is to run SSH on a high port number, thus decreasing the chances of it being attacked. The thing I have always wondered about though is that it seems more secure to run SSH on the standard port and just add an arbitrary number between 1.000 and 10.000 to the end of your password rather than using a non standard SSH port. My reasoning for this is that it adds the same amount of secrecy/obscurity (where I use the word 'obscurity' in the sense that passwords and keys are security through obscurity), however with a port as soon as you hit the correct number you receive confirmation from the server. With a password however you need the fully correct password before you receive confirmation.

Just to be very clear here, I am comparing the following two situations:

Username: user, Password: password2938, Port: 22
Username: user, Password: password, Port: 2938

and yes, I do know that using pubkey authentication is better, however it has certain disadvantages when it comes to usability (something which is not a valid concern on production servers, but is often a valid concern on private systems).

Is this reasoning correct and is the advice to run SSH on non-standard port numbers therefore incorrect/weak?

A password with increased complexity is great, but if there is an exploit against the server software (OpenSSH or otherwise) that you're running, it won't help.  The idea behind an obscure high port number is that it won't be attacked in the first place, but there are caveats to consider:

High ports introduce an additional security risk.  If the SSH server goes down, a local user can stand up a new SSH server on the same port.  Only ports 1-1024 are restricted to the root user, so your alternate port should be in that range.  (This cuts both ways: port scanners only examine these ports, so you're less hidden.)

This is security through obscurity and should be considered "extra" but it should not be considered a part of the security when calculating entropy and risk.  It's not bad to be obscure, but it is bad to assume that obscurity provides sufficient security.  Adapting a quote from @barbecue:

  Obscurity is to security as camouflage is to armor.One makes it harder to find you, the other protects you once you have been found.

You might get fewer attacks on port 2938, but a weak password is a weak password.

I really like your idea of comparing the password entropy of whatever to whatever2938 (*changed from password and password2938 for reasons noted below), which I calculate to be 17 bits vs 30 bits, showing that the longer password is certainly more secure, but in order to model this properly, you'd have to get statistics on how many port-22-bound attackers would eventually break that longer password versus how many attackers that would both find the nonstandard port and break the shorter password, and even that analysis would have to assume the same rate of persistence even though attacks are increasing in both frequency and sophistication.

Instead, I'd recommend something like Fail2ban, which can recognize failed logins and ban the IP that attempted them (by default, Fail2ban blocks an IP for ten minutes after ten failed logins within ten minutes, but this is all configurable).  This limits attacks to trying one password a minute, so whatever would take about a week to break and even a more typical (yet still weak) password like Da5id would take 12+ years (222.6 ÷ 365 ÷ 24 ÷ 60 = 12) of non-stop password checking, which is presumably enough time to get you to notice the attempts in the logs.

Do not think that this makes weak passwords like Da5idRox a good idea.  Fail2ban only runs on the SSH server; somebody with shell access would break this in two weeks.

Of course, there's nothing stopping you from doing it all.  Add complexity to your password, use an alternate port, and block IPs with too many failures.  An additional obfuscation technique you could try is port knocking, which can even be done securely if the knock itself is encrypted end-to-end or uses a one-time password.

* A minor note: I changed the question's sample passwords to use whatever rather than password because password is a special case.  Common passwords like password (and simple variations) are best assumed to an entropy around 0–5, so e.g. p455w0rDz has an entropy of around 12, which is weaker than L%.  In the above math, I've instead assumed you meant a random dictionary word, which has an entropy of 17 bits). More on password complexity calculations.


Does the BitTorrent protocol expose my home IP address, even over VPN/Tor? I am filesharing from home using a BitTorrent client in one of three scenarios:

I am using my regular ISP connection
I am using a tunnel (VPN) connection
I am using a Tor connection (a)

Obviously I expose my home IP address in scenario 1, how else would my peers be able to share with me? But I have this notion (citation needed) that even in scenarios 2 and 3, the way the BitTorrent protocol works means that it exposes my home IP address anyway. Is this true?

Footnotes

(a) Do not do this.

The answer to #2 depends a little bit on your VPN provider and how the routing is configured. VPNs that you subscribe to for privacy should hide your IP properly.

The easiest answer is found by performing a test. Do a google search for "bittorrent ip leak" and you'll find results for tests that provide you with your IP address when using a BitTorrent client.

For #3, the answer depends a bit too. It's worth noting that in 2010 the Tor project itself doesn't recommend using Tor for BitTorrent: https://blog.torproject.org/bittorrent-over-tor-isnt-good-idea. It's possible that your BitTorrent client may ignore your proxy settings, for example. I'd recommend to test this by performing a similar test as in #2.


Are consumer-grade routers any more or less vulnerable? I apologize if this is an obvious question, I'm not very familiar with hardware.

I am planning on hosting a few personal websites from my home, but I'm concerned about my security. I'm using a fairly old cable router (probably around 10 years old I would guess, it's ASUS RX3041). I was wondering if it would be possible for an attacker to send some malicious packets and gain access to my router or be able to send packets to computers connected to the router on ports that are not mapped, or any other exploit, really.

Even if the router was compromised, the server should still be secured with its own firewall and what not but what I want to know is if I can rely on the router as a security layer.

Is it reliable to host a website with my current setup?

TL:DR - Yes, routers CAN be vulnerable.

Misconfigured/Unconfigured routers -
A ton of people just install their routers and leave the default accounts turned on without modification. Thus allowing attackers easy access.

Vulnerable built in scripts - http://www.reddit.com/r/netsec/comments/1xy9k6/that_new_linksys_worm/

See:

What is the "Moose" worm and how can I protect myself from it?
http://www.pcworld.com/article/2899732/at-least-700000-routers-given-to-customers-by-isps-are-vulnerable-to-hacking.html
http://www.pcworld.com/article/2464300/fifteen-new-vulnerabilities-reported-during-router-hacking-contest.html
http://searchsecurity.techtarget.com/news/4500246976/NetUSB-router-vulnerability-puts-devices-in-jeopardy

As for answering whether your 'current setup' is secure. We would need a bit more information about the entire scope of your security onion before being able to answer that.


Would an official  HTML (6?) element/wrapper combat XSS effectively? Would it not be possible to use such a method to wrap areas where user input/output is expected (eg. comment boxes), so that even if a script is successfully injected through regex evasion, the script will not run since it falls within a certain HTML wrapper set up to disable all scripts within it?

Problems with your approach

No, this wouldn't work. The problems are:

An attacker can still inject tags. They can inject </disablescripts> to inject scripts and thus gain XSS.
It affects usability. What if I want to leave a comment that is: You can use </disablescripts> to exit the new HTML6 feature. After that, anything in <script>alert(1)</script> will be executed. That comment would not display correctly.
XSS is dangerous, but you shouldn't underestimate HTML injection, which would still be possible with your approach and allows to change the look and functionality of a website, which may be used for phishing attacks, defacement, and possibly even privilege escalation.

And that's not even considering the practicality of it. The problem with XSS is that developers often don't know where user input is expected. If they knew, they would HTML encode it already. But for some reason, they lost sight of what is user input and what isn't.

The same problem exists with your proposed idea: How does a developer know what areas likely contain JavaScript? Even if it was working, your approach would at best be a second line of defense, in addition to the proper solutions to XSS.

Better approaches to XSS

Better approaches are:

HTML encoding in HTML contexts, escaping in JavaScript contexts
Using something like HTMLPurifier if a limited subset of HTML is required
Use some templating engine or other mechanism that allows the automatic encoding of all variables (to ensure that none are forgot).
If you do not have inline JavaScript, use a content security policy such as script-src self https://cdn1.com. Only modern browsers will follow it, but they will not execute any injected inline scripts, and will only load external scripts from allowed sites.


Is the method of hardening the creation of a Cryptographically Generated Address (CGA) called hash extension CGAs are sha1 hashes truncated to a 59 bit value. Along with a 3 bit security parameter they form a IPv6 address (more precisely the interface identifier).

from wikipedia:

  The Sec parameter implements a hash extension by enforcing the first 16 times Sec bits of another hash, Hash2, to be 0

and...

  For a CGA with Sec equal to 0, this means that the cost of finding a set of CGA Parameters that yield the desired 59 bits is approximately O(2^{59}) (in big O notation). A larger value of Sec, however, increases this cost by a factor of 2^{16\times Sec} to O(2^{59+16\times Sec}) because the first 16 times Sec bits of Hash2 then become relevant (i.e. it implements a hash extension by demanding those bits to be equal to 0)

Is hash extension a known name for this method? Are there other examples where this kind method is applied?

in the CGA protocol in section 7.2 RFC3972 the technique is called hash extension.
It seems to be a method used particularly for CGAs and seems not to be well known in other scenarios.


Vulnerability of challenge-response (authentication) protocols to on-line man-in-the-middle attacks Are all challenge-response (or other authentication) protocols vulnerable to on-line main-in-the-middle attacks?

Let's say Alice wants to setup a connection with Bob (e.g. she wants to login on a server). Bob sends her a random number, r. Alice then replies with a MAC of the random number, using her password. Bob knows that only Alice can do this and logs her into the server.

But what if, during all this time, there was an on-line adversary between Alice and Bob. He can intercept r and sent it to Alice himself. He could spoof the IP of the server so Alice thinks it's coming from Bob. Alice then sends her response and again the adversary intercepts it and sends it to the server. The adversary just forwarded the message so Bob still accepts it as correct and logs-in the adversary. He now has setup a connection with Bob, in the name of Alice.

Is my reasoning correct? I assume that, because of this, you will never use challenge-response protocols to login a user or start a session. If I'm not mistaking, using session keys protects against this attack and allows a safe connection.

Your assumption is true if Alice and Bob must rely solely on this single communication channel and have no kind of knowledge about the other party before establishing the connection.

But consider the case that Alice has a key pair where the public key is public and thus known to Bob but the private key is only known to Alice. In this case of existing previous knowledge Bob can send a challenge to Alice which she can sign with the private key. This signature can be verified by Bob using the public key. A man in the middle cannot fake it since he has no access to the private key.

This mechanism can be made more flexible with a Public Key Innfrastructure (PKI) so that Bob does not need to know all the public keys of all possible Alice's but only need to trust a certificate agency which issues certificates for these Alice's. And this is basically the way the server is authenticated in SSL/TLS in order to detect man in the middle attacks.

Note that public key cryptography is not the only way previous knowledge could be used to defend against such man in the middle attacks. A secret shared between both sides of the communication would work too as long as the man in the middle attacker does not know the secret. But public key cryptography using a PKI scales better if many parties are involved.


How to spare file server data from being held hostage by client ransomware? Suppose in a network there is a file server which's storage is shared between all workstations and all users require full read/write access to this storage for their cooperation workflow. (Over samba, afd and nfs)

If (at least) one client gets infected by ransomware, how can that infection be kept from encrypting/affecting the whole file servers data?

The only effective countermeassure I can think of is to forbid write access and only explicitly grant it on request for all write/delete actions, but this seems to introduce a big organizational overhead.

I'm not asking how to recover from such a szenario - backups are in place that should keep the damage minimal in such a case.

I'd rather not use these backups and keep the effect of the infection local, e.g. keep it off the server altogether.

Generally, make sure you enforce the least privilege principle as much as you can. Evaluate the damage that would be done to the business if a ransomware encrypts all the files and balance it against the overhead which would be introduced by applying more restrictions.

You could also deploy a monitoring system which monitors the write access of every user. If some user writes to an unusual amount of files in a defined time, you could trigger an action like killing the connection to the share and throwing an notification to you.

Another measure is introducing a staging area. In this area everything is writable. At a defined point (after an amount of time of after a project or task is finished) files in this area are moved to a read-only part and can only be modified by request.


Can a host OS be attacked through the network stack? Forenote: I'm not familiar with how virtualisation works on a low-level (but I'd certainly like to learn) so this question could arise from ignorance.
Example Scenario: One virtualised router is connected to a networked device. Appropriate firewall rules are in place (on the virtualised router) to ensure the device cannot communicate directly with the router and cannot contact any other networked device. However as the router is virtualised, network traffic must traverse the host OS and be passed onto the VM.
Question: Could a malicious device specifically craft a packet to cause undesired behaviour on the host when being sent through the network stack, thus gaining access to the host OS?

All what is needed are bugs in the network stack of the target. And network stacks can be a complex beast and thus bugs are not unlikely. See for example CVE-2016-1287 where "crafted UDP packets" could "allow the attacker to execute arbitrary code and obtain full control of the system or to cause a reload of the affected system."


Security issues with PHP Sandbox I am working on a PHP sandbox for a Web Application Honeypot. The PHP sandbox will analyze a PHP file that may have been injected as part of an RFI attack. It should run the file in a safe environment and return the result, embedding the output of the PHP script. We hope to fool the attacker into believing that this is a genuine response and thus continue with the next step of his attack.

In order to build the sandbox, we used the Advance PHP Debugger (ADP). Using the rename_function and override_function, vulnerable PHP functions have been rewritten. Some functions such as exec,disk_free_space have been rewritten to send out fake replies. All the others function just return nothing. Here's a complete list of the functions that have been considered.

Also, the input script is run only for a maximum of 10 seconds in the sandbox. After that, the entire sandbox process gets killed.

Is this list good enough? Does this make the sandbox secure enough to be made part of the web app honeypot?
Beside blocking function calls like this, are there anymore security measures that should be taken?
In the end, this is a honeypot. So, we would like our reply to be as close as possible to a real reply. So, by blocking DNS function calls like dns_check_record and gethostbyname are we restricting the scope of execution for the script unnecessarily. (I am not sure why they are present in the first place)

In short, I would like to know what elements I should add/delete from the list.
Any other suggestions/advice on how to go about this will be highly appreciated.

I'm far from being a PHP expert, so my comments are more general rather than specific.

Probably not entirely, but it depends. I don't think that any whitelist/blacklist approach can ever be 100% accurate. There will always be a case of false positives or false negatives. So you're always balancing between hits (of a script being able to still penetrate through your defences) and misses (i.e. successfully blocking the script, but in such a way that doesn't allow you further analysis). PHP must have thousands of different calls and permutations, so building a waterproof list is very difficult. That said, the list on a very quick glance looks ok as a starting point. Again, my php experience is limited.
I'm not sure what you meant when you said "to be made part of the web app", but I would rather strongly advise against embedding this with anything that is even remotely connected or in proximity to real data or any real production application. If this is a honeypot, it should probably be kept in as much isolation as possible. You should consider things like:

Running this on a dedicated hardware machine which gets regularly 'refreshed' (re-imaged, built from scratch)
Don't let it connect to anything other than the outside world
Don't store any sensitive (or even not so sensitive) data on it
Log all access and use an external firewall with verbose logging
Use internal OS system logging
Monitor anything even remotely strange on any of your logs
Consider throttling the speed of the external connection

If the system is isolated well enough, then the main remaining risk besides to itself, is to other systems. Assuming the attackers went through your php protection layer successfully, your honeypot can be used to launch external attacks onto other systems - spam, denial of service, act as part of a botnet etc. This is why keeping it in isolation, keeping a close eye on it, as well as trashing and starting from scratch is a good idea.
Unfortunately I cannot answer that more than I already covered on 1.
See 2.


How to encrypt something with a key? I read a lot about security on the internet, especially how services like telegram work with their encryption and how they do it. I also heard of the Diffie-Hellman Key Exchange, which was quite difficult to understand, but now I get the point.

My question is: lets say I implemented this whole stuff and I have some keys. How do I actually encrypt something with these keys? Are there any Pre-made functions in some languages? I literally have no idea how I can encrypt something when I have both parts that I need, the payload to encrypt and a key or some sort of encryption key. Any help is appreciated :)

Yes, there are libraries for most programming languages. For example, for PHP see: http://php.net/manual/en/mcrypt.examples.php for some examples.

I would also recommend that you start out with basic, symmetric encryption (both sides have the same, 'pre-shared' key), before starting on the complicated stuff with private/public key pairs.


token _csrf in an url POST I wanted to know if it was a bad thing to have a _csrf token stored in a url. I saw that in a POST request that allows me to upload a file, the _csrf token was displayed in the url. Is it sensitive to store this token in a url. Is there a way to exploit this vulnerability ?
Thank you for your answers.

Transmitting sensitive information using an HTTP GET request should be avoided at all times, as it could be cached or end up in (proxy) server log files.
I do consider a session based anti-CSRF token as sensitive information. As the name suggests, the token is valid for the duration of the entire session.
As far as exploiting this, this might be rather hard, but it could be exploited when multiple vulnerabilities are present in the application.
Without any other type of vulnerabilities I consider the likelihood quite low.


Books about Penetration Testing What are the books you advise describing methods or steps required to make a successful penetration test?

I have a base knowledge of common security checks, but it would be great if someone more experienced describes the full test.

I am partial to the appsec side of penetration-testing.

Hunting Security Bugs
The Art of Software Security Assessment
Secure Programming with Static Analysis
Open-Source Fuzzing Tools
Fuzzing for Software Security Testing and Quality Assurance
Gray Hat Hacking, 3rd Edition
Advanced Windows Debugging
How to Break Software
Seven Deadliest Web Application Attacks
SQL Injection Attacks and Defense
Identifying Malicious Code through Reverse Engineering
The Shellcoder's Handbook (both 1st and 2nd Edition since they vary so greatly in content)
A Guide to Kernel Exploitation: Attacking the Core
Managed Code Rootkits
Mobile Application Security
Why Programs Fail, 2nd Edition
The Mac Hacker's Handbook
Gray Hat Python
The Software Vulnerability Guide
Hacking Exposed Linux, 3rd Edition
Code Reading: An Open-Souce Perspective

Most of the other answers seemed to be focused on web pen-testing or network pen-testing.

If you really want to learn network pen-testing, I'm surprised there has been no mention of:

Silence on the Wire
Network Security Assessment, 2nd Edition
Aggressive Network Self-Defense
Hacking Exposed Cisco Networks: Cisco Security Secrets & Solutions
Securing the Smart Grid: Next Generation Power Grid Security (useful for more than just Smart Grid stuff -- invaluable, and up-to-date resource for network, web, and app pen-testing)
Unauthorized Access: Physical Penetration-Testing for IT Security Teams
The Hacker's Handbook: The Strategy Behind Breaking Into and Defending Networks

If you want to learn the business process side of pen-testing, you'll have to check out Valsmith and H.D. Moore's work on Tactical Exploitation. I also recommend the Trace Security "Social Engineering: The Art of Human Hacking" book and the older "No Tech Hacking: A Guide to Social Engineering, Dumpster Diving, and Shoulder Surfing" from people who seem to have done PTES style pen-tests hundreds of times and let go with some practical knowledge of how to deal with situations instead of just technology.

You also may want to check out some fiction (e.g. Zero Day, Stealing the Network: The Complete Series Collector's Edition, Final Chapters) and some non-fiction (Zero Day Threat, Fatal System Error, No Place to Hide, etc). Yes, I've read all of this stuff except Zero Day: A Novel, which I just started. Haven't heard much about "The Lure" or Kingpin yet, but I plan on checking those out as well.


Service traffic hijacking, how does cloud make it worse? I read an article from CSA that they rank service traffic hijacking as the #3 threat to cloud-services. Why is it worse for the user if an attacker hijacks its service traffic on cloud? What new exploits can the attacker take advantage of in a cloud-service compared to before?
I had a hard time phrasing this question so if anything is unclear please ask.

I don't think that the impacts of account or service hijacking are necessarily worse when using cloud providers, but that does depend on what you're doing in the cloud.  Because you're using a service provider instead of hosting the application yourself you can sometimes incur unexpected usage charges due to fraud (i.e. someone charging a bunch of server time to do bitcoin mining).  If you don't catch the fraudulent use in time it can cost you thousands of dollars.

Due to the urgency some providers have had to quickly deploy solutions and start making money they don't all make security a priority.  That can result in bugs or architecture flaws that make vulnerabilities easier to find.  Again, this isn't unique to cloud applications, when compared to internal applications, but attackers may have more incentive to find a vulnerability in a system with a lot of customers instead of a system used by a single customer.

It's also possible that by moving applications to a cloud provider you are exposing data or services that were previously better protected inside your organization's network.  While attacks against internal systems do happen, they tend to be less frequent and more difficult for an outsider to carry out.  The added accessibility of a cloud-based system may make it easier for an attacker to obtain credentials and carry out theft or fraud.


How can websites with URL traversal functionality protect itself from revealing its IP? A good number of websites these days are not served directly over the internet, but through an intermediate providers, such as Cloudflare and Incapsula.

A basic premise of the security provided by these services involves not revealing the original IP of the server. Websites often leak their IP through MX records or through "direct" DNS records.

We'll now assume a website which does not leak its IP through such common techniques. The website, however, has some form of an URL traversal functionality controlled by the user, such as:

A website screenshot service
Generation of "link cards" on social networking websites
"Redirect checker" websites

Now, all the attacker needs to do is to type in an URL pointing to his own server and observe the server's request log. In the case of the "screenshot" services, it is even more trivial to do so: the attacker simply needs to point it to one of the "What is my IP" websites, and voilà: they have your IP.

What set of mitigations can be used to handle this IP leakage effectively?

It generally all comes down to the question: how important this functionality is for your business?

Option A: said URL traversal functionality isn't very important for the Web site. Say, that site can do a lot of things, and taking screenshot is a feature the site can more or less still live without.

Then it's enough to use any VPN or proxy on a different IP address (or, better, in a completely different IP network or even ISP/hosting provider) to connect to untrusted sites. Make sure the proxy doesn't set X-Forwarded-For, Forwarded or X-Real-IP HTTP headers (some of them do it by default). Also make sure all service traffic like DNS queries is routed through the same proxy or VPN.

Option B: the URL traversal is a part of the core business critical functionality, the Web site won't run without it.

Then a DDoS mitigation of some sort should be applied there too.

Good news: compared to the complexity of a typical Layer 7 DDoS protection nowadays, protecting such a functionality is rather simple: a provider only needs a decent amount of bandwidth and a stateful firewall with a TCP connection tracking ability near the network border.
Bad news: as of early 2018, neither Cloudflare nor Incapsula can do that, so you need to choose another provider for that. If you happen to have your own IP prefix and an autonomous system number, probably a BGP-based DDoS protection suits you even better than DNS-based one in this case, especially as we currently are running out of IPv4 address space.


To what extent are countermeasures against side-channel attacks effective/ used regularly by everyone? I'm doing an Extended Essay for IB right now and I'm doing it on how secure RSA is.

As side-channel attacks are one category of attack, I was wondering (as I am struggling with the conclusion) while there are countermeasures, is it true that most of them do not offer absolute privacy, but rather they only reduce risk? Are there any absolute solutions to any existing side channel attacks?

Since these countermeasures are not widely known to the general public, is it true that people may not employ those measures. Is it also true that most consumer standard devices usually don't have these measures built into them?

is it true that most of them do not offer absolute privacy, but rather they only reduce risk?

No, many of them completely eliminate the risk. Using constant time implementations of algorithms and not branching on secret-dependent conditions ensures that secrets being processed provably have no effect on timing, making such side-channel attacks impossible. Some cryptographic algorithms, like Ed25519, are designed to make implementations with comprehensive side-channel resistance in mind possible and practical. In other cases, the hardware itself is designed to make side-channel attacks difficult to pull off. AES-NI in many modern x86 processors is one example of that. It is an instruction set which provides acceleration for AES encryption and additionally runs in constant time.

  Are there any absolute solutions to any existing side channel attacks?

For some classes of side-channel attacks such as those based on timing, yes. See above. For the more advanced attacks that involve things such as differential power analysis, there is very often no way to completely avoid them, short of using specialized microprocessors designed specifically for security, such as those used in Hardware Security Modules (HSMs). Cheap consumer electronics are unlikely to take such measures as they bring the base manufacturing cost up.

There are a large number of different side-channel attacks. Generally, they fall into three categories:

Attacks which are done by executing code on the same system upon which secrets are being processed. These attacks include timing attacks and cache attacks and can be done remotely and without physical access if code execution on the target device is possible. Mitigation involves secure software design. This is the easiest attack to pull off, and the easiest to mitigate.
Attacks which require passive monitoring of the hardware. Differential power analysis and thermal imaging attacks fall into this category. It requires physical access to the target device and often very specialized equipment, but can be done even without code execution on the target.
Fault attacks where errors are triggered in the device by doing things such as feeding an IC with the incorrect voltage or an unstable clock in a process called glitching. Even side-channel resistant software can be vulnerable to this. Sometimes this can even involve physically removing the surface of a chip and shooting it with a tightly-focused laser to trigger faults. The results of these faults can sometimes be detected through side-channel attacks. This often results in physical destruction of the device and, naturally, requires physical access.

Mitigating the first is usually possible to do cheaply in software. Mitigating the second may or may not be possible in software depending on the actual attack, and mitigating the third is rarely possible in software, although fault attack-resistant software can be designed with sufficient expertise.

  Since these countermeasures are not widely known to the general public, is it true that people may not employ those measures. Is it also true that most consumer standard devices usually don't have these measures built into them?

It is often true, especially when the product does not use an established and popular library like OpenSSL which provide these mitigations and instead attempt to design it on their own. Those devices are often highly vulnerable to side-channel attacks, and abusing those weaknesses can be practical.

Unfortunately, the only cases where standard consumer devices do use such mitigations is with DRM in order to prevent their users from jailbreaking their own devices or running their own code on them. Companies which do that naturally care more about avoiding piracy (at the expense of restricting users' freedom) than about security against malicious attacks. This is because, in their threat model, the adversary is you, the device owner, not someone who is out to get your private information.


PRTK with 7Zip AES-256 encryption I've been running Access Data Password Recovery Toolkit (PRTK) on a bunch of encrypted archives (all zip files, I think they were encrypted with 7Zip AES-256) for a while and haven't had any hits. I decided to test if PRTK is working at all and made a simple AES-256 encrypted zip file with 7Zip.

The password was 'password' and I made a dictionary consisting of only the word 'password'. I turned off all the other dictionaries and every rule except for the 'dictionary primaries' rule and the 'as is' rule.

Surely enough the crack finished in less than a second and said that it didn't find anything.

Any ideas why this is happening? I feel like I've probably wasted the last couple of weeks trying to crack files that PRTK can't even crack.

I never managed to crack the archive I wanted to, but John The Ripper can crack these AES-256 encrypted archives.


JWT tokens size problem I'm developing a single-page-app that interacts with an oAuth based service. This service grants JWT tokens (refresh and access) for a lot of resources. Potentially the number of tokens can be anywhere between 2 and 100.

My question is- where should I store those tokens?

Cookies has a size limit of 4KB, and each token is roughly 1KB, so that's a no go.
Session storage solves that problem but is exposed to XSS, and will not persist if the user opens a new tab of my app.

Is there a best practice here? Is there a way to utilize session storage but keep it more secure somehow?

First thought is that it does seem to be quite a lot of tokens and it does beg the question if it's indeed a requirement for the authorization server to issue so many specific tokens or if less tokens with more broader applicability could suffice.

However, focusing on your question...

Besides the sessionStorage there is also localStorage which would tackle the issue of sharing between multiple tabs.

As you correctly pointed out, storing between cookies and web storage does present different security challenges, one being, that web storage is vulnerable to XSS while an HTTP-only cookie is not. However, a HTTP-only cookie used for authentication is vulnerable to CSRF because it's automatically included by the browser, while a token stored in web storage is not.

At the days end, choosing the right storage is choosing the pros and cons that best adjust to your specific scenario. For a better idea on the impact of your choices check this answer on StackOverflow. It covers the pros and cons of the following options:

Option 1 - Web Storage (localStorage or sessionStorage)
Option 2 - HTTP-only cookie
Option 3 - Javascript accessible cookie ignored by server-side

For the ones that don't follow links, I include the conclusions part inline:

  My recommendation for most common scenarios would be to go with Option 1, mostly because:

  If you create a Web application you need to deal with XSS; always, independently of where you store your tokens
  If you don't use cookie-based authentication CSRF should not even pop up on your radar so it's one less thing to worry about

  Also note that the cookie based options are also quite different, for Option 3 cookies are used purely as a storage mechanism so it's almost as if it was an implementation detail of the client-side. However, Option 2 means a more traditional way of dealing with authentication; for a further read on this cookies vs token thing you may find this article interesting: Cookies vs Tokens: The Definitive Guide.

  Finally, none of the options mention it, but use of HTTPS is mandatory of course, which would mean cookies should be created appropriately to take that in consideration.


If someone breaks encryption, how do they know they're successful? Let's say I have a file containing a random bunch of bits and then I encrypt it using some modern algorithm (Blowfish, AES, or whatever). If someone captures the file and mounts a brute force attack on it, how will they know they've successfully decrypted it?  It would be obvious if the original input was meaningful, but in this case the original input was just a bunch of random bytes.  How would they know, if at all, that this was the CORRECT bunch of random bytes?

They wouldn't. The problem you described is well-addressed in the Wikipedia article on Unicity Distance. That article also links to one by Bruce Schneier that may be more accessible.


Is it possible to sign/verify a key-pair? We currently have the need to authenticate and verify generated keypairs. Our system allows users to register for our service which generates them a key-pair for use on our network. We are in need of a way to authenticate key-pairs so that we can verify they were generated by us, and not by someone else.

Is it possible to sign each of the generated key-pairs with a master key that can then be used to verify each generated key-pair? I thought this must be possible because it is somewhat similar to the way in which certificates work.

EDIT: To be more clear on what I am after. We are developing a decentralized content network (as a proof of concept). Authoritive Content Providers (those who are authoritive over the content they serve) will be allowed to register their "domain name" via a master registry. This master registry will maintain a master keypair that is used. The registry will issue the content provider a keypair that can be used to digitally sign their content and any information transmitted so that the client can verify that the person transmitting the data is authoritive over the domain name. The issue we are having is how to communicate to the client when we issue a new key pair to a new authoritive host? We thought that if we could sign each keypair with the master registries keypair, then we could hardcode the public key into the client and use it to verify each keypair.

What you are describing is the exact problem of public key distribution that PKI is meant to solve. When your "master key pair" is used to sign the public key of an authoritative content provider for a specific domain, then you are issuing a certificate linking the domain name with a public key. That is what you are intending to do, and that's PKI, whether you want it or not.

Where private keys are generated is orthogonal to the issue. A content provider obtains a certificate (key pair linked to its domain name) through some procedure designed to ensure that only the right provider obtains the private key. There are many ways to organize such a procedure, and the key pair may be generated on your side or on the provider side. Generally speaking, it is preferable that private keys are generated on the provider side, because otherwise the private key has to travel, and we don't like it when private keys travel. But that's only the general assertion; in practice, the context matters a lot. E.g. if you meet the provider's people physically, you can arrange for a physically protected transfer of the private key itself, or of a big fat password which was used to encrypt the private key.

As for the actual formats and protocols, it is highly recommended that you stick to existing standards, i.e. X.509 in the case of certificates. The main reason for that is that the software which is easiest to develop is the software which has already been developed. You will find a lot of X.509 support in the tools you are already using, integrated in your programming framework (e.g. both Java and .NET handle certificates natively) or as extra opensource libraries. It is tempting to reinvent your own format, but experience has repeatedly shown that it is a bad idea. The core point is that it is very hard to design a secure cryptographic protocol properly; it is easy to have something "which works", but the "secure" part is the difficult one, especially since it cannot be tested. Do yourself a favour: don't reinvent the wheel. NIH is called a "syndrome" for good reasons.


How will social networks (like Facebook) prevent their facial recognition software being abused to render Witness Protection Programs useless? We're now close to or already at a stage where large social networks can recognize people from photos with facial recognition even without any context such as mutual friends. Facebook announced recognizing faces without being tagged well over a year ago and we can only expect technology has improved since then.

If someone goes into a witness protection program and gets a new identity then building their new lives, even from the other side of the world, is now potentially at risk. Previously large criminal organizations could possibly have paid off the witness protection program agents, but this is an expected attack vector and I'm sure government programs protect themselves from that somewhat.
But what would it take for criminal organizations to pay off some high-ranking Facebook engineers in order to see if there are any recent matches for a number of portraits they supply? Could they reliably restrict access to such lookups even to those on the infrastructure side of things that simply need low level access to databases?

How could or do these networks protect people from abuse of their system?

They probably won't. After all, dispelling and selling everyone's not-so-well-kept secrets - where they live, who they know, where they shop and what for... - is the social networks' business.

Reaching this data is unlikely to require anything as dramatic as bribing high-ranking fb engineers. Face recognition data is largely used in the open, with the advertised goal of helping users find their own photos, and it will likely be sold to third parties. It doesn't even matter if the social network itself has face recognition, as the photos themselves are in the open; others can run their own software on them.

Even without face recognition, it's a challenge to maintain two isolated social network identities (including non-simultaneously). Are you going to stop liking and reposting the same pages? Similar pages, views? Do you remember every one of your online-only friends so as not to add them again? It will only take a careless move or two, maybe even by your new friends, to create a connection. Not enough to pinpoint you, just to create a search circle around your old identity, and from there it's one step to your new identity's picture being recognized.

The simple answer is, social networks are not compatible with privacy. Their explicit goal is to put your life online and that's what they do. Their privacy restrictions are paper-thin and suitable for protection against minor embarrassment, not life and death situations.

Fortunately, social network use is still not mandatory. As long as there's enough non-users that they don't stick out (we're still on that edge), the choice exists.


Twitter's HTTP response vs Google's HTTP response I was looking at the HTTP responses form https://twitter.com and https://encrypted.google.com.  These two responses have interesting similarities and differences in their security definitions.

Both Twitter and Google have these header elements in common for the purposes of security:

X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Server: *custom*
Expires: *in the past*
Cache-Control: private***

However, twitter has a more extensive cache-control declaration and uses HSTS:

cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
strict-transport-security: max-age=631138519

Questions:

Is there any reason not to use HSTS?  Is Google depending on
HSTS preloading, and "normal" web application should enable
HSTS?
Are Google users more susceptible to Cache related information
disclosure than Twitter users because of the differing cache-control definition?

For completeness I have included the full HTTP header for both sites.

The HTTP response from https://encrypted.google.com:

HTTP/1.1 200 OK
Date: Sun, 06 Oct 2013 19:27:33 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=REMOVED
P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Alternate-Protocol: 443:quic
Content-Length: 100392

The HTTP response from https://twitter.com:

HTTP/1.1 200 OK
cache-control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Content-Length: 50221
content-type: text/html;charset=utf-8
date: Sun, 06 Oct 2013 19:33:08 GMT
expires: Tue, 31 Mar 1981 05:00:00 GMT
last-modified: Sun, 06 Oct 2013 19:33:08 GMT
ms: S
pragma: no-cache
server: tfe
set-cookie: _twitter_sess=REMOVED
status: 200 OK
strict-transport-security: max-age=631138519
x-frame-options: SAMEORIGIN
x-transaction: 699d2669d76b27f5
x-ua-compatible: IE=10,chrome=1
x-xss-protection: 1; mode=block

Google is not using HSTS enforcement. Neither in preloading nor headers. The preloaded HSTS entry in Chrome is set to "OPPORTUNISTIC" which basically means "unenforced", though it contains a set of allowed certificate hashes to prevent MITM.

Google's redirect to https depends on browser detection criteria, such as user-agent. I don't know precisely what criteria they check, but for example browsing google.com using Links does not redirect to https, and searching over unencrypted channels is still allowed, though browsing from Chrome will redirect (with a 302) to https. Furthermore, many URLs on the domain are not redirected to https no matter what browser you use. For example: http://www.google.com/services/

Their reason for not requiring SSL is not explicitly documented anywhere, but it probably has to do with the fact that doing so might "break things" -- albeit poorly-written things, most likely. The current trajectory seems to point toward migrating all of Google over to SSL, but they're doing so one piece at a time. My best guess would be to expect HSTS enforcement within 5 years.

The cache-control difference reflects the fact that Google's homepage is static, while Twitter's is constantly updated with new tweets. Google allows the browser to (privately) cache the search box splash page for a limited time, but twitter requires a reload in order to fetch the latest batch of deep philosophical insights from all your Twitter friends.

As for cache-related information disclosures; I'm not aware of any. The Google homepage contains no personal information unless delivered over HTTPS (in which case you get that bar at the top), which limits disclosure potential.


Files deleted by some Employee . How to find what time it happened and whether done from another computer on network? My Files got deleted by any Employee . How to find what time it happened and whether done from another computer on network ? The files were in shared drive in the computer. I am using windows 8. What are best tools to recover the files.

First of all, in such cases stop using the network drive. Deleted files are not immediately lost but just marked as "this space can be reused". If no need of additional space presents itself, a file may be fully recoverable years later. On the other hand, if a new file needs to be created and requires space, the deleted file area might be overwritten after a few seconds.

So, the less you write to the drive, the better.

The first line of defense should have been a full, adequate and updated backup. A file is deleted -- you just laugh it off and recover the file from the repository.

Second line of defense, before blaming someone's malice, be sure to rule out inexperience and clumsiness. The file might have been unwittingly dragged and dropped on a nearby folder by someone trying to open it with a double click. Weird, but I've seen that happen. So first of all, unless you already tried, try running a search for the file name in the whole drive.

As a last stand, if the file was indeed deleted, recovery depends on the file system on the network drive, while logging capability depends on its operating system.

For example: if the network drive is on a Windows system, NTFS - if you were sharing a folder in your own computer - then you might be able to easily recover the file using Recuva or any of several "undelete" utilities. If you're in luck, the Shadow Copy facility is activated and you will be able to directly access "Previous versions of this directory" from the Explorer interface on the server (you can't do that from the network, AFAIK).

On these systems, though, it is unlikely that logging facilities are running, especially with the level of detail you would need to have a culprit.

If it is a Linux system, recovery is usually more difficult (you'll need an ext* undelete tool - assuming the filesystem is EXT3/EXT4; undelete support for EXT3/4 is more complicated than in NTFS), but chances are that the file sharing system is Samba and both access times and maybe even operations (logged on a per-workstation basis) are available in the Samba logs. Here for example is a connection from my PC to my home server some time ago:

zotac (::ffff:192.168.4.24) connect to service public initially as user
lserni (uid=1000, gid=100) (pid 11642) [2012/05/03 17:20:07.499617,  1]

The workstation name (zotac), its IP address and the username are all logged. It is possible, but not the default since log files tend to grow huge, to log file-level operations (create, rename, delete).

Other possibilities are trying to locate old versions of the file, and verifying that the employee - if he did the deed with malice and forethought - has accessed or copied the file on his own workstation (just check Recent Files and Documents). I witnessed a case where an employee had copied the whole customers' archive on a USB key before attempting to overwrite the master database on the server. It was never clear whether he intended to hold the database for ransom, or he maybe planned to sell it to some competitor (in the end the PTB agreed on a "good faith mistake" and "let" the employee resign for reasons of health).


PCI-DSS and salt storage PCI-DSS states the following:

  3.5 Protect any keys used to secure cardholder data against disclosure and misuse

I have a service which stores a salted bcrypt hash of the user's PAN. Assuming the bcrypt algorithm is adjusted for significant slowness, how does the 3.5 requirement apply to the salt used to calculate the hash? Do I have to protect it like a common data encryption key?

In my opinion, you don't. The salt cannot be used directly to get the clear PAN back, so it is not subject to requirement 3.5.


Metasploit: Example Exploit for Windows 7 / Windows Server 2016 For testing purposes of a logging solution, I would like to simulate an attack by using Metasploit against a Windows 7 / Windows 2016 server. However, I am struggling to find a reliable exploit that actually spawns a root shell on the victim machine.
Initially, I tried to identify a reliable MSF module to be used during the exploit. I selected windows/http/icecast_header as it seems to be more or less independent of the underlying OS version (Win 7 vs. Win 2016). Thus, I installed the vulnerable Icecast version on the victim machine and configured the MSF module. However, as stated before, I am getting a Exploit completed, but no session was created.. On the victim machine, the server simply crashes and I am getting a message "Icecast2win MFC Application has stopped working".
Thus, my actual question is: Do you know of a reliable MSF mdoule that works on Windows 7 / 2016 that I can use for testing purposes?
Thanks,
André

You will have better luck with Windows 7 than Server 2016. The go-to is MS17-010. You would need to enable SMBv1 and ensure that it is not patched for that version. You can ensure that it's vulnerable first with Metasploit or nmap (nmap target -p445 --script=smb-vuln-ms17-010).
For Server 2016, I would recommend looking at a web vulnerability. For instance, you can install Tomcat and then use Metasploit to upload a malicious WAR file. This would produce a shell in the context of the user running the web service.


Sharing Wi-Fi with rental dorm using different frequenzy bands? We're in the process of renting out our house dorm, and discussing networking options. We currently got an ASUS router that's broadcasting both a 2.4GHz and a 5GHz network.

The question is: Would it introduce a security concern to allow the rental takers access to our 2.4GHz network, whilst we would continue using the 5GHz one? They're both connected to the same router, so I have a feeling that this could be a security problem. Thought it is worth mentioning that the administrator account of the router interface is changed from the default admin/admin combination.

With out any more details I would say yes, this is a bad idea.

2.4ghz and 5ghz are not isolated even if you give them both separate SSIDs they will still connect to the same network, both 2.4 and 5 traffic will use the same network.

you would basically just deciding who gets the faster wireless speed.


Using multiple hashes to verify a file I'm dreaming of a service where a client sends my service a hash of a file that they generate locally from that file. The idea is that having such a hash would be enough to show that the user is actually holding that file.

My service would rely on nobody being able to create hash collisions, preferably in the future as well. In other words, nobody should be able to create a slightly changed file (i.e. change a word in a pdf or in an image) that would generate the same hash as another file. Simple hash security stuff that all the non-broken hash functions can manage, but what I'm worried about is longevity. Would a hash generated today be still safe in 10 years?

So, my question is, would it not be a good idea to design the API so that the user would need to generate and send multiple hashes with different hash functions? Wouldn't it be a lot more difficult (even in 10 years time) to design hash collisions that collide in all those hash functions? My gut feeling is that my thinking is wrong, but I cannot figure out why it would be.

Given that none of the common hashes has actually a mathematically proven resistance against attacks it is not a bad idea to use multiple hashes with different algorithms at the same time. This idea is not new and there are already some place where it is used. To get the best security improvement it might be useful to use algorithms which are based on very different ideas, like SHA-2 (i.e. SHA-256, SHA-384) and SHA-3.


Are VPN users identifiable by matching their connection to the VPN server? Given a nation-state has full access to the logs of the ISPs operating on its territory and given it knows that a certain activity has been conducted by a user from its territory, can they do the following:

when starting their investigation, they trace initially the IP to a VPN server in another country
then they identify all domestic IPs, that have communicated with that VPN server at the time of the activity and thus identify the user (or a small group of users).

Is this logic correct?

If this is correct, I'd say it is safer to use Tor than a VPN, as at least with Tor they have to go through all the users who were using TOR at that moment. With VPN, the chance is much smaller that more than one user was using a particular provider and was connected to exactly the given server of the provider at the precise moment.

The logic used in your question is correct.

In the example of a nation-state wanting to trace online activity back to a user it would be as follows.

The initial communication will show the source IP address happening to be registered with a VPN provider.
The nation-state will then contact the VPN provider via sending a subpoena,etc requesting the logs for the VPN server registered with the IP address identified in step 1. Depending on where the VPN server is located, and how the company operates they will either have to provide this information, or respond explaining they're unable to do so due to either, not storing any logs, or being out of the nation-states jurisdiction and not having to comply.
In the event the VPN provider responds with the logs this will show potentially the true public IP of the user they're trying to trace. Which will be the IP address registered with that users ISP. It is at this stage the nation-state will follow a similar process to what was explained in Step 2 but with the ISP.

Generally in terms of operational security it is best to run TOR over VPN as they both have their pros and cons, but taking this layered approach is a much better option.


JKS - Keystore protection and configuration file It appears that Java Keystore is often used by web server using a configuration file, with the password opening the JKS written in it and also the password protecting the specific entry.

How could that be considered secure ? With this scheme, the "secret problem" has moved to the file. Even if the file is protected by user rights, it needs to be encrypted, doesn't it ? But that would mean that each time webserver is started, admin must enter a password to generate the symmetric key (PBKDF2) and decrypt the file ?

I would like to know more about how this is managed in secure way.

As @whoami mentioned, it does just move the issue to another place. As you mentioned it allows you to move it out of code (if you've hardcoded it), password protect it (if it was originally just a PEM or whatever on disk), and ACL it to the requisite permissions.

The problem is that you do need to know the key to unlock it, and that of course requires protection of some sort, and well, you get turtles all the way down.

What you're basically doing is moving the bar for the attackers so they have to put in more effort to break the thing. At some point they just say screw it, and move on. You can make it harder by introducing complexity to key generation, but if attackers know how this works they can do it themselves easily enough, or worse they can just steal the file and try brute forcing the key since its not particularly random. In some cases the OS does provide a mechanism of protecting the random keys, but in this case you'd need something that is exposed to the JVM.

More practical solutions involve moving the key to better-protected areas, and that usually means hardware of some sort. In some cases we're talking TPMs, HSMs, or simply smart cards (though they are all really the same thing, but with different features). The basic principle is that the key never leaves the hardware, so its impossible to steal it. A side effect of this is that all crypto usually occurs in the hardware itself, so all you're doing is shoving data in, and getting data out, without needing to worry about the crypto itself.

This then means you need to protect the interface to the hardware so only authorized systems can talk to it. See the turtles yet?


Ban MAC address from website? Possible Duplicate:
  Can I block based on Mac Address?

I have a situation where I need to ban a MAC address from accessing my webserver. (Windows Web Server 2008 R2). Is this possible?

P.S. I know how easy it is to change a MAC address... I just want to know if it is possible.

No, you can't do this unless the host happened to be on the same local network - at each hop, the router changes the MAC addressing.


What are some possible ways of sending anonymous request to re-crawl to Google? This is a proposed architecture for submitting anonymous request to re-crawl the web page to google bot. I tried to come up with the solution given below. The intention of posting it here is to know the security  loopholes in the given architecture and find out what improvements might benefit the current architecture

Here is the scenario, Let us say user visits a URL and he/she suspects that the page is cloaked or for some reason want the bot to re-crawl the URL. Google provides fetch as google tool for the same. But anyhow, when we are submitting the URL to Google, Google will know our IP. I want this submission to be anonymous. Please do not confuse with this. Assume that I reach the page turning off(disabling) my JavaScript.

So here are the steps:
1. User request for Random number from a authority which grants the user a random number and same to Google server. From a duration from t to t' same random number will be given to all the users and Google will also store same random number for that duration. After that a new random number will come into picture and that random number will not be used{ I wanted to minimize the management of keys for a user so I resorted to that approach}
2.Once we get the random number, XOR this with URL and send the encrypted URL to trusted mediator. This mediator stores the request of all users{ encrypted URL} and after every 5-10 mins gives these URL to the Google Server.
3. Also note that the a user can send one URL once every 15 mins.
4. As soon as the dialog with mediator is over the connection is closed by the user.
5. Now mediator sends all the encrypted URLs to the Google server
6. Google server only knows the encrypted URLs and source as mediator hence privacy of the user is preserved

These are assumptions I made:
a.Mediator can allow only one connection per user or client in every 15 mins window.
b.Mediator on terminating the connection with the user or client keeps no details about the user or client
c.Random number generator is true random number generator
d.Mediator and Random number generator are both fault tolerant(in this context I mean robust to load).

What are some existing flaws?What can be improvements?

EDIT: In spite of the fact I have accepted the answer. I welcome comments other answers and improvements so feel free to let me knows the flaws or improvements.

Simplest is to use any VPN or SOCKS proxy.

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

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

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

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


Opt-in a security profile at runtime, without tedious setup I like lowering my access privilege mid-program (e.g. restrict my program to the current directory and files, disable networking). I imagine this is a pretty common wish.

I would like to be able to do this as a normal user, without the involvement of configuration files, nor root access to enable said configuration, nor tagging files. I'd like to specify my security profile at runtime. In the best of world, I wouldn't need any special kernel config or parameters either.

Currently, I use apparmor, but it involves:

1) Enabling apparmor.

This is a problem since kernel support is required. I may need to be recompiled as is the case with arch-linux-arm.
In a work setting running Red Hat Linux, they don't typically have apparmor because it's a selinux world.

2) Writing a simple profile (let's call it my_profile.armor):

profile restricted_books {
  deny network,
  /home/flux/_/dev/localhost.books/ r,
  /home/flux/_/dev/localhost.books/** r,
  /home/flux/_/dev/localhost.books/progress/ rw,
  /home/flux/_/dev/localhost.books/progress/** rw,
  /home/flux/_/dev/localhost.books/tmp/ rw,
  /home/flux/_/dev/localhost.books/tmp/** rw,
  /usr/bin/ebook-convert Ux,
}

2) registering the profile (requires root)

sudo apparmor_parser my_profile.armor

Alternatively, you'd move my_profile.armor in /etc/apparmor.d/ and reboot.

3) opt-in the profile programmatically

#include <sys/apparmor.h>
aa_change_profile("restricted_books");
booyah();

Instead of all that, I'd love to just do:

sandbox_my_app_please_and_Im_normal_user("""
  deny network,
  /home/flux/_/dev/localhost.books/ r,
  /home/flux/_/dev/localhost.books/** r,
  /home/flux/_/dev/localhost.books/progress/ rw,
  /home/flux/_/dev/localhost.books/progress/** rw,
  /home/flux/_/dev/localhost.books/tmp/ rw,
  /home/flux/_/dev/localhost.books/tmp/** rw,
  /usr/bin/ebook-convert Ux,
""")
booyah()

Is there something like that out there? selinux has setcon() which looks similar to what I do with apparmor, but it involves a lot of config too (which I'm sure needs root too).
And the built-in seccomp() function looks really complicated so I'm not sure it can even do the simple file/directory, no network scenario.

Not really what you want, but more closer variant is:

normal@user:$ aa-exec -p restricted_books booyah

In this scenrio you still need:

Enabling AppArmor
Writing a profile
Registering profile

But after that you can confine any application with any profile as normal user by aa-exec (confine a program with the specified AppArmor profile).
More detail in man aa-exec


Using Ipod touch at work: Can they tell what I am looking at? I use my Ipod touch at work and connect to the company network Wifi. I know they can tell what apps I am using, but will they be able to tell what I am doing in those apps? (Safari? Reddit?)

Also, will they be able to connect my ipod touch to me? I have made no attempt to conceal my identity on my ipod touch.

Thanks in advance for your time, I see similar things posted but I was curious about my scenario. (this is a pretty big corporation)

Short answer is yes, it is possible for the Access Point owner to monitor which sites you connect to. It is also possible for them to work out that the IPod Touch is yours either through sniffing HTTP traffic or by monitoring the devices location and usage time compared to your building access records and desk location.

If you need to install any app or certificate to connect to your corporate WiFi it is far easier for them to do this.

Given it is possible, are they, is a different question. Most company IT departments are not interested in tracking down what sites you are on, specially on your own devices.


Can XSS vulnerabilities present in 3rd party js libraries be used to attack the app that uses the lib? I am using various 3rd party libs like cordova.js, jquery, jquery mobile, mobilizer and so on, in a an android mobile app.. These libs are found to have various XSS vectors through insecure use of eval, settimeout, inner/outerhtml and so on. However, the modules which have these issues are not used/called in the application.

Considering the above scenario, Is there any way by which an attacker can exploit my app based on the XSS vectors in the 3rd party libs, even if the vulnerable modules are not used in my app?

Possible, but unlikely. Why?

Allow me give you some background information. I've seen people obsess over supposed "XSS vulnerabilities" in jQuery and many other libraries, here's one example:

$('#inputElement').keyup(function () {
   $('#someDiv').html($(this).val())
});

Some would argue that this code is vulnerable to XSS, which is not true. Yes, you can write JavaScript in the input field and have it executed (for example, <script>alert(document.cookie)</script) but so what? You can already do that with with any application that gives you JavaScript console (Firebug), heck, you can even do it with Greasemonkey.

It can be only considered an XSS vulnerability if data from outside your app is used inside your app by tricking the user into malicious URL or submitting a specially crafted form. Here's an example:

$(document).ready(function () {
   $('#someDiv').html(window.location.hash)
});

Now this is vulnerable to XSS, an attacker could craft the following URL

http://example.com/search/searchQuery+<script>alert(document.cookie)</script>

Or even use some URL shortening services to make the attack a bit more obfuscated. The point is, in such cases you need to worry.

If the client side of your webapp is using data from outside and it's possible that the legitimate user might not have control over it (like the case above), then you need to worry.

Another example using History API-fallback libraries, such as jQuery BBQ (it parses window.location.hash) which might be vulnerable and somehow allows code in the URL to be executed.

Please note that this answer is strictly in the scope of your question; XSS attacks related to JavaScript libraries.


ASP.NET Machinekey encryption In Asp.NET you can use the MachineKey.Protect to encrypt data. We are thinking of using this to encrypt some data which will be stored in a hidden fields within a web page, these hidden fields are used when the web page is posted back.

I have read that when encrypting it is better to use a different Initialisation Vector each time as if the same one is used over and over again the encryption becomes easier to crack.

Surely by using MachineKey.Protect over and over again the encryption becomes easier to crack as the same IV is being used. The data I am protecting is not super sensitive so I don't need a gold standard solution, I am just checking that I am not about to do something that is very weak. If MachineKey.Protect is a medium strength solution that is fine.

Thanks for your help.

The MachineKey.Protect method automatically generates a random IV during encryption. You can see this in effect by protecting the same values multiple times:

for (int n = 0; n < 10; n++)
{
    byte[] data = MachineKey.Protect(Encoding.ASCII.GetBytes("This is a test."), "testing");
    var sb = new StringBuilder();
    for (int i = 0; i < data.Length; i++)
        sb.AppendFormat("{0:x2}", data[i]);
    Console.WriteLine(sb.ToString());
}

Output:

beb18d854f133f948e090a9d563d5670f3ccf9d337449357fba831e728e105fed44785e432d3f1dbe8c50a7f867570a3ce7d198b51faf34fb3f44511c876f715
dd62fe62ca56ff6f9cf4bb6b0f715f77106aa11ef081105099800850ce38a2d7d8d986f35f8e0db3ac32d5702a7cbfb2efb421770449a90587cd4895ec70a5af
fa548a8fb928fa3039eed3b2d0bf2fc53c4899da39acaad443170726f8a2fdfacf40684542b5429445c82f66cac529f94a750c2ec52532984e752e722f6accfa
ef37f809db93f2e8e1a45a58bc5def741239be955038b87d8712dcb8bfbae853e2dd21556b836dde41c56dcce6970c699107cc9a796dbbf14cf8ff231cfe7f08
fdb4e87ee327dfe4b0d3ae3edf66a4b3dc9eab7434d8e730eaf3424034bd2b6935b0b92613b13bf703cac6951d92761e9a34ec815dd5e66e9e514baf5181edab
1203a0891da6e7bc09f6037a3419be62a07dbb1b5e3c3ab2449e7163e5b082d9a6ef4338b17132e95e04ef8df00582afca2aa0576003260766f256659b971f11
0a96d6f17169789d86c0812c810826efe356c5ec5ad4f88d1d79620c7d9a31b665244e095ef711a3f555b29ac04dc684de4971396cdb621c34c6753ad16cbebe
0a537e35e7554831c0870e762996f3b9d23ed3ae3363133341097e7a80ed3fca12c9beb1592ecb1d4d2ca4cc2178837996484ee71773e4ce5dcd911220d38e17
9e943971c1847254cba338a69973d55e857e55fb0bdaf62b18bbe4cfd39647256d31ac88a9c75823594c062b2def6c618429af60618150f640590c6ef7a0d565
18028aa0c81dd5dc03ed972d0a066803841f1cb0a43eadbb4cf001ecafbc38f3604579f84196e9c6344cb3f676f53add0d4054b1daa5eca119c46522201ae27c

If you step into the decompiled sources for System.Web.dll and System.Security.dll, you'll find that the MachineKey.Protect call loads a provider from a factory which ultimately wraps the underlying DPAPI protection methods - specifically CryptProtectData, using the hash of the purposes list as the "optional entropy" field. The DPAPI automatically applies a salt and a MAC.


Setup Wireshark to decrypt TLS_DHE I have a passively sniffed traffic dump of client/server were packets are encrypted with cipher suite

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)

With a Logjam attack I managed to find the DH private key.

How do I setup Wireshark to decrypt the packets?

As documented in this post, Wireshark supports several options for providing secrets to enable TLS decryption. In this case, I would suggest the use of the PMS_CLIENT_RANDOM key which maps the Random bytes from the Client Hello message to the premaster secret (both are hex-encoded).

For the DH key exchange, the premaster secret is the shared DH secret. Using your private DH value and the public parameters and values from the ServerKeyExchange message (see RFC 5246, page 51), you can compute the shared secret. (This assumes ephemeral DH using finite fields, for ECDHE, see RFC 4492, Section 5.4. instead.)

Then after computing the shared secret, you need to encode it appropriately (see RFC 5246, Section 8.1.2.):

  A conventional Diffie-Hellman computation is performed.  The
  negotiated key (Z) is used as the pre_master_secret, and is converted
  into the master_secret, as specified above. Leading bytes of Z that
  contain all zero bits are stripped before it is used as the
  pre_master_secret.

Assuming you have found the secrets, you can write a text file which looks like:

PMS_CLIENT_RANDOM 9c39b93ced5c48db094a502f7ed4ef6b77a1ccb751964c04cac8c7e75837ddc8 2b1f6108824ef0c7e38443dda437c43177d8a1ac73221b6515c9df7d854bc503

and then configure Wireshark as usual via the "(Pre)master secret log filename" SSL protocol preference. If it fails, you can set the debug option at the SSL protocol preferences and read it to get more hints.