Arbitrary file upload, serve JPG as PHP I'm trying out random older WordPress exploits on my local server, I'm currently in the process trying to get this one to work:

https://www.exploit-db.com/exploits/20083/

It doesn't read any headers, just seems to filter file extensions.
I am able to upload {Filename}.php.jpg files as mentioned in the specified URL above. But what caught my curiosity was;

Plugin does not properly filter filetypes, which allows for the upload of filetypes in the following format:
filename.php.jpg
Vulnerable hosts will serve such files as a php file, allowing for malicious files to be uploaded and executed.

Opening the JPG just makes my browser throw an error, not seeing it as a valid image.

Which leads me to my question

Why would a server ever serve a JPG as PHP? (without editing .htaccess or php require())?

This behavior is not directly linked to this exploit, but by a weak web server configuration.

For instance:

Apache offers through mod_mime the possibility to serve files with multiple extension. This extension is designed to serve the same way files such as welcome.html.fr or welcome.fr.html (ie. french version of the welcome.html file). However it can be tricked to interpret myuploadedfile.php.jpg as a PHP script...
Nginx offers a virtual directory system allowing to have virtual sub-directories below a dynamic script. For instance, a URL like /agenda.php/2015/june/6 will execute the file agenda.php (SCRIPT_FILENAME) with /2015/june/6 as parameter (PATH_INFO). However you may trick him to execute your uploaded file (which does not even need to have include the .php extension) by using a URL such as /myuploadedfile.jpg/anything.php: it will be accepted as a PHP script due to the .php extension, then the URL will be divided into SCRIPT_FILENAME and PATH_INFO as described above, and finally the order will be given to the PHP interpretor to execute myuploadedfile.jpg content.


Ubuntu LVM LUKS Encryption I've been reading about Ubuntu LVM Encryption, and I understand that it supports the use of Linux Unified Key Setup (LUKS) during installation, which is a block level encryption that encrypts the entire logical volume.

Is it possible to read files on the encrypted volume when I boot the system with rescue media or a live CD?

Yes, but only if you provide the encryption key/passphrase used to encrypt the data.  Without the key, the data is inaccessible, and the device appears as (essentially) noise.


A computing environment that saves no data I want to use a laptop which doesn’t save any data, history, passwords anywhere in it. All state information should be destroyed once it is turned off or rebooted, without removing my ability to use the OS or specific applications such as Explorer or some remote desktop apps like Radmin. I am used to Windows OS, but I can use Mac also for such purposes.

The aim is that if I'm using the laptop and somebody approaches me, then simply pressing the power button will remove all context of what I've done.

You've described the principles behind a live CD boot. This can be most strongly ensured by having no permanent media within the machine. I'm going to gear my answer towards Linux as that's what I'm most familiar with in this context.

Having a hard drive with all disk partitions mounted as read-only and all read-write partitions mounted in memory would also provide this, but allow for easier updating of the underlying OS.

Careful use of SELinux, context switching, and UnionFS would allow you to persist selected configurations, etc. to disk while ensuring that everything else is only written to memory.


Is single-click phishing possible? For Chrome, IE/Edge, Safari, Firefox, Opera released after 2018, is it possible for a phishing to succeed by just enticing a user to click a URL?

Notice: The user only does a click on the URL, no any subsequent operations on the phishing website.

This would be a "Drive-by" attack, where the simple act of visiting a website from an initial click allows for a successful hack of the client.

Usually escaping the sandbox, getting code execution and privilege escalation is the result of combining multiple flaws to result in the desired goal.

This year, 2018, the pwn2own event held in March - awarded prizes for popping Edge, Safari and Firefox on desktop platforms.

So, in theory in 2018 it was possible… also if you look at CVE Details website for Chrome, Edge, Firefox and Safari you'll see the stats for 2018's CVE in those browsers. Given that these are just the known vulnerabilities it seems likely that drive-by are still possible.


Connection on port 3387 Event viewer says "authorized" This event shows up multiple times within a minute like it was being brute-forced, but it says "authorized". My question is: Is there anyway I can see any commands that came in from this connection? I looked through my logs and files edited on that date but didn't find anything conclusive. System will get wiped soon so anything worth looking into pre-wipe would be good for future reference. I had my VPN open to the net for temp access if anyone was wondering how they got to the port in the first place.

EDIT:

I would like to thank everyone again for the help with the rep to post the pics, you guys rock, also anyone who took the time to view the topic thank you as well.

EDIT:

Back into event viewer seeing patterns I didn't notice the first round.

Hack started at 11/28 @ 1:35 am

The TerminalServices-RemoteConnectionManager the first log shows at 5:17pm

I notice USER32 reboots the system soon after group policies stops then event viewer is stopped:

Keep looking at all the hits the computer is logging. Then a bunch of service control manager processes.

Winhttproxy runs after a couple more hits, so I checked the proxy setting:

More hits flash crashes:

Honestly, I don't know what to make of the crash, whether it was an exploit to flash or just a regular flash instability.

I will make a VHD tonight and most likely wipe the machine. If anyone sees something or has any questions or settings they'd like me to check, it would be great. This is a good learning experience so any input is welcomed.

Unfortunately, this is a known vulnerability. Port 3387 can be used to cause a Denial of Service attacks by running remote exploit code  or by Trojans. It is a hot spot. This should be closed by default (Windows). This is a udp or tcp based communication. The protocol is known as backroomnet mainly (used by other services as well). The opened ports can be found with netstat -ano. The associated pid will be helpful to identify the process. Other logs also indicate a DoS.


I left my debit card unattended -- how exposed am I? I yesterday visited a restaurant I usually visit, but it seems that after paying with my debit card, I accidentally left it there. Today (almost 24 hours later) I had realized that I didn't have it with me anymore.

I am not really that concerned about the unauthorized use of the card, since my previous experience with this bank (Bank of America) resulted in them cancelling any unauthorized payment first and asking questions later.

However, I'm concerned about what I don't know: what are the risks of leaving it unattended for a while?

This question pointed on the fact that asking for the zip code plays the extra role of verifying the actual owner -- but this restaurant never required me to indicate my zip code in order to pay them.

Risks that come to mind but I'd like someone to help solidify by explaining on how this may contribute are:

identity theft
unauthorized payments (card theft)
hacking other services that check on the last 4 digits of the card
anything else I may have missed?

Sidenote: I rarely contribute but read on this StackExchange site and find it awesomely helpful. If anyone has suggestions on how to make this question helpful to others (maybe making it broader?), please go ahead and provide your ideas.

Yes, you card can be misused at various places. Though, it has never happened to me, I believe there are some websites which accept payments from debit cards without any secure 3D password. All they ask for is CVV and Card#.

I would suggest you to block it right away.


Application to monitor software activities I am doing black box testing on a software which is installed in my local machine. I want to analyze and see the list of files and registry entries that software create/modify/delete. Basically analyze a software for the files which software deals with. is there any software available to do this?
Am using Windows machine.

I'd suggest that you could use Process Monitor from the sysinternals suite to do this.


What is the meaning of Triage in Cybersec world? I searched Google about this term, but the definitions that I found was related to the medical world, and nothing related to IT. I think that is some kind of procedure of documenting something maybe? Note that I heard this word for the first time in the SOC (Security Operations Center) that I am currently working.

We just got reports that 4000 of our systems are infected with ransomeware.

3000 are end users, 800 are non-critical servers, 200 are critical servers.

Triage is looking at this mess and deciding which order to start restoring systems in. We can't tackle them all at once, so we have to look at some and say 'Sorry, little Inspiron that couldn't, you get to sit there and be useless for a while.'

It comes from the medical world, as you've stated. It's the same reasoning as an ER doctor looking at two patients and deciding to work on the one that they're more certain they can save. You let one go, as hard as it may be, so that the other might live. If you'd worked on the worse injured person, it's possible they both would have died.

The difference in the security world is that often it's dollars lost due to users being unable to work, rather than literal life and death. You work on the systems that you are most likely to be able to restore, and that will return the largest amount of productivity to the environment. You leave the individual laptops that only affect a single user to the side, for now.


Is my service provider hacked and what can I do to protect myself? I found myself looking at a stock and forex search page when I try to access Chinese Stackexchange using my FireFox browser today. This is what the page looks like:

And this is the HTML of the page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

    <title>stackexchange.com</title>
    <meta name="keywords" content="stackexchange.com" />
    <meta name="description" content="stackexchange.com" />
    <meta name="robots" content="index, follow" />
    <meta name="revisit-after" content="10" />

    <meta name="viewport" content="width=device-width, initial-scale=1.0" />

  <frameset rows="100%,*" frameborder="no" border="0" framespacing="0">
    <frame src="http://chinese.stackexchange.com?epl=someverylongstring" name="stackexchange.com">
  </frameset>
  <noframes>
    Click here to go to stackexchange.com.
  </noframes>

Though rare, this is is not the first time I have encountered such a problem. My Google Chrome browser works correctly. And I suspect this has to do with my ISP's DNS. I immediately called my service provider notifying that there could be an issue with their DNS.

I tried surfing Stackexchange again and the issue is gone. Is it possible to confirm the source of the problem from my end? What others steps should I take to protect myself?

Without more information, the problem is very likely DNS related.

[ayrx@c00kies ~]$ host chinese.stackexchange.com
chinese.stackexchange.com has address 198.252.206.16

There are a few likely causes.

A problem with your ISP's DNS. This is very a possible scenario that might stem from some bad configurations. If this is the case, switching to another DNS service provider like Google's 8.8.8.8 might resolve the problem.
Someone is conducting a MITM on your network. I'll say this is a less likely scenario as you probably are not a high value target and Stackexchange is not a high value site.
You have malware messing with your machine's DNS to redirect you to that particular site. This is very possible as well. If this is the case, you can check by using another (hopefully clean) machine to access the Internet through your network. If this is the case, your best bet would be to nuke the infected machine and reinstall from scratch as cleaning up malware is very difficult.


OAuth2 - Sending a hash of your client_secret when using the client credentials grant instead of the secret I'm working on an API that I'd like to be accessible internally by other servers as well as devices that I consider both as confidential private clients. Devices are considered private clients because the client_secret is stored in an encrypted area that prevents from unauthorised readout and modification (even though nothing is never bullet proof)

For auth, I'd like to use OAuth2 with the client_credentials grant that seems to be a very good fit for these use cases. However I'm wondering how flexible is the standard regarding sharing the client_secret.

Basically the RFC doesn't say much about sending your client id / client secret, it just offers an example here: https://tools.ietf.org/html/rfc6749#section-4.4.2 which is very simple by using the following header Authorization Basic: base64(client_id:client_secret)

In my opinion, it could be slightly more secure by computing a hash:

the client requests a random to the server by sending their client_id
the server replies with a random code (valid for like 10 mins, just like an authorization code)
the client computes a hash = sha256(client_id, client_secret, code) and asks for a token
the server computes the same hash, compares the client hash with the computed hash and sends an access token if they match

It would add an extra layer of security in case https is somehow broken or if anyone is able to read the header somehow.

However it doesn't seem very OAuth2 compliant and I don't really like re-inventing a standard.
Another option would be to create my own extention grant, I'm just wondering if it's really worth it, like no one seems to have done this.

Also, if I want to share my API with a 3rd party app, not sure it's a good thing to force them into using something non really standard.

OAuth2 says that the method of client authentication is up to the authorisation server. It can be anything. Based on RFC 6749,

  If the client type is confidential, the client and authorization server establish a client authentication method suitable for the security requirements of the authorization server.  The authorization server MAY accept any form of client authentication meeting its security requirements.

Client authentication using client id and client secret is one way. In this case you should follow the best practices for username + password authentication (for example, OWASP Authentication cheetsheet).

One of the important aspects is to not let the attacker figure out a valid username but returning generic error messages (i.e. not returning errors such as "username is invalid"). Your solution's first step would defy this.

  the client requests a random to the server by sending their client_id

If the client requests a random value from the server based on their client id, it would confirm to the attacker that the client id is valid.

If the authentication using client id and client secret is not sufficient for you, you should explore other ways of client authentication namely:

Client certificate authentication using TLS (Refer Draft RFC 8705)
Client id + Signed JWT (Refer RFC 7523).


Likely Sources of MITM Attack over Public Internet SSH Earlier today when attempting to ssh into my remote server, I got the standard man in the middle warning relating to inconsistent public keys. In fact the key-type wasn't even correct. My server uses ssh-rsa, and whatever was on the other end was using ecdsa-sha2-nistp256. I'm the only one with access to the server, and I know for certain that the keys were not changed during this time.

I resisted the urge the reset my client's known_hosts file, and waited a few hours. SSH started working again with the correct public keys and everything seems fine. However it's a little unsettling, so I'd like to understand what's going on here.

I've ruled out an eavesdropper on the client subnet. I tried SSH clients from EC2 instances and over VPN, and got the same malicious public keys. I had ssh sessions that were previously open, that remained uninterrupted through the events. Self-SSH'ing to localhost and the subnet IP worked fined, but SSH'ing from the server to the public IP showed the malicious key.

The sever sits behind a common household router, with port 22 forwarding enabled. The server ISP is Comcast Business, so I don't know if this is could be related to the web-page injections that Comcast has been doing more frequently lately. Any good ideas on what the likely cause of this is?

I have no idea about sources of attacks, so strictly speaking, this won't answer your question. However, I think there are some things you can do to figure out who or what may be engaged in this. It will require extreme care on your part. Also, it's been a few days, so first you need to see if it's still happening.

You should set up your server to determine who's doing this (by IP). Turn on logging on the server and your firewall was my first thought. See if someone is knocking on your front door and testing SSH credentials. Note the times in the logs. If it isn't you, examine the logs for IP addresses of the attacker(s).

You can do a lot with an IP address. Reverse lookup won't tell you everything, but it will tell you a lot. Is the address a cable modem, a US government address or an endpoint in China or Bulgaria? Perhaps, it terminates inside Comcast? Then, you can call up Comcast and ask them, WTF?

No matter what, DO NOT SCAN OR ATTACK THAT IP. You have no idea who or what you're dealing with. You're almost certainly ill equipped to handle whomever is on the other side of this thing if it's any kind of sophisticated attacker. You don't want the Eye of Sauron upon you.

However, you don't know if the attacker has reached your server, yet, or if the logs are showing some random scanning of your ssh port, although you should be able to figure this out. So, if you feel like continuing, jump to your client computer.

Look over your entire client and server set up, the credentials used to authenticate the server, the usr/pwd and other secrets used to authenticate the client. Keep a copy of all of this information, or just note it all and be prepared to change it later. Make a copy of your client's known_hosts file.

Test running an IP snooping program on your client, something like wireshark. Become familiar with how it works and make sure you can capture the ssh/tcp/ip session with the attacker/server. As it will be over SSH, you won't see the content. However, (just like NSA meta data collection) you will know the remote IP address. You might be able to know that without wire shark because the IP should appear in your client's ARP database (arp -a). However, wire shark will give a little bit more information (and it's cool to watch the packet exchange). Also, compare IPs from your server logs with IPs from your client. Are there matches? Are they related?

You've gone pretty far and collected a lot of data. You've logged at your server (and may have seen the MITM IP), you've passively set up an SSH session from the client, you can see the offending host (MITM), you have knowledge of the IP, perhaps that's far enough.

If you feel like digging deeper, you can. However, this one becomes a bit more dangerous for your home network. You need to be very confident about your ability to protect that network from the inside. Honestly, I'm not sure you should take this step, but here's how far you can go.

You could set up what amounts to a honeypot. Replace your machine on the backend with another old machine. I'm not sure if your backend needs to be live 24x7, so this may not be possible. If you can, just disconnect your backend network and leave only the honeypot in place. If you have a real router, isolate the honeypot so all incoming connections are to it. Harden it as best you can. Set up a dummy account with very different username/password and whatever other secrets you need. Set up some dummy information, maybe even load a web server on there and a mysql database. Something that looks vaguely real. Also, the best honeypot is actually running a VM, where you've virtualized the honeypot running on top of the real hardware. It can be harder to break out of a VM and do damage.

Turn on logging on the honeypot on everything. Log incoming connections, log shell session histories, log everything you can. Run wire shark on the real computer underneath the VM honeypot. Then, perform the whole shebang. Connect from the client via ssh (run wireshark), use your honeypot credentials and complete the SSH login. Are you on your honeypot or on some foreign machine? Then, go home and check your honeypot logs. Did someone connect in? Can you leave the pot around for a few days? It might take a little while.

This last bit doesn't get you a whole lot more information, but you will know two things if you see someone log in. (1) You are definitely dealing with an active attacker and (2) you have the IP of the machine used to engage in the attack.

At that point, I'd hand things off to the authorities. It's a tough call who to go to. If you get this far and can't find anyone who will listen to you, PM me and I might be able to help get you to someone (casual acquaintance type of thing).

Lastly, throw away the honeypot. Smash it, destroy it, never use it again. That thing cannot be trusted, they might have dug into its BIOS. Never again plug it into a network you care about. Change every single password you have on everything. Modem, router, machines, accounts. Consider re-imaging and/or re-installing firmware on any device used in the honeypot scenario. Get that firmware/image before you start the honeypot project and keep it well secured.  In fact, use an old modem for the honeypot project and just disconnect everything else and smash that modem, too, when you're done. If I were you, I would be completely paranoid when running the honeypot scenario.

I hope this helps.


Why did ChangeChiperSpec Drop work? Apparently, in the past, a man in the middle was able to defeat the security (confidentiality, to be precise) of TLS by simply suppressing the ChangeCipherSpec message.

It's called "ChangeCipherSpec Drop" and unfortunately, I was only able to find very little information about it online.

Some sources said the attacker would simply drop the ChangeCipherSpec message, others were less precise about it, and this graphic I found here shows both the ChangeCipherSpec and the Finished message crossed through.

My questions are:

Why did the server then send payload data? Isn't the server supposed to wait until having received the ChangeCipherSpec and Finished messages from the client before it sends its own ChangeCipherSpec and Finished messages and only send payload data after that?
How is this even triggered? There expectedly has to pass time between the server's last message of the first half of the connection establishment (ServerHelloDone) and the server's first message of the second half of the connection establishment. An entire round-trip time, even. How the server doesn't just start sending payload data right away every time. Is there a really weird timeout?
How did the client's ChangeCipherSpec not arriving cause the server to send its payload data unencrypted? Shouldn't the server's ChangeCipherSpec determine the point in time after which the server only sends encrypted data?

The attack is described in Analysis of the SSL 3.0 protocol from David Wagner and Bruce Schneier in section "4.3 Dropping the change cipher spec message". In short:

The attack works by stripping the ChangeCipherSpec message (but not the Finished message). This works since the (existence and content of the) ChangeCipherSpec message is not protected by the MAC in the Finished message.
The attack works only when a cipher is used which provides no or only very weak encryption, i.e. the encryption of the Finished message must be none or weak enough to break it in real time.
The language in TLS 1.0 makes it more clear that there should be no Finished message without preceding ChangeCipherSpec.

For more details see the paper.


Doesn't Authentication logically imply Non-repudiation? If it is confirmed that Alice is the source of a message (authentication), then shouldn't she be unable to deny that the message is from her (non-repudiation)?

Is there an example where authentication happens without non-repudiation?

Non-Repudiation is the assurance that someone cannot deny something.

Examples of authentication without non-repudiation:

Alice's credentials were/could have been stolen and used by
someone else.
The authentication process itself is flawed (has bugs).
The system has provisions for impersonation, say by an
administration or support user.


Question about IDS and IPS I am studying Security Fundamentals on Networks and as a part of an excercise I have the following question:

Which of the following statements are true? (Select all that apply)

a.- An IDS deals with malicious traffic that the firewall missed.

b.- An IPS is on the boundary of the trusted inside and the untrusted outside.

c.- A network-based firewall protects hosts from malicious traffic originating on their same network.

d.- An IPS protects hosts from malicious traffic originating on their same network.

What could be the answers? According to me, b and c would be the answers because an IPS protects the original traffic that pass through, b because it is in the boundary but I have a doubt with option a because and IDS as I know makes a copy of the traffic just to analyze it.

First of all, let's look at definitions for IPS and IDS:
IDS:

An intrusion detection system (IDS) is a device or software application that monitors a network or systems for malicious activity or policy violations. Any detected activity or violation is typically reported either to an administrator or collected centrally using a security information and event management (SIEM) system.

IPS

Intrusion prevention systems (IPS) [...] are network security appliances that monitor network or system activities for malicious activity. The main functions of intrusion prevention systems are to identify malicious activity, log information about this activity, report it and attempt to block or stop it.
Intrusion prevention systems are considered extensions of intrusion detection systems because they both monitor network traffic and/or system activities for malicious activity. The main differences are, unlike [IDS], [IPS] are placed in-line and are able to actively prevent or block intrusions that are detected. IPS can take such actions as sending an alarm, dropping detected malicious packets, resetting a connection or blocking traffic from the offending IP address.

(Emphasis mine.)
Now let's look at the question and the given answers:

Which of the following statements are true? (Select all that apply)
a.- An IDS deals with malicious traffic that the firewall missed.

As we just learned, an IDS is only used for monitoring and not for "dealing with" (whatever that means exactly). It is fair to say that IDS is not actively involved in blocking or filtering such traffic, so "dealing with" is probably: FALSE.
As Georgios pointed out, "dealing with" could also be interpreted less actively, so this might be TRUE. English is not my first language, so other comments are welcome.

b.- An IPS is on the boundary of the trusted inside and the untrusted
outside.

I wouldn't say so, but you could argue it that way. Typically the IPS sits behind the boundary - this is where the firewall would be - to lower the load of traffic the IPS has to analyze. The firewall filters out most of the easy-to-detect unwanted traffic, the IPS takes care of the more sophisticated stuff.
In my view: FALSE.

c.- A network-based firewall protects hosts from malicious traffic
originating on their same network.

Nope. A network-based firewall protects hosts inside a network from malicious traffic that originates from the internet or any other network that sends traffic to these hosts. A host-based firewall protects a host (if set up correctly) from all sorts of traffic, irrelevant where it comes from. This would be a software that is installed on a machine, like Windows firewall.
FALSE.

d.- An IPS protects hosts from malicious traffic originating on their
same network.

Helloooo, there it is. This is a correct statement. BUT, an IPS does more than that. See (at least) wikipedia article for more information on that.
TRUE.


Can I safely run a virus using sandboxie? I want to test some untrusted software to check them, for this reason, I researched for a good sandbox software and I found Sandboxie I tested few safe application, but I am not sure if I can run untrusted application also?

Depends on your risk tolerance. I've done it before with no ill effects, but the gold standard for this sort of thing is to use a virtual machine.

Sandboxie is a solution that avoids the need for a fully virtualized machine by wrapping the userspace APIs that programs have access to. Unless they've screwed up and missed one, that'll do the trick -- but the available attack surface is much less well-documented and there's a lot less defense in depth than a VM.

If you're using a recent Windows 10 build, you can install the Windows Sandbox (just run OptionalFeatures.exe and check the box), a very nice and speedy VM just for this sort of thing. Once it's installed, you can just cut-n'-paste the suspect file in there and see what happens. However, closing it will clear the sandbox; Sandboxie can retain state if you want it to, which can be useful sometimes.


Is it easy to protect against SSI injection? SSI injection is, to the best of my understanding, the process of injecting commands into user input fields, e.g.

&lt;!--#exec cmd="ls" --&gt;

to get the files in the current directory. However, while seemingly powerful, it also seems incredibly easy to prevent by simply validating input fields. For example, one could just check to see if the first three characters in any input field is &lt;!- and prevent such inputs.

Is there something I'm missing here? When is it not easy to prevent SSI injection? I'm new to network security so please forgive any misunderstandings there may be in the above paragraph.

It's not a terribly difficult attack to prevent.  I would say prevention has more to do with the developer being security aware than it does with the complexity of preventing it.  This is actually true of many security vulnerabilities.

To answer your question - no, I don't think you are missing anything.  It's just a matter of making sure developers are thinking about security when they implement functionality that uses SSI.


What is the suggested best practice for changing a user's email address? I recently jumped onto the hypetrain for an unnamed email service and am currently on my way to update all my accounts on various websites to get most of my (future) data off Google's Gmail.
During this adventure I came across a couple user-flows of changing your e-mail address which I would like to share (amounts like "many" or "a few" are purely subjective, I did not count):

No questions asked
The email address is just changed without any confirmation emails, second password check, or spellchecking (two input fields). The email address is the main login method to this account with some sensitive data. Any person with malicious intent will not be stopped from taking over my account if they change the email address and afterward change my password.

Confirmation of new email
What I feel like the method used by most platforms: You will receive a confirmation email to the new address you provide. This will assure you typed in the email correctly, but will not stop anyone from changing the main login method though.

Confirmation through old address
Very few platforms send an email to the old address to check if I am the actual owner of this account. If I click the link in the mail or enter a number they send me, the address is changed.

Confirmation through old and of new address
Just once I had to confirm with my old address that I am the owner of the account and got another email to the new address to check that it does indeed exist.

Looking back at it, it feels like the usual UX vs security conflict. While method 1 provides the most comfortable flow, I see the most issues with it, as already pointed out.
Having to confirm the old address and the new one is kind of a hassle, but it's the best way of those listed to keep the account of your users in their own hands.
Are there other common methods I am not aware of? What is generally considered best practice?

The problem I see with confirming the old email address is that sometimes people change address because they cannot access the old one anymore. For example, the old address might have expired (and maybe even reassigned to someone else!). Or they might just have forgotten the password to the old address, and have no alternative ways to prove their identity. Or the old address belonged to a company where they used to work, and they don't have access to it anymore. Or it might have been blocked or terminated for for other reasons (violation of ToS, DoSed, filled with spam and practically unusable, etc.)
So the way I see it, you have two ways to log in to an account: using your password, or using your email account to request a password reset. Therefore the email account is an alternative way to authenticate. Now, whenever you make changes to the ways you can authenticate, you should verify your identity. And if you can't rely on the old email account (that you are about to change) the obvious solution seems to ask for your current password before you can change the address.

Ask for your current password (it's a valid verification of your identity) to be able to change the email address.
Verify you have access to the new email address and, if verified, make it the new default one.
Maybe do something with the old address that has been changed.

What you do with the old account, in my opinion, has some pros and cons. You could decide to:

Send a notice to the old email, for example: "Your email address for accessing Website Example has been changed, if you didn't expect this your account might have been compromised, etc." You might also provide a link to recover the possibly compromised account, with a token that expires after some time. The problem with this option is that if the old account has been reassigned to someone else, you would not want to let them know too much information (and definitely not give them a direct recovery option)
Just throw away the old email once it's been successfully updated, without sending any notices. The problem with this is that if an attacker manages to steal a user's password, they can take over their account completely and lock them out.
Don't send anything to the old email, but keep it in the database for some time, for support or recovery, in case the real owner of a compromised account (with the old email) shows up asking for help. The problem with this option is that the real owner, in case the account is compromised, might not realize it until... how long?


return-to-libc attack I was trying to attempt at return-to-libc buffer overflow attack for my Computer Software Security assignment. As far as my understanding goes, we can do these kind of attacks regardless of stack protection measures such as canaries and non-executable stack. This is because the libc functions do not reside on the stack and we just need to shift our program's control flow by overwriting the return address with the libc function address and passing suitable arguments. This figure seems to summarize the procedure I guess.
 What my doubt is, according to the figure for second part, is the stack frame given for the libc function or is it just for a function defined in the user's program itself? I am not able to figure out the need of fake_ret. Can't we just overwrite the return address of our function by overwriting EIP with the address of say unlink and the arguments can be placed in the user's function buffer which can be used to pass to the unlink function? Please note that by the use of user's (something), I aim at pointing to (something) which is defined by the user himself/herself in his/her program. Thanks.

You can write a frame for any function call, it doesn't have to be system(). However most exploits will aim for a shell if possible. The fake_ret address is simply where the execution will return to after the system() call. If you just put \x41\x41\x41\x41 there it will segfault. If you point it at exit() it will gracefully exit, or you could point it at a number of pop register followed by a ret to control execution down the stack (ROP).


Hashing Password on Client Side to avoid lag on single-core game server? I am currently implementing a simple login system. I would like to securely store all the user passwords in my database. The passwords are the most important components. All the other user data is not important. If an account gets hacked, as long as the password cannot be figured out its fine; other data are things like: score and account creation date.

I am assuming that some of my users will be using the same password as they are for other sites. So i need to make sure that the password cannot be read by a potential hacker.

Can I generate the Hash on the client side somehow to avoid any hacker ever seeing the real password?

Before you say I shouldn't do it on the client. The server has a constant game loop that needs to run, and I don't want the game to lag every time someone registers an account or tries to login. This approach would take some of the load off the server.

EDIT: Since this question was closed I would like to elaborate. Moving to the client allows me to use a lot more rounds when hashing the password, since this wont affect the server or other users experience in any way. This also makes it much easier to prevent a user from spamming requests and slowing down the server.

I am assuming that some of my users will be using the same password as they are for other sites.

In the context of protecting password from use on other sites (besides your own), it does not matter whether you hash the password client-side or server-side.

However, depending on your client environment, (i.e. web browsers) you may have difficulty finding a sufficiently well-optimized (strong) implementation of a Slow Password Hash. (e.g. Argon2 or BCrypt) So, your suggestion of client-side hashing may only be practical in App environments where native cryptography is available.

Of course, hashing client-side will do nothing to protect the password from being used on your site. An attacker who has stolen the hash can simply skip the client-side hash routine and become authenticated with your server. (never trust the client) Fortunately, this attack vector can be solved server-side. (see below)

  The server has a constant game loop that needs to run, and I don't want the game to lag every time someone registers an account or tries to login. This approach would take some of the load off the server.

As you know, it is traditionally recommended to hash sever-side. If you are concerned about load, I submit a few suggestions:

The Work Factor should be tuned only to take ~100ms on your target hardware. (your server) So, that's not really much of a lag, is it? I normally advocate 50ms-500ms, but your site could use a lower value and still be considered robust.
The Hash should be in a separate thread from your main game loop (async) so that the game can continue to operate (albeit with slightly poorer performance) while the hash is calculating.
You should include some form of DoS protection to limit the amount of hashes your server would calculate. Typically, the site would throttle sign-in attempts (per user?) so that an attacker would not be able brute-force effectively. Such a throttle would prevent endless hash computation.
If you like, you could hash the password on both the Client and the Server, if the client environment has sufficient native support. (described above) Then you can get away with an even smaller work factor server-side.

If the client-side has a sufficiently strong Work Factor, then it actually becomes reasonable to run only a quick (i.e. zero lag) SHA-2 on the server-side, and that will solve your problem completely. (thanks @HenningMakholm)

Finally, make sure the client sends the password (or hash) over HTTPS only. This is the most important thing, as no amount of supposed hashing will protect passwords typed into an HTTP site.


OAuth2 Cross Site Request Forgery, and state parameter http://tools.ietf.org/html/draft-ietf-oauth-v2-30#section-10.12 says:

  The client MUST implement CSRF protection [...] typically accomplished by requiring any request sent to the redirection URI endpoint to include a value that binds the request to the user-agent's authenticated state (e.g. a hash of the session cookie [...]

It doesn't say much about the implementation, though. It only puts some light on how the CSRF works:

  A CSRF attack against the client's redirection URI allows an attacker to inject their own authorization code or access token, which can result in the client using an access token associated with the attacker's protected resources rather than the victim's (e.g. save the victim's bank account information to a protected resource controlled by the attacker)

But use of the word "rather" rather makes the statement worthless.

I am thinking how to implement the "state" in GAE (using Webapp2). It would be easiest starting at how a hacker could use a CSRF against OAuth2. I found only one good article about the matter: "Cross Site Request Forgery and OAuth2".

Unfortunately, while this blog post is well written, there's not much information beyond explaining the OAuth2. The examples don't work, and I don't know Spring. Still, I found one interesting recommendation there: the server connecting to an OAuth2 provider should store "state" as a random session key (e.g. "this_is_the_random_state":"this_doesn't_matter"), and not a value under a static key (e.g. "state":"random_state_string").

My question is, what's the sane implementation of the "state"?

Should the randomly generated state be hashed, or can the same value be stored and sent to the OAuth2 provider?
Is there a difference here if the session backend is secure cookies or a server-side storage technology (e.g. in GAE Memcache, or  database)?
Should state be stored as a key as suggested?
Should state has validity period, or is session (if there is one) lifetime enough?

Let's walk through how this attack works.

The Attack

I visit some client's website and start the process of authorizing that client to access some service provider using OAuth
The client asks the service provider for permission to request access on my behalf, which is granted
I am redirected to the service provider's website, where I would normally enter my username/password in order to authorize access
Instead, I trap/prevent this request and save its URL
I somehow get you to visit that URL instead. If you are logged-in to the service provider with your own account, then your credentials will be used to issue an authorization code
The authorization code is exchanged for an access token
Now my account on the client is authorized to access your account on the service provider

So, how do we prevent this using the state parameter?

Prevention

The client should create a value that is somehow based on the original user's account (a hash of the user's session key, for example). It doesn't matter what it is as long as it's unique and generated using some private information about the original user.
This value is passed to the service provider in the redirect from step three above
Now, I get you to visit the URL I saved (step five above)
The authorization code is issued and sent back to the client in your session along with the state parameter
The client generates a state value based on your session information and compares it to the state value that was sent back from the authorization request to the service provider. This value does not match the state parameter on the request, because that state value was generated based on my session information, so it is rejected.

Your Questions

Should the randomly generated state be hashed or can same value be stored and sent to OAuth2 provider?

The point is that the attacker should not be able to generate a state value that is specific to a given user. It should be unguessable.

Is there a difference here, if session back-end is secure-cookies or a server-side storage (in GAE Memcache or database)?

I don't think this matters (if I understand you correctly)

Should state be stored as a key as suggested?

I don't know what this means.

Should state has validity period, or session (if there is one) lifetime is enough?

Yes, state should have an expiration. It doesn't necessarily have to be tied to the session, but it could be.


Should API Secrets used for simple authentication be hashed in the database? There was a similar question which I found which was asked the better half of a decade ago "Is it okay for API secret to be stored in plain text or decrypt-able?", but the majority of answers seem to revolve around API security schemes where the secret is used as a key, for example, to produce a hash, in which case the answer is of course that you need to have a full copy of it available.

However, there are other API schemes, if we take a look at Stripe, for example, you can see that essentially the secret is used as a password in a request header:

https://stripe.com/docs/api/authentication?lang=curl#authentication

I have no particular insight into how Strip operates, but there is of course some level of a performance hit if you allow there to be multiple active API keys assuming you use any reasonable hashing scheme.

Now I can think of a way of avoiding this (such as including in the key some sort of identifier which can be used to pull back the specific hashed version), but that doesn't seem to have been done here.

So, is there some reason why you would not need to hash this data? It seems like it is just as important as any password, with perhaps the exception to the fact you know it's not being reused on other websites.

I work for Nike as a penetration tester/adversarial simulation specialist, and we typically will mark API keys that are stored in plain-text as a high/critical vulnerability. Understandably, API keys will have to be stored somewhere in order to be used. Most often we will recommend the following to our stakeholders:

Use strong symmetric encryption to encrypt the key before storing on device. Use obfuscation to make the discovery of the decryption key for the API key more difficult. Limit the functionality and privileges of the API to only do what it needs to do (principle of least privilege: https://en.wikipedia.org/wiki/Principle_of_least_privilege)

These two things when implemented correctly will deter most attackers from getting your keys. But if you do have to store the keys on device for some reason, just know that it is possible for a dedicated attacker to get those keys if they try hard enough.

Lastly, you may consider using something like AWS secrets manager, because it sounds great. Amazon's secrets API must be secure! Wrong, you're still left with the original problem of having to secure an API key. But now the API key you have to secure is an API
master key that will give an attacker access to all your API keys for all your AWS apps. By using secrets manager, you effectively increase the scope that a breach of your API key encryption would have (good for attacker, bad for devs). We see this a lot and always recommend against it.

Finally I'll point you to another Stack Exchange question: Do I need to hash or encrypt API keys before storing them in a database?

I hope these considerations answer any questions you had.


How does Comcast know my WiFi password? How does Comcast know my WiFi password? I generated it via KeePass and entered it into my Arris router/cable modem myself, and I bought the router used from a friend. When I went to the account web page, it showed me my password. I changed the password and it instantly showed the new password on the account web page (after refresh).

https://customer.xfinity.com/#/settings/security

Model:TG862G
Hardware Revision: 5
eMTA & DOCSIS Software Version: 9.1.103M2AM.SIP.PC20.CT
Packet Cable:2.0

I did not install any "Comcast package" or software or wizard setup program.

The PSK passphrase is (by design) stored in a retrievable format by the Modem vendor, in this case Arris, but the same standard is supported by many other modem vendors.  In DOCSIS cable modems this is most commonly done via SNMP against this specific OID:

clabWIFIAccessPointSecurityKeyPassphrase    OBJECT-TYPE
    SYNTAX      SnmpAdminString (SIZE(0..63))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This object is defined in TR-181 Device.WiFi.AccessPoint{i}.Security.KeyPassphrase."
    REFERENCE
        "TR-181 Device Data Model for TR-069."
    ::= {clabWIFIAccessPointSecurityEntry 5

This is part of the CableLabs WiFi MIB, which is is in turn based on the TR-069 sub-standard of TR-181.

Not only does this apply to cable modems, but many DSL and FTTH endpoints will also allow the service provider to retrieve your PSK passphrases and a litany of other settings.

This allows for end users to have their settings backed up in case of a device having to be replaced or much more commonly for call centers to be able to retrieve some of the settings, like the pass phrase, when a customer calls in because they can't remember it.


Whatsapp access to Google Drive I am very concerned today as I discovered whatsapp has access to my google drive.

Does this mean whatsapp can steal my google drive data with this access or is it restricted only to a specific folder?

If you go to Google My Account Permissions and expand "WhatsApp Messenger":

View and manage its own configuration data in your Google Drive
View and manage Google Drive files and folders that you have opened or created with this app

I am not an expert on Google Apps permissions, but the wording would indicate that it is limited to files WhatsApp wrote to Google Drive itself: "opened or created with this app".


how did the meltdown attack break KASLR in 128 steps for a target machine with 8GB RAM with 40bit randomization on a 64bit machine? In the meltdown official paper released the authors broke the KASLR with 128 steps at worse. Unable to understand how did they come down to that number

Paper for reference

KASLR (Kernel Address Space Layout Randomization) is a technique for making it harder for an attacker to exploit a vulnerability that they've found.  Instead of placing kernel data structures in predictable locations, they get scattered around at random, so an attacker needs to spend time looking for their target data before they can use it.

A 64-bit computer has 264 possible memory addresses.  This is far more space than anyone can use right now, so to keep things simple, only a few of the addresses are made available -- for current CPUs, typically 240 addresses.

The number of "bits" of randomization is a measure of how many places there are that something could end up in.  With 40 bits of randomization, that's 1,099,511,627,776 possible locations -- if the attacker is looking for a small piece of data such as the root password, they're probably not going to find it before the attack gets stopped.

In the case of Meltdown, though, the target is "a complete copy of physical RAM".  This occupies a single continuous block that overlaps many of the possible locations that it could be placed at: in the case of 8 GB of RAM, the equivalent of 33 bits worth of locations.  With 40 bits of available addresses, this leaves only  7 bits for randomizing the location.  After at most 27 = 128 probes, the attack has found its target and can start reading memory.


Are there security advantages to adding an OTP to SSH connections? Are there any tangible improvements to gain from enabling TOTP (google-authenticator PAM plugin) over existing public key based SSH connections?

Does it make security sense to enable TOTP based Two-Factor auth for SSH into bastion servers? I get what advantages OTP offers for web applications, but what about SSH? Are there existing examples for infrastructure security that uses OTP that I can learn from?

What advantages do you see with OTP for web applications? Could there be the same advantages for SSH?
So the question is, which threats do you have when using SSH keys?

I think one central threat is, that you can not control or know if a user looses his private SSH key. You can not even know or assure in the first, if the user protects his private SSH key with a passphrase. (unless you are using smartcards for the private SSH key).

So in my opinion, yes, it can improve security to also add OTP to an SSH connection given:

The administrator controlls the creation of the OTP devices and
You are using hardware OTP tokens

In this case

the user can keep up security by protecting his private SSH key (which can not be controlled by the administrator, the company or organization)
the administrator can keep up security by controlling the secure 2nd factor of the OTP token.

I wrote a blog entry about this utilizing privacyIDEA to manage the OTP 2nd factors.


Decryption using GRUB and TPM I'm trying to plan security routine for my new Linux install and few questions came up during searching for solution which meet my needs.

Is it possible to use private key from TPM in GRUB to decrypt /boot partition located on external storage?
Is it possible to use GRUB to decrypt partition located on external storage with keyfiles by entering the password?
Is it possible to use these keyfiles to decrypt internal hard drive?

The TPM support is very rudimentary at this time. You'll need a bootloader that can extend the chain of trust and I only know of TrustedGRUB which is a pretty old version of GRUB with TPM-related functionalities added.

On the other hand, I believe the TPM is just all hype related to Bitlocker, practically it provides very little security (maybe that's by design to please the three-letter agencies?) as the machine now has all it needs to boot and decrypt its content without any other secret, allowing an attacker who stole the machine (even off) to boot it and then attack it with DMA or cold-boot attacks to retrieve the keys. TPM doesn't protect against that. Also, a theoretical attack I always think about is to simply sniff the low-speed serial bus the TPM is attached to and wait for it to transmit the encryption key. Only requires some wires to solder on the board, very easy and doesn't require expensive equipment.

An USB flash drive + keyfile/password would be way safer as the material needed to unlock the machine is now separate from it, if the computer is stolen off it's essentially an useless brick, there is absolutely nothing on the machine that holds the key.

Now, to answer your specific questions.

1) No, some unencrypted code has to be run before an encrypted partition can be decrypted and mounted, so the /boot, no matter where it is, should be unencrypted. The firmware (BIOS/UEFI) itself has no support for encrypted filesystems. Also, in case of disk encryption we're using symmetric crypto, so there is no notion of public key and all the TPM does is check if the data supplied to it (hashes of every component executed thus far and their configurations, so the firmware, its configuration, the bootloader, etc) and gives back a data block if the hashes match when the TPM was "sealed". This data block is the decryption key.

2) First, GRUB doesn't do encryption. The Linux kernel handles the crypto, which means everything before the kernel should be unencrypted. Finally there is no way to require both a password and keyfile with LUKS, but you can encrypt your keyfile with some program (GPG?) which you bundle into the (unencrypted) initrd and call it before passing the (decrypted) keyfile to LUKS to continue booting.

3) Sure. LUKS allows to transparently encrypt a block device by exposing its unencrypted version as a separate device node, so the system uses that instead of the real block device which now contains encrypted data. Whether it's an internal device, external, or some voodoo magic like an disk image file from an NFS server mounted as a loop device with LUKS on top, it'll work just as well (performance not guaranteed for the last one though). Whether you use keyfiles or passwords doesn't change anything either.


Is an attacker looking at encrypted non-boot partition able to tell if this is VeraCrypt, TrueCrypt or DiskCryptor? In theory an encrypted partition WITH encrypted partition header as created by mentioned encryption software, should be nearly random-looking.
But maybe there are some clues, like offsets, double backup data.
This question is important, because I want to know if revealing that a specific disk has been encrypted with one of those software is lowering the security and attacker's effort or not. One also wouldn't want to potentially make an attacker weary by giving him false or vague information which he could prove to be false.

No.

An attacker can not distinguish between VeraCrypt and TrueCrypt.
The reason for this is that they both share the volume format and guarantee a completely random looking container.

Concerning DiskCryptor, which seems to be an earlier fork of TrueCrypt, it looks like the header is also random-looking. The only difference may be measured if the drive is mounted, as the size of the volume, as TrueCrypt uses larger headers than DiskCryptor.

So by an offline attack no difference can be measured.


In client side certificate authentication why, if, do we need to share the certificate Certificate authentication on https has always been one of my huge knowledge gaps ,and was trying to fill it today.

I have made some progress on the client side certificate authentication but however there's some fundamental question that can't get my head around.

I have worked with third parties that use to send the certificate (and passphrase) over and then we were able to start using their services. Unfortunately I wasn't involved at all in the process so not even sure if it's my misunderstanding. Assuming that was correct, please let me know if not, my questions are

Do you exchange the pfx, with the private key as well as the certificate?
If I had a certificate signed by a trusted CA why not just send that one and the server would just need to validate it? is the case that the exchanges certificates are ad-hoc ones and they just need to validate it's issued by them?
Is this exchange where the Certificate Signing Request can be used?

I understand the question is both simple and vague but can't really see the use case of this exchange, from what I have been reading for a while

Thanks

Do you exchange the pfx, with the private key as well as the certificate?

Only the client certificate is provided to the server. And the client proves to the server that it has access to the private key by signing some data which are at least in part provided by the server. This is actually very similar to how it works with the server certificate.

  If I had a certificate signed by a trusted CA why not just send that one and the server would just need to validate it? is the case that the exchanges certificates are ad-hoc ones and they just need to validate it's issued by them?

"Trusted CA" is what the server considers as trusted for the authentication of the client. This often does not mean that the certificate was issued by a publicly trusted CA as is preinstalled in the systems but by a private CA which the server considers as trusted for the purpose of client authentication.

  Is this exchange where the Certificate Signing Request can be used?

A certificate signing request (CSR) is used when applying for a certificate. In case of a private CA trusted by the server you need to send your CSR to this private CA which then issues a certificate based on the CSR. Note that using a CSR is not mandatory. Instead it might be that you just get issued a personalized smartcard with a certificate (and the matching key) already on it without creating a CSR.


Is there any risk of login information being compromised after submitting a Firefox crash report? Title says it all. I have crash reports specifically disabled and yet the browser submitted one anyway. What's the risk of login information (in particular: saved login info, open sessions in online services) being compromised? Is there any way of getting Mozilla to delete a crash dump?

Some advice for everyone else running Firefox: delete crashreporter.exe from the Firefox directory, that thing is dangerous. There is no legitimate reason to send any such information when the end-user has taken every step to say "No". I was never prompted to send any crash report, the browser just sent it automatically despite having opted to disable them in the Settings.

It is very unlikely that you gave away compromising information. Your active logins, cookies, search history and the content of your visited websites are safe. Presumably, the most relevant sensitive information in your case is the last visited URL (which you had to explicitly agree to submit).

Also note that Firefox doesn't submit crash reports without your consent. In the Mozilla docs you can find details on how the Mozilla Crash Reporter works and how you can understand crash reports.

What does a crash report contain?

A Firefox crash report contains information relevant for debugging such as:

Browser version
Installed extensions
Operating system version and  configuration
Stack trace of the crash (involved modules, functions, etc.)

You can optionally include the URL of where the crash has occurred and a contact email address.

Where can I view my previous crash reports?

You can view your crashes from inside Firefox at about:crashes or locally at ~/.mozilla/firefox/Crash Reports/. All submitted Firefox crash reports are published on crash-stats.

Who else can view a crash report?

Everyone is able to view a basic version of your report but only few users can see sensitive details.

  Some fields, such as "URL" and "Email Address", are privacy-sensitive and are only visible to users with minidump access.

(Source)

So even if you submitted the URL - it's not public, developers will probably never read it given the total amount of crash reports, and nobody will know it was you.


security for intranet applications If an application is intended to work only on a machine which is NOT connected to the internet BUT stores extremely confidential information, should we implement same security policy as if it was intended to be exposed to the internet? I'm about to conduct a pentest / audit and thinking what recommendations should be written for such application and how strict should they be.
What can (if this is relevant) be ignored in terms of  security for an intranet application?

A computer "NOT connected to the internet" is somewhat of an oxymoron nowadays. It may not be exposed directly on the Internet, but it is very likely part of a LAN and in that same LAN there are other computers with access to the Internet...

So, if a computer in that same LAN is compromised, it can be used as a stepping-stone to that machine holding sensitive data. Put it differently, it is indirectly reachable from the Internet.

Even if you can isolate it from the network completely (which is rarely practical) you still have to factor access controls, physical security, internal actors etc.


How to read memory from format string exploit correctly I'm trying to solve a problem on format string exploitation in which I have to overwrite anything in a specific address. Since the target address has a null byte at the begining, I need to write it at the end of the format string, and I want to locate where the last 4 bytes of my format string are, so I just made some format strings like
"%08x " * whatever_integer + "AAAA"

until I find some memory leak of the form 0x41414141.
However, I don't get the right output of my "AAAA" always. For example, if I use a factor of 35, I get the following:
$ ./format-two "`python -c 'print "%08x " * 35 + "AAAA"'`"
Welcome to phoenix/format-two, brought to you by https://exploit.education
00000000 0000004d ffffe83b 01010101 ffffe49f ffffe4e0 ffffe4e0 ffffe5e0 00400705 ffffe638 00400368 78383025 30252078
20783830 38302520 25207838 78383025 30252078 20783830 38302520 25207838 78383025 30252078 20783830 38302520 25207838
78383025 30252078 20783830 38302520 25207838 78383025 30252078 00414141 00000000 AAAABetter luck next time!

As it can be seen, I only get three 0x41, so one of them is missing despite the fact that it should be in a contiguous memory location. If I repeat the process with a factor of 40, suddenly it behaves as expected:
    $ ./format-two "`python -c 'print "%08x " * 40 + "AAAA"'`"
    Welcome to phoenix/format-two, brought to you by https://exploit.education
    00000000 00000034 ffffe822 01010101 ffffe48f ffffe4d0 ffffe4d0 ffffe5d0 00400705 ffffe628 00400368 78383025 30252078
    20783830 38302520 25207838 78383025 30252078 20783830 38302520 25207838 78383025 30252078 20783830 38302520 25207838
    78383025 30252078 20783830 38302520 25207838 78383025 30252078 20783830 38302520 25207838 41414141 00000000 00000000
    00000000 AAAABetter luck next time!

Why is this happening? Is there an exact way of using format strings such that memory is printed correctly?

The answer is simple: your %08x  are also in memory!
Did you try decoding the section before the AAA in memory (78383025 30252078 20783830 38302520 25207838 78383025 30252078 00414141)? It's something like 0% x x8080% % x8x80%0% x.AAA after hex decoding. The memory output here is aligned by 4 bytes, but you chose to write 35x5 bytes before your A's, which is 175; 4 does not go evenly into 175. For your second attempt, you did 40x5 == 200, which does evenly divide by 4, hence the correct alignment in your output.
As far as the missing 0x41 goes, I suspect this is a 64-bit system and you are only printing 4 bytes per every 8, so one of them simply isn't being printed. If this is a 64-bit system and you are trying to print the whole 8 bytes, I suggest using %p instead of %08x as a format specifier.


Did I just get DNS Hijacked? I went online on my Macbook today and noticed my iTunes complaining that it couldn't connect to Apple, I tried logging out and in of my account but weirdly it said it couldn't log in; I didn't think much of it at first as I thought maybe it was iTunes just being more buggy than usual.

However then I noticed something really weird, when I tried to visit www.apple.com my browser warned me (Google Chrome) saying this website was not secure. This started ringing alarm bells in my mind, I clicked "Continue Anyway" and was greeted with this page:

Being (somewhat of) a web designer/developer I pay attention to the little details on a website and I knew instantly this was not what the Apple homepage looks like, and they certainly didn't prompt you to login on their homepage. I dug in a little deeper to the source code for the page and could see that the source code was way too simplified for a large corporation; the only piece of JS was to verify that the email address was in the right format.

I began to suspect maybe my Mac machine had been infected, so I switched to my iPhone (on the same WiFi network), tried www.apple.com, and got shown the exact same page.  To me this sounded like something to do with DNS as the chances that both my devices were infected were very unlikely.  I then turned to my router to have a look at its settings.

Lo and behold, when digging into the DNS settings I could see that the  settings looked a little odd. I had initially set my DNS settings to use Google's servers, although this was set many years ago I knew the were something along the lines of 8.8.*.*.

In my settings however I found the following IP's:

Primary: 185.183.96.174
Secondary: 8.8.8.8

I knew straight away that the DNS had been changed, the primary address should have been 8.8.4.4.  No one has access to my router administration page aside from me on the network, and I have disabled access to the router outside of the local network I can see outside access was enabled, on initial setup this was definitely switched off.

My question is: "How could the DNS have been changed/What can I do to prevent this from happening again?

I try to keep my router firmware up to date (although I was maybe 1 release behind at the time of this post).

More about the phishing site:

Before I changed the Primary DNS setting back and I wanted to find out more about this phishing site, so I ran ping apple.com to find the IP address was 185.82.200.152.

When I entered this into a browser I could see that the person had created a number of sites to try and capture logins.  I suspect they're based in the US; I don't believe Walmart operates outside of the states (at least not in the UK).
I have reported the IP to the Dubai based web host and am waiting for a response.

Edit (Router details):
Asus AC87U, FW Version 3.0.0.4.380.7743 (1 release behind)
I did not have the default passwords set.

Second update:
Host has suspended the account.

Yes, your router's primary DNS entry was pointed to a rogue DNS server to make devices in your network resolve apple.com and other domains to phishing sites instead. The router possibly got compromised through an unpatched vulnerability in its firmware.

  I have an Asus AC87U, FW Version 3.0.0.4.380.7743 (1 release behind).

Your release is over half a year old. The latest release 3.0.0.4.382.50010 (2018-01-25) comes with lots of security fixes, including RCE vulnerabilities which may have been exploited here.

  Security fixed

  Fixed KRACK vulnerability
  Fixed CVE-2017-14491: DNS - 2 byte heap based overflow
  Fixed CVE-2017-14492: DHCP - heap based overflow
  Fixed CVE-2017-14493: DHCP - stack based overflow
  Fixed CVE-2017-14494: DHCP - info leak
  Fixed CVE-2017-14495: DNS - OOM DoS
  Fixed CVE-2017-14496: DNS - DoS Integer underflow
  -Fixed CVE-2017-13704 : Bug collision
  Fixed predictable session tokens(CVE-2017-15654), logged user IP validation(CVE-2017-15653), Logged-in information disclosure (special
  thanks for Blazej Adamczyk contribution)
  Fixed web GUI authorization vulnerabilities.
  Fixed AiCloud XSS vulnerabilities
  Fixed XSS vulnerability. Thanks for Joaquim's contribution.
  Fixed LAN RCE vulnerability. An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure
  Disclosure program
  Fixed remote code execution vulnerability. Thanks to David Maciejak of Fortinet's FortiGuard Labs
  Fixed Smart Sync Stored XSS vulnerabilities. Thanks fo Guy Arazi's contribution.
  -Fixed CVE-2018-5721 Stack-based buffer overflow.

(Source)

Although Asus doesn't publish bug details, attackers may have independently discovered some of the vulnerabilities patched in that release. Diffing firmware releases to reverse-engineer what parts were patched is usually quite straightforward, even without access to the original source. (This is routinely done with Microsoft security updates.)  Such "1-day exploits" are comparatively cheap to develop.

Also, this looks like it's part of a more wide-spread recent attack. This tweet from three days ago seems to describe an incident very similar to what you experienced:

  My ASUS home router was apparently hacked and a rogue DNS server in Dubai added to the configuration. It redirected sites like http://apple.com  to a phishing site that (I think) I caught before my children gave away their credentials. Check your routers kids.

(@harlanbarnes on Twitter, 2018-03-09)

  [...] my browser warned me (Google Chrome) saying this website was not secure. [...] I began to suspect maybe my Mac machine had been infected [...]

The fact that you got certificate warnings makes it less likely that an attacker managed to get into your machine. Otherwise, they could have messed with your local certificate store or browser internals and wouldn't need to conduct a blatant DNS change.

  No one has access to my router administration page aside from me on the network

Even if your router interface isn't visible from outside your network, it can be vulnerable to a range of attacks. As an example, take this Netgear router arbitrary code execution exploit from a while ago which had Netgear routers execute arbitrary commands sent as part of the URL.

The idea here is to trick you into visiting a prepared website that makes you conduct the attack yourself by issuing a specially crafted cross-origin request to the router interface. This could happen without you noticing and wouldn't require the interface to be remote accessible.

Ultimately, the given information doesn't reveal the exact attack path. But it's plausible that they leveraged vulnerabilities in your outdated firmware release. As an end user you should at least update your firmware as soon as possible, do factory resets if necessary, and keep your router interface password-protected even if it's only accessible from the intranet.


How secure is full-disk encryption technology on LineageOS, or Android phones in general? We're attempting to assess the information security on our mobile devices, and information seems rather varied on the question of encryption. Is the encryption technology employed by Android-based phones uniform, and is it secure? I'm also particularly interested in protection from any malicious attackers who may have a decent amount of computing power at their disposal.

As per this question, my impression seems to be that any phone that comes with standard Google-linked (and likely, manufacturer-linked) Android is entirely vulnerable to being unlocked by Google. Do encrypted phones with LineageOS (which I realise has a lot of versions, but in a general sense, at least) use a secure full-disk encryption without backdoors? Or do they at least securely encrypt all user data?

There's clearly some basic security, as my vague attempts to gather any information off a LineageOS phone without unlocking it hasn't gotten anywhere. But again, I can't find great wells of information on the matter, and I realise LineageOS is open-source, though, so surely a knowledgeable attacker could work out what needs doing without too much effort.

Is encryption on standard-Google-android phones secure? Is the encryption on an up-to-date LineageOS install more or equally secure? Are there any better ways to encrypt phone data such that knowledgeable attackers would have a hard time gather any actual data?

Simplified Explanation
Both Android and Lineage use the same encryption. Both are secure enough against the threats it is designed to protect against. Specifically, an attacker with physical access to a powered-off phone.
Bad analogy time:
Think of device encryption like a document safe. You have the only key.
Think of the lock screen like the security guard you hire to keep people away from your safe.
If an attacker wants to read your documents, if your safe is locked, the security guard is irrelevant. There is no way for them to get into the safe to get your documents. This is when your phone is powered off.
When you go to read your documents, you send your security guard off for lunch, as you are watching after the safety of your documents now. You use your key to unlock the safe. Now you can read your documents. This is when you are actively using your phone.
You have a full work day ahead of you. You step away from the room, leaving the safe unlocked. In a few minutes, the security guard comes back. They will prevent anyone else from getting into the room. This is when your phone is turned on but locked with a lockscreen password.
Your security guard gets a call from their boss. There is a search warrant out for the contents of your safe. They are instructed to allow the police into the room with the safe and keep you out of it. This is Google or other device management software remotely unlocking your phone or even changing the lockscreen password.
They could even remove your documents from the safe, putting them into a new safe, just in case you manage to come back and attempt to lock your safe again. This is Google changing or removing your encryption password, which you will note is only possible because the safe was already unlocked. Had you locked your safe/encrypted your phone, they would need your key, which only you have, to do anything.
A Little More Detail
If I remember correctly, and if it has not changed since I learned about it, the device encryption key is randomly generated and actually stored on the device. This encryption key is then itself encrypted using a mix of your supplied password/PIN/pattern and some device-specific hardware-backed information that is hard to access without destroying the device (and hopefully the data as well). When you turn on your phone, you supply the password to Android, which lets Android decrypt the encryption key, which it can now use to decrypt your data as needed, until you power off your phone again.
Modern Android devices come already encrypted. They use a hard-coded default password mixed with the device-specific stuff to encrypt the encryption key. This lets you use your phone right away out of the box without entering a password. It also lets you set your own password without waiting for all the 128+ GB of data on your phone to be re-encrypted with a new key; the same key is used for encryption, that has not changed, you just re-encrypt the key itself with a new key.
Since the encryption key is already decrypted while your device is powered on, it is easy for Android to just re-encrypt that key whenever it needs to, with a new password, or with the default password again. This is exactly what happens when you change your password, when you enable an accessibility service, or theoretically when Google gets a lawful order to do so (I have not heard of this last one happening). The lockscreen is only software-enforced, if someone has control over the software running on the device, it could easily be bypassed. There are occasionally software bugs (especially in unofficial Android ports like Lineage that mess with the lockscreen behavior) allowing lockscreen bypass without any special access. Without those bugs, or if the phone is off (the encryption key is still encrypted), either special software must already be present on the device, or an automatic update must push such software without user intervention to allow access.
Here Lineage and similar ROMs provide a trade-off:
With Lineage, assuming you do not have Google's services installed (or any other software with similar access or exploitable bugs), there is not any preloaded software or automatic update mechanism that would allow lockscreen bypass or changing encryption passwords. The security guard does not have a phone, so they never get the call to allow the police inside. However, with Lineage you must unlock your bootloader to install Lineage in the first place.
Back to the bad analogy: a locked bootloader is like tamper-proof features on the safe that automatically incinerate the contents if someone removes them. The tamper-proof features prevent affixing anything to the lock, so an attacker cannot attach a device that captures a mould of your key when you insert it, or fit it with some automated system that can somehow try keys much faster than a person casting one key after another and trying each manually (ok, the analogy is stretched to its limit here).
When you unlock your bootloader, all your data gets wiped. But the phone simply will not run any software other than from Google or your device manufacturer, unless the bootloader is unlocked. An attacker probably would love to install a low-level keylogger or a password brute-force cracking program that runs before you even enter your password, but cannot, because the bootloader is locked. If they unlock it to install their software, the data they wanted is now gone. So, they're limited to manually entering one password after another, and can't really speed things up.
But Lineage requires an unlocked bootloader. An attacker with physical access could reboot to "recovery" (the same method used to install Lineage) and then install whatever they want without decrypting your phone first. Then they can either give your phone back and capture your password when you enter it, or brute-force your password in software, guessing thousands or more per second instead of one every few seconds.
If you have a strong password (unlikely for most people, because it's a phone) you'll still be fine. If not, Google as a potential adversary may be preferable.
Note: it is actually possible to have a separate lockscreen password compared to your encryption password. There isn't a UI for it in the system settings (Lineage removed their UI due to flaws in the implementation a while ago), and it may not be possible on "stock" Android at all, but it's technically supported. This might make using a strong encryption password less onerous.
Update: File-Based Encryption
All the above was written with "full-disk encryption" (FDE) in mind. Older versions of Android used FDE, where after rebooting, you could not unlock and use your phone at all until you entered your password or PIN. But, newer Android devices almost universally use "file-based encryption", or FBE. With FBE, your phone boots all the way to Android's lock screen, where you can make and receive calls and see a few notifications before ever entering your PIN. This complicates the situation quite a bit, because the idea of FBE is that only certain files get encrypted with secret data: many of the files on the phone–specifically all files required to boot, make phone calls, and some other tasks–are left unencrypted, or encrypted only with data saved on the device and accessible to Android without user input (I'm not 100% clear on whether it is fully unencrypted or encrypted in an accessible way). In particular, if you're using an SD card with "adoptable storage", the SD card encryption key is available at boot without user interaction. Adoptable storage has been removed from many stock Android ROMs because it renders the SD card usable only on the device where it was formatted (which apparently confuses a lot of users), but is still present as an option in Lineage OS.
Revisiting the analogy, FBE is like you only keep a few of your documents in the safe. The rest of your documents are left lying around the room and rely fully on the security guard to keep away from prying eyes. You even have a locked file cabinet for some documents that won't fit in your primary safe (your SD card), but you leave the key for the file cabinet on a hook on the wall, rather than in the secure safe for which you keep the key.
Unfortunately it can be difficult to know which documents are kept in the safe and which are left out on the table.
FBE adds another trade-off to installing Lineage. In stock Android, there are normally no built-in features that allow ADB or any other methods to get files off the device until the device is successfully booted. While it may be possible for well-funded experts to do so, there are no official features allowing it, so your average petty criminal will not be able to get your data even if it happens to be one of the files FBE does not fully secure. Lineage and other ROMs are often installed with a special "recovery" image that allows filesystem access as a built-in feature. Even if you use a recovery without full filesystem access, such as Lineage's recovery, with an unlocked bootloader (back to that again) an adversary could easily boot whichever recovery they choose and access your filesystem that way. Thus adoptable storage and any other files not fully protected with encryption under FBE are more at risk with Lineage than with a stock Android image, which may outweigh the risk of those files actually protected by encryption under FBE from being compromised by backdoor access from Google or your phone manufacturer while your phone is already unlocked (e.g. in response to court orders).
All of this discussion is relevant only to the scope in which device encryption is intended to protect your data: i.e. when an attacker gains physical access to your locked device. There may be other security considerations that weigh into a user's decision to install a custom ROM, e.g. for out-of-support devices Lineage may provide protection from known network-exploitable vulnerabilities that have since been fixed by Google. But that just means there are more things to weigh against the trade-off in the security offered by device encryption.


Is it secure to share an access token via HTML5 messaging API between various iframes? I have a main website that embeds 3 other websites via iframes (legacy systems providing various functionalities with a user interface). Currently the user has to authenticate with each of the system despite that they are all using the same authorization server. In order to make it user-friendly I was thinking to share the access token across the various iframes using the HTML5 messaging API and I was wondering whether this approach is viable from a security point of view?

The postMessage API  is designed for cross domain communication as part of the Cross Origin Resource Sharing mechanism.
The Window.postMessage() method, introduced in HTML5, allows JavaScript code running on different origins to communicate with each other in a bidirectional manner. This API can be used for communication between an iframe and its parent document. Similarly, it can be used by an HTML page and a child window to exchange messages, such as an embedded third-party video notifying its parent frame when the user pauses the video.
The classical rules of security also apply to applications using postMessage(). You are planning to use this method for sharing authentication information which is perfectly fine if you you follow basic input validation rules while implementation.

Never broadcast your auth tokens: Your scenario contains multiple different parties who need to have access to a common token. you might be tempted to broadcast the authentication information so that all the iframes get access to it. This may result in unauthorized access to your tokens. Hence the postMessage() call should always specify the target origin.

Always validate message origin:  You need to validate that the message has been received from a valid and expected origin. Only after origin validation you should proceed with using the message in the application logic. Imagine a case where your app is iframed by a malicious domain. If you do not validate the origin of the message it may result in script injection.

Additionally, depending on your trust relationship with the authorization server, you may want to validate the token itself once the sender origin is validated.
For a more detailed analysis of postMessage() API security along with a few example code snippets, refer to my Blog


Implications of the proposed Burr-Feinstein senate bill? It has been rumoured (I guess it is more than a rumour) that senators Burr and Feinstein will be introducing legislation requiring companies to provide the government (with warrants) access to encrypt material. So, one could maybe expect the government to require that companies keep a masterkey that can unlock all encryption. We don't have the exact language of the bill yet, and the White House might even oppose the bill already.
But, I am a bit confused about the implications of such legislation. While I understand that one can require Apple, Facebook, Google, etc. to basically implement backdoors in the encryption scheme, what would such a policy mean for encryption?
Would it, for example, be reasonable to assume that such legislation would basically ban strong encryption? There are so many programs out there that has implemented various strong algorithms (like PGP). Is the consequence of such legislation only that the default encryption used on, for example iPhones will have a backdoor?
Is it even practically possible to outlaw all strong encryption?
To be clear, I am not asking about whether or not one should support such restrictive measures. I am only interested in what the implications of such legislation would be.

I think the really interesting implications are when you look outside the US. Once the mechanism is in place to legally request a key or decrypted content, the other countries where affected companies do business are going to require the same thing.

The method used to provide decrypted content will impact what happens next.

If the company keeps its keys secret and decrypts user content on request, you'll end up with a situation where the company is required to respond to decryption requests from all sorts of foreign agencies, and some of those will probably be for devices belonging to citizens of the company's own country.
If the key itself has to be provided, and the company only maintains one master key for all its products, then you have a situation where governments have the ability to decrypt devices belonging to foreigners (including, say, government officials or C-level executives)
If the key itself has to be provided but there are separate keys (either per-device or localized to a country) then in order to preserve their ability to read their citizens' devices, countries would have to make importation of encrypted devices illegal (and, practically, you end up with a situation where the "bad guys" (like terrorists and secret agents) just import phones illegally and have perfect encryption and only the "good guys'" devices can be decrypted). To allow legal travelers to bring their devices into the country, you may also need to create a key management system to import into or retrieve keys from each device (and of course, "you must run this program on your computer to be allowed entry into our country" has additional implications).


Best way to administer all my passwords I am trying to figure out what  the best solution is to store  different types of passwords:

Personal passwords (my personal email, my company's email, all the services I use to buy things like Amazon, etc.)
My business passwords (all the tools used to run my business, harvest, Google apps, slack, deploybot, etc.)
My client's passwords, their own services which they sometimes share  with me to use (like Amazon AWS, some email account they create for me, some other tools they use like Salesforce).

I know that probably I won't find one tool to rule them all, but I would like to hear your advice or experiences to deal with this same situation.

EDIT:

After more than 3 years of my original question, I would like to say that I am using LastPass as recommended by @dotancohen and it really solves most of the use cases I described, even on the free account.

The easiest way would be using several databases. Tools like KeePass allow you to store passwords in different files. You could for instance opt to store your passwords in seperate databases based on client or purpose.


What are eligible service providers for SAQ-D in PCI DSS? PCI SSC specifies that Self-Assessment Questionnaire D can be used by "eligible" service providers (source):

  Questionnaire D. For Service Providers: All service providers defined by a payment card brand as eligible to complete a Self-Assessment Questionnaire.

How can one identify whether service provider is SAQ-D eligible or not?

Only Level 2 Service Providers are eligible to use the Self-Assessment Questionnaire.  As PCI Policy Portal summarizes, these are defined as:

  [Level 2] Service Provider Criteria for VISA: Any service provider that stores, processes and/or transmits less than 300,000 Visa
  transactions annually.
  [Level 2] Service Provider Criteria for MasterCard: (1). Includes all DSE’s that store, transmit, or process less than 300,000 total
  combined MasterCard and Maestro transactions annually.

Additionally, American Express defines Level 2 Service Providers as "less than 2.5 million American Express Card Transactions per year; or any Service Provider not deemed Level 1 by American Express."

In practice, you will rarely see a Service Provider - even a Level 2 - using an SAQ. They don't get a heck of a lot of respect out of QSAs, and QSAs are the ones deciding how hard to look at a given merchants' chosen Service Providers.


Keepass Dictionary Attack Protection Strategy Though pretty interested, I'm everything but an expert in Information Security, please redirect me to any helpful resources if my question is stupid or correct me if my assumptions are wrong.
When reading through the Keepass Security page it seemed to me that the workflow of generating the password that's actually used to encrypt the kdbx file from the user-entered password (assuming no keyfiles or Windows user account is used) is as follows:

Take user-entered password and hash it (SHA-256)
Generate random password/retreive it from kdbx file
Encrypt the hash from 1 N times using the key from 2
Hash the output of 3 using SHA-256 again

Then, the output of 4 is the key to be actually used to encrypt the database.
What I'm wondering about is: Why the hassle with the key stored in plain and encryption? Why not just omit steps 2 and 3 and hash the user-entered password N (or maybe C*N, with C being the time relation between AES-encrypting and SHA-256-hashing) times? I'm pretty sure I'm overlooking something important here and I'd be grateful if you could enlighten me.

[Disclosure: I work for AgileBits, the makers of 1Password]

I may have my history wrong here, but I believe that KeePass is designed to work with PasswordSafe databases, and that PasswordSafe was designed prior to general adoption of PBKDF2. So what we are seeing here is a "home grown" approach to do the job that PBKDF2 was designed to do. (And of course PBKDF2 isn't ideal, which is why the world is seeking a successor).

The choice of AES (in KeePass) over HMAC (as is typically used in PBKDF2) for as the PRF for each round isn't really a big difference, as both are PRFs. Indeed, PBKDF2 could be used in such a mode (though I've only ever seen it used with HMAC).

It is interesting to note that both schemes suffer from the issue of using a constant key/salt for the PRF. This is now recognized as a (small) problem (among larger one) with PBKDF2.

So off of the top of my head and based solely on your description above, I don't see that scheme as being any worse (though also little better) than PBKDF2. It isn't as general as PBKDF2 in terms of flexibility in the size of derived keys, but that is probably a good thing. Other than that, it appears (again, just from a casual glance) to be very like PBKDF2-HMAC in its strengths and weaknesses.

Over the years, I've gone from describing PBKDF2 as "Peanut Butter Keeps Dogs Friendly, too" to "People's Babies Keep Dingos Feed, too". Despite this, we still use it (carefully) in 1Password, but we are eagerly awaiting a successor to PBKDF2, scrypt, and bcrypt.


What is Return-Oriented Programming? With return-oriented programming, when we fill a buffer with the stack contents (arguments and return addresses) for the function calls we plan on "injecting," how do we actually change the stack pointer to point to this buffer before we start our attack?

Can anyone properly explain what Return-Oriented Programming is?

The video @schroeder linked too is great. Maybe you need a simpler explanation though.

Data execution prevention is software or hardware that monitors the location of executable code in memory. It is useful because if you ran malicious code from a part of memory reserved for trusted programs, it would be harder to detect. Windows keeps track of memory to prevent that from happening, so in most cases it is the data execution prevention.

Return Oriented Programming is exploiting a trusted program to execute malicious code from memory in order to evade the data execution prevention in Windows or whatever OS you use.

Windows will say some parts of memory are only for non executable code, which means the code there will not be treated as instructions by the processor. ROP uses the Windows API to make the section of memory with the malicious code executable, so it will be ran by the processor.


Can I hide torrent details from my ISP? I admit that I know very little about torrents. There seems to be very little point in encryption them as an ISP can detect the torrent protocol and a user might then have some explaining to do (which a search of their PC might make difficult).

My question (which shows how little I know of torrents) is this - for HTTP one can have end to end encryption, using a service such as JAP which hides the requested URl from the ISP.  Is there an equivalent for torrents? Is that what VPNs do?

If one was looking for a VPN, where would one find one which is fast, keeps no logs, has a track record of several years, and is preferably located offshore & has never revealed any details of its users?

Yes, a VPN would mask your HTTP requests as they would be routed through the tunnel. Unless your ISP is somehow exploiting a weakness in the VPN protocol and decrypting the traffic, they would not see the requests.